Resumen

  • draft-hardaker-dnsop-nothing-new-00 propone combinar TC con una señal NN y un registro LARGE de 16 bits para que un resolvedor pueda evitar volver a obtener un RRset voluminoso que parece no haber cambiado.
  • Es un Internet-Draft individual, expresamente incompleto y no implementable. Datatracker no le asigna flujo ni estado RFC previsto, mientras el encabezado dice Standards Track.
  • El borrador permite enviar LARGE sin su firma cuando esta no cabe. Su argumento de seguridad compara esa pista con la capacidad existente de provocar uso de datos obsoletos mediante pérdida de paquetes; no autentica la pista ni prueba que el caché sea actual.
  • La operación segura conserva por separado procedencia de NN, vínculo del identificador con el RRset, vigencia DNSSEC, estado de cada autoridad, política de caché, decisión de transporte y resultado del cliente.

La señal pequeña controla la adquisición de la prueba grande

La motivación es comprensible. Una respuesta DNS grande puede superar el espacio disponible en UDP, llegar con TC y obligar a otra consulta sobre un transporte fiable. Claves y firmas poscuánticas podrían aumentar el tamaño, aunque la revisión 00 no aporta mediciones, adopción ni previsiones de despliegue.

El mecanismo intenta evitar repetir una transferencia cuando el resolvedor ya posee el mismo RRset. El servidor autoritativo enviaría NN junto con TC para indicar que el registro solicitado no cambió recientemente. LARGE aportaría un identificador compacto. Si coincide con el asociado al caché, el resolvedor podría seguir usando el objeto existente.

El orden importa. La comparación se realiza antes de descargar el objeto completo. Por tanto, la pista decide si se adquirirá la evidencia capaz de refutarla. Esa estructura exige un registro más rico que match=true.

El recibo mínimo nombra al servidor, vista, nombre, tipo, clase, hora, bits TC y NN, identificador LARGE, autenticación, método de generación y hash exacto del RRset almacenado. Sin esos datos, una decisión local se convierte retrospectivamente en una afirmación imposible de auditar sobre “el DNS”.

Una pista sin firma no se vuelve auténtica por ser plausible

La revisión 00 dice que, si la firma de LARGE cabe en la respuesta, debe incluirse. Si no cabe, el registro debería enviarse sin ella. Esa segunda rama concentra el problema: datos no firmados influyen en la decisión de no recuperar datos firmados.

La sección de seguridad no lo oculta. Sostiene que un adversario en el camino capaz de falsificar la señal ya podría descartar solicitudes o respuestas y hacer que el resolvedor use datos obsoletos después de un tiempo de espera. NN podría acelerar un resultado que ya era posible.

Esa comparación acota la capacidad marginal del atacante. No demuestra quién produjo NN, qué generación comparó ni si la política local de datos obsoletos autoriza el mismo resultado. Tampoco prueba que acelerar la transición carezca de impacto: elimina el intervalo y las alarmas que habría producido un fallo de actualización.

El sistema debe registrar cuatro cosas distintas: autenticidad de NN, autenticidad de LARGE, validez del RRSIG del RRset en caché y autorización de la política para reutilizarlo. Un indicador único llamado secure no puede representar esas cuatro autoridades.

Una firma vigente no expresa intención actual

DNSSEC valida un RRset concreto durante un intervalo concreto bajo una cadena concreta. Un RRSIG no vencido prueba esa relación criptográfica. No prueba que el operador no haya querido reemplazar los datos, que todas las autoridades hayan cargado el reemplazo o que el resolvedor haya elegido la genealogía correcta del caché.

Esta separación es especialmente importante durante rotaciones DNSKEY, cambios de delegación o recuperación. La generación antigua puede seguir verificándose mientras la nueva ya se publica en parte del conjunto autoritativo. Llamar “actual” a la antigua porque su firma sigue siendo válida confunde admisibilidad criptográfica con estado operativo.

La fecha de expiración sirve como límite, no como recibo de intención. El monitoreo debe conservar inicio y fin del RRSIG, hash del RRset, identificador, autoridad observada y cualquier evidencia de una generación posterior. Sólo así puede explicar por qué una respuesta era verificable pero no necesariamente la más reciente.

Dieciséis bits necesitan linaje

LARGE contiene un identificador de 16 bits que debe ser único durante la vida de las firmas de los datos representados. No es un número de versión global ni permanente.

El borrador permite hashes, contadores, marcas temporales o valores derivados del contenido. Cada opción necesita reglas propias. Un hash truncado tiene colisiones; un contador exige persistencia y coordinación; una marca temporal necesita resolución y conducta de reinicio; una derivación exige una representación canónica.

Dos valores iguales sólo son comparables si pertenecen al mismo nombre, tipo, clase, vista, perfil de generación y época sin reutilización. Restaurar una configuración antigua, reiniciar un contador o mezclar vistas puede fabricar igualdad entre objetos diferentes.

