Két év fejlesztés után az ISC konzorcium bemutatta a BIND 9.18 új, jelentős ágának első stabil kiadását. A 9.18 ág támogatása három éven át, 2025 második negyedévéig fog zajlani a kibővített fenntartási ciklus keretében. A 9.11 ág támogatása márciusban, a 9.16 ág támogatása pedig 2023 közepén fog megszűnni. A következő stabil verzió funkcionalitásának fejlesztése érdekében létrejött a BIND 9.19.0 kísérleti ága.
A BIND 9.18.0 kiadását a 'DNS HTTPS-en keresztül' (DoH, DNS over HTTPS) és a DNS TLS-en keresztül (DoT, DNS over TLS) technológiák támogatásának megvalósítása, valamint az XoT (XFR-over-TLS) mechanizmus bevezetése jellemzi, amely lehetővé teszi a DNS zónák biztonságos átvitelét a szerverek között (támogatott mind a zónák küldése, mind fogadása XoT-n). A megfelelő beállítások mellett a named folyamat most már nemcsak a hagyományos DNS kéréseket, hanem a DNS-over-HTTPS és DNS-over-TLS használatával elküldött kéréseket is képes kiszolgálni. A DNS-over-TLS kliens támogatása beépítve van a dig segédprogramba, amely a ' +tls ' flag megadásával használható TLS-en keresztüli kérések küldésére.
A DoH-ban használt HTTP/2 protokoll megvalósítása az nghttp2 könyvtár alkalmazásán alapul, amely az opcionális build függőségek közé tartozik. A DoH és DoT számára a tanúsítványokat a felhasználó biztosíthatja, vagy automatikusan generálhatók az indítás során.
A DoH és DoT használatával történő kérések feldolgozása az 'http' és 'tls' opciók hozzáadásával történik a listen-on direktívához. Az nem titkosított DNS-over-HTTP támogatásához a beállításokban 'tls none' értéket kell megadni. A kulcsokat a tls szekcióban kell meghatározni. A szabványos hálózati portok, mint a 853 a DoT számára, 443 a DoH számára és 80 a DNS-over-HTTP számára, felülírhatók a tls-port, https-port és http-port paraméterekkel. Például:
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;}; }
A DoH megvalósításának jellemzője a TLS titkosítási műveletek egy másik szerverre való áthelyezése, ami akkor lehet szükséges, ha a TLS tanúsítványokat egy másik rendszeren tárolják (például webkiszolgálós infrastruktúrában), és más személyzet kezeli. A nem titkosított DNS-over-HTTP támogatása a hibakeresés megkönnyítése érdekében és mint szint a belső hálózaton való továbbításhoz (a titkosítás másik szerverre való áthelyezéséhez) valósult meg. A TLS forgalom létrehozásához a kivezetett szerveren nginx alkalmazható, hasonlóan ahhoz, ahogyan a HTTPS kötődés történik a webhelyek esetében.
Egy másik jellemző a DoH integrációja, mint egy általános szállítási módszer, amely nemcsak a kliens kérések feldolgozására szolgál a feloldóhoz, hanem a szerverek közötti adatcserében, az övezetek átadásán szintén az illetékes DNS-kiszolgáló által, és bármilyen, más DNS szállítások által támogatott kérések feldolgozása során is alkalmazható.
A hátrányok közül, amelyeket a DoH/DoT összeállításának letiltásával vagy a titkosítás másik szerverre való áthelyezésével lehet kompenzálni, kiemelhető a kódalap általános bonyolultsága — beépített HTTP-szerver és TLS könyvtár kerül a rendszerbe, amelyek potenciális sebezhetőségeket tartalmazhatnak, és további támadási vektorokat jelenthetnek. Továbbá, a DoH használata növeli a forgalmat.
Ne feledjük, hogy a DNS-over-HTTPS hasznos lehet a szolgáltatók DNS szerverei által történő hívott hostnevek adatainak kiszivárgásának megakadályozására, a MITM támadásokkal és a DNS forgalom hamisításával szembeni védekezésre (például nyilvános Wi-Fi használatakor), valamint a DNS szintű blokkolásokkal szembeni küzdelemre (a DNS-over-HTTPS nem helyettesíthető a blokkolások megkerülésében, amelyeket a DPI szintjén valósítanak meg) vagy a DNS szerverekhez való közvetlen csatlakozás hiányában való működés megszervezésére (például proxy-n keresztüli működés esetén). Ha a normál helyzetben a DNS lekérdezések közvetlenül a rendszer konfigurációjában megadott DNS szerverekre kerülnek, akkor DNS-over-HTTPS esetén a lekérdezés a VPN hostot a HTTPS forgalom keretein belül kapszulázva és egy HTTP szerverre küldve, amelyen a resolver a web API-n keresztül dolgozza fel a lekérdezéseket. IP address A „DNS over TLS” a „DNS over HTTPS”-től abban különbözik, hogy a szokásos DNS protokollt (amely általában a 853-as portot használja) titkosított kapcsolaton keresztül valósítja meg, amelyet a TLS protokoll segítségével alakítanak ki, a host érvényesítése TLS/SSL tanúsítványokkal, amelyeket egy hitelesítési központ igazolt. Az egy létező DNSSEC szabvány csak az ügyfél és a szerver hitelesítésének biztosítására használ titkosítást, de nem védi a forgalmat a lehallgatástól és nem garantálja a lekérdezések titkosságát.
A BIND DNS szerver fejlesztői bejelentették, hogy az 9.17-es kísérleti ágban megvalósították a "DNS over HTTPS" (DoH, DNS over HTTPS) és DNS over TLS (DoT, DNS over TLS) technológiák szerveroldali támogatását, valamint.
Néhány egyéb újdonság:
- A tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer és udp-send-buffer beállítások hozzáadásra kerültek a TCP és UDP kérések küldése és fogadása során használt pufferek méretének meghatározására. A terhelt szervereken a bejövő pufferek növelése megakadályozza a csomagok eldobását a forgalom csúcsidőszakában, míg a csökkentés segít eltávolítani a régi kérésekből eredő memória tömörödést.
- Új naplózási kategóriaként bevezetésre került az „rpz-passthru”, amely lehetővé teszi az RPZ (Response Policy Zones) átkonfigurálási műveletek külön naplózását.
- A response-policy szekcióban hozzáadva lett a „nsdname-wait-recurse” opció, amelynek beállítása esetén „no” értékre a RPZ NSDNAME szabályok csak akkor alkalmazhatók, ha a kéréshez kapcsolódóan a cache-ben megtalálhatóak a névkiszolgálók, ellenkező esetben a RPZ NSDNAME szabály figyelmen kívül marad, de az információ a háttérben kinyerésre kerül és a további kérésekre alkalmazásra kerül.
- Az HTTPS és SVCB típusú bejegyzésekhez az „ADDITIONAL” szekció feldolgozása valósult meg.
- Beállítható frissítési szabálytípusok — krb5-subdomain-self-rhs és ms-subdomain-self-rhs lettek hozzáadva, amelyek lehetővé teszik az SRV és PTR rekordok frissítésének korlátozását. Az update-policy blokkokban lehetőség nyílt a rekordok számának korlátozására, típusonként egyedileg.
- A dig eszköz kimenetéhez információk kerültek hozzáadásra a szállítási protokollról (UDP, TCP, TLS, HTTPS) és a DNS64 előtagokról. Hibakeresési célokra a dig rendszerbe került a lehetőség, hogy megadjuk a kérés azonosítóját (dig +qid=).
- Hozzáadtuk az OpenSSL 3.0 könyvtár támogatását.
- A DNS üzenetek nagy méretű feldolgozásával kapcsolatos IP-fragmentációs problémák megoldása érdekében, a DNS Flag Day 2020 kezdeményezés keretében, a resolverből eltávolítottuk a kódot, amely az EDNS puffer méretének módosítását végezte, ha nem érkezett válasz a kérésre. Az EDNS puffer mérete mostantól állandó (edns-udp-size) minden kimenő kérésnél.
- A build rendszer autoconf, automake és libtool csomagok használatára lett átállítva.
- A 'map' formátumú zónafájlok támogatása megszűnt (masterfile-format map). A formátumot használó felhasználóknak ajánlott a zónák átkonvertálása raw formátumra a named-compilezone eszközzel.
- A régi DLZ (Dynamically Loadable Zones) illesztőprogramok támogatása megszűnt, helyettük a DLZ modulok kerültek bevezetésre.
- A Windows platformra vonatkozó építési és futtatási támogatás megszűnt. Az utolsó verzió, amely telepíthető Windows-ra, a BIND 9.16 maradt.
Forrás: opennet.ru
