8.8.8.8 возвращает NXDOMAIN случайным образом для всех наших поддоменов
Наши клиенты проводят довольно много проверок домена в отношении общедоступного DNS Google со следующими доменами , но часто они терпят неудачу. Для других, таких как Cloudflare, это всегда успешно.
Когда мы запускаем nslookup в цикле к 8.8.8.8, примерно в 80% случаев Google не может решить проблему. До 1.1.1.1 всегда успешно. См. Ниже пример сбоя:
Запрос:
while :
do
nslookup 7157599388.sip.teltel.io 8.8.8.8
done
Ответ:
Server: 8.8.8.8
Address: 8.8.8.8#53
** server can't find 7157599388.sip.teltel.io: NXDOMAIN
Кроме того, при копании в направлении 8.8.8.8 иногда это не удается, иногда нет:
Кто-нибудь знает, почему?
Заранее спасибо!
Из копки +trace 7157599388.sip. teltel.io query:
teltel.io. 86400 IN NS dina.ns.cloudflare.com.
teltel.io. 86400 IN NS kanye.ns.cloudflare.com.
sip.teltel.io. 1800 IN NS ns1.teltel.io.
sip.teltel.io. 1800 IN NS ns2.teltel.io.
ns1.teltel.io. 1800 IN A 3.9.142.25
ns2.teltel.io. 1800 IN A 3.9.142.25
7157599388.sip.teltel.io. 300 IN A 104.248.101.248
Мы видим, что поддомен sip.teltel.io делегирован с DNS-серверов CloudFlare на серверы имен ns1.teltel.io и ns2.teltel.io.
Для начала обе записи этих двух серверов имён разрешаются в 3.9.142.25. Если у вас нет избыточных DNS-серверов, вы можете использовать только одну запись NS и жить с этой единственной точкой отказа.
Кроме того, зона для субдомена sip.teltel.io в настоящее время по-прежнему не содержит записей NS, и запрос dig -t NS sip.teltel.io @ns1.teltel.io по-прежнему не выполняется. См. Почему для файлов зон DNS требуются записи NS? и Пояснение того, почему для файлов зон DNS требуются записи NS для более подробного объяснения того, почему это плохо.
Я не знаю, является ли какая-либо из этих причин причиной периодических сбоев при разрешении.