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.
We willen u er nogmaals op wijzen dat DNS-over-HTTPS nuttig kan zijn om te voorkomen dat informatie over opgevraagde hostnamen via de DNS-servers van providers lekt, om MITM-aanvallen en DNS-verkeersvervanging tegen te gaan (bijvoorbeeld bij het verbinden met openbare wifi-netwerken), en om blokkering op DNS-niveau te omzeilen (DNS-over-HTTPS kan geen vervanging zijn voor...). VPN (bijvoorbeeld om blokkeringen op DPI-niveau te omzeilen) of om werkzaamheden te organiseren in gevallen waarin directe toegang tot DNS-servers onmogelijk is (bijvoorbeeld bij gebruik van een proxy). Normaal gesproken worden DNS-query's rechtstreeks naar de in de systeemconfiguratie gedefinieerde DNS-servers gestuurd, maar bij DNS-over-HTTPS wordt de aanvraag voor bepaling via een aparte server verzonden. IP-adressen De host wordt ingekapseld in HTTPS-verkeer en naar een HTTP-server gestuurd, waar de resolver de verzoeken verwerkt 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
