Despois de dous anos de desenvolvemento, o consorcio ISC lanzou a primeira versión estable dunha nova rama importante do servidor DNS BIND 9.18. O apoio á rama 9.18 prestarase durante tres anos ata o segundo trimestre de 2 como parte dun ciclo de apoio estendido. O soporte para a rama 2025 rematará en marzo e o soporte para a rama 9.11 a mediados de 9.16. Para desenvolver a funcionalidade da seguinte versión estable de BIND, formouse unha rama experimental BIND 2023.
O lanzamento de BIND 9.18.0 destaca pola implementación de compatibilidade con DNS sobre HTTPS (DoH, DNS sobre HTTPS) e DNS sobre TLS (DoT, DNS sobre TLS), así como polo mecanismo XoT (XFR-sobre-TLS). para a transferencia segura de contido DNS.zonas entre servidores (as zonas de envío e recepción a través de XoT son compatibles). Coa configuración adecuada, un único proceso con nome agora pode atender non só consultas DNS tradicionais, senón tamén consultas enviadas mediante DNS sobre HTTPS e DNS sobre TLS. O soporte ao cliente para DNS sobre TLS está integrado na utilidade dig, que se pode usar para enviar solicitudes a través de TLS cando se especifica a marca "+tls".
A implementación do protocolo HTTP/2 usado en DoH baséase no uso da biblioteca nghttp2, que se inclúe como unha dependencia de montaxe opcional. Os certificados para DoH e DoT poden ser proporcionados polo usuario ou xerados automaticamente no momento do inicio.
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 { ficheiro de chave "/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;}; }
Unha das características da implementación DoH en BIND é a capacidade 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 está implementada para simplificar a depuración e como capa para o reenvío a outro servidor da rede interna (para mover o cifrado a un servidor separado). 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.
Outra característica é a integración de DoH como transporte xeral que se pode usar non só para xestionar as solicitudes dos clientes ao resolver, senón tamén cando se comunican entre servidores, cando se transfiren zonas por un servidor DNS autorizado e cando se procesan calquera consulta admitida por outros DNS. transportes.
Entre as deficiencias que se poden compensar desactivando a compilación con DoH/DoT ou movendo o cifrado a outro servidor, destaca a complicación xeral da base de código: engádense un servidor HTTP integrado e unha biblioteca TLS, que potencialmente podería conter. vulnerabilidades e actúan como vectores adicionais para ataques. Ademais, ao usar DoH, o tráfico aumenta.
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.
Algunhas outras novidades:
- Engadíronse as opcións de tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer e udp-send-buffer para establecer os tamaños dos búfers utilizados ao enviar e recibir solicitudes a través de TCP e UDP. En servidores ocupados, o aumento dos búfers de entrada axudará a evitar que se descartan paquetes durante os picos de tráfico, e diminuílos axudará a desfacerse da obstrucción da memoria con solicitudes antigas.
- Engadiuse unha nova categoría de rexistro "rpz-passthru", que che permite rexistrar por separado as accións de reenvío de RPZ (zonas de políticas de resposta).
- Na sección de política de resposta, engadiuse a opción "nsdname-wait-recurse", cando se define como "non", as regras de RPZ NSDNAME só se aplican se se atopan servidores de nomes autorizados presentes na caché para a solicitude; Ignorase a regra RPZ NSDNAME, pero a información obténse en segundo plano e aplícase ás solicitudes posteriores.
- Para rexistros con tipos HTTPS e SVCB, implementouse o procesamento da sección "ADICIONAL".
- Engadíronse tipos de regras de políticas de actualización personalizadas: krb5-subdomain-self-rhs e ms-subdomain-self-rhs, que che permiten limitar a actualización dos rexistros SRV e PTR. Os bloques de políticas de actualización tamén engaden a posibilidade de establecer límites no número de rexistros, individuais para cada tipo.
- Engadiuse información sobre o protocolo de transporte (UDP, TCP, TLS, HTTPS) e os prefixos DNS64 á saída da utilidade dig. Para fins de depuración, dig engadiu a posibilidade de especificar un identificador de solicitude específico (dig +qid= ).
- Engadido soporte para a biblioteca OpenSSL 3.0.
- Para solucionar problemas coa fragmentación de IP ao procesar mensaxes DNS grandes identificadas polo Día da bandeira de DNS 2020, eliminouse do resolvedor o código que axusta o tamaño do búfer EDNS cando non hai resposta a unha solicitude. O tamaño do búfer EDNS agora está configurado como constante (edns-udp-size) para todas as solicitudes de saída.
- O sistema de compilación cambiouse a usar unha combinación de autoconf, automake e libtool.
- O soporte para ficheiros de zona no formato "mapa" (mapa con formato de ficheiro mestre) foi descontinuado. Recoméndase aos usuarios deste formato converter as zonas a formato bruto mediante a utilidade named-compilezone.
- A compatibilidade con controladores DLZ (Zonas cargables dinámicamente) máis antigas foi descontinuada, substituíndose por módulos DLZ.
- A compatibilidade de compilación e execución para a plataforma Windows foi descontinuada. A última rama que se pode instalar en Windows é BIND 9.16.
Fonte: opennet.ru