Két év fejlesztés után az ISC konzorcium kiadta a BIND 9.18 DNS-kiszolgáló egy jelentős új ágának első stabil kiadását. A 9.18 ág támogatása három évig, 2 második negyedévéig, meghosszabbított támogatási ciklus keretében történik. A 2025-es fiók támogatása márciusban, a 9.11-os ág támogatása 9.16 közepén szűnik meg. A BIND következő stabil verziójának funkcionalitásának fejlesztésére a BIND 2023 kísérleti ágat alakították ki.
A BIND 9.18.0 megjelenése figyelemre méltó a HTTPS-n keresztüli DNS (DoH, DNS over HTTPS) és a DNS over TLS (DoT, DNS over TLS), valamint az XoT (XFR-over-TLS) mechanizmus támogatása. a DNS-tartalom biztonságos átviteléhez.zónák a szerverek között (az XoT-n keresztüli küldő és fogadó zónák egyaránt támogatottak). A megfelelő beállításokkal egyetlen elnevezett folyamat már nem csak a hagyományos DNS-lekérdezéseket tudja kiszolgálni, hanem a DNS-over-HTTPS és DNS-over-TLS használatával küldött lekérdezéseket is. A DNS-over-TLS ügyféltámogatása be van építve a dig segédprogramba, amely használható kérések küldésére TLS-en keresztül, ha a „+tls” jelző meg van adva.
A DoH-ban használt HTTP/2 protokoll megvalósítása az nghttp2 könyvtár használatán alapul, amely opcionális összeállítás-függőségként szerepel. A DoH és DoT tanúsítványait a felhasználó biztosíthatja, vagy automatikusan generálhatja az indításkor.
A DoH és DoT használatával történő kérésfeldolgozás engedélyezhető a „http” és „tls” opciók hozzáadásával a figyelési direktívához. A titkosítatlan DNS-over-HTTP támogatásához adja meg a „tls none” értéket a beállításokban. A kulcsok a „tls” részben vannak meghatározva. Az alapértelmezett 853-as hálózati portok DoT-hez, 443-as DoH-hoz és 80-as DNS-over-HTTP-hez a tls-port, https-port és http-port paraméterekkel felülírhatók. Például:
tls local-tls { kulcsfájl "/elérési_útja/priv_key.pem"; cert-file "/path/to/cert_chain.pem"; }; http local-http-szerver { végpontok { "/dns-lekérdezés"; }; }; options { https-port 443; figyelési port 443 tls local-tls http myserver {bármilyen;}; }
A DoH megvalósításának egyik jellemzője a BIND-ban, hogy a TLS titkosítási műveleteit át lehet helyezni egy másik szerverre, ami szükséges lehet olyan körülmények között, amikor a TLS-tanúsítványokat egy másik rendszeren tárolják (például egy webszerverekkel rendelkező infrastruktúrában) és karbantartják. más személyzet által. A titkosítatlan DNS-over-HTTP támogatása a hibakeresés egyszerűsítése és a belső hálózat egy másik szerverére történő továbbítás rétegeként valósul meg (a titkosítás külön kiszolgálóra való áthelyezéséhez). Egy távoli szerveren az nginx használható TLS-forgalom generálására, hasonlóan ahhoz, ahogyan a HTTPS-kötés meg van szervezve a webhelyeken.
Egy másik funkció a DoH integrálása általános átviteli eszközként, amely nemcsak a kliens kérések kezelésére használható a feloldóhoz, hanem a szerverek közötti kommunikációhoz, a mérvadó DNS-kiszolgáló zónáinak átviteléhez, valamint bármely más DNS által támogatott lekérdezés feldolgozásához is. szállít.
A DoH/DoT-el történő build letiltásával vagy a titkosítás másik szerverre költöztetésével kompenzálható hiányosságok közül kiemelkedik a kódbázis általános bonyodalma – egy beépített HTTP szerver és TLS könyvtár került hozzáadásra, amely potenciálisan tartalmazhat a sebezhetőségeket, és további támadási vektorokként működnek. Emellett a DoH használatakor megnő a forgalom.
Emlékezzünk vissza, hogy a DNS-over-HTTPS hasznos lehet a kért gazdagépnevekkel kapcsolatos információk kiszivárgásának megakadályozására a szolgáltatók DNS-kiszolgálóin keresztül, a MITM-támadások és a DNS-forgalom meghamisítása elleni küzdelemben (például nyilvános Wi-Fi-hez való csatlakozáskor), DNS-szintű blokkolás (DNS-over-HTTPS nem helyettesítheti a VPN-t a DPI-szinten megvalósított blokkolás megkerülésével), vagy olyan munkaszervezéshez, amikor lehetetlen közvetlenül elérni a DNS-kiszolgálókat (például proxy-n keresztül végzett munka esetén). Ha normál helyzetben a DNS kérések közvetlenül a rendszerkonfigurációban meghatározott DNS szerverekhez kerülnek, akkor DNS-over-HTTPS esetén a gazdagép IP-címének meghatározására irányuló kérés HTTPS forgalomba kerül, és elküldésre kerül a HTTP szervernek, ahol a feloldó a webes API-n keresztül dolgozza fel a kéréseket.
A „DNS over TLS” eltér a „DNS over HTTPS”-től a szabványos DNS-protokoll használatában (általában a 853-as hálózati portot használják), amely egy TLS-protokoll használatával szervezett titkosított kommunikációs csatornába van csomagolva, a gazdagép érvényességének ellenőrzése TLS/SSL-tanúsítványokon keresztül. tanúsító hatóság által. A meglévő DNSSEC szabvány csak a kliens és a szerver hitelesítésére használ titkosítást, de nem védi a forgalmat az elfogástól, és nem garantálja a kérések titkosságát.
Néhány további újítás:
- Hozzáadva a tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer és udp-send-buffer beállításokat a TCP-n és UDP-n keresztüli kérések küldésekor és fogadásakor használt pufferek méretének beállításához. A forgalmas szervereken a bejövő pufferek növelése segít elkerülni a csomagok kiesését a forgalmi csúcsok idején, csökkentése pedig segít megszabadulni a régi kérések miatti memóriaeltömődéstől.
- Egy új „rpz-passthru” naplókategória került hozzáadásra, amely lehetővé teszi az RPZ (Response Policy Zones) továbbítási műveletek külön naplózását.
- A válasz-házirend részhez hozzáadtuk az „nsdname-wait-recurse” opciót, ha „no”-ra állítjuk, az RPZ NSDNAME szabályok csak akkor érvényesek, ha a gyorsítótárban található hiteles névszerverek találhatók a kéréshez, ellenkező esetben a A rendszer figyelmen kívül hagyja az RPZ NSDNAME szabályt, de az információkat a háttérben kéri le, és a későbbi kérésekre is vonatkozik.
- A HTTPS és SVCB típusú rekordok esetében a „KIEGÉSZÍTŐ” szakasz feldolgozása megtörtént.
- Egyéni frissítési házirend-szabálytípusok hozzáadva - krb5-subdomain-self-rhs és ms-subdomain-self-rhs, amelyek lehetővé teszik az SRV- és PTR-rekordok frissítésének korlátozását. A frissítési házirend blokkok lehetővé teszik a rekordok számának korlátozását is, minden típushoz egyedileg.
- Információk hozzáadva a szállítási protokollról (UDP, TCP, TLS, HTTPS) és a DNS64 előtagokról a dig segédprogram kimenetéhez. Hibakeresési célból a dig hozzáadta egy adott kérésazonosító megadásának lehetőségét (dig +qid= ).
- Hozzáadott támogatás az OpenSSL 3.0 könyvtárhoz.
- A DNS Flag Day 2020 által azonosított nagy DNS-üzenetek feldolgozásakor felmerülő problémák megoldása érdekében az EDNS-puffer méretét módosító kódot eltávolítottuk a feloldóból, ha nem érkezik válasz a kérésre. Az EDNS-puffer mérete most állandóra (edns-udp-size) van állítva minden kimenő kérésnél.
- A build rendszert az autoconf, automake és libtool kombinációjára váltották.
- A „térkép” formátumú (masterfile-formátumú térkép) zónafájlok támogatása megszűnt. Ennek a formátumnak a felhasználóinak ajánlott a zónákat nyers formátumba konvertálni a named-compilezone segédprogrammal.
- A régebbi DLZ (dinamikusan betölthető zónák) illesztőprogramok támogatása megszűnt, helyüket DLZ modulok váltották fel.
- A Windows platform építési és futtatási támogatása megszűnt. Az utolsó Windows rendszerre telepíthető ág a BIND 9.16.
Forrás: opennet.ru