De ontwikkelaars van de BIND DNS-server hebben de toevoeging aangekondigd van serverondersteuning voor de technologieën DNS over HTTPS (DoH, DNS over HTTPS) en DNS over TLS (DoT, DNS over TLS), evenals het XFR-over-TLS-mechanisme voor veilige het overbrengen van de inhoud van DNS-zones tussen servers. DoH is beschikbaar voor testen in release 9.17 en DoT-ondersteuning is aanwezig sinds release 9.17.10. Na stabilisatie zal DoT- en DoH-ondersteuning worden teruggezet naar de stabiele 9.17.7-tak.
De implementatie van het HTTP/2-protocol dat in DoH wordt gebruikt, is gebaseerd op het gebruik van de nghttp2-bibliotheek, die is opgenomen in de assemblage-afhankelijkheden (in de toekomst is het de bedoeling dat de bibliotheek wordt overgedragen naar het aantal optionele afhankelijkheden). Zowel gecodeerde (TLS) als niet-gecodeerde HTTP/2-verbindingen worden ondersteund. Met de juiste instellingen kan één benoemd proces nu niet alleen traditionele DNS-query's verwerken, maar ook query's die worden verzonden via DoH (DNS-over-HTTPS) en DoT (DNS-over-TLS). HTTPS-ondersteuning aan de clientzijde (dig) is nog niet geïmplementeerd. XFR-over-TLS-ondersteuning is beschikbaar voor zowel inkomende als uitgaande verzoeken.
Verzoekverwerking met behulp van DoH en DoT wordt mogelijk gemaakt door de http- en tls-opties toe te voegen aan de luister-on-richtlijn. Om niet-versleutelde DNS-over-HTTP te ondersteunen, moet u in de instellingen “tls none” opgeven. Sleutels worden gedefinieerd in de sectie 'tls'. De standaard netwerkpoorten 853 voor DoT, 443 voor DoH en 80 voor DNS-over-HTTP kunnen worden overschreven via de tls-port-, https-port- en http-port-parameters. Bijvoorbeeld: tls local-tls { sleutelbestand "/pad/naar/priv_key.pem"; cert-bestand "/pad/naar/cert_chain.pem"; }; http local-http-server {eindpunten { "/dns-query"; }; }; opties {https-poort 443; luisterpoort 443 tls local-tls http mijnserver {any;}; }
Onder de kenmerken van de DoH-implementatie in BIND wordt integratie vermeld als een algemeen transport, dat niet alleen kan worden gebruikt om clientverzoeken aan de oplosser te verwerken, maar ook bij het uitwisselen van gegevens tussen servers, bij het overdragen van zones door een gezaghebbende DNS-server, en bij het verwerken van verzoeken die worden ondersteund door andere DNS-transporten.
Een ander kenmerk is de mogelijkheid om encryptiebewerkingen voor TLS naar een andere server te verplaatsen, wat nodig kan zijn in omstandigheden waarin TLS-certificaten op een ander systeem worden opgeslagen (bijvoorbeeld in een infrastructuur met webservers) en worden onderhouden door ander personeel. Ondersteuning voor ongecodeerde DNS-over-HTTP wordt geïmplementeerd om het debuggen te vereenvoudigen en als laag voor forwarding in het interne netwerk, op basis waarvan encryptie op een andere server kan worden georganiseerd. Op een externe server kan nginx worden gebruikt om TLS-verkeer te genereren, vergelijkbaar met hoe HTTPS-binding is georganiseerd voor websites.
Laten we niet vergeten dat DNS-over-HTTPS nuttig kan zijn voor het voorkomen van het lekken van informatie over de opgevraagde hostnamen via de DNS-servers van providers, het bestrijden van MITM-aanvallen en het spoofen van DNS-verkeer (bijvoorbeeld bij het verbinden met openbare Wi-Fi), het tegengaan van blokkeren op DNS-niveau (DNS-over-HTTPS kan een VPN niet vervangen bij het omzeilen van blokkering geïmplementeerd op DPI-niveau) of voor het organiseren van werk wanneer het onmogelijk is om rechtstreeks toegang te krijgen tot DNS-servers (bijvoorbeeld wanneer u via een proxy werkt). Als in een normale situatie DNS-verzoeken rechtstreeks naar DNS-servers worden verzonden die in de systeemconfiguratie zijn gedefinieerd, dan wordt in het geval van DNS-over-HTTPS het verzoek om het host-IP-adres te bepalen ingekapseld in HTTPS-verkeer en verzonden naar de HTTP-server, waar de oplosser verwerkt verzoeken via de web-API.
“DNS over TLS” verschilt van “DNS over HTTPS” in het gebruik van het standaard DNS-protocol (meestal wordt netwerkpoort 853 gebruikt), verpakt in een gecodeerd communicatiekanaal georganiseerd met behulp van het TLS-protocol, waarbij de geldigheid van de host wordt gecontroleerd via gecertificeerde TLS/SSL-certificaten door een certificeringsinstantie. De bestaande DNSSEC-standaard gebruikt alleen encryptie om de client en server te authenticeren, maar beschermt het verkeer niet tegen onderschepping en garandeert niet de vertrouwelijkheid van verzoeken.
Bron: opennet.ru