Resumen

  • RFC 9953 recomienda poner a cero el ID de cabecera DNS para que consultas DoC equivalentes compartan una Cache-Key de CoAP.
  • La reutilización queda limitada por Max-Age y los TTL DNS, y no sustituye la prueba separada de resultado DNS, fuente, validación, política o efecto.

El registro de una automatización suele empezar demasiado tarde. Dice que un cliente recibió una respuesta o que una caché tuvo un acierto. Si después un equipo pregunta por qué se utilizó un nombre, ese registro no basta. Falta saber qué consulta se normalizó, de dónde provenía la representación, qué edad tenía, qué dijo realmente DNS y qué regla local convirtió la respuesta en una acción.

RFC 9953 define DNS over CoAP, DoC, como un intercambio de consultas DNS de OPCODE 0 sobre CoAP. Cada pareja DNS de consulta y respuesta se convierte en una operación de petición y respuesta CoAP. La consulta se lleva en el cuerpo de FETCH y usa application/dns-message, formato de contenido 553. Es una adaptación útil para nodos con memoria, energía, tamaño de trama y latencia restringidos; no es una nueva forma de declarar que una respuesta DNS es verdadera en todos los sentidos operativos.

El ID DNS muestra el diseño. El cliente DoC DEBERÍA usar 0 para que consultas con los mismos datos DNS no generen Cache-Key distintas sólo por un identificador de transacción tradicional. Así, una caché CoAP —por ejemplo, un proxy en ruta— puede devolver la misma representación. El servidor DEBE copiar el ID de la consulta en su respuesta. El cero no identifica al servidor, no autentica el dato y no decide quién puede usarlo. Sólo impide que una variación irrelevante fracture la clave de reutilización.

La norma no deja que esa normalización alargue el tiempo por accidente. El servidor DoC DEBE comprobar que la suma del Max-Age de CoAP y cualquier TTL DNS en la respuesta sea menor o igual que el TTL correspondiente recibido de un DNS ascendente. Si no aparece la opción, también cuenta el Max-Age por defecto de 60 segundos. Al recibir la respuesta, el cliente DoC DEBE sumar el Max-Age a todos los TTL DNS y usar los TTL calculados. La hora del transporte y la hora del DNS forman una sola restricción de vida, no dos adornos intercambiables.

RFC 9953 recomienda tomar el TTL DNS mínimo como Max-Age y restarlo de todos los TTL del cuerpo. Con ello una caché intermedia no debería servir un registro expirado de forma involuntaria, y un ETag que depende del contenido puede mantenerse aunque una caché ascendente haya refrescado el TTL restante. Las respuestas de error que sólo deben durar poco pueden tener un Max-Age menor o cero. Es una disciplina de caducidad, no una licencia para suponer que toda entrada retenida tiene la misma importancia.

También hay dos resultados que conservar. Una respuesta DNS que puede analizarse se recomienda dentro de un 2.05 Content de CoAP incluso si DNS trae NXDOMAIN u otro RCODE de error. Los códigos CoAP no exitosos se reservan para fallos de la capa CoAP o para peticiones que no cumplen DoC. Un tablero que sólo conserva el código exterior puede anunciar éxito donde DNS informó un problema. Un tablero que sólo conserva RCODE puede borrar que el transporte funcionó y que el problema estaba aguas arriba.

La procedencia no queda resuelta por una representación cacheada. RFC 9953 admite que el servidor DoC sea autoritativo, stub o recursivo, y que PUEDA ser validador DNSSEC. También permite proteger mensajes con (D)TLS u OSCORE. Ninguna de esas posibilidades obliga a que todo despliegue valide DNSSEC, fija una política local o prueba que una aplicación consumió el dato. La lectura editorial de Daniel Kade a partir de Heng Lu conserva esta diferencia: una especificación común hace compatible el mecanismo; la decisión posterior sigue siendo localizada y comprobable.

Fuentes