Na twee jaar ontwikkeling heeft het ISC-consortium de eerste stabiele release uitgebracht van een belangrijke nieuwe branch van de BIND DNS-server: BIND 9.18. Ondersteuning voor de 9.18-branch wordt drie jaar lang geboden, tot het tweede kwartaal van 2, als onderdeel van een uitgebreide onderhoudscyclus. De ondersteuning voor de 2025-branch eindigt in maart en voor de 9.11-branch medio 9.16. Een experimentele branch, BIND 2023, is ontwikkeld om de functionaliteit van de volgende stabiele versie van BIND te ontwikkelen.
De release van BIND 9.18.0 is opmerkelijk vanwege de implementatie van ondersteuning voor DNS over HTTPS (DoH, DNS over HTTPS) en DNS over TLS (DoT, DNS over TLS) technologieën, evenals het XoT (XFR-over-TLS) mechanisme voor het veilig overbrengen van de inhoud van DNS-zones tussen servers (zowel verzend- als ontvangstzones via XoT worden ondersteund). Met de juiste instellingen kan één enkel benoemd proces nu niet alleen traditionele DNS-query's verwerken, maar ook query's die worden verzonden via DNS-over-HTTPS en DNS-over-TLS. Clientondersteuning voor DNS-over-TLS is ingebouwd in het hulpprogramma dig, dat kan worden gebruikt om query's via TLS te verzenden wanneer de vlag "+tls" is opgegeven.
De implementatie van het HTTP/2-protocol dat in DoH wordt gebruikt, is gebaseerd op de nghttp2-bibliotheek, die deel uitmaakt van de optionele build-afhankelijkheden. Certificaten voor DoH en DoT kunnen door de gebruiker worden verstrekt of automatisch worden gegenereerd bij het opstarten.
Verwerking van verzoeken met DoH en DoT wordt ingeschakeld door de opties "http" en "tls" toe te voegen aan de listen-on-richtlijn. Om ongecodeerde DNS-over-HTTP te ondersteunen, moet "tls none" worden opgegeven in de instellingen. De 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 parameters tls-port, https-port en http-port. 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; listen-on poort 443 tls local-tls http mijnserver {alle;}; }
Een van de kenmerken van de DoH-implementatie in BIND is de mogelijkheid om encryptiebewerkingen voor TLS naar een andere server te verplaatsen. Dit kan nodig zijn in situaties waarin TLS-certificaten op een ander systeem zijn opgeslagen (bijvoorbeeld in een infrastructuur met webservers) en door ander personeel worden beheerd. Ondersteuning voor ongecodeerde DNS-over-HTTP is geïmplementeerd om foutopsporing te vereenvoudigen en als een niveau voor doorsturen naar een andere server in het interne netwerk (om encryptie naar een aparte server te verplaatsen). Op de externe server kan nginx worden gebruikt om TLS-verkeer te genereren, vergelijkbaar met hoe HTTPS-binding voor websites is georganiseerd.
Een andere feature is de integratie van DoH als algemeen transport. Dit transport kan niet alleen worden gebruikt voor het verwerken van clientverzoeken aan de resolver, maar ook voor het uitwisselen van gegevens tussen servers, voor het overdragen van zones door een gezaghebbende DNS-server en voor het verwerken van verzoeken die door andere DNS-transporten worden ondersteund.
Van de tekortkomingen die kunnen worden gecompenseerd door de assembly met DoH/DoT uit te schakelen of de encryptie naar een andere server te verplaatsen, valt de algemene complicatie van de codebase op: een ingebouwde HTTP-server en TLS-bibliotheek worden aan de compositie toegevoegd, wat mogelijk kwetsbaarheden kan bevatten en kan dienen als extra aanvalsvectoren. Bovendien neemt het verkeer toe bij gebruik van DoH.
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.
Enkele andere nieuwe functies:
- Instellingen voor tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer en udp-send-buffer toegevoegd om de grootte van de buffers te specificeren die worden gebruikt bij het verzenden en ontvangen van verzoeken via TCP en UDP. Op drukke servers helpt het vergroten van de inkomende buffers om te voorkomen dat pakketten tijdens pieken in het verkeer worden gedropt, terwijl het verkleinen ervan helpt voorkomen dat het geheugen vol raakt met oude verzoeken.
- Er is een nieuwe logcategorie 'rpz-passthru' toegevoegd om afzonderlijke logging van RPZ (Response Policy Zones) passthru-acties mogelijk te maken.
- In het gedeelte Responsbeleid is nu een optie beschikbaar met de naam "nsdname-wait-recurse". Als deze optie is ingesteld op "nee", worden RPZ NSDNAME-regels alleen toegepast als er in de cache opgeslagen, gezaghebbende naamservers voor de aanvraag worden gevonden. Als dit niet het geval is, wordt de RPZ NSDNAME-regel genegeerd, maar wordt de informatie op de achtergrond opgehaald en toegepast op volgende aanvragen.
- Voor records met HTTPS- en SVCB-typen is de verwerking van de sectie 'EXTRA' geïmplementeerd.
- Aangepaste updatebeleidregeltypen toegevoegd — krb5-subdomein-self-rhs en ms-subdomein-self-rhs — om updates tot SRV- en PTR-records te beperken. Updatebeleidblokken bieden nu ook de mogelijkheid om limieten voor het aantal records voor elk type in te stellen.
- De uitvoer van dig bevat nu informatie over het transportprotocol (UDP, TCP, TLS, HTTPS) en DNS64-prefixen. Voor foutopsporing kunt u met dig nu een specifieke aanvraag-ID opgeven (dig +qid= ).
- Ondersteuning toegevoegd voor de OpenSSL 3.0-bibliotheek.
- Om problemen met IP-fragmentatie bij het verwerken van grote DNS-berichten aan te pakken, zoals benadrukt door DNS Flag Day 2020, heeft de resolver code verwijderd die de EDNS-buffergrootte aanpast wanneer een query niet wordt beantwoord. De EDNS-buffergrootte is nu ingesteld op een constante grootte (edns-udp-size) voor alle uitgaande query's.
- Er wordt nu gebruikgemaakt van een combinatie van autoconf, automake en libtool als bouwsysteem.
- Ondersteuning voor zonebestanden in het "map"-formaat (masterfile-format map) is stopgezet. Gebruikers van dit formaat wordt geadviseerd zones naar het raw-formaat te converteren met behulp van het hulpprogramma named-compilezone.
- Ondersteuning voor oude DLZ-stuurprogramma's (Dynamically Loadable Zones) is stopgezet en vervangen door DLZ-modules.
- Прекращена поддержка сборки и запуска для платформы Windows. Последней веткой, которую можно установить в Windows, остаётся BIND 9.16.
Bron: opennet.ru
