Efter to års udvikling har ISC-konsortiet præsenteret den første stabile udgave af den nye betydelige gren af DNS-serveren BIND 9.18. Støtten til 9.18-grenen vil blive opretholdt i tre år frem til 2. kvartal 2025 som en del af den udvidede supportcyklus. Støtten til 9.11-grenen stopper i marts, mens støtten til 9.16-grenen ophører i midten af 2023. For at udvikle funktionaliteten i den næste stabile version af BIND er der dannet en eksperimentel gren, BIND 9.19.0.
Udgivelsen af BIND 9.18.0 er bemærkelsesværdig på grund af implementeringen af understøttelse af teknologierne 'DNS over HTTPS' (DoH) og DNS over TLS (DoT), samt mekanismen XoT (XFR-over-TLS) til sikker overførsel af DNS-zoner mellem servere (både ved udlevering og modtagelse af zoner via XoT understøttes). Med de rette indstillinger kan én named-proces nu betjene ikke kun traditionelle DNS-forespørgsler, men også forespørgsler sendt ved hjælp af DNS-over-HTTPS og DNS-over-TLS. Klientunderstøttelse for DNS-over-TLS er indbygget i værktøjet dig, som kan bruges til at sende forespørgsler over TLS ved at angive flaget ‘+tls’.
Implementeringen af HTTP/2-protokollen, der anvendes i DoH, er baseret på brugen af biblioteket nghttp2, som er inkluderet blandt de valgfrie build-afhængigheder. Certifikater til DoH og DoT kan leveres af brugeren eller genereres automatisk ved opstart.
Behandlingen af forespørgsler ved hjælp af DoH og DoT aktiveres ved at tilføje indstillingerne ‘http’ og ‘tls’ i listen-over-direktivet. For at understøtte ubeskyttet DNS-over-HTTP skal indstillingerne angive ‘tls none’. Nøglerne defineres i sektionen ‘tls’. De standard netværksporte 853 til DoT, 443 til DoH og 80 til DNS-over-HTTP kan overskrives via parametrene tls-port, https-port og http-port. For eksempel:
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;}; }
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.
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.
Among the drawbacks that can be mitigated by disabling the DoH/DoT build or offloading encryption to another server is the overall complexity of the codebase — a built-in HTTP server and TLS library are added, which may contain vulnerabilities and serve as additional attack vectors. Additionally, using DoH increases traffic.
It’s 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 в области обхода блокировок, реализованных на уровне DPI) или для организации работы в случае невозможности прямого обращения к DNS-серверам (например, при работе через прокси). Если в обычной ситуации DNS-запросы напрямую отправляются на определённые в конфигурации системы DNS-серверы, то в случае DNS-over-HTTPS запрос на определение IP-adresser хоста инкапсулируется в трафик HTTPS и отправляется на HTTP-сервер, на котором резолвер обрабатывает запросы через Web API.
«DNS over TLS» adskiller sig fra «DNS over HTTPS» ved at anvende den standard DNS-protokol (normalt bruger netværksport 853), indpakket i en krypteret kommunikationskanal etableret ved hjælp af TLS-protokollen med validering af værtens identitet gennem TLS/SSL-certifikater, som er verificeret af et certifikationsorgan. Den eksisterende standard DNSSEC bruger kryptering kun til at autentificere klienten og serveren, men beskytter ikke traffikken mod opsnapping og garanterer ikke fortrolighed for forespørgsler.
Nogle andre nyheder:
- Der er tilføjet indstillinger for tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer og udp-send-buffer til at angive størrelsen på de buffere, der bruges til at sende og modtage forespørgsler over TCP og UDP. På belastede servere vil en stigning i indgående buffere hjælpe med at undgå pakkeafvisning i perioder med spidstrafik, mens en reduktion vil bidrage til at fjerne ældre forespørgsler fra hukommelsen.
- En ny logkategori «rpz-passthru» er blevet tilføjet, som gør det muligt at logge handlinger vedrørende RPZ (Response Policy Zones) separat.
- I sektionen response-policy er der tilføjet en mulighed «nsdname-wait-recurse», som ved indstilling til «no» anvender RPZ NSDNAME-reglerne kun, hvis der findes autoritative navneservere i cachen til forespørgslen, ellers ignoreres RPZ NSDNAME-reglen, men oplysningerne hentes i baggrunden og anvendes til efterfølgende forespørgsler.
- Behandling af sektionen «ADDITIONAL» er implementeret for optegnelser med typerne HTTPS og SVCB.
- Konfigurerbare typer af regler for update-policy — krb5-subdomain-self-rhs og ms-subdomain-self-rhs, der muliggør begrænsning af opdatering af SRV- og PTR-poster, er blevet tilføjet. I opdateringspolicy-blokkene er der også tilføjet mulighed for at sætte begrænsninger på antallet af poster, specifik for hver type.
- Der er tilføjet oplysninger om transportprotokol (UDP, TCP, TLS, HTTPS) og DNS64-præfikser i output fra dig-værktøjet. For fejlfinding er muligheden for at angive en specifik forespørgsels-id (dig +qid=) tilføjet i dig.
- Support for OpenSSL 3.0 er blevet tilføjet.
- For at løse problemer med IP-fragmentering ved behandling af DNS-beskeder af stor størrelse, som angivet af DNS Flag Day 2020-initiativerne, er koden til at justere størrelsen på EDNS-buffere i resolveren blevet fjernet, hvis der ikke er noget svar på forespørgslen. Størrelsen på EDNS-buffere er nu indstillet til en konstant (edns-udp-size) for alle udgående forespørgsler.
- Byg-systemet er blevet ændret til at bruge en kombination af autoconf, automake og libtool.
- Støtten til zonefiler i «map»-format (masterfile-format map) er blevet fjernet. Brugere af dette format anbefales at konvertere zoner til raw-format ved hjælp af værktøjet named-compilezone.
- Støtten til gamle DLZ-drivere (Dynamically Loadable Zones) er blevet ophævet, og de er blevet erstattet af DLZ-moduler.
- Støtten til compilation og kørsel for Windows-platformen er stoppet. Den sidste version, der kan installeres på Windows, er BIND 9.16.
Kilde: opennet.ru
