Resumen

  • La tabla 1 de APNIC registra 51,73 consultas autoritativas por prueba con SERVFAIL y 83,46 sin respuesta, frente a 4,40 con NXDOMAIN, 3,93 con NOERROR/NODATA y 3,43 en el control positivo.
  • El punto de observación es el servidor autoritativo. La prueba no instrumentó toda la ruta entre stub, reenviadores, frontends y motores recursivos, pérdidas, servidores alternativos y transportes. El propio autor deja la causa para otro estudio.
  • RFC 9520 obliga a almacenar temporalmente los fallos y acota la repetición hacia una misma dirección y transporte. La conmutación por otros caminos sigue existiendo: hace falta presupuesto por capa y trazabilidad de extremo a extremo.

Cinco respuestas, cinco incentivos

Una respuesta DNS no sólo describe un resultado. También informa a la siguiente máquina de si tiene sentido insistir. NXDOMAIN niega la existencia del nombre. NOERROR/NODATA conserva el nombre pero niega el tipo solicitado. REFUSED expresa una decisión de política. SERVFAIL reconoce que el servidor no pudo contestar. El silencio no dice nada y entrega la decisión a los temporizadores.

El informe publicado por Geoff Huston el 4 de septiembre convirtió esos matices en una comparación a gran escala. APNIC Labs utilizó scripts dentro de anuncios para provocar consultas sobre nombres aleatorios en zonas experimentales y contó lo que llegó a sus servidores autoritativos.

En la tabla final, una respuesta positiva promedió 3,43 consultas por prueba; NOERROR/NODATA, 3,93; NXDOMAIN, 4,40; REFUSED, 11,47; SERVFAIL, 51,73; y ninguna respuesta, 83,46. La distancia entre una negación reutilizable y un fallo presuntamente transitorio es de un orden de magnitud.

La explicación intuitiva es fácil: una negativa concluyente se almacena, mientras que un fallo ambiguo invita a probar otro servidor o esperar un instante. La explicación causal es más difícil, porque muchos componentes pueden repetir de forma independiente.

La tabla corrige al párrafo, pero no identifica al actor

El artículo fuente presenta dos discrepancias. En el párrafo de SERVFAIL aparece 51,29 como promedio de consultas; en la tabla 1, 51,73 es el promedio de consultas y 51,29 el de repeticiones. El párrafo sin respuesta imprime 11,6050,253 pruebas y un promedio de 82,6; la tabla dice 116.050.253 y 83,46. Aquí se usan los datos del resumen tabular y se deja constancia de la diferencia.

El conjunto SERVFAIL comprende 138.643.924 pruebas y 7.171.673.166 consultas; 6.920.490.780 son repeticiones. Apenas 3.702.576 pruebas terminaron con una sola consulta por cada tipo utilizado. El silencio recibió 9.685.775.212 consultas en el número de pruebas de la tabla, de las cuales 9.466.474.491 fueron repetidas.

Es evidencia suficiente para afirmar que la carga recibida cambia con la clase de respuesta. No basta para repartir responsabilidades. El servidor autoritativo ve paquetes procedentes de sistemas recursivos. No ve necesariamente la decisión original del stub, un reenvío doméstico, la distribución entre frontend y backend, la pérdida que agotó un temporizador, ni si otro cliente abrió una resolución equivalente.

Huston formula exactamente esa incertidumbre: ¿se debe a implementaciones recursivas o a arquitecturas DNS más complejas? Promete volver a ella. Por tanto, 51,73 no es una constante de SERVFAIL, un veredicto contra un producto ni una base para extrapolar todo el tráfico mundial.

El primer paquete no es el único paquete legítimo

La fase NXDOMAIN se realizó del 5 al 11 de agosto de 2026 con 115.750.503 endpoints captados mediante Google Ads. El texto menciona una amplia diversidad geográfica y de plataformas, con Rusia como principal excepción.

El 48% de los equipos preguntó por A y AAAA, el 51% sólo por A, el 1% sólo por AAAA; el 39% generó también consultas HTTPS. Una consulta por cada tipo observado habría dado unos 218 millones. Se recibieron 509.410.787. APNIC atribuye la diferencia de 291.919.927 a repetición. El 57% no superó una consulta por tipo; el grupo que repitió promedió 6,03 repeticiones.

Los nombres eran aleatorios, de modo que no existía una respuesta exacta previamente almacenada. La zona no estaba firmada con DNSSEC: un validador no podía aplicar la síntesis de respuestas negativas de RFC 8198 usando pruebas NSEC/NSEC3. El autoritativo admitía UDP y TCP, no DoT ni DoH; las respuestas eran breves, no truncadas; se contaron llegadas durante 24 horas.

Que NOERROR/NODATA promediara algo menos que NXDOMAIN no autoriza a escoger el código por economía. Sus afirmaciones son distintas. RFC 2308 establece la caché negativa y RFC 8020 permite que NXDOMAIN corte preguntas bajo el nombre inexistente. Una respuesta falsa ahorra paquetes a costa de corromper el espacio de nombres.

El límite de RFC 9520 tiene coordenadas

RFC 9520 convirtió en obligatoria la caché de fallos de resolución: SERVFAIL, servidores inaccesibles, errores de validación DNSSEC y casos afines. Recomienda un periodo inicial entre un segundo y cinco minutos, mínimo configurable y espera progresiva. Tras el intento inicial, limita a dos reintentos adicionales contra la misma dirección de servidor y el mismo transporte.

La motivación incluye episodios reales: más de diez veces el volumen normal durante una tormenta de reintentos en Dyn; ochenta veces más DNSKEY en el cambio de KSK raíz; un experimento de 2021 que pasó de unas 50 a 60.000 consultas por segundo al responder SERVFAIL; y el salto de 7.000 a 900.000 consultas por segundo en .COM/.NET durante la caída de Facebook.

Sin embargo, el estándar no prohíbe probar otros servidores, direcciones o transportes. Tampoco controla todos los reintentos originados más cerca del usuario. Unir preguntas equivalentes que siguen pendientes evita que la concurrencia convierta una política individualmente moderada en una tormenta colectiva.

RFC 8914 permite adjuntar un Extended DNS Error a SERVFAIL. El dato aclara el diagnóstico, pero la norma ordena que no cambie el procesamiento DNS. Explicar un fallo no equivale a convertirlo en una negativa definitiva.

El autor escribe en APNIC, no en nombre de APNIC

El informe tiene firma individual y la advertencia de que las opiniones del autor no representan necesariamente a APNIC. La institución aporta el entorno editorial y APNIC Labs la medición; no por ello el análisis se convierte en una política del registro.

Sí constituye una razón sólida para reproducir la prueba, revisar la distribución temporal y verificar la aplicación de RFC 9520. No prueba incumplimiento de un operador concreto ni aconseja alterar la semántica correcta para reducir tráfico.