Nossos clientes fazem algumas verificações de domínio no DNS público do Google com os domínios a seguir <userid>.sip.teltel.io, mas muitas vezes elas falham. Para outros, como o Cloudflare, é sempre um sucesso.
Quando executamos o nslookup em um loop em direção a 8.8.8.8, cerca de 80% das vezes o Google não consegue resolver. Para 1.1.1.1 é sempre bem sucedido. Veja abaixo um exemplo de falha:
Solicitar:
while :
do
nslookup 7157599388.sip.teltel.io 8.8.8.8
done
Resposta:
Server: 8.8.8.8
Address: 8.8.8.8#53
** server can't find 7157599388.sip.teltel.io: NXDOMAIN
Além disso, ao fazer uma pesquisa em direção ao 8.8.8.8, às vezes ele falha, às vezes não:
Alguém tem uma ideia do porquê?
Agradeço antecipadamente!
Responder1
De uma dig +trace 7157599388.sip.teltel.ioconsulta:
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
Podemos ver que o subdomínio sip.teltel.io é delegado dos servidores DNS CloudFlare para os servidores de nomes ns1.teltel.io e ns2.teltel.io.
Para começar, esses dois registros de servidores de nomes são resolvidos como 3.9.142.25. Quando você não possui servidores DNS redundantes, é melhor usar apenas um único registro NS e conviver com esse único ponto de falha.
Além disso, a zona do subdomínio sip.teltel.io atualmente ainda não contém nenhum registro NS e a consulta dig -t NS sip.teltel.io @ns1.teltel.ioainda falha. VerPor que os arquivos de zona DNS exigem registros NS?eEsclarecimento sobre por que os arquivos de zona DNS exigem registros NSpara um raciocínio mais detalhado sobre por que isso é ruim.
Não sei se algum desses é o motivo pelo qual a resolução falha intermitentemente.