Despu\u00e9s de dos a\u00f1os de desarrollo, el consorcio ISC ha presentado la primera versi\u00f3n estable de la nueva y significativa rama del servidor DNS BIND 9.18. El soporte para la rama 9.18 se mantendr\u00e1 durante tres a\u00f1os, hasta el segundo trimestre de 2025, como parte de un ciclo de soporte ampliado. El soporte para la rama 9.11 finalizar\u00e1 en marzo, y el de la rama 9.16 a mediados de 2023. Para el desarrollo de la funcionalidad de la pr\u00f3xima versi\u00f3n estable de BIND, se ha formado una rama experimental BIND 9.19.0. <\/p>\n
La versi\u00f3n BIND 9.18.0 se destaca por la implementaci\u00f3n del soporte para las tecnolog\u00edas 'DNS sobre HTTPS' (DoH, DNS over HTTPS) y DNS sobre TLS (DoT, DNS over TLS), as\u00ed como el mecanismo XoT (XFR-over-TLS) para la transferencia segura del contenido de las zonas DNS entre servidores (se admite tanto la entrega como la recepci\u00f3n de zonas por XoT). Con la configuraci\u00f3n adecuada, un proceso named ahora puede atender no solo solicitudes DNS tradicionales, sino tambi\u00e9n solicitudes enviadas utilizando DNS-over-HTTPS y DNS-over-TLS. El soporte del cliente para DNS-over-TLS est\u00e1 incorporado en la utilidad dig, que puede utilizarse para enviar solicitudes a trav\u00e9s de TLS especificando la opci\u00f3n '+tls'. <\/p>\n
La implementaci\u00f3n del protocolo HTTP\/2, utilizado en DoH, se basa en el uso de la biblioteca nghttp2, que se incluye entre las dependencias de construcci\u00f3n opcionales. Los certificados para DoH y DoT pueden ser proporcionados por el usuario o generados autom\u00e1ticamente al iniciar. <\/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 soportar DNS sin cifrado sobre HTTP, se debe especificar 'tls none' en la configuraci\u00f3n. Las claves se definen en la secci\u00f3n 'tls'. Los puertos de red est\u00e1ndar 853 para DoT, 443 para DoH y 80 para DNS-over-HTTP pueden ser sobrescritos a trav\u00e9s de los par\u00e1metros tls-port, https-port y http-port. Por ejemplo: <\/p>\n
tls local-tls { key-file '\/path\/to\/priv_key.pem'; cert-file '\/path\/to\/cert_chain.pem'; }; http local-http-server { endpoints { '\/dns-query'; }; }; options { https-port 443; listen-on port 443 tls local-tls http myserver {any;}; } <\/p>\n
Entre las caracter\u00edsticas de la implementaci\u00f3n de DoH en BIND se destaca la posibilidad de delegar las operaciones de cifrado para TLS a otro servidor, lo que puede ser necesario en situaciones donde los certificados TLS se almacenan en otro sistema (por ejemplo, en una infraestructura con servidores web) y son gestionados por otro personal. El soporte de DNS-over-HTTP no cifrado se ha implementado para facilitar la depuraci\u00f3n y como un nivel para redirigir a otro servidor en la red interna (para delegar el cifrado a un servidor separado). En el servidor delegado, se puede utilizar nginx para generar tr\u00e1fico TLS, similar a c\u00f3mo se organiza la envoltura HTTPS para los sitios. <\/p>\n
Otra caracter\u00edstica es la integraci\u00f3n de DoH como un transporte com\u00fan, que puede aplicarse no solo para manejar las solicitudes de los clientes al resolutor, sino tambi\u00e9n en el intercambio de datos entre servidores, durante la transferencia de zonas por parte del servidor DNS autoritativo y al manejar cualquier solicitud admitida por otros transportes DNS. <\/p>\n
Entre las desventajas que se pueden compensar desactivando la construcci\u00f3n con DoH\/DoT o trasladando el cifrado a otro servidor, se destaca la complejidad general de la base de c\u00f3digo: se agrega un servidor HTTP incorporado y una biblioteca TLS, que potencialmente pueden contener vulnerabilidades y actuar como vectores adicionales para ataques. Adem\u00e1s, al utilizar DoH, aumenta el tr\u00e1fico. <\/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 \u00abDNS sobre TLS\u00bb se diferencia de \u00abDNS sobre HTTPS\u00bb por el uso del protocolo DNS est\u00e1ndar (normalmente se utiliza el puerto de red 853), envuelto en un canal de comunicaci\u00f3n cifrado, organizado mediante el protocolo TLS con la verificaci\u00f3n de validez del host a trav\u00e9s de certificados TLS\/SSL, emitidos por una autoridad certificadora. El est\u00e1ndar actual DNSSEC utiliza cifrado \u00fanicamente para la autenticaci\u00f3n del cliente y del servidor, pero no protege el tr\u00e1fico de la interceptaci\u00f3n ni garantiza la confidencialidad de las consultas. <\/p>\n Algunas otras novedades: <\/p>\n\n