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.
De uitgave van BIND 9.18.0 valt op door de implementatie van ondersteuning voor de technologieën "DNS over HTTPS" (DoH, DNS over HTTPS) en DNS over TLS (DoT, DNS over TLS), evenals het mechanisme XoT (XFR-over-TLS) voor veilige overdracht van DNS-zone-inhoud tussen servers (ondersteunt zowel verzending als ontvangst van zones via XoT). Met de juiste instellingen kan één proces named nu niet alleen traditionele DNS-verzoeken bedienen, maar ook verzoeken die zijn verzonden met behulp van DNS-over-HTTPS en DNS-over-TLS. Clientondersteuning voor DNS-over-TLS is ingebouwd in de utiliteit dig, die kan worden gebruikt om verzoeken via TLS te verzenden door de vlag "+tls" op te geven.
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.
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 niet-versleutelde DNS-over-HTTP dienen 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 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ïmplementeerd 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.
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.
Onder de nadelen die kunnen worden gecompenseerd door de configuratie zonder DoH/DoT of door versleuteling naar een andere server te verplaatsen, bevindt zich de algemene complexiteit van de codebasis - er wordt een ingebouwde HTTP-server en TLS-bibliotheek toegevoegd, die potentiële kwetsbaarheden kunnen bevatten en extra aanvalsvectoren kunnen vormen. Ook neemt het verkeer toe bij het gebruik van DoH.
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.
Enkele andere vernieuwingen:
- Instellingen tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer en udp-send-buffer zijn toegevoegd om de afmetingen van de buffers die worden gebruikt bij het verzenden en ontvangen van verzoeken via TCP en UDP in te stellen. Bij drukke servers zal het verhogen van de inkomende buffers helpen om het verliezen van pakketten tijdens piekverkeer te voorkomen, terwijl het verkleinen helpt om geheugenproblemen door oude verzoeken te verhelpen.
- Een nieuwe logcategorie «rpz-passthru» is toegevoegd, waarmee de acties van de RPZ (Response Policy Zones) doorsturen afzonderlijk kunnen worden gelogd.
- In de response-policy-sectie is de optie «nsdname-wait-recurse» toegevoegd; wanneer deze is ingesteld op «nee», worden de RPZ NSDNAME-regels alleen toegepast als er voor het verzoek autoritatieve naamservers in de cache zijn gevonden, anders wordt de RPZ NSDNAME-regel genegeerd, maar informatie wordt op de achtergrond opgehaald en toegepast op volgende verzoeken.
- Voor records van de types HTTPS en SVCB is de verwerking van de «ADDITIONAL»-sectie geïmplementeerd.
- Configurabele regeltypes update-policy — krb5-subdomain-self-rhs en ms-subdomain-self-rhs — zijn toegevoegd, waarmee de update van SRV- en PTR-records kan worden beperkt. In de update-policy-blokken is ook de mogelijkheid toegevoegd om beperkingen voor het aantal records, afzonderlijk voor elk type, in te stellen.
- In de uitvoer van de dig-tool zijn informatie over het transportprotocol (UDP, TCP, TLS, HTTPS) en de prefixes van DNS64 toegevoegd. Voor debugdoeleinden is in dig de mogelijkheid toegevoegd om een specifieke verzoekidentificatie op te geven (dig +qid=).
- Ondersteuning voor de OpenSSL 3.0-bibliotheek is toegevoegd.
- Om problemen met IP-fragmentatie bij de verwerking van grote DNS-berichten, aangeduid door het initiatief DNS Flag Day 2020, op te lossen, is de code die de EDNS-buffer-grootte aanpast in het resolver verwijderd als er geen antwoord op het verzoek is. De EDNS-buffer-grootte wordt nu constant ingesteld (edns-udp-size) voor alle uitgaande verzoeken.
- Het buildsysteem is overgeschakeld naar het gebruik van de combinatie van autoconf, automake en libtool.
- De ondersteuning voor zonebestanden in het «map»-formaat (masterfile-format map) is stopgezet. Gebruikers van dit formaat wordt aangeraden om zones om te zetten naar het raw-formaat met de utility named-compilezone.
- De ondersteuning voor oude DLZ (Dynamically Loadable Zones) drivers is stopgezet; deze zijn vervangen door DLZ-modules.
- De ondersteuning voor compilatie en uitvoering op het Windows-platform is stopgezet. De laatste versie die op Windows kan worden geïnstalleerd, blijft BIND 9.16.
Bron: opennet.ru
