Po dvou letech vývoje představil konsorcium ISC první stabilní verzi nové významné větve DNS serveru BIND 9.18. Podpora této větve 9.18 bude zajišťována po dobu tří let až do druhého čtvrtletí 2025 v rámci rozšířeného cyklu údržby. Podpora větve 9.11 skončí v březnu a větve 9.16 v polovině roku 2023. Pro vývoj funkcionality další stabilní verze BIND byla vytvořena experimentální větev BIND 9.19.0.
Vydání BIND 9.18.0 je význačné implementací podpory technologií „DNS přes HTTPS“ (DoH, DNS over HTTPS) a DNS přes TLS (DoT, DNS over TLS), stejně jako mechanismu XoT (XFR-over-TLS) pro bezpečný přenos obsahu DNS zón mezi servery (podporováno jak při odesílání, tak při příjmu zón přes XoT). Při odpovídajících nastaveních nyní může jeden proces named obsluhovat nejen tradiční DNS dotazy, ale i dotazy zaslané pomocí DNS-over-HTTPS a DNS-over-TLS. Klientská podpora DNS-over-TLS je integrována do utility dig, která může být použita k odesílání dotazů přes TLS při uvedení příznaku „+tls”.
Implementace protokolu HTTP/2, který se používá v DoH, je založena na využití knihovny nghttp2, která je zahrnuta mezi volitelné závislosti při sestavování. Certifikáty pro DoH a DoT mohou být poskytovány uživatelem nebo generovány automaticky při spuštění.
Zpracování dotazů pomocí DoH a DoT se aktivuje přidáním možností „http“ a „tls“ do direktivy listen-on. Pro podporu nezabezpečeného DNS-over-HTTP je třeba v nastaveních uvést „tls none“. Klíče jsou definovány v sekci „tls“. Standardní síťové porty 853 pro DoT, 443 pro DoH a 80 pro DNS-over-HTTP mohou být přepsány prostřednictvím parametrů tls-port, https-port a http-port. Například:
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;}; }
Mezi vlastnostmi implementace DoH v BIND se vyznačuje možnost přesunutí šifrovacích operací pro TLS na jiný server, což může být nezbytné v situacích, kdy jsou TLS certifikáty uloženy na jiném systému (například v infrastruktuře s webovými servery) a spravovány jiným personálem. Podpora nešifrovaného DNS-over-HTTP byla implementována pro usnadnění debuggingu a jako úroveň pro předání na jiný server v interní síti (pro přesun šifrování na samostatný server). Na externím serveru pro generování TLS provozu může být použit nginx, podobně jako je organizováno obalování HTTPS pro webové stránky.
Další vlastností je integrace DoH jako obecného transportu, který může být použit nejen pro zpracování požadavků klientů na resolver, ale také při výměně dat mezi servery, při předávání zón autoritativním DNS serverem a při zpracování jakýchkoliv požadavků podporovaných jinými DNS transporty.
Mezi nevýhody, které mohou být kompenzovány zakázáním kompilace s DoH/DoT nebo přesunem šifrování na jiný server, patří celkové ztížení kódové základny — přidává se vestavěný HTTP server a TLS knihovna, které potenciálně mohou obsahovat zranitelnosti a představovat dodatečné vektory pro útoky. Také při použití DoH se zvyšuje provoz.
Připomínáme, že DNS-over-HTTPS může být užitečné pro vyloučení úniků informací o dotazovaných názvech hostitelů přes DNS servery poskytovatelů, pro boj s MITM útoky a podvodem DNS provozu (například při připojení k veřejným Wi-Fi), pro odolávání blokacím na úrovni DNS (DNS-over-HTTPS nemůže nahradit VPN v oblasti obcházení blokací, realizovaných na úrovni DPI) nebo pro organizaci práce v případě nemožnosti přímého přístupu k DNS serverům (například při práci přes proxy). Pokud jsou v běžné situaci DNS dotazy přímo odesílány na určité v konfiguraci systému DNS servery, pak v případě DNS-over-HTTPS je požadavek na určení IP adres hostitele enkapsulován v HTTPS provozu a odeslán na HTTP server, na němž resolver zpracovává požadavky prostřednictvím Web API.
„DNS over TLS“ se liší od „DNS over HTTPS“ použitím standardního protokolu DNS (obvykle používaný síťový port 853), zabalného do šifrovaného komunikačního kanálu, organizovaného pomocí protokolu TLS s ověřením platnosti hosta prostřednictvím TLS/SSL certifikátů, které jsou certifikovány certifikační autoritou. Existující standard DNSSEC používá šifrování pouze pro autentizaci klienta a serveru, ale nechrání provoz před odposloucháváním a nezaručuje důvěrnost dotazů.
Některé další novinky:
- Byly přidány nastavení tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer a udp-send-buffer pro nastavení velikostí bufferů používaných při odesílání a přijímání dotazů přes TCP a UDP. Na zatížených serverech zvýšení příchozích bufferů pomůže zabránit ztrátě paketů během špičkového provozu, zatímco snížení pomůže zbavit se přetížení paměti starými dotazy.
- Byla přidána nová kategorie logů „rpz-passthru“, která umožňuje samostatně zaznamenávat akce pro průchod RPZ (Response Policy Zones).
- Do sekce response-policy byla přidána možnost „nsdname-wait-recurse“, při jejímž nastavení na „no“ jsou pravidla RPZ NSDNAME aplikována pouze tehdy, pokud jsou pro dotaz nalezeny v cache autoritativní servery názvů, jinak je pravidlo RPZ NSDNAME ignorováno, ale informace se odtahují na pozadí a aplikují se na následující dotazy.
- Pro záznamy s typy HTTPS a SVCB byla realizována podpora zpracování sekce „ADDITIONAL“.
- Byly přidány konfigurovatelné typy pravidel update-policy — krb5-subdomain-self-rhs a ms-subdomain-self-rhs, které umožňují omezit aktualizaci záznamů SRV a PTR. V blocích update-policy byla také přidána možnost stanovit omezení počtu záznamů, která jsou specifická pro každý typ.
- Do výstupu nástroje dig byly přidány informace o přenosovém protokolu (UDP, TCP, TLS, HTTPS) a předponách DNS64. Pro účely ladění byla do dig přidána možnost určení konkrétního identifikátoru dotazu (dig +qid=).
- Byla přidána podpora pro knihovnu OpenSSL 3.0.
- Aby se vyřešily problémy s IP fragmentací při zpracování velkých DNS zpráv, které byly označeny iniciativou DNS Flag Day 2020, byl z resolveru odstraněn kód, který upravoval velikost bufferu EDNS v případě absence odpovědi na dotaz. Velikost bufferu EDNS je nyní nastavena na konstantní (edns-udp-size) pro všechny odchozí dotazy.
- Systém sestavení byl převeden na použití sady autoconf, automake a libtool.
- Podpora souborů zón ve formátu „map“ (masterfile-format map) byla ukončena. Uživatelům tohoto formátu se doporučuje převést zóny na formát raw pomocí nástroje named-compilezone.
- Podpora starých ovladačů DLZ (Dynamically Loadable Zones) byla ukončena a na jejich místo přišly moduly DLZ.
- Podpora sestavení a spuštění pro platformu Windows byla ukončena. Poslední větví, kterou lze nainstalovat na Windows, zůstává BIND 9.16.
Zdroj: opennet.ru
