
Наши клиенты делают довольно много проверок доменов в 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для более подробного обоснования того, почему это плохо.
Я не знаю, является ли что-то из этого причиной периодических сбоев разрешения.