Resumen

  • RFC 9520 obliga a almacenar un fallo de resolución entre un segundo y cinco minutos. Mientras la entrada coincide, el resolutor no envía trabajo equivalente hacia arriba; no afirma NXDOMAIN ni NODATA.
  • El fallo sólo existe después de que ningún servidor ni transporte disponible entregue datos, una remisión descendente o una negativa útil.
  • Una decisión defendible conserva intentos, reintentos, consultas de clientes agrupadas, clave y alcance del caché, retroceso, consultas a ancestros evitadas, presión de recursos y prueba de recuperación.

El día en que una ausencia de ruta se convirtió en 900.000 preguntas

El 4 de octubre de 2021, una orden de mantenimiento desconectó por error los centros de datos de Facebook de su red troncal. El informe de Meta explica que sus instalaciones DNS autoritativas retiraron los anuncios BGP al perder comunicación con esos centros. Los servidores seguían encendidos; para Internet, sin embargo, sus direcciones ya no eran alcanzables.

Verisign observó el efecto fuera de la red afectada. facebook.com, instagram.com y whatsapp.net generaban normalmente unas 7.000 consultas por segundo en la infraestructura .com y .net. Durante la caída de casi seis horas, el total superó las 900.000 por segundo. Las fuentes recursivas más activas de Google y Cloudflare alcanzaron picos cercanos a 7.000 y 2.000 veces sus tasas habituales para esos nombres.

La delegación en los padres no había cambiado. Volver a pedirla no podía reconstruir una ruta retirada por el hijo. Aun así, el patrón de reintento trasladó la carga de una zona inaccesible a sistemas superiores que funcionaban correctamente. La avería ya no era únicamente de Facebook: el modo de preguntar de los resolutores se había convertido en parte del mecanismo de impacto.

RFC 9520 exige una respuesta limitada. Si ninguna vía disponible produce información útil, el resolutor guarda el fallo. Una petición posterior que coincida con esa entrada no debe originar consultas salientes hasta su vencimiento. El registro significa «este trabajo acaba de fracasar y no lo repetiré todavía». No significa «el nombre no existe».

NXDOMAIN y NODATA son negativas con contenido. El fallo de resolución es la falta de información útil sobre la existencia de los datos. Confundirlos convierte una decisión de capacidad en una afirmación sobre una zona que nunca habló.

Agotar opciones antes de pronunciar el fallo

Un resolutor suele disponer de varios servidores NS, varias direcciones por nombre y, a veces, varios transportes por dirección. Un cliente también puede conocer más de un servicio recursivo. Por ello, un timeout, un SERVFAIL o un REFUSED aislado no bastan.

RFC 9520 considera útil una respuesta que contiene los datos solicitados, una remisión a una zona descendente o una indicación válida de que esos datos no existen en el nombre consultado. Si cualquier servidor disponible produce una de ellas, la resolución no ha fallado. El expediente debe enumerar la matriz completa de direcciones y transportes y el resultado terminal de cada intento.

Para una misma pregunta, dirección y transporte, sólo se permiten dos reintentos después del primer envío: tres consultas en total. Es posible probar otro transporte conocido en la misma dirección si cumple la política de seguridad. La norma no impone un timeout universal; menciona valores habituales aproximados de tres a treinta segundos.

La autonomía sobre ese valor tiene una condición: debe ser observable. Distintas rutas, puntos anycast y presupuestos de servicio justifican distintas esperas. Lo que no puede justificarse es una etiqueta genérica de fallo que oculte caminos no intentados o cronologías incompatibles.

Un RCODE no sustituye el diagnóstico

SERVFAIL puede significar que un autoritativo carece de una copia válida de la zona, que un recursivo agotó sus caminos o que DNSSEC no validó. REFUSED suele expresar política o alcance. Un timeout indica que no llegó respuesta dentro del plazo local; ICMP, TCP o TLS pueden terminar antes el transporte. Una delegación circular, una cadena CNAME que vuelve al origen y un FORMERR tienen mecanismos distintos.

La caché puede conservar esa diversidad, pero el efecto común es pequeño: suspender trabajo saliente equivalente. No puede transformar REFUSED en SERVFAIL, datos bogus en datos validados ni silencio en inexistencia.

RFC 8914 permite añadir Extended DNS Errors como Cached Error, No Reachable Authority o DNSSEC Bogus. Mejoran la explicación, pero no alteran el procesamiento del RCODE. Un EDE es contexto operativo, no una firma de la autoridad.

Agrupar primero, reintentar después, recordar al final

Cuando un nombre popular deja de responder, cientos de clientes pueden presentar el mismo QNAME, QTYPE y QCLASS mientras el primer intento espera. Un resolutor que agrupa consultas idénticas crea una sola transacción ascendente y vincula a ella todos los clientes. Uno que no agrupa replica el trabajo y sus reintentos.

El experimento presentado en DNS-OARC 35, citado por RFC 9520, midió cerca de 50 consultas por segundo para un dominio de botnet cuando sus autoritativos respondían normalmente. Con todos devolviendo SERVFAIL, el flujo llegó aproximadamente a 60.000 por segundo; la raíz y el TLD también recibieron más tráfico pese a que la delegación no había cambiado.

La agrupación también reduce el riesgo descrito por RFC 5452: varias transacciones equivalentes pendientes aumentan la probabilidad de que una respuesta falsificada coincida con alguna. Hay, por tanto, tres controles independientes. Agrupar demanda simultánea. Limitar a tres los envíos por dirección y transporte. Guardar el fallo después de agotar las opciones.

Cada uno actúa en un momento diferente. La agrupación controla cuántas transacciones existen. El límite controla cuánto trabajo recibe un camino. La caché controla cuándo se vuelve a abrir trabajo futuro. Declarar únicamente «negative caching activo» no demuestra los otros dos.

