Utgåvan av DNS-servern BIND 9.18.0 med stöd för DNS-over-TLS och DNS-over-HTTPS

Efter två års utveckling har konsortiet ISC presenterat den första stabila versionen av den nya betydande grenen av DNS-servern BIND 9.18. Stödet för version 9.18 kommer att ges under tre år fram till andra kvartalet 2025 inom ramen för en utvidgad supportcykel. Stödet för version 9.11 upphör i mars, och för version 9.16 i mitten av 2023. För att utveckla funktionaliteten i nästa stabila version av BIND har en experimentell gren BIND 9.19.0 skapats.

Utgivningen av BIND 9.18.0 är anmärkningsvärd med implementeringen av stöd för teknologierna "DNS över HTTPS" (DoH, DNS over HTTPS) och DNS över TLS (DoT, DNS over TLS), samt mekanismen XoT (XFR-over-TLS) för säker överföring av innehållet i DNS-zoner mellan servrar (stöd för både utlämning och mottagning av zoner via XoT). Med lämpliga inställningar kan nu en process vid namn named hantera inte bara traditionella DNS-förfrågningar utan också förfrågningar som skickas med hjälp av DNS-over-HTTPS och DNS-over-TLS. Klientstödet för DNS-over-TLS är inbyggt i verktyget dig, som kan användas för att skicka förfrågningar över TLS genom att ange flaggan "+tls".

Implementeringen av protokollet HTTP/2 som används i DoH är baserad på användningen av biblioteket nghttp2, som ingår bland obligatoriska byggberoenden. Certifikat för DoH och DoT kan tillhandahållas av användaren eller genereras automatiskt vid start.

Bearbetningen av förfrågningar med DoH och DoT aktiveras genom att lägga till alternativen "http" och "tls" i direktivet listen-on. För att stödja okrypterad DNS-over-HTTP bör inställningarna ange "tls none". Nycklar definieras i sektionen "tls". De standard nä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 { 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;}; }

En implementeringen av DoH i BIND är en av funktionerna möjligheten att utföra TLS-krypteringsoperationer på en annan server, vilket kan vara nödvändigt i situationer där TLS-certifikat lagras på ett annat system (till exempel i en infrastruktur med webservrar) och administreras av annan personal. Stöd för okrypterad DNS-over-HTTP implementeras för att underlätta felavhjälpning och som ett lager för att vidarebefordra till en annan server i det interna nätverket (för att flytta krypteringen till en separat server). Nginx kan användas på den externa servern för att generera TLS-trafik, på samma sätt som HTTPS-bindningar organiseras för webbplatser.

En annan egenskap är integrationen av DoH som en gemensam transport, som kan användas inte bara för att hantera klientanrop till resolvern, utan också vid datautbyte mellan servrar, vid överföring av zoner från auktoritativa DNS-servrar och vid hantering av alla förfrågningar som stöds av andra DNS-transporter.

Bland nackdelarna, som kan kompenseras genom att stänga av DoH/DoT-samlingen eller flytta krypteringen till en annan server, är den allmänna kompliceringen av kodbasen — den inbyggda HTTP-servern och TLS-biblioteket läggs till, vilket potentiellt kan innehålla sårbarheter och fungera som ytterligare vektorer för attacker. Användning av DoH ökar också trafiken.

Vi påminner om att DNS-over-HTTPS kan vara användbart för att förhindra läckor av information om begärda värdnamn via internetleverantörernas DNS-servrar, för att motverka MITM-attacker och modifikation av DNS-trafik (till exempel när man ansluter till offentliga Wi-Fi-nät), samt för att motstå blockeringar på DNS-nivå (DNS-over-HTTPS kan inte ersätta VPN när det gäller att kringgå blockeringar som genomförts på DPI-nivå) eller för att organisera arbete när direkt åtkomst till DNS-servrar inte är möjlig (till exempel när man arbetar via en proxy). I en vanlig situation skickas DNS-förfrågningar direkt till specifika DNS-servrar som definieras i systemets konfiguration, men i fallet DNS-over-HTTPS inkapslas förfrågningen för att bestämma IP-adresser värden i HTTPS-trafiken och skickas till en HTTP-server, där resolvern hanterar förfrågningarna via Web API.

«DNS över TLS» skiljer sig från «DNS över HTTPS» genom användningen av det standard DNS-protokollet (vanligtvis används nätverksport 853), inbäddat i en krypterad kommunikationskanal som organiseras med hjälp av TLS-protokollet och validering av värd via TLS/SSL-certifikat, som utfärdas av en certifieringsmyndighet. Den befintliga standarden DNSSEC använder kryptering endast för autentisering av klient och server, men skyddar inte trafiken från avlyssning och garanterar inte sekretess för förfrågningar.

Några andra nyheter:

• Inställningar för tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer och udp-send-buffer har lagts till för att ange storlekar på buffertarna som används vid sändning och mottagning av förfrågningar över TCP och UDP. På belastade servrar kommer en ökning av ingående buffrar att förhindra paketförlust vid trafiktoppar, medan en minskning hjälper till att undvika överbelastning av minnet med gamla förfrågningar.
• En ny loggkategori «rpz-passthru» har lagts till, vilket gör det möjligt att logga åtgärder för RPZ (Response Policy Zones) separat.
• I sektionen response-policy har alternativet «nsdname-wait-recurse» lagts till, där inställningen till «nej» innebär att RPZ NSDNAME-regler endast tillämpas om förfrågan hittar cachelagrade auktoritativa namnservrar; annars ignoreras RPZ NSDNAME-regeln, men informationen extraheras i bakgrunden och tillämpas på efterföljande förfrågningar.
• För poster med typerna HTTPS och SVCB har hantering av sektionen «ADDITIONAL» implementerats.
• Anpassningsbara regeltyper för update-policy har lagts till — krb5-subdomain-self-rhs och ms-subdomain-self-rhs, vilket gör det möjligt att begränsa uppdatering av SRV- och PTR-poster. I blocken för update-policy har möjligheten att ställa in begränsningar för antalet poster lagts till, specifikt för varje typ.
• Information om transportprotokollet (UDP, TCP, TLS, HTTPS) och DNS64-prefix har lagts till i output från verktyget dig. För felsökningssyften har möjligheten att ange ett specifikt förfrågnings-ID lagts till i dig (dig +qid=).
• Stöd för OpenSSL 3.0 har lagts till.
• För att lösa problem med IP-fragmentering vid hantering av stora DNS-meddelanden, som anges av DNS Flag Day 2020-initiativet, har koden för justering av EDNS-buffertens storlek tagits bort från resolvern, i fall av avsaknad av svar på en förfrågan. Buffertens storlek för EDNS ställs nu in till ett fast värde (edns-udp-size) för alla utgående förfrågningar.
• Byggsystemet har övergått till användning av en kombination av autoconf, automake och libtool.
• Stödet för zonfiler i "map"-format (masterfile-format map) har upphört. Användare av detta format rekommenderas att konvertera zoner till raw-format med hjälp av verktyget named-compilezone.
• Stödet för gamla DLZ-drivrutiner (Dynamically Loadable Zones) har upphört, och de har ersatts med DLZ-moduler.
• Stödet för byggande och körning på Windows-plattformen har upphört. Den senaste versionen som kan installeras på Windows är BIND 9.16.

Källa: opennet.ru