Los desarrolladores del servidor DNS BIND han anunciado la incorporaci\u00f3n en la rama experimental 9.17 de la implementaci\u00f3n del soporte del servidor para las tecnolog\u00edas \u00abDNS sobre HTTPS\u00bb (DoH, DNS over HTTPS) y DNS sobre TLS (DoT, DNS over TLS), as\u00ed como un mecanismo de XFR-over-TLS para la transmisi\u00f3n segura del contenido de las zonas DNS entre servidores. DoH est\u00e1 disponible para pruebas en la versi\u00f3n 9.17.10, mientras que el soporte para DoT est\u00e1 presente desde la versi\u00f3n 9.17.7. Tras la estabilizaci\u00f3n, el soporte para DoT y DoH se trasladar\u00e1 a la rama estable 9.16. <\/p>\n
La implementaci\u00f3n del protocolo HTTP\/2, utilizado en DoH, se basa en el uso de la biblioteca nghttp2, que est\u00e1 incluida entre las dependencias de construcci\u00f3n (m\u00e1s adelante, se planea trasladar la biblioteca a las dependencias opcionales). Se admiten tanto conexiones cifradas (TLS) como no cifradas a trav\u00e9s de HTTP\/2. Con la configuraci\u00f3n adecuada, un proceso named ahora puede atender no solo solicitudes DNS tradicionales, sino tambi\u00e9n solicitudes enviadas utilizando DoH (DNS-over-HTTPS) y DoT (DNS-over-TLS). El soporte para HTTPS del lado del cliente (dig) a\u00fan no est\u00e1 implementado. El soporte para XFR-over-TLS est\u00e1 disponible tanto para solicitudes entrantes como salientes. <\/p>\n
El procesamiento de solicitudes utilizando DoH y DoT se activa mediante la adici\u00f3n de las opciones http y tls en la directiva listen-on. Para habilitar DNS sin cifrado sobre HTTP, en la configuraci\u00f3n se debe especificar \u00abtls none\u00bb. Las claves se definen en la secci\u00f3n \u00abtls\u00bb. Los puertos de red est\u00e1ndar 853 para DoT, 443 para DoH y 80 para DNS sobre HTTP pueden ser redefinidos a trav\u00e9s de los par\u00e1metros tls-port, https-port y http-port. Por ejemplo: tls local-tls { key-file \u00ab\/path\/to\/priv_key.pem\u00bb; cert-file \u00ab\/path\/to\/cert_chain.pem\u00bb; }; http local-http-server { endpoints { \u00ab\/dns-query\u00bb; }; }; options { https-port 443; listen-on port 443 tls local-tls http myserver {any;}; } <\/p>\n
De las caracter\u00edsticas de la implementaci\u00f3n de DoH en BIND, se destaca la integraci\u00f3n como un transporte com\u00fan que puede ser utilizado no solo para el procesamiento de solicitudes de clientes al resolutor, sino tambi\u00e9n durante el intercambio de datos entre servidores, al transferir zonas a trav\u00e9s del servidor DNS autoritativo y al procesar cualquier solicitud admitida por otros transportes DNS. <\/p>\n
Otra caracter\u00edstica es la posibilidad de externalizar las operaciones de cifrado para TLS en otro servidor, lo que puede ser necesario en situaciones donde los certificados TLS se almacenan en otro sistema (por ejemplo, en infraestructura con servidores web) y son gestionados por otro personal. Se ha implementado soporte para DNS sin cifrar sobre HTTP para facilitar la depuraci\u00f3n y como un nivel para el reenv\u00edo en la red interna, sobre el cual se puede organizar la encriptaci\u00f3n en otro servidor. En el servidor externo para la generaci\u00f3n de tr\u00e1fico TLS se puede utilizar nginx, de manera similar a c\u00f3mo se organiza el encapsulamiento HTTPS para los sitios. <\/p>\n
Recordemos que DNS-over-HTTPS puede ser \u00fatil para evitar fugas de informaci\u00f3n sobre los nombres de host solicitados a trav\u00e9s de los servidores DNS de los proveedores, luchar contra ataques MITM y la suplantaci\u00f3n de tr\u00e1fico DNS (por ejemplo, al conectarse a Wi-Fi p\u00fablico), y enfrentar bloqueos a nivel de DNS (DNS-over-HTTPS no puede reemplazar VPN<\/a> en el \u00e1mbito de eludir bloqueos, implementados a nivel de DPI) o para organizar el funcionamiento en caso de que no se pueda acceder directamente a los servidores DNS (por ejemplo, al trabajar a trav\u00e9s de un proxy). Si en situaciones normales las solicitudes DNS se env\u00edan directamente a los servidores DNS especificados en la configuraci\u00f3n del sistema, en el caso de DNS-over-HTTPS la solicitud para resolver IP<\/a> el host se encapsula en el tr\u00e1fico HTTPS y se env\u00eda a un servidor HTTP, donde el resolvedor maneja las solicitudes a trav\u00e9s de Web API. <\/p>\n