Сегодня утром мы обнаружили, что (из-за перехода) одна из наших записей DNS для важной службы неверна. Он был изменен на нашем основном DNS-сервере, но клиенты на дополнительных сайтах не видят этого изменения. (Наша сеть почти полностью работает с серверами OS X 10.5 и клиентами OS X 10.5).
Назову несколько машин для примера:
На клиенте (который выполняет поиск DNS через вторичный сервер) при проверке того, как все настроено, я получаю:
nslookup service.ourdomain.com
** server can't find service.ourdomain.com: NXDOMAIN
nslookup service.ourdomain.com secondary
** server can't find service.ourdomain.com: NXDOMAIN
nslookup service.ourdomain.com primary
(returns appropriate information about how to contact the service)
Когда я вхожу в
Я получил:
nslookup service.ourdomain.com
(returns appropriate information about how to contact the service)
nslookup service.ourdomain.com secondary
** server can't find service.ourdomain.com: NXDOMAIN
nslookup service.ourdomain.com primary
(returns appropriate information about how to contact the service)
Я в недоумении. Вторичный, похоже, знает, где находится служба, но не возвращает значения при запросе. (Конечно, записи DNS могут быть полностью независимыми или то, что он возвращает при запросе доменного имени, но все же - похоже, он должен знать!)
Я попытался очистить DNS на вторичном сервере и на клиенте. (dscacheutil -flushcache). Я также остановил и перезапустил DNS на вторичном сервере. (sudo serveradmin stop dns и sudo serveradmin start dns)
На нашем основном сайте мой коллега перезагрузил основной сайт и клиента, чтобы имя разрешилось правильно. К сожалению, у нас есть 14 вторичных сайтов, и я бы предпочел не перезагружать серверы, которые делятся файлами, в течение дня, если это возможно, но сделаю это, если это решит проблему.
По запросу:
host -C ourdomain.com # [with names substituted]:
ourdomain.com SOA record primary.ourdomain.com. admin.ourdomain.com. 2009121410 21600 3600 604800 345600
[Я понятия не имею, что такое admin.ourdomain.com - не думаю, что у нас есть ящик с таким именем; Я точно не могу пинговать. Однако основной DNS-сервер отображается правильно.]
Также по запросу, вот вывод dig service.ourdomain.com @secondary (с заменой имени):
; <<>> DiG 9.4.3-P1 <<>> service.ourdomain.com @secondary
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19207
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;service.ourdomain.com. IN A
;; AUTHORITY SECTION:
ourdomain.com. 10800 IN SOA primary.ourdomain.com. admin.ourdomain.com. 2009121409 21600 3600 604800 345600
;; Query time: 3 msec
;; SERVER: [IP of secondary]#53([IP of secondary])
;; WHEN: Mon Dec 14 10:34:11 2009
;; MSG SIZE rcvd: 88
И выход dig service.ourdomain.com @primary:
; <<>> DiG 9.4.3-P1 <<>> service.ourdomain.com @primary
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47885
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;service.ourdomain.com. IN A
;; ANSWER SECTION:
service.ourdomain.com. 10800 IN A [IP of service]
;; AUTHORITY SECTION:
ourdomain.com. 10800 IN NS primary.ourdomain.com.
;; ADDITIONAL SECTION:
primary.ourdomain.com. 10800 IN A [IP of primary]
;; Query time: 8 msec
;; SERVER: [IP of primary]#53([IP of primary])
;; WHEN: Mon Dec 14 10:34:18 2009
;; MSG SIZE rcvd: 92
Наиболее разительные отличия заключаются в том, что вторичный не ответил, а первичный сказал: «;; ВНИМАНИЕ: рекурсия запрошена, но недоступна».
Ваш вторичный сервер пытается рекурсивно ответить (RD - желаемая рекурсия, RA - рекурсия доступна), но не работает (NXDOMAIN), в то же время обслуживая SOA авторитетно записывать (AA - авторитетный ответ).
Кажется, у вас здесь немного странная смесь ... нам нужно установить, как ваш вторичный сервер знает о зоне ( SOA запись), но не знает о записи в зоне.
Я бы пошел по рекомендации Майкла - нажмите серийный номер на главном устройстве, а затем перезапустите BIND на вторичном, чтобы убедиться, что его кеш очищен.
Не зная вашей конфигурации, я бы предположил, что это проблема кеширования или проблема распространения DNS.
Не зная, какой домен вы используете, я не могу проверить его отсюда. Я лично не понимаю, почему люди пропускают такую важную информацию, но они часто это делают.
Попробуйте "host -C yourdomain.com" и скажите мне, что вы видите. Если вы видите разные записи SOA с разными серийными номерами, вам необходимо исправить распространение DNS. ЕСЛИ вторичный сервер не указан в записях NS для этой зоны, добавьте строку «также-уведомление», если выполняется BIND.
Попробуйте изменить серийный номер на главном устройстве, чтобы убедиться, что он был изменен правильно, а также для проверки распространения.
Попробуйте установить лучшее время отрицательного кеширования, которое намного меньше, скажем, 600 (10 минут) или около того. Это одно из значений в записи SOA.
Попробуйте «копать hostname.yourdomain.com @secondaryserver» и посмотреть, что он вернет. Сделайте то же самое на начальном. Если они отличаются, то это слом.
Если каждый из этих сайтов, которые возвращают неверные данные, имеет огромное время кеширования, вы должны иметь возможность подключиться к ним по ssh и просто перезапустить сервер имен, а не перезагружать каждый сайт полностью. BIND быстро перезапустится, если это то, что используется.
Вы можете вручную принудительно перенести зону, используя rndc утилита. Выполните эту команду на всех своих вторичных DNS-серверах:
rndc -p 54 retransfer mydomain.example.com IN com.apple.ServerAdmin.DNS.public
Вы также можете использовать эту утилиту для перезагрузки конфигурации без перезапуска. названный.
rndc -p 54 reload