Na twee jaar ontwikkeling heeft het ISC-consortium de eerste stabiele release uitgebracht van een grote nieuwe tak van de BIND 9.18 DNS-server. Ondersteuning voor tak 9.18 zal gedurende drie jaar worden verleend tot het 2e kwartaal van 2025 als onderdeel van een verlengde ondersteuningscyclus. De ondersteuning voor de 9.11-tak eindigt in maart en de ondersteuning voor de 9.16-tak medio 2023. Om de functionaliteit van de volgende stabiele versie van BIND te ontwikkelen, is een experimentele tak BIND 9.19.0 gevormd.
De release van BIND 9.18.0 is opmerkelijk vanwege de implementatie van ondersteuning voor DNS via HTTPS (DoH, DNS via HTTPS) en DNS via TLS (DoT, DNS via TLS), evenals het XoT-mechanisme (XFR-over-TLS). voor veilige overdracht van DNS-inhoud zones tussen servers (zowel verzendende als ontvangende zones via XoT 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 DNS-over-HTTPS en DNS-over-TLS. Clientondersteuning voor DNS-over-TLS is ingebouwd in het dig-hulpprogramma, dat kan worden gebruikt om verzoeken 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 het gebruik van de nghttp2-bibliotheek, die is opgenomen als een optionele assembly-afhankelijkheid. Certificaten voor DoH en DoT kunnen door de gebruiker worden verstrekt of automatisch worden gegenereerd tijdens het opstarten.
Verzoekverwerking met behulp van DoH en DoT wordt mogelijk gemaakt door de opties "http" en "tls" toe te voegen aan de luisterrichtlijn. 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;}; }
Een van de kenmerken van de DoH-implementatie in BIND 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 niet-gecodeerde DNS-over-HTTP is geïmplementeerd om het debuggen te vereenvoudigen en als laag voor het doorsturen naar een andere server op het interne netwerk (voor het verplaatsen van de codering naar een aparte server). Op een externe server kan nginx worden gebruikt om TLS-verkeer te genereren, vergelijkbaar met hoe HTTPS-binding is georganiseerd voor websites.
Een ander kenmerk is de integratie van DoH als algemeen transportmiddel dat niet alleen kan worden gebruikt om clientverzoeken aan de oplosser af te handelen, maar ook bij de communicatie tussen servers, bij het overbrengen van zones door een gezaghebbende DNS-server en bij het verwerken van vragen die worden ondersteund door andere DNS-servers. transporteert.
Onder de tekortkomingen die kunnen worden gecompenseerd door de build met DoH/DoT uit te schakelen of de codering naar een andere server te verplaatsen, valt de algemene complicatie van de codebasis op: er zijn een ingebouwde HTTP-server en TLS-bibliotheek toegevoegd, die mogelijk kwetsbaarheden en fungeren als extra vectoren voor aanvallen. Ook neemt het verkeer toe bij gebruik van DoH.
Laten we niet vergeten dat DNS-over-HTTPS nuttig kan zijn voor het voorkomen van het lekken van informatie over de opgevraagde hostnamen via de DNS-servers van providers, het bestrijden van MITM-aanvallen en het spoofen van DNS-verkeer (bijvoorbeeld bij het verbinden met openbare Wi-Fi), het tegengaan van blokkeren op DNS-niveau (DNS-over-HTTPS kan een VPN niet vervangen bij het omzeilen van blokkering geïmplementeerd op DPI-niveau) of voor het organiseren van werk wanneer het onmogelijk is om rechtstreeks toegang te krijgen tot DNS-servers (bijvoorbeeld wanneer u via een proxy werkt). Als in een normale situatie DNS-verzoeken rechtstreeks naar DNS-servers worden verzonden die in de systeemconfiguratie zijn gedefinieerd, dan wordt in het geval van DNS-over-HTTPS het verzoek om het host-IP-adres te bepalen ingekapseld in HTTPS-verkeer en verzonden naar de HTTP-server, waar de oplosser verwerkt verzoeken 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 innovaties:
- Instellingen voor tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer en udp-send-buffer toegevoegd om de grootte van de buffers in te stellen die worden gebruikt bij het verzenden en ontvangen van verzoeken via TCP en UDP. Op drukke servers zal het vergroten van de inkomende buffers helpen voorkomen dat pakketten wegvallen tijdens verkeerspieken, en het verkleinen ervan zal helpen om verstopping van het geheugen door oude verzoeken te voorkomen.
- Er is een nieuwe logcategorie “rpz-passthru” toegevoegd, waarmee u RPZ-doorstuuracties (Response Policy Zones) afzonderlijk kunt loggen.
- In de sectie responsbeleid is de optie “nsdname-wait-recurse” toegevoegd. Wanneer deze is ingesteld op “no”, worden de RPZ NSDNAME-regels alleen toegepast als er gezaghebbende naamservers in de cache worden gevonden voor het verzoek, anders wordt de De RPZ NSDNAME-regel wordt genegeerd, maar de informatie wordt op de achtergrond opgehaald en is van toepassing op volgende verzoeken.
- Voor records met HTTPS- en SVCB-typen is de verwerking van de sectie “ADDITIONEEL” geïmplementeerd.
- Aangepaste updatebeleidsregeltypen toegevoegd - krb5-subdomain-self-rhs en ms-subdomain-self-rhs, waarmee u de update van SRV- en PTR-records kunt beperken. De updatebeleidsblokken voegen ook de mogelijkheid toe om limieten in te stellen voor het aantal records, individueel voor elk type.
- Informatie toegevoegd over het transportprotocol (UDP, TCP, TLS, HTTPS) en DNS64-voorvoegsels aan de uitvoer van het dig-hulpprogramma. Voor foutopsporingsdoeleinden heeft dig de mogelijkheid toegevoegd om een specifieke verzoek-ID op te geven (dig +qid= ).
- Ondersteuning toegevoegd voor de OpenSSL 3.0-bibliotheek.
- Om problemen met IP-fragmentatie aan te pakken bij het verwerken van grote DNS-berichten die zijn geïdentificeerd door DNS Flag Day 2020, is code die de EDNS-buffergrootte aanpast wanneer er geen reactie op een verzoek is, uit de oplosser verwijderd. De EDNS-buffergrootte is nu ingesteld op constant (edns-udp-size) voor alle uitgaande verzoeken.
- Het bouwsysteem is overgeschakeld naar het gebruik van een combinatie van autoconf, automake en libtool.
- Ondersteuning voor zonebestanden in het “kaart”-formaat (kaart in masterfile-formaat) is stopgezet. Gebruikers van dit formaat wordt aangeraden zones naar raw-formaat te converteren met behulp van het hulpprogramma Named-compilezone.
- Ondersteuning voor oudere DLZ-stuurprogramma's (Dynamically Loadable Zones) is stopgezet en vervangen door DLZ-modules.
- Ondersteuning voor het bouwen en uitvoeren van het Windows-platform is stopgezet. De laatste branch die op Windows kan worden geïnstalleerd is BIND 9.16.
Bron: opennet.ru