De ontwikkelaars van de DNS-server BIND hebben aangekondigd dat in de experimentele tak 9.17 serverondersteuning voor technologieën zoals 'DNS over HTTPS' (DoH, DNS over HTTPS) en DNS over TLS (DoT, DNS over TLS) is toegevoegd, evenals een mechanisme voor XFR-over-TLS voor veilige overdracht van DNS-zone-inhoud tussen servers. DoH is beschikbaar voor testen in versie 9.17.10, en ondersteuning voor DoT is aanwezig vanaf versie 9.17.7. Na stabilisatie zal de ondersteuning voor DoT en DoH worden teruggevoerd naar de stabiele tak 9.16.
De implementatie van het HTTP/2-protocol, gebruikt in DoH, is gebaseerd op de toepassing van de nghttp2-bibliotheek, die tot de bouwafhankelijkheden behoort (de bibliotheek zal in de toekomst worden omgezet naar optionele afhankelijkheden). Zowel versleutelde (TLS) als niet-versleutelde verbindingen via HTTP/2 worden ondersteund. Met de juiste instellingen kan één named-proces nu niet alleen traditionele DNS-verzoeken verwerken, maar ook verzoeken die zijn verzonden met behulp van DoH (DNS-over-HTTPS) en DoT (DNS-over-TLS). Ondersteuning voor HTTPS aan de clientszijde (dig) is nog niet geïmplementeerd. Ondersteuning voor XFR-over-TLS is beschikbaar voor zowel inkomende als uitgaande verzoeken.
De verwerking van verzoeken met behulp van DoH en DoT wordt ingeschakeld door opties http en tls toe te voegen aan de directive listen-on. Om ondersteuning voor niet-versleutelde DNS-over-HTTP te bieden, dient in de instellingen 'tls none' te worden opgegeven. Sleutels worden gedefinieerd in de sectie 'tls'. Standaard netwerkpoorten 853 voor DoT, 443 voor DoH en 80 voor DNS-over-HTTP kunnen worden overschreven via de parameters tls-port, https-port en http-port. Bijvoorbeeld: 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;}; }
Een kenmerk van de implementatie van DoH in BIND is de integratie als een algemeen transport, dat kan worden toegepast voor niet alleen het verwerken van verzoeken van clients aan de resolver, maar ook voor gegevensuitwisseling tussen servers, bij de overdracht van zones door een autoritatieve DNS-server en bij het verwerken van alle verzoeken die door andere DNS-transports worden ondersteund.
Een andere functie is de mogelijkheid om TLS-encryptieoperaties naar een andere server te verplaatsen, wat nodig kan zijn wanneer TLS-certificaten op een ander systeem worden opgeslagen (bijvoorbeeld in een infrastructuur met webservers) en door ander personeel worden beheerd. Ondersteuning voor onbeveiligde DNS-over-HTTP is geïmplementeerd om debugging te vereenvoudigen en als niveau voor doorvoer in het interne netwerk, waarop versleuteling op een andere server kan worden georganiseerd. Op de externe server kan Nginx worden gebruikt voor het genereren van TLS-verkeer, vergelijkbaar met hoe HTTPS voor websites wordt opgezet.
Ter herinnering, DNS-over-HTTPS kan nuttig zijn om lekken van informatie over aangevraagde hostnamen via de DNS-servers van providers te voorkomen, om MITM-aanvallen en vervalsing van DNS-verkeer (bijvoorbeeld bij verbinding met openbare Wi-Fi) tegen te gaan en om blokkades op DNS-niveau te omzeilen (DNS-over-HTTPS kan niet vervangen worden in de context van het omzeilen van blokkades die op DPI-niveau zijn gerealiseerd) of voor het organiseren van werking in gevallen waarin direct contact met DNS-servers niet mogelijk is (bijvoorbeeld bij het werken via een proxy). In een normale situatie worden DNS-aanvragen rechtstreeks naar bepaalde DNS-servers in de systeemconfiguratie gestuurd, maar in het geval van DNS-over-HTTPS wordt de aanvraag voor het bepalen VPN van de host ingekapseld in HTTPS-verkeer en verzonden naar de HTTP-server, waar de resolver aanvragen verwerkt via een Web API. IP-adressen Zorg ervoor dat je een eigen vertaling voor deze tekst maakt, als deze tekst anders is vermeld in de vereisten.
«DNS over TLS» verschilt van «DNS over HTTPS» door het gebruik van het standaard DNS-protocol (meestal gebruikt op netwerkpoort 853), verpakt in een versleuteld communicatiekanaal, georganiseerd met behulp van het TLS-protocol met hostvalidatie via TLS/SSL-certificaten, gecertificeerd door een certificeringsinstantie. De bestaande DNSSEC-standaard gebruikt versleuteling alleen voor de authenticatie van de client en server, maar beschermt de verkeer niet tegen onderschepping en garandeert geen vertrouwelijkheid van verzoeken.
Bron: opennet.ru
