Presentación de un problema en el despliegue de IPv6 originado por el bloqueo de respuestas a consultas DNS por registros AAAA (quad-A). Se presenta diagnóstico y soluciones. Charla presentada en evento LACNIC XVI en el año 2011, Buenos Aires, Argentina.

1. Bloqueo de quad-A en DNS
o
“Retardos navegando en IPv6”
Hugo Salgado
NIC Chile
Octubre 2011

2. El problema

3. Retardo en navegación web
• Oficinas de NIC Chile con IPv6 nativo en dual
stack.
• Sitios web con lentitud en carga
– uno de televisión tarda 45 segundos en cargar!
• Comportamiento común:
– browser se queda en “looking up...”
– aunque tienen registro A sin problemas, el registro
AAAA arroja error (timeout) en los servidores
autoritativos.

4. El diagnóstico

5. Comportamiento de navegadores
• Browsers con IPv6 activo consultan por A y AAAA
al mismo tiempo.
• Dependiendo del sistema operativo y browser,
stub resolver espera que AAAA responda antes
que A.
– gethostbyname da timeout a los 5 segundos, y
reintenta 2 veces más, totalizando 15 segundos.
• Esto es anterior a “happy eyeballs”

6. No hay respuesta para quad-A
• Los DNS autoritativos para estas zonas
IGNORAN las consultas AAAA (nunca hay
respuesta)
• Un DNS puede
– retornar AAAA (sí hay registros)
– NOERROR + answers=0 (no hay AAAA pero sí existe
el nombre)
– NXDOMAIN (no existe el nombre)
– RCODE!=NOERROR (no entiendo la pregunta)
• Pero SIEMPRE debe responder!

7. Errores encadenados
• En el caso de sitio de televisión, los timeouts se
encadenan:
– sitio en “www.<dominio>.cl”
– CSS y javascripts en “static.<dominio>.cl”
– imágenes y medios en “ads.<dominio>.cl”
• Totalizando 45 segundos en cargar.

8. Los afectados

9. Zonas en .CL
• Revisión exhaustiva de ~300k nombres .CL
– Por restricciones de la herramienta sólo detectamos
nombres con problemas en todos sus DNS
– 392 dominios con bloqueo quad-A
• Se han detectado (simplemente por uso!)
nombres en otros TLDs.

10. Comportamiento en navegadores
• El comportamiento es independiente del
navegador
– Firefox, Chrome, Safari, Explorer
• Linux 2.6.35 (Fedora 14): 15 segundos
• Windows Vista: 7 segundos
• MacOSX Lion: 0 segundos

11. Posibles culpables
• Fingerprinting revela DNS sanos en las
respuestas correctas
• Sospechoso algún middleware
– firewall
– balanceador de carga
• Comportamiento recurrente: www apunta a
CNAME y este tiene TTL pequeño (balanceo de
carga por DNS)
• Tampoco responde por otros RRs (SOA, TXT,
etc)

12. Herramientas

13. Dominio de prueba
• Se mantiene un servidor de nombres ad-hoc
(simple y no muy robusto) para pruebas, con un
dominio especial
• qname: www.test-aaaa-block.cl

14. Cómo saber si mi dominio está
bien?
• Usar herramienta de diagnóstico de DNS
– dig o drill
% dig @ns.test-aaaa-block.cl www.test-aaaa-block.cl aaaa +norec
[...]
;; connection timed out; no servers could be reached
• Usar prueba disponible también en
– http://www.test-aaaa-block.cl

15. Resumiendo

16. IPv6 te alcanzará,
¡aunque no hagas nada!
;)

17. Más información
• Y. Morishita & T. Jinmei, “Common Misbehavior
Against DNS Queries for IPv6 Addresses”, RFC
4074, May 2005.

18. Gracias
Hugo Salgado
NIC Chile
hugo@nic.cl