Nos encargamos de implementar los cambios que sugirió sip.teltel.ioen nuestras preguntas anteriores, pero no mejoró.
El subdominio alojado en AWS a veces no se resuelve en 8.8.8.8
8.8.8.8 No logra resolver nuestros subdominios aleatoriamente
8.8.8.8 devuelve NXDOMAIN aleatoriamente para todos nuestros subdominios
ACTUALIZAR:
- Incluso creamos un subdominio de prueba
xip.teltel.ioque está configurado exactamente de la misma manerasip.teltel.ioy cuando se resuelve ese dominio hacia 8.8.8.8, funciona bien siempre. La única diferencia entre sip.teltel.io y xip.teltel.io es la carga: sorborecibe el tráfico de nuestros clientes yxipsólo nuestras solicitudes de prueba.
¿Cómo puedes explicar eso?
- Esto es lo que también notamos: cuando se resuelve hacia 8.8.8.8 desde una red wifi local o un punto de acceso personal, etc., a veces falla. Las respuestas se reciben de estas direcciones IP de Google:
74.125.46.10
74.125.112.1
74.125.112.9
74.125.x.x
74.125.z.z
74.125.w.w
Pero cuando se resuelve hacia 8.8.8.8 desde un servidor en AWS o DO, siempre tiene éxito. Las respuestas se reciben de diferentes direcciones IP de Google:
172.253.199.4
172.253.1.194
172.217.33.132
¿Le da Google mayor prioridad a los grandes clientes como AWS o DO frente al público...? ¿O hay una explicación diferente?
- Capturamos el tráfico realizando un tcpdump (tcpdump udp y puerto 53) y notamos que cuando Google no resuelve, nuestros servidores de nombres nunca reciben una solicitud de Google.
- Aquí puedes probar los bucles tú mismo:
Esto a veces falla con "sorbo" -while true; do dig A 42894078.sip.teltel.io @8.8.8.8; done;
Esto siempre está bien con "xip"-while true; do dig A 42894078.xip.teltel.io @8.8.8.8; done;
¿Puedes ayudarnos a resolver esto? Todo esto nos parece bastante misterioso.
¡Gracias!