Efter to \u00e5rs udvikling har ISC-konsortiet pr\u00e6senteret den f\u00f8rste stabile udgave af den nye betydelige gren af DNS-serveren BIND 9.18. St\u00f8tten til 9.18-grenen vil blive opretholdt i tre \u00e5r frem til 2. kvartal 2025 som en del af den udvidede supportcyklus. St\u00f8tten til 9.11-grenen stopper i marts, mens st\u00f8tten til 9.16-grenen oph\u00f8rer i midten af 2023. For at udvikle funktionaliteten i den n\u00e6ste stabile version af BIND er der dannet en eksperimentel gren, BIND 9.19.0. <\/p>\n
Udgaven af BIND 9.18.0 er bem\u00e6rkelsesv\u00e6rdig for implementeringen af st\u00f8tte til teknologierne \u00abDNS over HTTPS\u00bb (DoH, DNS over HTTPS) og DNS over TLS (DoT, DNS over TLS), samt mekanismen XoT (XFR-over-TLS) til sikker overf\u00f8rsel af indholdet af DNS-zoner mellem servere (b\u00e5de ved afgivelse og modtagelse af zoner via XoT underst\u00f8ttes). Med de rette indstillinger kan \u00e9n named-proces nu betjene ikke blot traditionelle DNS-foresp\u00f8rgsler, men ogs\u00e5 foresp\u00f8rgsler sendt med DNS-over-HTTPS og DNS-over-TLS. Klientunderst\u00f8ttelsen for DNS-over-TLS er indbygget i v\u00e6rkt\u00f8jet dig, som kan bruges til at sende foresp\u00f8rgsler over TLS ved at angive flaget \u00ab+tls\u00bb. <\/p>\n
Implementeringen af HTTP\/2-protokollen, der anvendes i DoH, er baseret p\u00e5 brugen af biblioteket nghttp2, som er inkluderet blandt de valgfrie build-afh\u00e6ngigheder. Certifikater til DoH og DoT kan leveres af brugeren eller genereres automatisk ved opstart. <\/p>\n
Behandling af foresp\u00f8rgsler med DoH og DoT aktiveres ved at tilf\u00f8je mulighederne \u00abhttp\u00bb og \u00abtls\u00bb i listen-over-direktivet. For at underst\u00f8tte usikret DNS-over-HTTP skal der angives \u00abtls none\u00bb i konfigurationen. N\u00f8gler defineres i sektionen \u00abtls\u00bb. De standard netv\u00e6rksporte 853 til DoT, 443 til DoH og 80 til DNS-over-HTTP kan overskrives med parametrene tls-port, https-port og http-port. For eksempel: <\/p>\n
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
BIND's implementation of DoH has the feature of offloading encryption operations for TLS to another server, which may be necessary when TLS certificates are stored on a different system (for example, in infrastructure with web servers) and managed by different personnel. Support for unencrypted DNS-over-HTTP is provided to facilitate debugging and as a layer for routing to another server within the internal network (to offload encryption to a separate server). Nginx can be used on the external server to generate TLS traffic, similar to how HTTPS wrapping is organized for websites. <\/p>\n
Another feature is the integration of DoH as a universal transport, which can be used not only for processing client requests to the resolver but also during data exchange between servers, zone transfers by authoritative DNS servers, and handling any requests supported by other DNS transports. <\/p>\n
Blandt de ulemper, som kan kompenseres ved at deaktivere opbygningen med DoH\/DoT eller ved at flytte krypteringen til en anden server, fremh\u00e6ves den generelle kompleksitet i kodebasen \u2014 en indbygget HTTP-server og TLS-bibliotek tilf\u00f8jes, som potentielt kan indeholde s\u00e5rbarheder og fungere som yderligere angrebsvektorer. Desuden \u00f8ges trafikken ved brug af DoH. <\/p>\n
It\u2019s worth noting that DNS-over-HTTPS can be useful for preventing the leakage of requested hostnames through provider DNS servers, combating MITM attacks and DNS traffic spoofing (for example, when connecting to public Wi-Fi), and overcoming DNS-level blocks (DNS-over-HTTPS cannot replace the circumvention of blocks implemented at the DPI level) or for enabling functionality when direct access to DNS servers is not possible (for example, when working through a proxy). In normal situations, DNS queries are directly sent to specific DNS servers configured in the system, but in the case of DNS-over-HTTPS, the request for hostname resolution is encapsulated in HTTPS traffic and sent to the HTTP server, where the resolver processes requests via Web API. VPN<\/a> i forbindelse med omg\u00e5else af blokeringer implementeret p\u00e5 DPI-niveau) eller til at organisere drift i tilf\u00e6lde af, at direkte adgang til DNS-servere ikke er muligt (for eksempel ved brug af en proxy). Hvis DNS-foresp\u00f8rgsler normalt sendes direkte til de i systemkonfigurationen angivne DNS-servere, s\u00e5 indkapsles DNS-over-HTTPS-foresp\u00f8rgslen til bestemmelse af IP-adresser<\/a> v\u00e6rten i HTTPS-trafik og sendes til en HTTP-server, hvor resolveren behandler foresp\u00f8rgsler via Web API. <\/p>\n \u00abDNS over TLS\u00bb adskiller sig fra \u00abDNS over HTTPS\u00bb ved at anvende den standard DNS-protokol (normalt anvendt netv\u00e6rksport 853), indkapslet i en krypteret kommunikationskanal, organiseret ved hj\u00e6lp af TLS-protokollen med hostvalidering via TLS\/SSL-certifikater, som er godkendt af et certifikatmyndighed. Den eksisterende standard DNSSEC anvender kryptering kun til autentificering af klient og server, men beskytter ikke trafikken mod aflytning og garanterer ikke fortroligheden af foresp\u00f8rgsler. <\/p>\n Nogle andre nyheder: <\/p>\n\n