Resumen

  • DoH protege el canal entre cliente y resolutor, pero no decide cuál corresponde al contexto del usuario.
  • El descubrimiento puede conservar el servicio cifrado del resolutor de red; la política del cliente sigue tomando la decisión final.
  • El espacio de nombres, el filtrado, el repliegue y la jurisdicción de los registros cambian con la selección.
  • Un mapa de política debe unir designación, autenticación, selección, contexto de nombres y prácticas de datos.

Imaginemos un caso hipotético. Dos portátiles administrados entran en la misma red de oficina. El sistema operativo del primero descubre y valida el servicio cifrado del resolutor designado por la red; el nombre de una aplicación interna sigue funcionando. En el segundo, el navegador selecciona un servicio DoH público. El túnel cifrado está sano, pero el nombre privado deja de existir y el filtro DNS de la red queda fuera del camino. No hay una avería criptográfica: cambió la autoridad que resuelve.

RFC 8484 describe cada consulta y respuesta DNS como un intercambio HTTPS protegido por TLS. Así mejora la confidencialidad y la integridad. El propio estándar advierte que, con política local o DNS dividido, distintos servidores pueden devolver respuestas diferentes. También señala que la inspección basada en DNS sin cifrar deja de funcionar ante DoH. La mejora del transporte descubre, por tanto, una decisión de gobierno: qué componente escoge el servicio que contestará.

RFC 9462 permite descubrir un Designated Resolver y pasar de un resolutor conocido a un servicio cifrado del mismo operador o de uno que coopera con él. Verified Discovery exige una cadena de certificados válida y un subjectAltName de dirección IP que cubra al resolutor que designa. Opportunistic Discovery admite el servicio cifrado cuando comparte la dirección IP del servicio no cifrado y recomienda ese modo solo para direcciones privadas o locales. Protege el transporte sin autenticar la identidad del resolutor mediante el nombre del certificado. Ambos métodos ofrecen garantías distintas y ninguno impone una selección universal.

RFC 9463 permite que una red anuncie resolutores cifrados mediante DHCPv4, DHCPv6 o Router Advertisements de IPv6. La designación puede incluir dominio de autenticación, direcciones, protocolos y prioridad. Sin embargo, el cliente conserva su política: puede aceptar la oferta, compararla con otra configuración o rechazarla. La responsabilidad se reparte entre red, sistema operativo, aplicación y operador del resolutor.

También se mueve el gobierno de los datos. RFC 8932 recomienda minimizar la recopilación, conservar datos operativos durante el menor tiempo viable, limitar el acceso del personal y explicar las prácticas. Cuando una aplicación cambia de resolutor puede cambiar a la vez el lugar de procesamiento, la retención, la jurisdicción y la evidencia disponible para investigar un incidente.

La respuesta práctica es un mapa de política del resolutor. Para cada grupo de clientes y contexto de red, debe registrar al responsable de la política y el momento de la decisión, quién lo designó, cómo se autenticó su identidad, qué componente lo seleccionó, qué espacio de nombres sirve, qué controles aplica y qué repliegue admite. También debe identificar quién gobierna consultas y registros, durante cuánto tiempo se conservan y qué jurisdicción se aplica. Las pruebas deben cubrir nombres públicos y privados y repetirse ante cambios del navegador, del sistema, de DHCP, de certificados o del extremo del servicio.

Fuentes