dig показывает SERVFAIL, при указании на сервер имен работает нормально

, что-то похожее на этот поток . Я столкнулся с проблемой, когда копают blah.net (ради простота, назовем это blah.net ) возвращает status: SERVFAIL

Эта зона DNS размещена на route53, и я использую GoDaddy в качестве регистратора, который указывает на NS-записи размещенной зоны на route53

это довольно простая зона, которая состоит из CNAME и A Record, а также значений по умолчанию для записей SOA и NS для зоны хоста route53 (обновлен / уменьшен только TTL)

Проблема заключается в dig blah.net вызывает статус : SERVFAIL при указании на сервер имен разрешает нормально (например, dig @ns - #. awsdns - ##. net. blah.net работает нормально со статусом : NOERROR )

Он также показывает, что записи / разрешает нормально (без ошибок), если я использую dig blah.net + trace

Я ждал больше 48 часов, чтобы убедитесь, что G oDaddy распространил изменения, и дважды / трижды проверенный GoDaddy указывает на blah.net NS-записи

Я не вижу ничего странного в /etc/resolve.conf на моей машине (но не эксперт!), и он также не работает на сервере имен Google (скрыт), возможно, что-то пошло не так со стороны GoDaddy? Любые предложения / комментарии о том, как отлаживать это, действительно приветствуются


[Edit] исправление: опечатка в имени DNS.

-2
задан 4 August 2020 в 19:04
1 ответ

Проблема заключается в том, чтобы копать blah.net вызывает статус: SERVFAIL при указании на сервер имен восстанавливает штраф (например, dig @ns-#.awsdns-##.net. blah.net отлично работает со статусом: NOERROR )

Это указывает на то, что любой DNS-сервер, который вы используете на хосте под управлением dig, неправильно настроен, имеет поврежденный кэш или (если использовать технический термин) взвинчен.

Он также показывает записи / разрешения отлично (без ошибок), если я использую dig blah.net + trace

Это дополнительно поддерживает вышеуказанное понятие, потому что dig +trace не использует настройки DNS хоста для проверки DNS, а скорее переходит непосредственно к корневым ссылкам.

Неправильное разрешение по адресу @8.8.8.8 точно не исключает локальную среду DNS.

И, конечно же, никто не может оказать вам какую-либо реальную помощь, пока вы не предоставите фактическое доменное имя, о котором идет речь.

0
ответ дан 4 August 2020 в 16:54

Теги

Похожие вопросы