Utvecklarna av BIND DNS-servern tillkännagav tillägget av serverstöd för teknologierna DNS över HTTPS (DoH, DNS över HTTPS) och DNS över TLS (DoT, DNS över TLS), samt XFR-over-TLS-mekanismen för säker överföra innehållet i DNS-zoner mellan servrar. DoH är tillgängligt för testning i release 9.17, och DoT-stöd har funnits sedan release 9.17.10. Efter stabilisering kommer DoT- och DoH-stöd att backporteras till den stabila 9.17.7-grenen.
Implementeringen av HTTP/2-protokollet som används i DoH baseras på användningen av nghttp2-biblioteket, som ingår bland assembly-beroendena (i framtiden planeras biblioteket att överföras till antalet valfria beroenden). Både krypterade (TLS) och okrypterade HTTP/2-anslutningar 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 DoH (DNS-over-HTTPS) och DoT (DNS-over-TLS). HTTPS-stöd på klientsidan (dig) är ännu inte implementerat. XFR-over-TLS-stöd är tillgängligt för både inkommande och utgående förfrågningar.
Bearbetning av förfrågningar med hjälp av DoH och DoT aktiveras genom att lägga till alternativen http och tls i lyssningsdirektivet. 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 { key-file "/path/to/priv_key.pem"; cert-fil "/path/to/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;}; }
Bland funktionerna i DoH-implementeringen i BIND noteras integration som en allmän transport, som inte bara kan användas för att behandla klientförfrågningar till resolvern, utan också vid utbyte av data mellan servrar, vid överföring av zoner av en auktoritativ DNS-server, och vid behandling av förfrågningar som stöds av andra DNS-transporter.
En annan funktion ä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 i det interna nätverket, på basis av vilket kryptering kan organiseras på en annan server. På en fjärrserver kan nginx användas för att generera TLS-trafik, liknande hur HTTPS-bindning är organiserad för webbplatser.
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.
Källa: opennet.ru