Bajo éste acrónimo, subyace un nuevo proyecto (2020) con la intención de convertirse en protocolo estándar para la resolución DNS. ODoH vendría a significar ‘DNS sobre Https Ajeno’, o lo que es lo mismo: la comunicación entre el cliente que solicita una resolución de nombres y el servidor que actúa como resolutor, no es directa; sino que tiene lugar mediante un proxy intermedio.
La idea de éste artículo es básicamente la de difundir una idea general sobre el proyecto a partir de lo publicado por uno de sus mayores impulsores: Cloudflare. En parte porque no he podido probarlo en persona (aún está en fase de validación) y en parte porque es complicado explicarlo mejor que la propia gente de Cloudflare.
Las empresas tras ODoH son básicamente tres: Cloudflare, Apple y Fastly. Aunque se supone que se irán sumando de otras a medida que se vaya estandarizando y ganando cuota de implementación (PCCW, SURF y Equinix).
Necesidad de ODoH
Como la mayoría de protocolos surgidos en los primeros tiempos de Internet, DNS no tenía ningún tipo de seguridad o privacidad en su diseño:
«Para proteger el DNS de observadores y terceros, la organización internacional IETF (Internet Engineering Task Force) estandarizó el cifrado de DNS con DNS mediante HTTPS (DoH) y DNS mediante TLS (DoT). Ambos protocolos evitan que las consultas sean interceptadas, redirigidas o modificadas entre el cliente y el resolutor»
Esto planteaba dos cuestiones importantes para la gente de Cloudflare:
La centralización de los servidores introduce puntos únicos de fallo
Caso de producirse una brecha de seguridad, se podrían filtrar todas las consultas y vincularlas a la dirección ip de los usuarios demandantes
La solución aportada:
«ODoH funciona añadiendo una capa de cifrado de clave pública, así como un proxy de red entre los clientes y los servidores de DoH. La combinación de estos dos elementos garantiza que solo el usuario tenga acceso a los mensajes DNS y a su propia dirección IP al mismo tiempo.»
Funcionamiento
Esquema funcionamiento de ODoH
«Hay tres participantes en la ruta de ODoH. Empecemos por el servidor de destino fijándonos en el diagrama que se muestra arriba. El servidor de destino descifra las consultas encriptadas por el cliente a través de un proxy. De manera similar, el servidor de destino encripta las respuestas y las devuelve al proxy. El estándar ni confirma ni desmiente que el destino es el resolutor. El servidor proxy hace lo que se supone que debe hacer un proxy, es decir, reenvía los mensajes entre el cliente y el servidor de destino. El cliente se comporta como lo hace en el DNS y el DoH, pero difiere al cifrar las consultas para el destino y descifrar las respuestas del destino. Cualquier cliente que elija hacerlo puede especificar el servidor proxy y de destino de su elección.
Juntos, el cifrado añadido y el proxy garantizan lo siguiente:
El destino solo ve la consulta y la dirección IP del proxy.
El proxy no tiene visibilidad de los mensajes DNS, ni capacidad para identificar, leer o modificar la consulta que envía el cliente o la respuesta que devuelve el servidor de destino.
Solo el servidor de destino previsto puede leer el contenido de la consulta y generar una respuesta.»
De ésta forma se consigue una independencia absoluta entre el cliente y el servidor DNS. Protegiendo al primero, de cualquier violación que pudiera sufrir el segundo.
Pero la idea va un paso más allá. Dado que la norma establece que el servidor Proxy y el DNS NO pueden convivir conjuntamente, se permite que sea el propio usuario quien eliga una combinación de ambos:
«Es importante que los clientes tengan el control total de la selección de los servidores proxy y de destino. Las consultas de los clientes pueden ser privadas y seguras sin necesidad de programas similares de resolutores recursivos de confianza TRR. El servidor de destino solo conoce el proxy y, por tanto, el destino y cualquier resolutor ascendente son ajenos a la existencia de cualquier dirección IP del cliente. La importancia de esto radica en que los clientes tienen un mayor control de sus consultas y las formas en que pueden ser utilizadas. Por ejemplo, los clientes pueden seleccionar y alterar sus servidores proxy y de destino en cualquier momento, por cualquier razón.»
Flujo de mensajes
Sobre éste aspecto hay mucha información tecnica, así que me limitaré a comentar lo más relevante que expone la propia Cloudflare. Destacar la especial relevancia que adquiere su nueva capa de cifrado entre sesiones TLS:
«En ODoH, la ‘O’ significa oblivious (ajeno), y esta propiedad proviene del nivel de cifrado de los propios mensajes DNS. Este cifrado añadido es «de extremo a extremo» entre el cliente y el servidor de destino y es independiente de la encriptación de nivel de conexión proporcionada por TLS/HTTPS. Uno podría preguntarse por qué se requiere este cifrado adicional en presencia de un proxy. La respuesta es que se necesitan dos conexiones TLS separadas para admitir la funcionalidad del proxy. En concreto, el proxy termina una conexión TLS del cliente, e inicia otra conexión TLS con el destino. Entre esas dos conexiones, los contextos de los mensajes DNS aparecerían en ¡texto sin formato! Por este motivo, ODoH también cifra los mensajes entre el cliente y el destino para que el proxy no tenga acceso al contenido del mensaje.»
Rendimiento
Y acabo con una de las principales dudas que puede suscitar el sistema de funcionamiento que propone ODoH: ¿afectará al rendimiento de las resoluciones DNS el hecho de su doble cifrado y el paso por un segundo servidor (Proxy)?
«Hemos hecho muchas mediciones para averiguarlo, y seguiremos en ello mientras se generaliza la implementación de ODoH. Nuestra serie preliminar de configuraciones de medición abarcó ciudades de Estados Unidos, Canadá y Brasil. Es importante que nuestras mediciones incluyan no solo 1.1.1.1, sino también 8.8.8.8 y 9.9.9.9. Hasta ahora, el conjunto completo de mediciones está documentado para acceso abierto.»
«Lo primero que podemos decir con seguridad es que la encriptación adicional es marginal. Lo sabemos porque seleccionamos al azar 10.000 dominios del conjunto de millones de datos de Tranco y medimos tanto la encriptación del registro A con una clave pública diferente como su descifrado. El coste adicional entre una consulta/respuesta de DoH mediante proxy y su homólogo ODoH es consistentemente menor de 1ms en el percentil 99.»
«…las consultas ODoH se resuelven en menos de 228ms… las consultas DoH se resuelven en menos de 146ms. La mitad de las veces esa diferencia nunca es mayor de 100ms.»
De todo ello se infiere que sí, ODoH aumenta por lo general el tiempo de resolución frente a DoH. Aunque la propia Cloudflare reconoce que es algo sujeto a distintas variables como la cantidad de servidores disponible en cada zona o la combinación Proxy + resolutor DNS elegida.
Aquí tenéis la fuente original, con muchos más detalles técnicos y referencias.