Подтвердить что ты не робот

Dig возвращает команду SERVFAIL, но + trace

Вот основная проблема:

dig maktabkhooneh.info + trace

работает отлично и возвращает правое поле.

dig maktabkhooneh.info

(без + trace) возвращает:

; < < → DiG 9.8.1-P1 < lt; → maktabkhooneh.info

;; глобальные параметры: + cmd

;; Получил ответ:

;; → > HEADER < - opcode: QUERY, статус: SERVFAIL, id: 58716

;; флаги: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ДОПОЛНИТЕЛЬНО: 0

В чем может быть причина? Я читал этот. Это единственная возможная причина, по которой я изменил данные домена 12 часов назад? нет другой возможной причины для SERVFAIL?

дополнительная информация:

У меня есть два сервера BIND, работающих на 168.144.251.73 (мастер) и 168.144.92.50 (ведомый).

а у мастера у меня есть:

$TTL 300

maktabkhooneh.info. IN SOA ns1.maktabkhooneh.info.
admin.maktabkhooneh.info. (

2012060201; Последовательный

86400; Обновить

7200; Повторить попытку

3600000; Удалено

300); Минимум

maktabkhooneh.info. IN A 168.144.97.83

maktabkhooneh.info. IN NS ns1.maktabkhooneh.info.

maktabkhooneh.info. IN NS ns2.maktabkhooneh.info.

ns1 IN A 168.144.251.73

ns2 IN A 168.144.92.50

www IN CNAME maktabkhooneh.info.

4b9b3361

Ответ 1

dig +trace следует всей цепочке с самого начала - он запрашивает корневые серверы, а затем .info-серверы, а затем ваши namservers. Таким образом, он избегает любых решателей кэширования, а также избегает проблем распространения.

dig +notrace (по умолчанию) запрашивает ваш DNS-фильтр по умолчанию (в Linux, независимо от того, что указано в /etc/resolv.conf).

Там какая-то проблема с этим резольвером - может быть, это неправильно сконфигурировано, может быть, у него есть старые данные в кешках, возможно, он не может связаться с вашими авторитетными серверами имен и т.д.