У меня проблемы с загрузкой зоны на подчиненном DNS-сервере. Оба сервера работают под управлением BIND 9.9.3-P2.
Я уже обслуживаю ~ 150 зон, и все они исправно работают. Однако, когда я добавляю другой домен, подчиненный сервер отказывается его распознавать.
Вот спецификация зоны на мастере:
zone "test.no" { type master; file "/var/lib/named/zones/test.zone"; };
Вот спецификация зоны на ведомом устройстве:
zone "test.no" { type slave; masters { master.ip; }; file "/var/lib/named/zones/test.zone"; };
И когда я делаю rndc reload на мастере ведомый получает уведомление, передает зону от мастера и не жалуется. Это из логов на раб:
27-Mar-2014 10:30:15.146 zone test.no/IN: no master file
27-Mar-2014 10:30:15.146 zone_settimer: zone test.no/IN: enter
27-Mar-2014 10:30:15.157 dns_zone_maintenance: zone test.no/IN: enter
27-Mar-2014 10:30:15.158 zone_settimer: zone test.no/IN: enter
27-Mar-2014 10:30:15.166 zone_timer: zone test.no/IN: enter
27-Mar-2014 10:30:15.166 zone_maintenance: zone test.no/IN: enter
27-Mar-2014 10:30:15.166 queue_soa_query: zone test.no/IN: enter
27-Mar-2014 10:30:15.166 zone_settimer: zone test.no/IN: enter
27-Mar-2014 10:30:15.166 soa_query: zone test.no/IN: enter
27-Mar-2014 10:30:15.170 refresh_callback: zone test.no/IN: enter
27-Mar-2014 10:30:15.170 refresh_callback: zone test.no/IN: serial: new 2014031901, old not loaded
27-Mar-2014 10:30:15.170 queue_xfrin: zone test.no/IN: enter
27-Mar-2014 10:30:15.171 zone test.no/IN: Transfer started.
27-Mar-2014 10:30:15.171 zone test.no/IN: no database exists yet, requesting AXFR of initial version from x.x.x.x#53
27-Mar-2014 10:30:15.171 transfer of 'test.no/IN' from x.x.x.x#53: connected using x.x.x.y#59644
27-Mar-2014 10:30:15.179 zone test.no/IN: zone transfer finished: success
27-Mar-2014 10:30:15.179 zone test.no/IN: transferred serial 2014031901
27-Mar-2014 10:30:15.179 zone_needdump: zone test.no/IN: enter
27-Mar-2014 10:30:15.179 zone_settimer: zone test.no/IN: enter
27-Mar-2014 10:30:15.179 zone_settimer: zone test.no/IN: enter
27-Mar-2014 10:30:15.179 transfer of 'test.no/IN' from x.x.x.x#53: Transfer completed: 1 messages, 6 records, 197 bytes, 0.007 secs (28142 bytes/sec)
27-Mar-2014 10:30:15.180 zone_timer: zone test.no/IN: enter
27-Mar-2014 10:30:15.180 zone_maintenance: zone test.no/IN: enter
27-Mar-2014 10:30:15.180 zone test.no/IN: sending notifies (serial 2014031901)
27-Mar-2014 10:30:15.186 zone_dump: zone test.no/IN: enter
27-Mar-2014 10:30:15.186 zone_settimer: zone test.no/IN: enter
27-Mar-2014 10:30:15.186 zone_gotwritehandle: zone test.no/IN: enter
27-Mar-2014 10:30:15.186 decrement_reference: delete from rbt: 0x9a725d8 test.no
27-Mar-2014 10:30:15.187 dump_done: zone test.no/IN: enter
И /var/lib/named/zones/test.zone создается и заполняется на подчиненном сервере:
-rw-r--r-- 1 named named 250 Mar 27 10:30 test.zone
Все хорошо! Однако после того, как я увеличил серийный номер на мастере и сделаю еще одну перезагрузку, я получаю ту же чертову ошибку:
27-Mar-2014 10:30:51.405 client x.x.x.x#42033: received notify for zone 'test.no': not authoritative
В test.no zone - это вторая зона, которую я пытаюсь с той же ошибкой, и конфигурация имеет тот же синтаксис, что и остальные рабочие зоны.
Фактический файл зоны, как он отображается на мастере:
$TTL 1h0m6s
@ IN SOA ns1.domain.no. postmaster.domain.no. (
2014031902 ; serial, todays date + todays serial #
1H ; refresh, seconds
2H ; retry, seconds
2D ; expire, seconds
1H ) ; minimum, seconds
NS ns1.domain.no.
NS ns2.domain.no.
TXT "test.no"
test A 10.0.0.1
В интересах всех, кто столкнулся с этой проблемой и попал сюда из Google, для меня проблема была вызвана тем, что я использовал представления BIND.
Я настроил несколько представлений, предполагая, что BIND объединит все совпадающие представления в одно, но на самом деле он выбирает первое совпадающее представление и использует только это, игнорируя все остальные. Следовательно, клиент видел только небольшую часть моих зон, и поэтому те, которые отсутствовали в представлении, считались неавторизованными.
Моя проблема была решена путем вставки всего содержимого во включаемые файлы и их использования, чтобы каждое представление было полностью завершено само по себе.
Решено:
На сервере было два экземпляра привязки! Один, казалось бы, осиротевший, который продолжал обслуживать запросы (и, таким образом, отказался от зоны, о которой он не знал). И тот, который послушно ответил на rndc команды и запись всего необходимого в тот же файл журнала, что и другой экземпляр.
Я понял это, когда изменил директиву listen на localhost, чтобы отфильтровать весь шум, исходящий от клиентов, в файле журнала. Однако запросы продолжали обрабатывать файлы журнала, а затем я дважды проверил, какие порты и IP-адреса прослушивают, и действительно, было несколько несогласованных записей.
Я немного разочарован rndc reload позвольте мне продолжить разговор с практически изолированным процессом без предупреждения о том, что указанный процесс не был привязан к его порту udp из-за конфликта ;-)