Udviklerne af DNS-serveren BIND har annonceret, at de i den eksperimentelle gren 9.17 har tilføjet serverunderstøttelse for teknologierne "DNS over HTTPS" (DoH, DNS over HTTPS) og DNS over TLS (DoT, DNS over TLS), samt en mekanisme til XFR-over-TLS for sikker overførsel af DNS-zones indhold mellem servere. DoH er tilgængelig til testning i version 9.17.10, og understøttelsen af DoT er til stede fra version 9.17.7. Efter stabilisering vil understøttelsen af DoT og DoH blive backportet til den stabile gren 9.16.
Implementeringen af HTTP/2-protokollen, der anvendes i DoH, er baseret på brugsbiblioteket nghttp2, som er inkluderet i byggeafhængighederne (biblioteket planlægges senere at blive flyttet til optionale afhængigheder). Både krypterede (TLS) og ukrypterede forbindelser over HTTP/2 understøttes. Med de rette indstillinger kan én named-proces nu håndtere ikke blot traditionelle DNS-forespørgsler, men også forespørgsler sendt med DoH (DNS-over-HTTPS) og DoT (DNS-over-TLS). Klient-side understøttelse af HTTPS (dig) er endnu ikke implementeret. Understøttelse af XFR-over-TLS er tilgængelig for både indgående og udgående forespørgsler.
Håndtering af forespørgsler med DoH og DoT aktiveres ved at tilføje http- og tls-optioner i listen-on-direktivet. For at understøtte ukrypteret DNS-over-HTTP skal indstillingerne angive "tls none". Nøgler defineres i "tls"-sektionen. De standard netværksporte 853 for DoT, 443 for DoH og 80 for DNS-over-HTTP kan overskrives via tls-port, https-port og http-port parametre. For eksempel: 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 af de dragende træk ved implementeringen af DoH i BIND er integrationen som en generel transport, som kan anvendes ikke blot til at håndtere forespørgsler fra klienter til resolveren, men også ved dataudveksling mellem servere, ved overførsel af zoner fra den autoritative DNS-server og ved håndtering af enhver forespørgsel, der understøttes af andre DNS-transporter.
En anden funktion er muligheden for at flytte krypteringsoperationer til TLS til en anden server, hvilket kan være nødvendigt, når TLS-certifikater opbevares på et andet system (for eksempel i en infrastruktur med webservere) og håndteres af andet personale. Understøttelse af ukrypteret DNS-over-HTTP er implementeret for at forenkle fejlfinding og som et niveau til at videresende i det interne netværk, hvorpå kryptering kan organiseres på en anden server. Nginx kan anvendes på den eksterne server til generering af TLS-trafik, ligesom det gøres med HTTPS-indpakning for websteder.
It’s worth noting that DNS-over-HTTPS can be useful for preventing the leakage of requested hostnames through provider DNS servers, combating MITM attacks and DNS traffic spoofing (for example, when connecting to public Wi-Fi), and overcoming DNS-level blocks (DNS-over-HTTPS cannot replace the circumvention of blocks implemented at the DPI level) or for enabling functionality when direct access to DNS servers is not possible (for example, when working through a proxy). In normal situations, DNS queries are directly sent to specific DNS servers configured in the system, but in the case of DNS-over-HTTPS, the request for hostname resolution is encapsulated in HTTPS traffic and sent to the HTTP server, where the resolver processes requests via Web API. VPN i forbindelse med omgåelse af blokeringer implementeret på DPI-niveau) eller til at organisere drift i tilfælde af, at direkte adgang til DNS-servere ikke er muligt (for eksempel ved brug af en proxy). Hvis DNS-forespørgsler normalt sendes direkte til de i systemkonfigurationen angivne DNS-servere, så indkapsles DNS-over-HTTPS-forespørgslen til bestemmelse af IP-adresser værten i HTTPS-trafik og sendes til en HTTP-server, hvor resolveren behandler forespørgsler via Web API.
«DNS over TLS» adskiller sig fra «DNS over HTTPS» ved at anvende den standard DNS-protokol (normalt bruger netværksport 853), indpakket i en krypteret kommunikationskanal etableret ved hjælp af TLS-protokollen med validering af værtens identitet gennem TLS/SSL-certifikater, som er verificeret af et certifikationsorgan. Den eksisterende standard DNSSEC bruger kryptering kun til at autentificere klienten og serveren, men beskytter ikke traffikken mod opsnapping og garanterer ikke fortrolighed for forespørgsler.
Kilde: opennet.ru
