8.8.8.8 возвращает NXDOMAIN случайным образом для всех наших поддоменов

8.8.8.8 возвращает NXDOMAIN случайным образом для всех наших поддоменов

Наши клиенты делают довольно много проверок доменов в Google Public DNS со следующими доменами <userid>.sip.teltel.io, но они часто терпят неудачу. Для других, как 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 иногда происходит сбой, иногда нет: введите описание изображения здесь Кто-нибудь знает почему?

Заранее спасибо!

решение1

Из dig +trace 7157599388.sip.teltel.ioзапроса:

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для более подробного обоснования того, почему это плохо.

Я не знаю, является ли что-то из этого причиной периодических сбоев разрешения.

Связанный контент