Назад | Перейти на главную страницу

Что произойдет, если я не установлю свой реальный первичный DNS в качестве записи SOA в скрытой первичной настройке?

Я хочу настроить скрытый первичный DNS-сервер, т.е. я размещаю файлы зоны на своем собственном сервере, но все запросы должны поступать на вторичные DNS-серверы, размещенные выделенной DNS-компанией. Мой собственный DNS-сервер не должен использоваться рекурсивными преобразователями или конечными пользователями. Указанная компания скопирует файлы зон с моего сервера с переносом зоны. В идеале никто даже не должен знать, что мой сервер существует в этой настройке DNS.

Конечно все NS записи в такой настройке будут указывать на серверы имен DNS-компании. Но я не уверен в SOA запись.

Насколько я понимаю, эта настройка будет означать, что мой сервер является «началом полномочий», и поэтому мне придется указать его в SOA - что сделает общедоступным, что мой сервер является настоящим основным сервером. В соответствии с еще один ответ на serverfault MNAME должен быть установлен на "the <domain-name> сервера имен, который был исходным или основным источником данных для этой зоны ".

Если это возможно без особых проблем, я бы предпочел не указывать свой NS-сервер в SOA, а вместо этого указывать SOA на мою хостинговую компанию сервера имен.

Каковы будут последствия, если я на самом деле установлю company.example.com как SOA вместо моего собственного сервера myserver.example.org?

Использование внешних серверов имен (из другого домена) не является нарушением стандарта DNS, но это не похоже на скрытую первичную конфигурацию. NS дан как первичный в SOA должен быть в пределах NS записей, но на самом деле это не означает, что серверы должны быть настроены так, чтобы первичный сервер, представленный миру, был фактическим исходным источником данных.

Это могло бы, например, быть тем, что вы не хотите открывать миру первичный сервер с вашими личными ключами DNSSEC. Это особенно полезно, если публично объявленный первичный сервер имеет другие функции, которые может быть легче взломать, например некоторые веб-приложения.

Возьмем пример. Конфигурации предполагают BIND.

$ORIGIN example.com.
@       IN      SOA     ns1.example.com. hostmaster.example.com. (
                        2020053100 ; serial
                        7200       ; refresh (2 hours)
                        3600       ; retry (1 hour)
                        604800     ; expire (1 week)
                        86400      ; minimum (1 day)
                        )
@       IN      NS      ns1.example.com.
@       IN      NS      ns2.example.com.
@       IN      NS      ns3.example.com.

ns1     IN      A       192.0.2.10
ns2     IN      A       198.51.100.20
ns3     IN      A       203.0.113.30

  • Скрытый мастер не указан в зоне.

    • Этот сервер находится только в частной сети и имеет IP-адрес. 172.16.10.40.
    • Этот сервер подписывает DNSSSEC, поэтому я использовал example.com.signed.

    • Он настроен как мастер для example.com, разрешая передачу зон с общедоступного первичного сервера, но только с использованием LAN (или это также может быть VPN). 

      zone "example.com" {
    type master; 
    file "/etc/bind/db/example.com.signed";
    allow-transfer { 172.16.10.20; };
    notify explicit;
    also-notify { 172.16.10.20; };
};

    • Уведомление настраивается вручную с помощью notify explicit & also-notify, так как notify yes будет уведомлять только серверы, указанные как NS кроме того, который указан как основной в SOA. Это просто не сработало бы из коробки.

  • Общественные первичные сервер ns1.example.com

    • У этого сервера два IP-адреса: общедоступный. 192.0.2.10 и частный 172.16.10.20.

    • Это настроен как раб для зоны и позволяет передавать зоны от другого NS:

      zone "example.com" { 
    type slave; 
    file "/etc/bind/db/example.com"; 
    masters { 172.16.10.40; };
    allow-transfer { 198.51.100.20; 203.0.113.30; };
    notify yes;
};

  • Общественное вторичное серверы ns2.example.com & ns3.example.com.

    • В этом примере эти серверы находятся в другом месте, обеспечивая как обязательный сетевое разнообразие и геологическая избыточность.

    • Эти серверы выполняют передачу зон с публичного первичного сервера.

      zone "example.com" { 
    type slave; 
    file "/etc/bind/db/example.com"; 
    masters { 192.0.2.10; };
};