Po dwóch i pół roku prac konsorcjum ISC przedstawiło pierwszą stabilną wersję nowej, znaczącej gałęzi serwera DNS BIND 9.20, która zawiera zmiany rozwijane w eksperymentalnej gałęzi BIND 9.19. Wsparcie dla gałęzi 9.20 będzie realizowane w ramach wydłużonego cyklu wsparcia do pierwszego kwartału 2028 roku. Wsparcie dla gałęzi 9.18 zakończy się w drugim kwartale 2025 roku. W celu rozwinięcia funkcjonalności następnej stabilnej wersji BIND zostanie utworzona eksperymentalna gałąź BIND 9.21.0. Kod projektu napisany jest w języku C i jest rozpowszechniany na zasadach licencji MPL 2.0.
Główne zmiany:
- Rdzeń aplikacji, łączący wszystkie komponenty, został przeniesiony do wykorzystania cyklu przetwarzania zdarzeń w trybie nieblokującym, zrealizowanego na podstawie biblioteki libuv, stosowanej w takich projektach jak Node.js, Knot DNS, H2O, Luvit i MoarVM. W gałęzi 9.16 menedżer połączeń sieciowych w BIND został przetworzony na libuv, a teraz także części wykorzystywane do interakcji wewnętrznych komponentów infrastruktury oraz długoterminowo wykonywane w odrębnych wątkach pomocnicze procesory (threadpool), używane do weryfikacji DNSSEC, transferu stref, utrzymywania katalogu stref i obsługi RPZ (Response Policy Zone). Aby zbudować BIND, teraz wymagana jest co najmniej wersja libuv 1.34.0.
- Zaproponowano nowy backend do pracy z bazą danych — „QP trie”, który zastępuje RBTDB (Red-Black Tree Database) i jest domyślnie używany do przechowywania pamięci podręcznej i bazy stref DNS. W przypadku pracy wielowątkowej w QP trie wykorzystano bibliotekę liburcu z implementacją w przestrzeni użytkownika struktur, które nie używają blokad, dzięki zastosowaniu mechanizmu synchronizacji RCU (read-copy-update) oraz metody bezpiecznego zwalniania pamięci QSBR (Quiescent-State-Based Reclamation).
- Zastosowano zaktualizowany mechanizm kompresji nazw domen, wykorzystujący bardziej kompaktową metodę kodowania nazw z większą liczbą etykiet.
- Rozszerzone możliwości DNSSEC: „dnssec-policy” można stosować do zarządzania podpisanymi strefami (opcja auto-dnssec została usunięta); przy użyciu „inline-signing” dodano wsparcie dla RFC 8901 (model wielo-podpisujący DNSSEC 2); wznowiono wsparcie dla PKCS#11 opartego na OpenSSL 3.0.0 Engine API; w „dnssec-policy” dodano wsparcie HSM (Hardware Security Module).
- Dodano wsparcie dla drugiej wersji katalogu stref (Catalog Zone, RFC 9432), co upraszcza zarządzanie wtórnymi serwerami DNS, ponieważ zamiast definiowania oddzielnych rekordów dla każdej wtórnej strefy na serwerze wtórnym, między serwerem pierwotnym a wtórnym odbywa się transfer katalogu wtórnych stref. Po skonfigurowaniu transferu katalogu w analogiczny sposób jak transfer oddzielnych stref, strefy dodawane na serwerze pierwotnym, oznaczone jako należące do katalogu, są automatycznie tworzone na serwerze wtórnym bez potrzeby edytowania plików konfiguracyjnych.
- Dodano wsparcie dla mechanizmu rozszerzonych błędów (Extended DNS Errors, RFC 8914), który umożliwia zwracanie dodatkowych informacji o przyczynie błędu, który wystąpił podczas wykonywania zapytania DNS.
- Realizacja technologii «DNS over HTTPS» (DoH, DNS over HTTPS) oraz DNS over TLS (DoT, DNS over TLS) zastosowywanych do szyfrowania zapytań klientów do resolvera oraz szyfrowanej wymiany danych między serwerami została przekształcona na wykorzystanie zjednoczonego transportu.
- Dodano możliwość użycia protokołu PROXYv2 ze wszystkimi transportami obsługiwanymi w BIND. Protokół PROXY umożliwia przekazywanie informacji o połączeniu w celu zachowania danych o pierwotnym adresie IP oraz numerze portu podczas przesyłania zapytań DNS przez inne zaplecza, load balancery i proxy.serwery.
- Dodano wsparcie dla trybu USDT (User Statically Defined Tracing), który umożliwia śledzenie aplikacji za pomocą polecenia perf bez wprowadzania dodatkowych obciążeń, gdy śledzenie jest wyłączone.
- W zbieranej statystyce wdrożono odzwierciedlenie informacji o niedokończonych przychodzących operacjach przesyłania stref.
- Podjęto działania mające na celu skrócenie opóźnień, zmniejszenie zużycia pamięci i obciążenia CPU podczas rozwiązywania nazw, działania DNS-over-TLS i formowania odpowiedzi poprzez UDP i TCP.
Źródło: opennet.ru
