Po dwóch latach prac konsorcjum ISC wydało pierwszą stabilną wersję nowej, dużej gałęzi serwera DNS BIND 9.18. Wsparcie dla gałęzi 9.18 będzie świadczone przez trzy lata do II kwartału 2 roku w ramach rozszerzonego cyklu wsparcia. Wsparcie dla gałęzi 2025 zakończy się w marcu, a wsparcie dla gałęzi 9.11 w połowie 9.16 roku. Aby rozwinąć funkcjonalność kolejnej stabilnej wersji BIND-a, utworzono eksperymentalną gałąź BIND 2023.
Wydanie BIND 9.18.0 wyróżnia się implementacją obsługi DNS przez HTTPS (DoH, DNS przez HTTPS) i DNS przez TLS (DoT, DNS przez TLS), a także mechanizmu XoT (XFR-over-TLS) do bezpiecznego transferu treści DNS pomiędzy serwerami (obsługiwane są zarówno strefy wysyłające, jak i odbierające poprzez XoT). Przy odpowiednich ustawieniach pojedynczy nazwany proces może teraz obsługiwać nie tylko tradycyjne zapytania DNS, ale także zapytania wysyłane za pomocą DNS-over-HTTPS i DNS-over-TLS. Obsługa klienta dla DNS-over-TLS jest wbudowana w narzędzie dig, którego można używać do wysyłania żądań przez TLS, jeśli określona jest flaga „+tls”.
Implementacja protokołu HTTP/2 stosowanego w DoH opiera się na wykorzystaniu biblioteki nghttp2, która jest dołączona jako opcjonalna zależność zestawu. Certyfikaty DoH i DoT mogą być dostarczone przez użytkownika lub wygenerowane automatycznie podczas uruchamiania.
Przetwarzanie żądań przy użyciu DoH i DoT jest włączane poprzez dodanie opcji „http” i „tls” do dyrektywy nasłuchiwania. Aby obsługiwać niezaszyfrowany DNS-over-HTTP, należy określić w ustawieniach opcję „tls none”. Klucze są zdefiniowane w sekcji „tls”. Domyślne porty sieciowe 853 dla DoT, 443 dla DoH i 80 dla DNS-over-HTTP można zastąpić za pomocą parametrów tls-port, https-port i http-port. Na przykład:
tls local-tls { plik-klucza "/ścieżka/do/klucz_prywatny.pem"; plik-certyfikatu "/ścieżka/do/cert_chain.pem"; }; http lokalny serwer http { punkty końcowe { "/dns-query"; }; }; opcje {port https 443; port nasłuchiwania 443 tls local-tls http mójserwer {any;}; }
Jedną z cech implementacji DoH w BIND jest możliwość przeniesienia operacji szyfrowania dla TLS na inny serwer, co może być konieczne w warunkach, gdy certyfikaty TLS są przechowywane w innym systemie (np. w infrastrukturze z serwerami WWW) i utrzymywane przez inny personel. Obsługa niezaszyfrowanego DNS-over-HTTP została zaimplementowana w celu uproszczenia debugowania i jako warstwa do przekazywania do innego serwera w sieci wewnętrznej (w celu przeniesienia szyfrowania na oddzielny serwer). Na zdalnym serwerze nginx może służyć do generowania ruchu TLS, podobnie jak w przypadku witryn internetowych zorganizowane jest powiązanie HTTPS.
Inną funkcją jest integracja DoH jako ogólnego transportu, którego można używać nie tylko do obsługi żądań klientów kierowanych do mechanizmu rozpoznawania nazw, ale także do komunikacji między serwerami, przesyłania stref przez autorytatywny serwer DNS i przetwarzania wszelkich zapytań obsługiwanych przez inne systemy DNS transporty.
Wśród niedociągnięć, które można zrekompensować poprzez wyłączenie kompilacji z DoH/DoT lub przeniesienie szyfrowania na inny serwer, wyróżnia się ogólna komplikacja bazy kodu - dodano wbudowany serwer HTTP i bibliotekę TLS, która potencjalnie może zawierać luki i działają jako dodatkowe wektory ataku. Ponadto podczas korzystania z DoH zwiększa się ruch.
Przypomnijmy, że DNS-over-HTTPS może być przydatny w zapobieganiu wyciekom informacji o żądanych nazwach hostów przez serwery DNS dostawców, zwalczaniu ataków MITM i fałszowaniu ruchu DNS (na przykład podczas łączenia się z publicznym Wi-Fi), przeciwdziałaniu blokowanie na poziomie DNS (DNS-over-HTTPS nie może zastąpić VPN w omijaniu blokowania realizowanego na poziomie DPI) lub do organizowania pracy, gdy nie ma możliwości bezpośredniego dostępu do serwerów DNS (np. podczas pracy przez proxy). Jeżeli w normalnej sytuacji żądania DNS kierowane są bezpośrednio do serwerów DNS zdefiniowanych w konfiguracji systemu, to w przypadku DNS-over-HTTPS żądanie ustalenia adresu IP hosta jest hermetyzowane w ruchu HTTPS i wysyłane do serwera HTTP, gdzie moduł rozpoznawania nazw przetwarza żądania za pośrednictwem interfejsu API sieci Web.
„DNS over TLS” różni się od „DNS over HTTPS” zastosowaniem standardowego protokołu DNS (zwykle używany jest port sieciowy 853), opakowanego w szyfrowany kanał komunikacyjny zorganizowany przy użyciu protokołu TLS ze sprawdzaniem ważności hosta za pomocą certyfikowanych certyfikatów TLS/SSL przez urząd certyfikujący. Istniejący standard DNSSEC wykorzystuje szyfrowanie jedynie do uwierzytelnienia klienta i serwera, ale nie chroni ruchu przed przechwyceniem i nie gwarantuje poufności żądań.
Kilka innych innowacji:
- Dodano ustawienia tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer i udp-send-buffer, aby ustawić rozmiary buforów używanych podczas wysyłania i odbierania żądań przez TCP i UDP. Na obciążonych serwerach zwiększenie buforów przychodzących pomoże uniknąć upuszczania pakietów podczas szczytów ruchu, a zmniejszenie ich pomoże pozbyć się zatykania pamięci przez stare żądania.
- Dodano nową kategorię dziennika „rpz-passthru”, która umożliwia osobne rejestrowanie działań związanych z przekazywaniem RPZ (Response Policy Zones).
- W sekcji polityki odpowiedzi dodano opcję „nsdname-wait-recurse”, gdy jest ustawiona na „nie”, reguły RPZ NSDNAME są stosowane tylko wtedy, gdy dla żądania zostaną znalezione autorytatywne serwery nazw obecne w pamięci podręcznej, w przeciwnym razie Reguła RPZ NSDNAME jest ignorowana, ale informacje są pobierane w tle i dotyczą kolejnych żądań.
- Dla rekordów typu HTTPS i SVCB wprowadzono przetwarzanie sekcji „DODATKOWE”.
- Dodano niestandardowe typy reguł aktualizacji - krb5-subdomain-self-rhs i ms-subdomain-self-rhs, które pozwalają ograniczyć aktualizację rekordów SRV i PTR. Bloki update-policy dodają także możliwość ustawienia limitów liczby rekordów, indywidualnych dla każdego typu.
- Dodano informacje o protokole transportowym (UDP, TCP, TLS, HTTPS) i prefiksach DNS64 do danych wyjściowych narzędzia dig. Na potrzeby debugowania dig dodał możliwość określenia konkretnego identyfikatora żądania (dig +qid= ).
- Dodano obsługę biblioteki OpenSSL 3.0.
- Aby rozwiązać problemy z fragmentacją IP podczas przetwarzania dużych wiadomości DNS zidentyfikowanych podczas Dnia Flagi DNS 2020, z mechanizmu rozpoznawania nazw usunięto kod regulujący rozmiar bufora EDNS w przypadku braku odpowiedzi na żądanie. Rozmiar bufora EDNS jest teraz ustawiony na stały (edns-udp-size) dla wszystkich żądań wychodzących.
- System kompilacji został przełączony na kombinację autoconf, automake i libtool.
- Zakończono obsługę plików stref w formacie „mapy” (mapa w formacie masterfile). Użytkownikom tego formatu zaleca się konwersję stref do formatu surowego przy użyciu narzędzia o nazwie-compilezone.
- Zaprzestano obsługi starszych sterowników DLZ (dynamicznie ładowanych stref) i zastąpiono je modułami DLZ.
- Zakończono obsługę kompilacji i uruchamiania platformy Windows. Ostatnią gałęzią, którą można zainstalować w systemie Windows, jest BIND 9.16.
Źródło: opennet.ru