Depois de dois anos de desenvolvimento, o cons\u00f3rcio ISC apresentou o primeiro lan\u00e7amento est\u00e1vel da nova e significativa vers\u00e3o do servidor DNS BIND 9.18. O suporte para a vers\u00e3o 9.18 ser\u00e1 mantido por tr\u00eas anos at\u00e9 o segundo trimestre de 2025, como parte de um ciclo de suporte expandido. O suporte para a vers\u00e3o 9.11 ser\u00e1 encerrado em mar\u00e7o, e para a vers\u00e3o 9.16, em meados de 2023. Para o desenvolvimento de funcionalidade na pr\u00f3xima vers\u00e3o est\u00e1vel do BIND, foi formada a vers\u00e3o experimental BIND 9.19.0. <\/p>\n
A vers\u00e3o BIND 9.18.0 \u00e9 not\u00e1vel pela implementa\u00e7\u00e3o de suporte \u00e0s tecnologias \u201cDNS sobre HTTPS\u201d (DoH, DNS over HTTPS) e DNS sobre TLS (DoT, DNS over TLS), bem como um mecanismo XoT (XFR-over-TLS) para a transfer\u00eancia segura de conte\u00fados de zonas DNS entre servidores (suporta tanto a entrega quanto a recep\u00e7\u00e3o de zonas via XoT). Com as configura\u00e7\u00f5es adequadas, um processo named agora pode atender n\u00e3o apenas \u00e0s consultas DNS tradicionais, mas tamb\u00e9m \u00e0s consultas enviadas usando DNS-over-HTTPS e DNS-over-TLS. O suporte do cliente para DNS-over-TLS est\u00e1 integrado na ferramenta dig, que pode ser utilizada para enviar consultas atrav\u00e9s de TLS ao especificar a flag \u201c+tls\u201d. <\/p>\n
A implementa\u00e7\u00e3o do protocolo HTTP\/2, utilizado no DoH, \u00e9 baseada na biblioteca nghttp2, que est\u00e1 entre as depend\u00eancias opcionais para compila\u00e7\u00e3o. Certificados para DoH e DoT podem ser fornecidos pelo usu\u00e1rio ou gerados automaticamente durante a inicializa\u00e7\u00e3o. <\/p>\n
O processamento de consultas usando DoH e DoT \u00e9 ativado atrav\u00e9s da adi\u00e7\u00e3o das op\u00e7\u00f5es \u201chttp\u201d e \u201ctls\u201d na diretiva listen-on. Para suportar DNS-over-HTTP n\u00e3o criptografado, as configura\u00e7\u00f5es devem especificar \u201ctls none\u201d. As chaves s\u00e3o definidas na se\u00e7\u00e3o \u201ctls\u201d. As portas de rede padr\u00e3o 853 para DoT, 443 para DoH e 80 para DNS-over-HTTP podem ser sobrepostas atrav\u00e9s dos par\u00e2metros tls-port, https-port e http-port. Por exemplo: <\/p>\n
tls local-tls { key-file \u2018\/path\/to\/priv_key.pem\u2019; cert-file \u2018\/path\/to\/cert_chain.pem\u2019; }; http local-http-server { endpoints { \u2018\/dns-query\u2019; }; }; options { https-port 443; listen-on port 443 tls local-tls http myserver {any;}; } <\/p>\n
Entre as caracter\u00edsticas da implementa\u00e7\u00e3o do DoH no BIND destaca-se a possibilidade de mover as opera\u00e7\u00f5es de criptografia para TLS para outro servidor, o que pode ser necess\u00e1rio em situa\u00e7\u00f5es onde os certificados TLS s\u00e3o armazenados em outro sistema (por exemplo, em uma infraestrutura com servidores web) e s\u00e3o geridos por outra equipe. O suporte para DNS-over-HTTP n\u00e3o criptografado \u00e9 implementado para facilitar a depura\u00e7\u00e3o e servir como um n\u00edvel para encaminhamento para outro servidor na rede interna (para mover a criptografia para um servidor separado). No servidor externo, o nginx pode ser utilizado para formar o tr\u00e1fego TLS, semelhante \u00e0 forma como a liga\u00e7\u00e3o HTTPS \u00e9 organizada para sites. <\/p>\n
Outra caracter\u00edstica \u00e9 a integra\u00e7\u00e3o do DoH como um transporte comum, que pode ser aplicado n\u00e3o apenas para o processamento das solicita\u00e7\u00f5es dos clientes para o resolvedor, mas tamb\u00e9m na troca de dados entre servidores, na transmiss\u00e3o de zonas por um servidor DNS autoritativo e no processamento de quaisquer solicita\u00e7\u00f5es suportadas por outros transportes DNS. <\/p>\n
Entre as desvantagens, que podem ser compensadas pela desativa\u00e7\u00e3o da compila\u00e7\u00e3o com DoH\/DoT ou pela transfer\u00eancia da criptografia para outro servidor, destaca-se a complexidade geral da base de c\u00f3digo \u2014 a inclus\u00e3o de um servidor HTTP integrado e de uma biblioteca TLS, que potencialmente podem conter vulnerabilidades e atuar como vetores adicionais para ataques. Al\u00e9m disso, o uso de DoH aumenta o tr\u00e1fego. <\/p>\n
Vale lembrar que o DNS-over-HTTPS pode ser \u00fatil para eliminar vazamentos de informa\u00e7\u00f5es sobre os nomes de hosts solicitados atrav\u00e9s dos servidores DNS dos provedores, combater ataques MITM e a substitui\u00e7\u00e3o do tr\u00e1fego DNS (por exemplo, ao se conectar a Wi-Fi p\u00fablico), e enfrentar bloqueios a n\u00edvel de DNS (o DNS-over-HTTPS n\u00e3o pode substituir VPN<\/a> no \u00e2mbito da supera\u00e7\u00e3o de bloqueios implementados a n\u00edvel de DPI) ou para possibilitar o funcionamento em caso de impossibilidade de conex\u00e3o direta aos servidores DNS (por exemplo, ao operar atrav\u00e9s de um proxy). Se em uma situa\u00e7\u00e3o comum as solicita\u00e7\u00f5es DNS s\u00e3o enviadas diretamente para os servidores DNS especificados na configura\u00e7\u00e3o do sistema, no caso do DNS-over-HTTPS a solicita\u00e7\u00e3o para determinar endere\u00e7os IP<\/a> o host \u00e9 encapsulada no tr\u00e1fego HTTPS e enviada para o servidor HTTP, onde o resolvedor processa as solicita\u00e7\u00f5es atrav\u00e9s da API Web. <\/p>\n \u201cDNS over TLS\u201d se diferencia de \u201cDNS over HTTPS\u201d pela aplica\u00e7\u00e3o do protocolo DNS padr\u00e3o (normalmente usando a porta de rede 853), encapsulado em um canal de comunica\u00e7\u00e3o criptografado, que \u00e9 organizado atrav\u00e9s do protocolo TLS com valida\u00e7\u00e3o do host via certificados TLS\/SSL, emitidos por uma autoridade certificadora. O padr\u00e3o DNSSEC existente utiliza criptografia apenas para autentica\u00e7\u00e3o do cliente e do servidor, mas n\u00e3o protege o tr\u00e1fego de intercepta\u00e7\u00e3o e n\u00e3o garante a confidencialidade das consultas. <\/p>\n Algumas outras inova\u00e7\u00f5es: <\/p>\n\n