Na twee jaar ontwikkeling heeft het consortium ISC de eerste stabiele release van de nieuwe belangrijke tak van DNS-server BIND 9.18 gepresenteerd. De ondersteuning voor tak 9.18 zal gedurende drie jaar plaatsvinden tot het tweede kwartaal van 2025 als onderdeel van een uitgebreid onderhoudscyclus. De ondersteuning voor tak 9.11 eindigt in maart, terwijl de ondersteuning voor tak 9.16 medio 2023 zal stoppen. Voor de ontwikkeling van de functionaliteit van de volgende stabiele versie van BIND is er een experimentele tak BIND 9.19.0 gevormd. <\/p>\n
De release van BIND 9.18.0 is opmerkelijk door de implementatie van ondersteuning voor technologie\u00ebn zoals 'DNS over HTTPS' (DoH) en DNS over TLS (DoT), evenals het mechanisme XoT (XFR-over-TLS) voor veilige overdracht van DNS-zone-inhoud tussen servers (ondersteuning voor zowel uitwisseling als ontvangst van zones via XoT). Met de juiste instellingen kan \u00e9\u00e9n named-proces nu niet alleen traditionele DNS-verzoeken verwerken, maar ook verzoeken die via DNS-over-HTTPS en DNS-over-TLS zijn verzonden. Klantsupport voor DNS-over-TLS is ingebouwd in de dig-tool, die kan worden gebruikt om verzoeken over TLS te verzenden met de vlag '+tls'. <\/p>\n
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 optionele bouwafhankelijkheden. Certificaten voor DoH en DoT kunnen door de gebruiker worden verstrekt of automatisch worden gegenereerd tijdens de opstart. <\/p>\n
De verwerking van verzoeken met behulp van DoH en DoT wordt ingeschakeld door de opties 'http' en 'tls' toe te voegen aan de listen-on-directive. Voor ondersteuning van onbeveiligde DNS-over-HTTP dient 'tls none' te worden opgegeven in de instellingen. Sleutels worden gedefinieerd in de 'tls'-sectie. De standaard netwerpoorten 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: <\/p>\n
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;}; } <\/p>\n
Een van de kenmerken van de implementatie van DoH in BIND is de mogelijkheid om versleuteling voor TLS naar een andere server te verplaatsen, wat nodig kan zijn in situaties waarin TLS-certificaten op een ander systeem worden opgeslagen (bijvoorbeeld in infrastructuren met webservers) en door ander personeel worden beheerd. Ondersteuning voor ongecodeerde DNS-over-HTTP is ge\u00efmplementeerd om het debuggen te vergemakkelijken en als een laag voor het doorsturen naar een andere server binnen het interne netwerk (voor het verplaatsen van versleuteling naar een aparte server). Op de externe server kan nginx worden gebruikt voor het genereren van TLS-verkeer, vergelijkbaar met hoe de HTTPS-koppeling voor websites is ingericht. <\/p>\n
Een ander kenmerk is de integratie van DoH als een algemeen transport dat niet alleen kan worden toegepast voor het verwerken van klantaanvragen aan de resolver, maar ook voor het uitwisselen van gegevens tussen servers, bij het verzenden van zones door een autoritatieve DNS-server en bij het verwerken van alle aanvragen die door andere DNS-transports worden ondersteund. <\/p>\n
Een nadeel dat kan worden verholpen door de compilatie met DoH\/DoT uit te schakelen of de encryptie naar een andere server te verplaatsen, is de algehele complexiteit van de codebase \u2014 de ingebouwde HTTP-server en TLS-bibliotheek worden toegevoegd, die mogelijk kwetsbaarheden kunnen bevatten en extra aanvalsvectoren kunnen vormen. Bovendien neemt het verkeer toe bij het gebruik van DoH. <\/p>\n
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<\/a> van de host ingekapseld in HTTPS-verkeer en verzonden naar de HTTP-server, waar de resolver aanvragen verwerkt via een Web API. IP-adressen<\/a> Zorg ervoor dat je een eigen vertaling voor deze tekst maakt, als deze tekst anders is vermeld in de vereisten. <\/p>\n \u2018DNS over TLS\u2019 verschilt van \u2018DNS over HTTPS\u2019 door het gebruik van het standaard DNS-protocol (meestal gebruikt netwerkpoort 853), verpakt in een versleutelde communicatie-kanaal, georganiseerd met behulp van het TLS-protocol met host-validatie via TLS\/SSL-certificaten, goedgekeurd door een certificeringsinstantie. De bestaande standaard DNSSEC gebruikt versleuteling alleen voor authenticatie van de cli\u00ebnt en de server, maar beschermt het verkeer niet tegen onderschepping en waarborgt niet de vertrouwelijkheid van de aanvragen. <\/p>\n Enkele andere vernieuwingen: <\/p>\n\n