Вторичный сервер имен продолжает пытаться перенести домен и каждый раз успешно
Мы используем BIND 9.7.3 в стабильной версии Debian (обновляется еженедельно), и мы видим очень странное поведение для одного конкретного домена. Мы принимаем несколько сотен, но этот наш.
По сути, вторичный DNS-сервер пытается перенести домен с мастера. Согласно журналам, он успешно переносит домен каждый раз, но серийный номер всегда ошибается! В результате, он продолжает повторять передачу при каждой возможности. Я даже не уверен, откуда он получает серийный номер, потому что основной сервер сообщает правильный серийный номер.
Вот журналы, которые мы получаем от вторичного сервера (ip 192.168.0.130 является основным сервером, 192.168.0.4 является вторичным. И, конечно, они не настоящие.):
Aug 23 03:01:08 ns2 named[4242]: transfer of 'mydomain.ca/IN/external' from 192.168.0.130#53: connected using 192.168.0.4#60959
Aug 23 03:01:08 ns2 named[4242]: transfer of 'mydomain.ca/IN/external' from 192.168.0.130#53: Transfer completed: 0 messages, 1 records, 0 bytes, 0.001 secs (0 bytes/sec)
Это кажется вполне нормальным, хотя оба хоста настроены с адресами IPv6 и, говоря технически, они должны их использовать, но это проблема для другого дня (я думаю).
Итак, давайте запросим первичный сервер со вторичного и посмотрим, что он говорит:
$ host -4 -t any mydomain.ca 192.168.0.130
Using domain server:
Name: 192.168.0.130
Address: 192.168.0.130#53
Aliases:
mydomain.ca has IPv6 address fc00:::31
mydomain.ca has SOA record ns1.mydomain.bc.ca. hostmaster.mydomain.ca. 2011082201 900 3600 604800 86400
mydomain.ca name server ns2.mydomain.bc.ca.
mydomain.ca name server ns1.mydomain.bc.ca.
mydomain.ca mail is handled by 20 pop.mydomain.ca.
mydomain.ca has address 192.168.0.205
mydomain.ca descriptive text "v=spf1 mx ip4:192.168.0.4 ip4:192.168.0.193 ip6:fc00:::23 ip6:fc00:::12 ip6:fc00:::33 a:smtp.mydomain.ca a:webmail.mydomain.ca a:smtp2.mydomain.ca a:ns2.mydomain.ca ~all"
А затем давайте сделаем то же самое для вторичного сервера имен:
$ host -4 -t any mydomain.ca 192.168.0.4
Using domain server:
Name: 192.168.0.4
Address: 192.168.0.4#53
Aliases:
mydomain.ca has SOA record ns1.mydomain.bc.ca. hostmaster.mydomain.ca. 2011011013 600 600 600 600
mydomain.ca descriptive text "v=spf1 mx ip4:192.168.0.4 ip4:192.168.0.193 ip6:fc00::23 ip6:fc00::12 ip6:fc00::33 a:smtp.mydomain.ca a:webmail.mydomain.ca a:smtp2.mydomain.ca a:ns2.mydomain.ca ~all"
mydomain.ca has address 192.168.0.205
mydomain.ca mail is handled by 20 pop.mydomain.ca.
mydomain.ca name server ns1.mydomain.bc.ca.
mydomain.ca name server ns2.mydomain.bc.ca.
mydomain.ca has IPv6 address fc00::31
Здесь вы можете видеть, что серийный номер 2011011013 для вторичного устройства, но 2011082201 для основного. Я использовал дату плюс двузначное число, так что вторичная сторона как-то использует серийный номер с января. Я попытался найти эту конфигурацию в нашей конфигурации на первичном и вторичном серверах, но его нигде не было.
Говоря о конфигурации, вот конфигурация для этого домена в /etc/bind/named.conf:
zone "mydomain.ca" { type slave; file "secondaries/mydomain.ca"; masters { 192.168.0.130; }; };
а отметка времени на secondaries/mydomain.ca - это время последнего обновления. Удаление этого файла по-прежнему приводит к серийному номеру 2011011013. Содержимое этого файла очень длинное, но вот заголовки на вторичном сервере:
$ORIGIN .
$TTL 3600 ; 1 hour
mydomain.ca IN SOA ns1.mydomain.bc.ca. hostmaster.mydomain.ca. (
2011011013 ; serial
600 ; refresh (10 minutes)
600 ; retry (10 minutes)
600 ; expire (10 minutes)
600 ; minimum (10 minutes)
)
NS ns1.mydomain.bc.ca.
NS ns2.mydomain.bc.ca.
A 192.168.0.205
MX 20 pop.mydomain.ca.
TXT "v=spf1 mx ip4:192.168.0.4 ip4:192.168.0.193 ip6:fc00::23 ip6:fc00::12 ip6:fc00::33 a:smtp.mydomain.ca a:webmail.mydomain.ca a:smtp2.mydomain.ca a:ns2.mydomain.ca ~all"
AAAA fc00::31
$ORIGIN mydomain.ca.
и заголовки из эквивалентного файла на первичном:
$TTL 1d
@ IN SOA ns1.mydomain.bc.ca. hostmaster.mydomain.ca. (
2011082302 ; serial
15m ; refresh after 15 minutes
1h ; retry after 1 hour
1w ; expire after 1 week
1d ) ; negative caching TTL of 1 day.
IN NS ns1.mydomain.bc.ca.
IN NS ns2.mydomain.bc.ca.
IN MX 20 pop.mydomain.ca.
@ IN A 192.168.0.205
;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; SPF TXT records
;;;;;;;;;;;;;;;;;;;;;;;;;;;
mydomain.ca. TXT "v=spf1 mx ip4:192.168.0.4 ip4:192.168.0.193 ip6:fc00::23 ip6:fc00::12 ip6:fc00::33 a:smtp.mydomain.ca a:webmail.mydomain.ca a:smtp2.mydomain.ca a:ns2.mydomain.ca ~all"
; this next bit is for the Sender Policy Framework, if it ever really matters.
pop TXT "v=spf1 a -all"
pop3 TXT "v=spf1 a -all"
smtp TXT "v=spf1 a -all"
webmail TXT "v=spf1 a -all"
horde TXT "v=spf1 a -all"
2 ответа
Проверьте ваши разрешения в каталоге вторичного сервера для зон. Может ли указанный процесс записать в эту папку? Попробуйте удалить эту вторичную зону и разрешите переносу воссоздать ее
Обратите внимание, что ваш журнал BIND на основной указывает
... Transfer completed: 0 messages, 1 records, 0 bytes, 0.001 secs (0 bytes/sec)
Это не подтверждение успеха. Есть ли какое-либо сообщение об ошибке до этого?