Po dvou letech vývoje vydalo konsorcium ISC první stabilní verzi nové hlavní větve DNS serveru BIND 9.18. Podpora pro větev 9.18 bude poskytována po dobu tří let do 2. čtvrtletí roku 2025 v rámci prodlouženého cyklu podpory. Podpora pro větev 9.11 skončí v březnu a podpora pro větev 9.16 v polovině roku 2023. Pro vývoj funkčnosti další stabilní verze BIND byla vytvořena experimentální větev BIND 9.19.0.
Vydání BIND 9.18.0 je pozoruhodné implementací podpory pro DNS přes HTTPS (DoH, DNS přes HTTPS) a DNS přes TLS (DoT, DNS přes TLS), stejně jako mechanismus XoT (XFR-over-TLS). pro bezpečný přenos obsahu DNS.zóny mezi servery (podporovány jsou odesílací i přijímací zóny přes XoT). S příslušným nastavením může nyní jeden pojmenovaný proces obsluhovat nejen tradiční DNS dotazy, ale také dotazy odeslané pomocí DNS-over-HTTPS a DNS-over-TLS. Klientská podpora pro DNS-over-TLS je zabudována do obslužného programu dig, který lze použít k odesílání požadavků přes TLS, když je zadán příznak „+tls“.
Implementace protokolu HTTP/2 používaného v DoH je založena na použití knihovny nghttp2, která je zahrnuta jako volitelná závislost sestavení. Certifikáty pro DoH a DoT mohou být poskytnuty uživatelem nebo generovány automaticky při spuštění.
Zpracování požadavků pomocí DoH a DoT je povoleno přidáním možností "http" a "tls" do direktivy listen-on. Chcete-li podporovat nešifrované DNS-over-HTTP, měli byste v nastavení zadat „tls none“. Klíče jsou definovány v části "tls". Výchozí síťové porty 853 pro DoT, 443 pro DoH a 80 pro DNS-over-HTTP lze přepsat pomocí parametrů tls-port, https-port a http-port. Například:
tls local-tls { soubor-klíče "/cesta/k/priv_key.pem"; cert-file "/cesta/k/cert_chain.pem"; }; http místní-http-server { koncové body { "/dns-query"; }; }; možnosti { https-port 443; naslouchací port 443 tls local-tls http myserver {libovolný;}; }
Jednou z funkcí implementace DoH v BIND je schopnost přesunout operace šifrování pro TLS na jiný server, což může být nezbytné v podmínkách, kdy jsou certifikáty TLS uloženy na jiném systému (například v infrastruktuře s webovými servery) a udržovány. jiným personálem. Podpora nešifrovaného DNS-over-HTTP je implementována pro zjednodušení ladění a jako vrstva pro předávání na jiný server v interní síti (pro přesun šifrování na samostatný server). Na vzdáleném serveru lze nginx použít ke generování provozu TLS, podobně jako je organizována vazba HTTPS pro webové stránky.
Další funkcí je integrace DoH jako obecného transportu, který lze použít nejen ke zpracování požadavků klientů na resolver, ale také při komunikaci mezi servery, při přenosu zón autoritativním serverem DNS a při zpracování jakýchkoli dotazů podporovaných jinými DNS. přepravy.
Mezi nedostatky, které lze kompenzovat deaktivací sestavení s DoH/DoT nebo přesunem šifrování na jiný server, vyniká obecná komplikace kódové základny - je přidán vestavěný HTTP server a TLS knihovna, která by potenciálně mohla obsahovat zranitelnosti a fungují jako další vektory pro útoky. Při použití DoH se také zvyšuje provoz.
Připomeňme, že DNS-over-HTTPS může být užitečné pro zabránění úniku informací o požadovaných hostitelských názvech přes DNS servery poskytovatelů, potírání MITM útoků a DNS traffic spoofing (například při připojení k veřejné Wi-Fi), potírání zablokování na úrovni DNS (DNS-over-HTTPS nemůže nahradit VPN při obcházení blokování implementovaného na úrovni DPI) nebo pro organizaci práce, když není možný přímý přístup k serverům DNS (například při práci přes proxy). Pokud jsou za normální situace požadavky DNS odesílány přímo na servery DNS definované v konfiguraci systému, pak v případě DNS-over-HTTPS je požadavek na určení IP adresy hostitele zapouzdřen v HTTPS provozu a odeslán na HTTP server, kde resolver zpracovává požadavky přes Web API.
„DNS over TLS“ se liší od „DNS over HTTPS“ v použití standardního protokolu DNS (obvykle se používá síťový port 853), zabaleného do šifrovaného komunikačního kanálu organizovaného pomocí protokolu TLS s kontrolou platnosti hostitele prostřednictvím certifikovaných certifikátů TLS/SSL certifikační autoritou. Stávající standard DNSSEC používá šifrování pouze k ověření klienta a serveru, ale nechrání provoz před zachycením a nezaručuje důvěrnost požadavků.
Některé další inovace:
- Přidána nastavení tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer a udp-send-buffer pro nastavení velikosti vyrovnávacích pamětí používaných při odesílání a přijímání požadavků přes TCP a UDP. Na vytížených serverech pomůže zvýšení příchozích vyrovnávacích pamětí zabránit zahazování paketů během špiček provozu a jejich snížení pomůže zbavit se zahlcení paměti starými požadavky.
- Byla přidána nová kategorie protokolu „rpz-passthru“, která vám umožňuje samostatně protokolovat akce přeposílání RPZ (Response Policy Zones).
- V sekci response-policy byla přidána možnost „nsdname-wait-recurse“, při nastavení na „no“ se pravidla RPZ NSDNAME použijí pouze v případě, že jsou pro požadavek nalezeny autoritativní jmenné servery přítomné v mezipaměti, jinak Pravidlo RPZ NSDNAME je ignorováno, ale informace se získávají na pozadí a platí pro následné požadavky.
- Pro záznamy s typy HTTPS a SVCB je implementováno zpracování sekce „DALŠÍ“.
- Přidány vlastní typy pravidel pro aktualizaci – krb5-subdomain-self-rhs a ms-subdomain-self-rhs, které umožňují omezit aktualizaci záznamů SRV a PTR. Bloky aktualizace zásad také přidávají možnost nastavit limity počtu záznamů, individuální pro každý typ.
- Do výstupu obslužného programu dig byly přidány informace o transportním protokolu (UDP, TCP, TLS, HTTPS) a prefixech DNS64. Pro účely ladění dig přidal možnost zadat konkrétní identifikátor požadavku (dig +qid= ).
- Přidána podpora knihovny OpenSSL 3.0.
- Aby se vyřešily problémy s fragmentací IP při zpracování velkých zpráv DNS identifikovaných dnem příznaků DNS 2020, byl z překladače odstraněn kód, který upravuje velikost vyrovnávací paměti EDNS, když na požadavek není žádná odpověď. Velikost vyrovnávací paměti EDNS je nyní nastavena na konstantní (edns-udp-size) pro všechny odchozí požadavky.
- Systém sestavení byl přepnut na kombinaci autoconf, automake a libtool.
- Podpora pro soubory zóny ve formátu „map“ (mapa ve formátu masterfile) byla ukončena. Uživatelům tohoto formátu se doporučuje převést zóny do formátu raw pomocí nástroje named-compilezone.
- Podpora starších ovladačů DLZ (Dynamically Loadable Zones) byla ukončena a nahrazena moduly DLZ.
- Podpora sestavení a spouštění pro platformu Windows byla ukončena. Poslední větev, kterou lze nainstalovat na Windows, je BIND 9.16.
Zdroj: opennet.ru