Os desenvolvedores do servidor BIND DNS anunciaron a incorporación do soporte do servidor para as tecnoloxías DNS sobre HTTPS (DoH, DNS sobre HTTPS) e DNS sobre TLS (DoT, DNS sobre TLS), así como o mecanismo XFR-over-TLS para a seguridade. transferir o contido das zonas DNS entre servidores. DoH está dispoñible para probar na versión 9.17 e o soporte DoT está presente desde a versión 9.17.10. Despois da estabilización, o soporte DoT e DoH será retroportado á rama estable 9.17.7.
A implementación do protocolo HTTP/2 empregado en DoH baséase no uso da biblioteca nghttp2, que se inclúe entre as dependencias de montaxe (no futuro, está previsto que a biblioteca sexa transferida ao número de dependencias opcionais). Admítense conexións HTTP/2 cifradas (TLS) e non cifradas. Coa configuración adecuada, un único proceso con nome agora pode atender non só consultas DNS tradicionais, senón tamén consultas enviadas mediante DoH (DNS-over-HTTPS) e DoT (DNS-over-TLS). A compatibilidade HTTPS no lado do cliente (excavación) aínda non está implementada. A compatibilidade con XFR sobre TLS está dispoñible para solicitudes de entrada e saída.
O procesamento de solicitudes mediante DoH e DoT está habilitado engadindo as opcións http e tls á directiva listen-on. Para admitir DNS sobre HTTP sen cifrar, debes especificar "tls none" na configuración. As claves defínense na sección "tls". Os portos de rede predeterminados 853 para DoT, 443 para DoH e 80 para DNS-over-HTTP pódense anular a través dos parámetros tls-port, https-port e http-port. Por exemplo: tls local-tls { key-file "/path/to/priv_key.pem"; ficheiro-cert "/path/to/cert_chain.pem"; }; http local-http-server { endpoints { "/dns-query"; }; }; opcións { https-port 443; porto de escoita 443 tls local-tls http o meu servidor {calquera;}; }
Entre as características da implementación de DoH en BIND, a integración nótase como un transporte xeral, que se pode usar non só para procesar as solicitudes dos clientes ao resolver, senón tamén ao intercambiar datos entre servidores, ao transferir zonas por un servidor DNS autorizado e ao procesar calquera solicitude admitida por outros transportes DNS.
Outra característica é a posibilidade de mover as operacións de cifrado para TLS a outro servidor, o que pode ser necesario en condicións en que os certificados TLS estean almacenados noutro sistema (por exemplo, nunha infraestrutura con servidores web) e mantidos por outro persoal. A compatibilidade con DNS sobre HTTP sen cifrar implícase para simplificar a depuración e como capa para o reenvío na rede interna, en función da cal o cifrado pode organizarse noutro servidor. Nun servidor remoto, nginx pódese usar para xerar tráfico TLS, de forma similar a como se organiza a vinculación HTTPS para sitios web.
Lembremos que DNS-over-HTTPS pode ser útil para evitar filtracións de información sobre os nomes de host solicitados a través dos servidores DNS dos provedores, combater ataques MITM e suplantación de tráfico DNS (por exemplo, cando se conecta a wifi pública), contrarrestar o bloqueo a nivel de DNS (DNS-over-HTTPS non pode substituír unha VPN ao evitar o bloqueo implementado a nivel de DPI) ou para organizar o traballo cando é imposible acceder directamente aos servidores DNS (por exemplo, cando se traballa a través dun proxy). Se nunha situación normal as solicitudes de DNS envíanse directamente aos servidores DNS definidos na configuración do sistema, entón no caso de DNS sobre HTTPS a solicitude para determinar o enderezo IP do host encápsulase no tráfico HTTPS e envíase ao servidor HTTP, onde o resolvedor procesa as solicitudes a través da API web.
"DNS sobre TLS" difire de "DNS sobre HTTPS" no uso do protocolo DNS estándar (usualmente úsase o porto de rede 853), envolto nunha canle de comunicación cifrada organizada mediante o protocolo TLS con comprobación da validez do host mediante certificados TLS/SSL certificados. por una autoridad de certificación. O estándar DNSSEC existente usa o cifrado só para autenticar o cliente e o servidor, pero non protexe o tráfico da intercepción e non garante a confidencialidade das solicitudes.
Fonte: opennet.ru