Resumen

  • El borrador propone que un resolvedor recursivo que no valida DNSSEC retire el bit DO de la consulta ascendente si el cliente tampoco lo pidió.
  • Si después llega un cliente que sí necesita las pruebas, el resolvedor debe detectar que la respuesta guardada carece de ellas y consultar otra vez al servidor autoritativo.

La primera respuesta cabe más cómodamente por la red. Llega otro cliente y pide la firma. La respuesta está en caché; la firma, no. Ese segundo viaje es el precio exacto de Clearing the DO bit for DNSSEC, borrador individual presentado el 30 de octubre por Warren Kumari, Geoff Huston y Peter Thomassen. Es una idea abierta a debate, sin aprobación como norma de la IETF.

DO, «DNSSEC OK», indica que se solicitan registros de seguridad. RFC 3225 y RFC 4035 exigen hoy que un resolvedor recursivo compatible con DNSSEC lo active al consultar aguas arriba, incluso cuando el cliente original no lo activó. Después puede retirar las pruebas de la respuesta al cliente y conservarlas internamente.

El nuevo texto cambia esa secuencia para el resolvedor que no valida y recibe una consulta sin DO: recomienda que también consulte sin DO. El servidor autoritativo omitiría las pruebas automáticas. Las firmas poscuánticas podrían agrandar las respuestas, forzar truncamiento y aumentar las conexiones TCP. Los autores no aportan una medición de ahorro, fallos evitados ni despliegues.

La condición dura aparece en la caché. El resolvedor debe registrar qué entradas se obtuvieron sin registros DNSSEC. Cuando llega una petición con DO para una de ellas, tiene que repetir la consulta con DO. Una respuesta «en caché» no sirve al cliente validador si le faltan los materiales con los que debe verificarla. En la lista DNSOP ya se plantea la alternativa de transportar más DNS por conexiones de flujo en vez de optimizar respuestas UDP pequeñas. La decisión exige probar ambos órdenes de llegada, la validación posterior y la carga total de consultas. Falta una implementación medida con esos tres resultados.

Borrador · RFC 3225 · RFC 4035