Nuestros clientes realizan bastantes comprobaciones de dominio en el DNS público de Google con los siguientes dominios <userid>.sip.teltel.io, pero a menudo fallan. Para otros, como Cloudflare, siempre tiene éxito.
Cuando ejecutamos nslookup en un bucle hacia 8.8.8.8, aproximadamente el 80% de las veces Google no logra resolverlo. Hasta 1.1.1.1 siempre tiene éxito. Vea a continuación un ejemplo fallido:
Pedido:
while :
do
nslookup 7157599388.sip.teltel.io 8.8.8.8
done
Respuesta:
Server: 8.8.8.8
Address: 8.8.8.8#53
** server can't find 7157599388.sip.teltel.io: NXDOMAIN
Además, al realizar una excavación hacia 8.8.8.8, a veces falla, a veces no:
¿Alguien tiene una idea de por qué?
¡Gracias de antemano!
Respuesta1
De una 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 el subdominio sip.teltel.io está delegado desde los servidores DNS de CloudFlare a los servidores de nombres ns1.teltel.io y ns2.teltel.io.
Para empezar, esos dos registros de servidores de nombres se resuelven en 3.9.142.25. Cuando no tiene servidores DNS redundantes, también puede usar solo un único registro NS y vivir con ese único punto de falla.
Además, la zona para el subdominio sip.teltel.io todavía no contiene ningún registro NS y la consulta dig -t NS sip.teltel.io @ns1.teltel.ioaún falla. Ver¿Por qué los archivos de zona DNS requieren registros NS?yAclaración de por qué los archivos de zona DNS requieren registros NSpara un razonamiento más detallado de por qué eso es malo.
Sin embargo, no sé si alguna de esas es la razón por la que la resolución falla de forma intermitente.