El precio oculto del retroceso

La duración obligatoria tiene un suelo de un segundo y un techo de cinco minutos. El mínimo debería poder configurarse. Los fallos persistentes pueden aumentar el intervalo de forma lineal o exponencial, sin superar el máximo.

Un intervalo mayor reduce la carga durante una caída estable, pero puede mantener a los clientes detrás de un error cuando el servicio ya se ha reparado. Uno menor descubre antes la recuperación, a costa de repetir más trabajo. El retroceso protege capacidad y, al mismo tiempo, acumula deuda de recuperación.

Cada entrada necesita clave, alcance, causas, hora de inserción, duración efectiva, etapa de retroceso, vencimiento y versión de configuración. Al vencer, debe salir una prueba controlada, no toda la demanda acumulada. La primera respuesta útil elimina la base de la supresión. La métrica importante es el tiempo entre la posibilidad real de responder y la primera respuesta entregada al cliente.

El alcance depende del diseño. Un fallo DNSSEC puede asociarse a nombre, clase y tipo. Una dirección inalcanzable puede generar estado por IP. Un SERVFAIL de un servidor no necesariamente bloquea a sus pares. RFC 2308 definía alcances concretos cuando almacenar estos fallos era opcional. RFC 9520 lo hace obligatorio, pero deja la estructura al implementador, que debe documentarla para el operador.

Preguntar al padre no repara al hijo

Algunos resolutores, ante una zona completamente muda, volvían a solicitar al padre el conjunto NS. RFC 4697 prohibió esa repetición agresiva. RFC 9520 amplía la regla a todos los tipos de consulta y a todos los ancestros: si el trabajo hacia la zona está limitado, la repetición equivalente hacia arriba también debe estarlo.

Un padre sano puede repetir una delegación exacta sin tener poder para restaurar la red del hijo. Omitir la consulta no declara obsoleta esa delegación. Declara que, dentro del intervalo actual, repetirla no aporta información útil.

Conviene medir cuántas consultas a padres y ancestros se evitan. El dato muestra la carga que la avería habría desplazado. Una prueba controlada tras el vencimiento conserva la capacidad de descubrir una nueva delegación o dirección. La supresión es legítima precisamente porque termina.

DNSSEC: recordar el fallo sin confiar en su TTL

RFC 4035 permitía una caché BAD para evitar validaciones repetidas que probablemente volverían a fallar. Como los datos no validados no ofrecen un TTL fiable, el resolutor asigna una duración local pequeña y protege la memoria contra abuso.

RFC 9520 convierte aquella posibilidad en obligación. Los fallos de validación deben guardarse. La norma no autoriza a entregar el RRset inválido como seguro; autoriza a recordar que el intento reciente no produjo datos aceptables.

Un EDE puede explicar que el error proviene del caché o de una validación bogus. El expediente sigue necesitando cadena, momento, alcance y siguiente prueba. Una explicación comprensible no reemplaza la evidencia criptográfica.

Serve Stale y la caché de fallo no prometen lo mismo

RFC 8767 permite servir datos caducados cuando falla su actualización y la política local lo acepta. Recomienda espaciar las comprobaciones de una autoridad fallida, a menudo unos treinta segundos. Su objetivo es continuidad con datos antiguos que alguna vez fueron útiles.

RFC 9520 también actúa cuando no existen datos antiguos: un nombre nuevo, un tipo nuevo o una política sin Serve Stale. Un stale answer dice «puedo reutilizar temporalmente este dato». El fallo cacheado dice «ningún camino produjo un dato útil; no repetiré todavía». Uno entrega contenido; el otro contiene trabajo.

La telemetría debe separar ambos estados. Dos resolutores pueden evitar la misma cantidad de tráfico ascendente y ofrecer experiencias completamente distintas al cliente.

La caché protectora también consume poder y memoria

Un atacante puede generar innumerables nombres o tipos que fallen para agotar entradas, CPU y memoria. El operador necesita límites y métricas de cardinalidad, bytes, inserciones, expulsiones, concentración por fuente o zona y crecimiento de etiquetas aleatorias.

Además, los mensajes de fallo no son datos firmados. Una respuesta falsificada que coincida con una transacción puede lograr que el resolutor deje de consultar a una autoridad real durante el retroceso. El techo de cinco minutos limita un episodio, pero la falsificación repetida puede renovarlo. La defensa exige transacciones pendientes reducidas, evidencia de transporte y comparación entre servidores y puntos de observación.

La caché es un cortacircuitos con carga probatoria. Sin límite, el reintento se convierte en ataque involuntario. Sin alcance y vencimiento, el cortacircuitos se convierte en denegación.

Qué debe contener el recibo del fallo

Registrar QNAME, QTYPE, QCLASS, hora inicial y grupo de clientes unido. Enumerar corte de zona, NS, direcciones, punto de observación y transportes. Para cada intento, guardar inicio, fin, ordinal y resultado, junto con la prueba de respuesta útil.

Si se agotan los caminos, separar RCODE, error de transporte, DNSSEC y EDE. Añadir clave, alcance, inserción, duración, etapa, vencimiento y prioridad de expulsión. Anotar consultas a ancestros evitadas, disponibilidad stale y respuesta efectiva al cliente.

En la flota, comparar preguntas entrantes, grupos unidos y consultas salientes. Publicar amplificación, latencia, CPU, memoria y cardinalidad. Tras vencer, identificar la sonda, su destino, la primera respuesta útil y el retraso visible de recuperación.

Ese recibo mantiene la decisión en manos de quien soporta sus costes. No pide al padre ni al IETF que certifiquen un temporizador local. Exige que el operador demuestre por qué dejó de preguntar y cuándo volvió a hacerlo.

Fuentes