Resumen

  • Un contexto DoC protegido prueba un intercambio entre sus extremos, no cómo el servidor obtuvo la respuesta DNS después.
  • Descubrimiento, contexto, consulta, ruta aguas arriba, DNSSEC y aceptación de la aplicación son recibos diferentes.

RFC 9953 lleva una consulta DNS en una solicitud CoAP y devuelve la respuesta en CoAP. DTLS, TLS u OSCORE pueden proteger ese tramo. Es un límite útil: demuestra protección del mensaje entre quienes comparten el contexto, no una propiedad de cada actor posterior.

El servidor puede consultar infraestructura DNS aguas arriba sin protección, por ejemplo mediante DNS sobre UDP. Puede usar un segundo contexto protegido, pero ese hecho es opaco para el cliente DoC. Por ello, un indicador correcto del primer tramo no certifica al autoritativo, al recursor, a una caché ni al enlace posterior.

Tampoco lo certifica la configuración. El cliente debe conocer servidor y recurso, y una configuración automática solo puede proceder de una fuente de confianza. Eso respalda la procedencia de esa elección; no prueba que el servidor validó DNSSEC, que una respuesta concreta es correcta o que la aplicación la aceptó. La expresión de esa confianza queda fuera del alcance de la RFC.

Un registro completo une la fuente de descubrimiento, URI, contexto y vigencia, pregunta, respuesta, evidencia superior cuando se alegue, validación y decisión local. Amsüss es un coautor de un estándar colectivo, no el responsable de un servicio DNS real.

Sources