Etter to år med utvikling har ISC-konsortiet gitt ut den første stabile utgivelsen av en stor ny gren av BIND 9.18 DNS-serveren. Støtte til filial 9.18 gis i tre år frem til 2. kvartal 2025 som en del av en utvidet støttesyklus. Støtte for 9.11-grenen avsluttes i mars, og støtte for 9.16-grenen i midten av 2023. For å utvikle funksjonaliteten til den neste stabile versjonen av BIND, har en eksperimentell gren BIND 9.19.0 blitt dannet.
Utgivelsen av BIND 9.18.0 er kjent for implementeringen av støtte for DNS over HTTPS (DoH, DNS over HTTPS) og DNS over TLS (DoT, DNS over TLS), samt XoT (XFR-over-TLS) mekanismen for sikker overføring av DNS-innhold soner mellom servere (både sende- og mottakssoner via XoT støttes). Med de riktige innstillingene kan en enkelt navngitt prosess nå ikke bare betjene tradisjonelle DNS-spørringer, men også spørringer sendt ved hjelp av DNS-over-HTTPS og DNS-over-TLS. Klientstøtte for DNS-over-TLS er innebygd i graveverktøyet, som kan brukes til å sende forespørsler over TLS når "+tls"-flagget er spesifisert.
Implementeringen av HTTP/2-protokollen som brukes i DoH er basert på bruken av nghttp2-biblioteket, som er inkludert som en valgfri monteringsavhengighet. Sertifikater for DoH og DoT kan leveres av brukeren eller genereres automatisk ved oppstart.
Forespørselsbehandling ved å bruke DoH og DoT aktiveres ved å legge til "http" og "tls" alternativene i lytte-på-direktivet. For å støtte ukryptert DNS-over-HTTP, bør du spesifisere "tls none" i innstillingene. Nøkler er definert i "tls"-delen. Standard nettverksporter 853 for DoT, 443 for DoH og 80 for DNS-over-HTTP kan overstyres gjennom tls-port, https-port og http-port parametere. For eksempel:
tls local-tls { key-file "/path/to/priv_key.pem"; cert-fil "/path/to/cert_chain.pem"; }; http local-http-server { endpoints { "/dns-query"; }; }; alternativer { https-port 443; lytte-på-port 443 tls local-tls http minserver {any;}; }
En av funksjonene til DoH-implementeringen i BIND er muligheten til å flytte krypteringsoperasjoner for TLS til en annen server, noe som kan være nødvendig i forhold der TLS-sertifikater lagres på et annet system (for eksempel i en infrastruktur med webservere) og vedlikeholdes av annet personell. Støtte for ukryptert DNS-over-HTTP er implementert for å forenkle feilsøking og som et lag for videresending til en annen server på det interne nettverket (for å flytte kryptering til en egen server). På en ekstern server kan nginx brukes til å generere TLS-trafikk, på samme måte som HTTPS-binding er organisert for nettsteder.
En annen funksjon er integreringen av DoH som en generell transport som ikke bare kan brukes til å håndtere klientforespørsler til resolveren, men også når man kommuniserer mellom servere, når soner overføres av en autoritativ DNS-server, og når man behandler spørsmål som støttes av andre DNS transporter.
Blant manglene som kan kompenseres for ved å deaktivere byggingen med DoH/DoT eller flytte krypteringen til en annen server, skiller den generelle komplikasjonen av kodebasen seg ut - en innebygd HTTP-server og TLS-bibliotek er lagt til, som potensielt kan inneholde sårbarheter og fungerer som ekstra vektorer for angrep. Også når du bruker DoH, øker trafikken.
La oss huske at DNS-over-HTTPS kan være nyttig for å forhindre lekkasjer av informasjon om de forespurte vertsnavnene gjennom DNS-serverne til leverandører, bekjempe MITM-angrep og DNS-trafikk-spoofing (for eksempel når du kobler til offentlig Wi-Fi), motvirke blokkering på DNS-nivå (DNS-over-HTTPS kan ikke erstatte en VPN ved å omgå blokkering implementert på DPI-nivå) eller for å organisere arbeid når det er umulig å få direkte tilgang til DNS-servere (for eksempel når du arbeider gjennom en proxy). Hvis DNS-forespørsler i en normal situasjon sendes direkte til DNS-servere som er definert i systemkonfigurasjonen, i tilfelle DNS-over-HTTPS er forespørselen om å bestemme vertens IP-adresse innkapslet i HTTPS-trafikk og sendt til HTTP-serveren, der løseren behandler forespørsler via Web API.
"DNS over TLS" skiller seg fra "DNS over HTTPS" ved bruk av standard DNS-protokoll (nettverksport 853 brukes vanligvis), pakket inn i en kryptert kommunikasjonskanal organisert ved hjelp av TLS-protokollen med vertsvaliditetskontroll gjennom sertifiserte TLS/SSL-sertifikater av en sertifiseringsinstans. Den eksisterende DNSSEC-standarden bruker kryptering kun for å autentisere klienten og serveren, men beskytter ikke trafikk mot avlytting og garanterer ikke konfidensialiteten til forespørsler.
Noen andre innovasjoner:
- Lagt til innstillinger for tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer og udp-send-buffer for å angi størrelsene på buffere som brukes ved sending og mottak av forespørsler over TCP og UDP. På travle servere vil økende innkommende buffere bidra til å unngå at pakker droppes under trafikktopper, og å redusere dem vil bidra til å kvitte seg med tilstopping av minnet med gamle forespørsler.
- En ny loggkategori "rpz-passthru" er lagt til, som lar deg logge RPZ-videresendingshandlinger (Response Policy Zones) separat.
- I responspolicy-delen er "nsdname-wait-recurse"-alternativet lagt til, når satt til "no", brukes RPZ NSDNAME-reglene bare hvis autoritative navneservere som er tilstede i hurtigbufferen blir funnet for forespørselen, ellers RPZ NSDNAME-regelen ignoreres, men informasjonen hentes i bakgrunnen og gjelder for påfølgende forespørsler.
- For poster med HTTPS- og SVCB-typer, er behandling av "ADDITIONAL"-delen implementert.
- Lagt til tilpassede regeltyper for oppdateringspolicy - krb5-subdomain-self-rhs og ms-subdomain-self-rhs, som lar deg begrense oppdateringen av SRV- og PTR-poster. Oppdateringspolicyblokkene legger også til muligheten til å sette grenser for antall poster, individuelle for hver type.
- Lagt til informasjon om transportprotokollen (UDP, TCP, TLS, HTTPS) og DNS64-prefikser til utdataene fra dig-verktøyet. For feilsøkingsformål har dig lagt til muligheten til å spesifisere en spesifikk forespørselsidentifikator (dig +qid= ).
- Lagt til støtte for OpenSSL 3.0-bibliotek.
- For å løse problemer med IP-fragmentering ved behandling av store DNS-meldinger identifisert av DNS Flag Day 2020, er kode som justerer EDNS-bufferstørrelsen når det ikke er svar på en forespørsel fjernet fra løseren. EDNS-bufferstørrelsen er nå satt til konstant (edns-udp-størrelse) for alle utgående forespørsler.
- Byggesystemet har blitt byttet til å bruke en kombinasjon av autoconf, automake og libtool.
- Støtte for sonefiler i "kart"-format (kart i masterfilformat) er avviklet. Brukere av dette formatet anbefales å konvertere soner til råformat ved å bruke verktøyet named-compilezone.
- Støtte for eldre DLZ-drivere (Dynamically Loadable Zones) har blitt avviklet, erstattet av DLZ-moduler.
- Bygg og kjør støtte for Windows-plattformen er avviklet. Den siste grenen som kan installeres på Windows er BIND 9.16.
Kilde: opennet.ru