Por eso el recibo debe vincular la cifra corta a un hash completo del RRset y a la autoridad que la emitió. La cifra agiliza el protocolo. El hash y la procedencia sostienen la auditoría.

Un servidor no es el conjunto autoritativo

Primarias, secundarias e instancias anycast pueden servir generaciones distintas durante transferencia, carga o fallo parcial. Una respuesta NN describe la comparación del servidor alcanzado. No es un quórum.

Si una autoridad conserva A y otra ya sirve B, el caché con A puede coincidir honestamente con la primera. La decisión local es coherente, pero no prueba convergencia. La política debe declarar cuándo una muestra basta y cuándo una transición sensible exige observar un conjunto nombrado.

“Todas las autoridades” debe tener denominador. Una dirección anycast no revela cada instancia. Repetir consultas desde el mismo punto no enumera la red. La observación puede ser representativa sin convertirse en universal.

El mismo límite existe después del caché. Que un cliente reciba A de un resolvedor no demuestra qué recibieron otros clientes, ni que la aplicación lograra su objetivo. Cada capa requiere su propio recibo.

TC no declara inútil a TCP

TC dice que la respuesta disponible fue truncada. No afirma que TCP esté roto, que una consulta fiable no añada información o que el objeto omitido sea idéntico. RFC 7766 mantiene el transporte fiable dentro del contrato DNS completo.

Suprimir la nueva consulta es una acción del resolvedor. Debe quedar registrada como política: entradas, clase de riesgo, alternativa disponible y resultado. No se volvió a obtener es una descripción correcta. Se probó que estaba fresco añade una conclusión que no llegó por la red.

La sensibilidad puede variar. Una consulta rutinaria quizá favorezca el ahorro. Una rotación de claves, un cambio de delegación o una recuperación puede exigir descarga completa, observación múltiple o suspensión manual. El protocolo no debe borrar esa elección de gobierno.

Las pruebas de running code deben mantener TCP funcional mientras se falsifica NN, reutilizar un identificador, hacer vencer la firma, dividir las autoridades y expulsar el caché entre comparación y respuesta. El objetivo es comprobar que el sistema conserva incertidumbre y sigue su política, no obligarlo a producir siempre verde.

Datos obsoletos y datos actuales no son la misma promesa

RFC 8767 permite servir datos obsoletos bajo reglas limitadas cuando falla la actualización. Ese mecanismo explica por qué un atacante que descarta paquetes ya puede influir en el caché. No autoriza llamar actual a todo dato reutilizado.

Un timeout documenta que el intento de refresco no terminó. NN documenta que un servidor afirmó que el refresco no era necesario. Ambos pueden acabar sirviendo los mismos bytes, pero cambian el diagnóstico, la escalada y la confianza.

Las métricas útiles distinguen caché válido por TTL, válido por firma, retenido tras NN autenticado, retenido tras NN no autenticado, servido obsoleto después de fallo y actualizado por transporte fiable. Un porcentaje agregado de aciertos oculta justo el mecanismo que importa en un incidente.

La continuidad de la aplicación tampoco resuelve la cuestión. Un servicio puede funcionar con datos antiguos o fallar con datos nuevos correctos. El resultado es evidencia adicional, no una máquina de reescribir el pasado.

El documento tampoco es un recibo de despliegue

Al congelar la evidencia, Datatracker calificaba la revisión 00 como Internet-Draft individual activo, sin flujo, AD responsable, telechat ni estado RFC previsto. Su página aclara que no tiene respaldo formal del IETF. El encabezado del documento, en cambio, decía Standards Track.

El propio texto declara que está muy incompleto y no es implementable. IANA sigue en TBD. La sección DNSSEC anuncia ideas todavía no escritas. Formato, ubicación y posible señal del resolvedor hacia el padre aparecen como discusión.

No hay base para afirmar asignaciones finales, compatibilidad, soporte de productos, ahorro medido, despliegue PQC o incidentes. Sí hay base para examinar qué evidencia tendría que conservar una optimización futura.

El producto operativo es el grafo de recibos

El grafo comienza con consulta y caché. Añade autoridad y vista; TC, NN y LARGE; autenticación y perfil del identificador. La comparación enlaza las cifras pequeñas con hashes completos, intervalos de firma y época.

Luego aparece la decisión: recuperar o no, bajo qué política. Transporte, admisión en caché, respuesta al cliente y efecto de aplicación son nodos posteriores. Ninguno reemplaza al anterior.

Una conclusión defendible puede decir: “la autoridad X envió NN no autenticado; Y coincidió con el RRset Z, cuya firma vencía en T; la política P evitó una recuperación”. Esa frase no exagera. También permite revisar la decisión cuando cambien el riesgo o la evidencia.

La pregunta de liderazgo es quién puede autorizar la no adquisición de una prueba más costosa. La eficiencia es legítima. También lo es exigir evidencia más fuerte en transiciones irreversibles. El error sería permitir que una señal pequeña, precisamente porque evitó mirar de nuevo, se convierta en prueba de que nada cambió.

Fuentes