Udgivelse af BIND DNS Server 9.18.0 med understøttelse af DNS-over-TLS og DNS-over-HTTPS

Efter to års udvikling har ISC-konsortiet frigivet den første stabile udgivelse af en større ny gren af ​​BIND 9.18 DNS-serveren. Støtte til afdeling 9.18 ydes i tre år indtil 2. kvartal 2025 som en del af en udvidet støttecyklus. Support til 9.11-grenen slutter i marts, og støtte til 9.16-grenen i midten af ​​2023. For at udvikle funktionaliteten af ​​den næste stabile version af BIND, er en eksperimentel gren BIND 9.19.0 blevet dannet.

Udgivelsen af ​​BIND 9.18.0 er bemærkelsesværdig for implementeringen af ​​understøttelse af DNS over HTTPS (DoH, DNS over HTTPS) og DNS over TLS (DoT, DNS over TLS) samt XoT (XFR-over-TLS) mekanismen til sikker overførsel af DNS-indhold zoner mellem servere (både sende- og modtagezoner via XoT er understøttet). Med de passende indstillinger kan en enkelt navngivet proces nu ikke kun betjene traditionelle DNS-forespørgsler, men også forespørgsler sendt ved hjælp af DNS-over-HTTPS og DNS-over-TLS. Klientsupport til DNS-over-TLS er indbygget i dig-værktøjet, som kan bruges til at sende anmodninger over TLS, når "+tls"-flaget er angivet.

Implementeringen af ​​HTTP/2-protokollen, der bruges i DoH, er baseret på brugen af ​​nghttp2-biblioteket, som er inkluderet som en valgfri assembly-afhængighed. Certifikater for DoH og DoT kan leveres af brugeren eller genereres automatisk ved opstart.

Anmodningsbehandling ved hjælp af DoH og DoT aktiveres ved at tilføje "http" og "tls" mulighederne til listen-on-direktivet. For at understøtte ukrypteret DNS-over-HTTP skal du angive "tls none" i indstillingerne. Nøgler er defineret i "tls" sektionen. Standardnetværksportene 853 for DoT, 443 for DoH og 80 for DNS-over-HTTP kan tilsidesættes gennem tls-port, https-port og http-port parametrene. For eksempel:

tls local-tls { key-file "/path/to/priv_key.pem"; cert-fil "/sti/til/cert_chain.pem"; }; http local-http-server { endpoints { "/dns-query"; }; }; muligheder { https-port 443; lytte-på-port 443 tls local-tls http minserver {enhver;}; }

En af funktionerne ved DoH-implementeringen i BIND er muligheden for at flytte krypteringsoperationer for TLS til en anden server, hvilket kan være nødvendigt under forhold, hvor TLS-certifikater er lagret på et andet system (for eksempel i en infrastruktur med webservere) og vedligeholdes af andet personale. Understøttelse af ukrypteret DNS-over-HTTP er implementeret for at forenkle debugging og som et lag til videresendelse til en anden server på det interne netværk (for at flytte kryptering til en separat server). På en fjernserver kan nginx bruges til at generere TLS-trafik, svarende til hvordan HTTPS-binding er organiseret for websteder.

En anden funktion er integrationen af ​​DoH som en generel transport, der ikke kun kan bruges til at håndtere klientanmodninger til resolveren, men også når der kommunikeres mellem servere, når zoner overføres af en autoritativ DNS-server, og når der behandles forespørgsler understøttet af andre DNS transporter.

Blandt de mangler, der kan kompenseres for ved at deaktivere build med DoH/DoT eller flytte krypteringen til en anden server, skiller den generelle komplikation af kodebasen sig ud - der tilføjes en indbygget HTTP-server og TLS-bibliotek, som potentielt kan indeholde sårbarheder og fungerer som yderligere vektorer for angreb. Også, når du bruger DoH, øges trafikken.

