Efter två års utveckling har ISC-konsortiet släppt den första stabila versionen av en stor ny gren av BIND 9.18 DNS-servern. Stöd för filial 9.18 kommer att ges under tre år fram till 2:a kvartalet 2025 som en del av en utökad supportcykel. Stödet för 9.11-grenen upphör i mars och stödet för 9.16-grenen i mitten av 2023. För att utveckla funktionaliteten i nästa stabila version av BIND har en experimentell gren BIND 9.19.0 bildats.
Utgivningen av BIND 9.18.0 är känd för implementeringen av stöd för DNS över HTTPS (DoH, DNS över HTTPS) och DNS över TLS (DoT, DNS över TLS), såväl som XoT-mekanismen (XFR-over-TLS) för säker överföring av DNS-innehåll zoner mellan servrar (både sändnings- och mottagningszoner via XoT stöds). Med lämpliga inställningar kan en enda namngiven process nu inte bara betjäna traditionella DNS-frågor, utan även frågor som skickas med DNS-over-HTTPS och DNS-over-TLS. Klientstöd för DNS-over-TLS är inbyggt i dig-verktyget, som kan användas för att skicka förfrågningar över TLS när flaggan "+tls" är specificerad.
Implementeringen av HTTP/2-protokollet som används i DoH baseras på användningen av nghttp2-biblioteket, som ingår som ett valfritt monteringsberoende. Certifikat för DoH och DoT kan tillhandahållas av användaren eller genereras automatiskt vid uppstart.
Bearbetning av förfrågningar med hjälp av DoH och DoT aktiveras genom att lägga till alternativen "http" och "tls" i avlyssningsdirektivet. För att stödja okrypterad DNS-over-HTTP bör du ange "tls none" i inställningarna. Nycklar definieras i avsnittet "tls". Standardnätverksportarna 853 för DoT, 443 för DoH och 80 för DNS-over-HTTP kan åsidosättas genom parametrarna tls-port, https-port och http-port. Till exempel:
tls local-tls { nyckelfil "/sökväg/till/priv_key.pem"; cert-fil "/sökväg/till/cert_chain.pem"; }; http local-http-server { endpoints { "/dns-query"; }; }; alternativ { https-port 443; lyssna på port 443 tls local-tls http minserver {någon;}; }
En av funktionerna i DoH-implementeringen i BIND är möjligheten att flytta krypteringsoperationer för TLS till en annan server, vilket kan vara nödvändigt under förhållanden där TLS-certifikat lagras på ett annat system (till exempel i en infrastruktur med webbservrar) och underhålls av annan personal. Stöd för okrypterad DNS-over-HTTP är implementerat för att förenkla felsökning och som ett lager för vidarebefordran till en annan server på det interna nätverket (för att flytta kryptering till en separat server). På en fjärrserver kan nginx användas för att generera TLS-trafik, liknande hur HTTPS-bindning är organiserad för webbplatser.
En annan funktion är integrationen av DoH som en allmän transport som inte bara kan användas för att hantera klientförfrågningar till resolvern, utan också vid kommunikation mellan servrar, vid överföring av zoner av en auktoritativ DNS-server och vid bearbetning av eventuella frågor som stöds av annan DNS transporter.
Bland de brister som kan kompenseras för genom att inaktivera byggnaden med DoH/DoT eller flytta krypteringen till en annan server sticker den allmänna komplikationen av kodbasen ut - en inbyggd HTTP-server och TLS-bibliotek läggs till, som potentiellt kan innehålla sårbarheter och fungerar som ytterligare vektorer för attacker. Dessutom, när du använder DoH, ökar trafiken.
Låt oss komma ihåg att DNS-over-HTTPS kan vara användbart för att förhindra läckor av information om de begärda värdnamnen genom leverantörernas DNS-servrar, för att bekämpa MITM-attacker och DNS-trafikspoofing (till exempel vid anslutning till offentligt Wi-Fi), motverka blockering på DNS-nivå (DNS-over-HTTPS kan inte ersätta ett VPN genom att kringgå blockering implementerad på DPI-nivå) eller för att organisera arbete när det är omöjligt att direkt komma åt DNS-servrar (till exempel när du arbetar via en proxy). Om DNS-förfrågningar i en normal situation skickas direkt till DNS-servrar definierade i systemkonfigurationen, då i fallet med DNS-over-HTTPS är begäran om att fastställa värd-IP-adressen inkapslad i HTTPS-trafik och skickas till HTTP-servern, där resolvern behandlar förfrågningar via webb-API.
"DNS över TLS" skiljer sig från "DNS över HTTPS" i användningen av standard DNS-protokoll (nätverksport 853 används vanligtvis), insvept i en krypterad kommunikationskanal organiserad med hjälp av TLS-protokollet med värdvaliditetskontroll genom TLS/SSL-certifikat certifierade av en certifieringsmyndighet. Den befintliga DNSSEC-standarden använder endast kryptering för att autentisera klienten och servern, men skyddar inte trafik från avlyssning och garanterar inte konfidentialitet för förfrågningar.
Några andra innovationer:
- Lade till inställningar för tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer och udp-send-buffer för att ställa in storleken på buffertar som används när man skickar och tar emot förfrågningar över TCP och UDP. På upptagna servrar kommer ökade inkommande buffertar att hjälpa till att undvika att paket tappas under trafiktoppar, och att minska dem hjälper till att bli av med att minnet täpps igen med gamla förfrågningar.
- En ny loggkategori "rpz-passthru" har lagts till, som låter dig logga RPZ-vidarebefordran (Response Policy Zones) separat.
- I svarspolicysektionen har alternativet "nsdname-wait-recurse" lagts till, när det är inställt på "no" tillämpas RPZ NSDNAME-reglerna endast om auktoritativa namnservrar som finns i cachen hittas för begäran, annars RPZ NSDNAME-regeln ignoreras, men informationen hämtas i bakgrunden och gäller efterföljande förfrågningar.
- För poster med HTTPS- och SVCB-typer har bearbetning av avsnittet "YTTERLIGARE" implementerats.
- Tillagda anpassade regeltyper för uppdateringspolicy - krb5-subdomain-self-rhs och ms-subdomain-self-rhs, som låter dig begränsa uppdateringen av SRV- och PTR-poster. Uppdateringspolicyblocken lägger också till möjligheten att sätta gränser för antalet poster, individuella för varje typ.
- Lade till information om transportprotokollet (UDP, TCP, TLS, HTTPS) och DNS64-prefix till utdata från dig-verktyget. För felsökningsändamål har dig lagt till möjligheten att ange en specifik begäranidentifierare (dig +qid= ).
- Lagt till stöd för OpenSSL 3.0-biblioteket.
- För att lösa problem med IP-fragmentering vid bearbetning av stora DNS-meddelanden som identifierats av DNS Flag Day 2020, har kod som justerar EDNS-buffertstorleken när det inte finns något svar på en begäran tagits bort från resolvern. EDNS-buffertstorleken är nu inställd på konstant (edns-udp-size) för alla utgående förfrågningar.
- Byggsystemet har bytts till att använda en kombination av autoconf, automake och libtool.
- Stöd för zonfiler i "karta"-format (masterfile-format map) har upphört. Användare av detta format rekommenderas att konvertera zoner till råformat med hjälp av verktyget named-compilezone.
- Stödet för äldre DLZ-drivrutiner (Dynamically Loadable Zones) har upphört och ersatts av DLZ-moduler.
- Bygg- och körstöd för Windows-plattformen har upphört. Den sista grenen som kan installeras på Windows är BIND 9.16.
Källa: opennet.ru