Resumen

  • Las notas del 19 de agosto de AFRINIC convierten una prueba IPv6 de servidores del ccTLD en una afirmación sobre todos los sitios subordinados. El transporte de la consulta DNS y las direcciones que devuelve pertenecen a planos distintos.
  • Un resolutor recursivo de doble pila ofrece un contraejemplo. La recursión solo por IPv6, sin una vía alternativa hacia una autoridad necesaria, sí puede quedar limitada. Aquí no se ha medido una caída real.

La consulta puede cambiar de vehículo a mitad de camino. Un cliente habla por IPv6 con su resolutor recursivo; este consulta por IPv4 una parte de la jerarquía DNS, obtiene de una autoridad accesible los datos AAAA del sitio y devuelve la respuesta al cliente. La conexión posterior al sitio puede usar IPv6.

No es una demostración realizada sobre una red africana. Es una posibilidad del protocolo que falta en la explicación de AFRINIC.

El monitor de despliegue IPv6 y DNSSEC introdujo una pestaña para los dominios territoriales. En las notas de la versión 2.14.0, fechadas el 19 de agosto de 2026, separa tres comprobaciones de los servidores del registro: tener dirección IPv6, responder por IPv6 y contestar preguntas DNS por ese transporte. La distinción aporta información.

El texto salta después a otra conclusión: si los servidores del registro no son accesibles por IPv6, tampoco lo sería nada situado por debajo, independientemente de su configuración. Incluso para un nombre que realmente cuelga de ese ccTLD, la afirmación es excesiva. La jerarquía de delegaciones no obliga a usar la misma versión de IP en cada intercambio ni en la conexión final a la aplicación.

El registro AAAA no hereda el transporte

La RFC 3596, de octubre de 2003, establece que el transporte de una pregunta DNS es independiente de la familia de direcciones descrita en los registros. Por IPv4 se pueden recuperar direcciones IPv6; por IPv6, registros de direcciones IPv4.

Eso no significa que el ccTLD entregue normalmente el AAAA final de la web. Puede proporcionar una referencia a la zona hija. El resolutor sigue esa delegación por un transporte utilizable, consulta la autoridad correspondiente y devuelve los datos al cliente. Cada paso tiene sus propios requisitos de conectividad.

En el contraejemplo, las autoridades necesarias son accesibles, la información es válida y la aplicación tiene un camino IPv6 que funciona. La etapa del ccTLD puede usar IPv4 sin impedir la conexión IPv6 del usuario. Tampoco hace falta suponer que una respuesta estaba ya en caché. Estas condiciones muestran el límite lógico de la frase; no garantizan el funcionamiento de una red concreta.

La RFC 4472, documento informativo de abril de 2006, insiste en la separación entre transporte y datos solicitados. También ayuda a recordar que quien pregunta a un servidor autoritativo no suele ser quien utilizará la dirección: en medio hay un resolutor con interfaces y rutas propias.

Publicar un AAAA tampoco demuestra el éxito de una conexión IPv6. Pueden fallar el encaminamiento, el filtrado, el servicio o el trayecto hacia él. Una respuesta correcta del servidor padre no comprueba todo eso.

Cuándo sí importa la falta de IPv6 en el padre

El mejor argumento a favor de la preocupación de AFRINIC es un resolutor que realiza iteración exclusivamente por IPv6 y necesita contactar con una autoridad disponible solo por IPv4. Sin reenvío funcional a un servicio de doble pila, traducción u otra ruta, puede quedar bloqueado en esa etapa. Es una restricción real de una configuración definida, no una condena de todos los clientes IPv6.

La RFC 3901, guía de transporte DNS IPv6 publicada en septiembre de 2004, distingue la resolución directa del reenvío a un resolutor recursivo de doble pila. Su orientación histórica no equivale a una nueva prohibición de clientes solo IPv6 en 2026. Que el servicio atienda al cliente por IPv6 no significa que toda su recursión hacia las autoridades use únicamente IPv6.

Las propias notas del monitor introducen cautelas sensatas. Las comprobaciones parten de un solo lugar en África y dan más valor a una respuesta DNS que a un ping. La versión 2.15.0 añade preguntas sobre respuestas firmadas grandes y coherencia de delegaciones. Mejorar esas pruebas no convierte el resultado en una verificación mundial de cada sitio.

Este artículo revisa en septiembre una explicación publicada en agosto. Los recuentos antiguos del historial no son mediciones actuales hechas aquí. No hemos ejecutado consultas DNS ni probado aplicaciones; tampoco hemos establecido una caída nacional o un fallo presente de los servidores. La prueba del ccTLD merece conservarse, con una conclusión ajustada a lo que observa.