Los desarrolladores del servidor DNS BIND dieron a conocer hace ya varios dias la incorporación a la rama experimental 9.17, la implementación de soporte de servidor para las tecnologías DNS sobre HTTPS (DoH, DNS sobre HTTPS) y DNS sobre TLS (DoT, DNS sobre TLS), así como XFR.
La implementación del protocolo HTTP/2 utilizado en DoH se basa en el uso de la biblioteca nghttp2, que se incluye en las dependencias de la compilación (en el futuro, se planea transferir la biblioteca a las dependencias opcionales).
Con la configuración adecuada, un único proceso con nombre ahora puede atender no solo las solicitudes de DNS tradicionales, sino también las solicitudes enviadas mediante DoH (DNS sobre HTTPS) y DoT (DNS sobre TLS).
El soporte HTTPS del lado del cliente (dig) aún no está implementado, mientras que el soporte XFR-over-TLS está disponible para solicitudes entrantes y salientes.
El procesamiento de solicitudes usando DoH y DoT se habilita agregando las opciones http y tls a la directiva listen-on. Para admitir DNS sobre HTTP sin cifrar, debe especificar «tls none» en la configuración. Las claves se definen en la sección «tls». Los puertos de red estándar 853 para DoT, 443 para DoH y 80 para DNS sobre HTTP se pueden anular a través de los parámetros tls-port, https-port y http-port.
Entre las características de la implementación de DoH en BIND, se destaca que es posible transferir operaciones de cifrado para TLS a otro servidor, lo que puede ser necesario en condiciones en las que el almacenamiento de certificados TLS se realiza en otro sistema (por ejemplo, en una infraestructura con servidores web) y es atendida por otro personal.
El soporte para DNS sobre HTTP no cifrado se implementa para simplificar la depuración y como una capa para el reenvío en la red interna, sobre cuya base se puede organizar el cifrado en otro servidor. En un servidor remoto, nginx se puede utilizar para generar tráfico TLS, por analogía con la forma en que se organiza el enlace HTTPS para sitios.
Otra característica es la integración de DoH como transporte general, que se puede utilizar no solo para procesar las solicitudes del cliente al resolutor, sino también al intercambiar datos entre servidores, al transferir zonas mediante un servidor DNS autorizado y al procesar cualquier solicitud admitida por otros transportes DNS.
Entre las deficiencias que se pueden compensar deshabilitando la compilación con DoH/DoT o moviendo el cifrado a otro servidor, se destaca la complicación general del código base: se agregan un servidor HTTP integrado y una biblioteca TLS a la composición, lo que potencialmente puede contienen vulnerabilidades y actúan como vectores adicionales de ataques. Además, cuando se usa DoH, aumenta el tráfico.
Hay que recordar que DNS-over-HTTPS puede ser útil para evitar filtraciones de información sobre los nombres de host solicitados a través de los servidores DNS de los proveedores, combatir los ataques MITM y falsificar el tráfico DNS, contrarrestar el bloqueo de a nivel de DNS o para organizar el trabajo en caso de imposibilidad de acceso directo a los servidores DNS.
Si, en una situación normal, las solicitudes de DNS se envían directamente a los servidores DNS definidos en la configuración del sistema, entonces, en el caso de DNS sobre HTTPS, la solicitud para determinar la dirección IP del host se encapsula en el tráfico HTTPS y se envía al servidor HTTP, en el que el resolutor procesa las solicitudes a través de la API web.
«DNS sobre TLS» se diferencia de «DNS sobre HTTPS» por utilizar el protocolo DNS estándar (normalmente se utiliza el puerto de red 853) envuelto en un canal de comunicación cifrado organizado utilizando el protocolo TLS con validación de host a través de certificados TLS / SSL certificados por una certificación. autoridad.
Finalmente, se menciona que DoH está disponible para pruebas en la versión 9.17.10 y el soporte DoT ha estado presente desde 9.17.7, además de que una vez estabilizado, el soporte para DoT y DoH se trasladará a la rama estable 9.16.
Fuente: desdelinux