Lad os huske på, at DNS-over-HTTPS kan være nyttigt til at forhindre læk af information om de anmodede værtsnavne gennem udbydernes DNS-servere, bekæmpe MITM-angreb og DNS-trafik-spoofing (f.eks. ved tilslutning til offentlig Wi-Fi), modvirke blokering på DNS-niveau (DNS-over-HTTPS kan ikke erstatte en VPN ved at omgå blokering implementeret på DPI-niveau) eller til at organisere arbejde, når det er umuligt at få direkte adgang til DNS-servere (f.eks. når du arbejder gennem en proxy). Hvis DNS-anmodninger i en normal situation sendes direkte til DNS-servere defineret i systemkonfigurationen, er anmodningen om at bestemme værtens IP-adresse i tilfælde af DNS-over-HTTPS indkapslet i HTTPS-trafik og sendt til HTTP-serveren, hvor resolveren behandler anmodninger via Web API.

"DNS over TLS" adskiller sig fra "DNS over HTTPS" ved brugen af ​​standard DNS-protokollen (netværksport 853 bruges normalt), pakket ind i en krypteret kommunikationskanal organiseret ved hjælp af TLS-protokollen med værtsvaliditetskontrol gennem TLS/SSL-certifikater certificeret af en certificeringsmyndighed. Den eksisterende DNSSEC-standard bruger kun kryptering til at autentificere klienten og serveren, men beskytter ikke trafik mod aflytning og garanterer ikke fortroligheden af ​​anmodninger.

Nogle andre innovationer:

  • Tilføjet indstillinger for tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer og udp-send-buffer for at indstille størrelserne på buffere, der bruges ved afsendelse og modtagelse af anmodninger over TCP og UDP. På travle servere vil øgede indgående buffere hjælpe med at undgå, at pakker tabes under trafikspidsbelastninger, og at reducere dem vil hjælpe med at slippe af med tilstopning af hukommelsen med gamle anmodninger.
  • En ny logkategori "rpz-passthru" er blevet tilføjet, som giver dig mulighed for separat at logge RPZ-videresendelseshandlinger (Response Policy Zones).
  • I sektionen svarpolitik er muligheden "nsdname-wait-recurse" blevet tilføjet, når den er indstillet til "nej", anvendes RPZ NSDNAME-reglerne kun, hvis autoritative navneservere i cachen findes for anmodningen, ellers RPZ NSDNAME-reglen ignoreres, men oplysningerne hentes i baggrunden og gælder for efterfølgende anmodninger.
  • For poster med HTTPS- og SVCB-typer er behandling af afsnittet "YDERLIGERE" blevet implementeret.
  • Tilføjede brugerdefinerede regeltyper for opdateringspolitik - krb5-subdomain-self-rhs og ms-subdomain-self-rhs, som giver dig mulighed for at begrænse opdateringen af ​​SRV- og PTR-poster. Opdateringspolitikblokkene tilføjer også muligheden for at sætte grænser for antallet af poster, individuelt for hver type.
  • Tilføjede oplysninger om transportprotokollen (UDP, TCP, TLS, HTTPS) og DNS64-præfikser til outputtet af dig-værktøjet. Til fejlretningsformål har dig tilføjet muligheden for at angive en specifik anmodnings-id (dig +qid= ).
  • Tilføjet understøttelse af OpenSSL 3.0-bibliotek.
  • For at løse problemer med IP-fragmentering ved behandling af store DNS-meddelelser identificeret af DNS Flag Day 2020 er kode, der justerer EDNS-bufferstørrelsen, når der ikke er noget svar på en anmodning, blevet fjernet fra resolveren. EDNS-bufferstørrelsen er nu indstillet til konstant (edns-udp-størrelse) for alle udgående anmodninger.
  • Byggesystemet er skiftet til at bruge en kombination af autoconf, automake og libtool.
  • Understøttelse af zonefiler i "map"-formatet (masterfile-format map) er udgået. Brugere af dette format anbefales at konvertere zoner til råformat ved hjælp af værktøjet named-compilezone.
  • Understøttelse af ældre DLZ-drivere (Dynamically Loadable Zones) er afbrudt, erstattet af DLZ-moduler.
  • Byg og kør support til Windows-platformen er afbrudt. Den sidste gren, der kan installeres på Windows, er BIND 9.16.

Kilde: opennet.ru

Tilføj en kommentar