☰

Запись NS в файле зоны bind9

tag-icon • tag-icon domain-name-system bind
Запись NS в файле зоны bind9

Сегодня я столкнулся со странной ситуацией.

Обычно, когда мы настраиваем запись зоны bind9, мы устанавливаем запись NS, такую ​​же, как наш ORIGIN. Однако сегодня я нашел одну рабочую настройку bind9 на производственном сайте, в которой запись NS указывает на другой домен:

[data/cat_com.zone]

$ORIGIN cat.com.
$TTL 600
@       IN      SOA     ns.tree.com.    hostmaster.cat.com. (
                        2015030200
                        21600
                        3600
                        604800
                        86400 )

        IN      NS      ns.tree.com.
        IN      NS      ns2.tree.com.
        IN      MX      10      cat.com.

ns      IN      A       1.2.3.124
ns2     IN      A       1.2.3.124


host19  IN      A       1.2.3.66

И в записи tree.com: [data/tree_com.zone]

$TTL 600

@   IN  SOA ns.tree.com. hostmaster.tree.com. (
      2015030200 ; serial
      28800 ; refresh
      7200 ; retry
      3600000 ; expire
      86400 ; default_ttl
      )
@   IN  NS      ns.tree.com.
@   IN  NS      ns2.tree.com.
@   IN  MX  10  mail.tree.com.



tree.com.              IN  A 1.2.3.66

ns.tree.com.           IN A 1.2.3.124
ns2.tree.com.          IN A 1.2.3.124

А в named.conf есть следующее:

zone "tree.com" {
        type master;
        file "data/tree_com.zone";
};


zone "cat.com"  {
        type master;
        file "data/cat_com.zone";
};

Итак, когда я пытаюсь разрешить запись A в cat.com, скажем, host19.cat.com, я могу получить запись 1.2.3.66. Это странно, потому что согласно файлу зоны SOA, запись NS указывает на ns.tree.com, а в файле зоны SOA tree.com нет информации о host19.cat.com. Как процесс разрешения DNS может работать без ошибок в этом случае? Играет ли здесь роль запись NS или только named.conf решает, какой файл зоны SOA следует использовать (в этом случае cat.com будет ссылаться на файл cat_com.zone), а запись NS в SOA cat.com ничего не значит?

решение1

Совершенно нормально иметь доменное имя/файл зоны, указывающий на серверы имен за пределами этого домена, т.е. его совершенно нормально использовать ns1.example.comв качестве сервера имен для example.orgдомена.

Это не только означает, что вам не нужноКлей пластинкив example.orgзоне часто бывает и легче управлять.

Я думаю, вы допустили небольшую концептуальную ошибку, думая, что внешние записи NS, такие как ns1.example.comподразумевают, что записи ресурсов для example.orgдомена также должны быть извлечены из example.comданных зоны. Это не так, запись NS указывает только нахозяинзапуск службы имен для этого домена, но записи ресурсов будут поступать из данных зоны, специфичных для домена example.org.

Связанный контент