Po dwóch latach prac konsorcjum ISC zaprezentowało pierwszą stabilną wersję nowej, ważnej gałęzi serwera DNS BIND 9.18. Wsparcie dla gałęzi 9.18 będzie prowadzone przez trzy lata, do drugiego kwartału 2025 roku, w ramach rozszerzonego cyklu wsparcia. Wsparcie dla gałęzi 9.11 zakończy się w marcu, a dla gałęzi 9.16 w połowie 2023 roku. W celu rozwoju funkcjonalności następnej stabilnej wersji BIND utworzono eksperymentalną gałąź BIND 9.19.0.
Wydanie BIND 9.18.0 wyróżnia się wdrożeniem wsparcia dla technologii „DNS przez HTTPS” (DoH, DNS over HTTPS) oraz DNS przez TLS (DoT, DNS over TLS), a także mechanizmu XoT (XFR-over-TLS) dla bezpiecznego przesyłania zawartości stref DNS między serwerami (wsparcie zarówno dla wysyłania, jak i odbierania stref przez XoT). Przy odpowiednich ustawieniach jeden proces named może teraz obsługiwać nie tylko tradycyjne żądania DNS, ale również żądania wysyłane za pomocą DNS-over-HTTPS i DNS-over-TLS. Obsługa klienta DNS-over-TLS jest wbudowana w narzędzie dig, które można używać do wysyłania żądań przez TLS, wskazując flagę „+tls”.
Wdrożenie protokołu HTTP/2, używanego w DoH, opiera się na wykorzystaniu biblioteki nghttp2, która jest jednym z optionalnych zależności kompilacyjnych. Certyfikaty dla DoH i DoT mogą być dostarczane przez użytkownika lub generowane automatycznie podczas uruchamiania.
Przetwarzanie żądań z wykorzystaniem DoH i DoT włącza się poprzez dodanie opcji „http” i „tls” w dyrektywie listen-on. Aby wspierać niezaszyfrowany DNS przez HTTP, w ustawieniach należy wskazać „tls none”. Klucze określa się w sekcji „tls”. Standardowe porty sieciowe 853 dla DoT, 443 dla DoH oraz 80 dla DNS przez HTTP mogą być nadpisane przez parametry tls-port, https-port i http-port. Na przykład:
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;}; }
Wśród cech implementacji DoH w BIND wyróżnia się możliwość przeniesienia operacji szyfrowania TLS na inny serwer, co może być potrzebne w warunkach, gdy certyfikaty TLS są przechowywane w innym systemie (na przykład w infrastrukturze z serwerami webowymi) i obsługiwane przez inny personel. Wsparcie dla nieszyfrowanego DNS-over-HTTP zostało wprowadzone w celu uproszczenia debugowania i jako poziom do przekierowania na inny serwer w sieci wewnętrznej (w celu przeniesienia szyfrowania na osobny serwer). Na serwerze zdalnym do generowania ruchu TLS można wykorzystać nginx, podobnie jak w przypadku organizacji otoczki HTTPS dla stron internetowych.
Inną cechą jest integracja DoH jako ogólnego transportu, który może być stosowany nie tylko do przetwarzania zapytań klientów do resolvera, ale również podczas wymiany danych między serwerami, przy przekazywaniu stref przez autorytatywne serwery DNS oraz przy przetwarzaniu wszelkich zapytań obsługiwanych przez inne transporty DNS.
Do wad, które można zrekompensować wyłączeniem budowy z DoH/DoT lub przeniesieniem szyfrowania na inny serwer, należy ogólne skomplikowanie bazy kodu — do składu dodawany jest wbudowany serwer HTTP oraz biblioteka TLS, które potencjalnie mogą zawierać luki i stanowić dodatkowe wektory ataków. Ponadto, przy użyciu DoH zwiększa się ruch sieciowy.
Przypomnijmy, że DNS-over-HTTPS może okazać się pomocne w eliminowaniu wycieków informacji o żądanych nazwach hostów przez serwery DNS dostawców, w walce z atakami MITM oraz podmianą ruchu DNS (na przykład podczas podłączania się do publicznych Wi-Fi), w przeciwdziałaniu blokadom na poziomie DNS (DNS-over-HTTPS nie może zastąpić VPN w zakresie omijania blokad, zrealizowanych na poziomie DPI) lub dla organizacji pracy w przypadku braku możliwości bezpośredniego kontaktu z serwerami DNS (na przykład podczas pracy przez proxy). Jeśli w normalnej sytuacji zapytania DNS są bezpośrednio wysyłane do określonych w konfiguracji systemu serwerów DNS, to w przypadku DNS-over-HTTPS zapytanie dotyczące adresy IP hosta jest inkapsulowane w ruchu HTTPS i wysyłane na serwer HTTP, na którym resolver przetwarza zapytania przez Web API.
„DNS over TLS” różni się od „DNS over HTTPS” stosowaniem standardowego protokołu DNS (zazwyczaj używa portu sieciowego 853), owiniętego w zaszyfrowany kanał komunikacyjny utworzony za pomocą protokołu TLS z weryfikacją hosta przez certyfikaty TLS/SSL, które są zatwierdzone przez centrum certyfikacji. Istniejący standard DNSSEC używa szyfrowania tylko do uwierzytelnienia klienta i serwera, ale nie chroni ruchu przed przechwyceniem ani nie gwarantuje poufności zapytań.
Kilka innych nowości:
- Dodano ustawienia tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer i udp-send-buffer do określania rozmiarów buforów używanych podczas wysyłania i odbierania zapytań przez TCP i UDP. Na obciążonych serwerach zwiększenie buforów przychodzących pozwoli uniknąć odrzucania pakietów w momentach szczytowego ruchu, a zmniejszenie pomoże pozbyć się zatorów w pamięci spowodowanych starymi zapytaniami.
- Dodana została nowa kategoria logów „rpz-passthru”, umożliwiająca osobne rejestrowanie działań związanych z przekazaniem RPZ (Response Policy Zones).
- W sekcji response-policy dodano opcję „nsdname-wait-recurse”, przy ustawieniu której na wartość „no” reguły RPZ NSDNAME są stosowane tylko wtedy, gdy dla zapytania znaleziono autorytatywne serwery nazw, które są obecne w pamięci podręcznej; w przeciwnym razie reguła RPZ NSDNAME jest ignorowana, ale informacje są pobierane w tle i stosowane do kolejnych zapytań.
- Dla rekordów z typami HTTPS i SVCB wdrożono przetwarzanie sekcji „ADDITIONAL”.
- Dodano konfigurowalne typy zasad update-policy — krb5-subdomain-self-rhs i ms-subdomain-self-rhs, które umożliwiają ograniczenie aktualizacji rekordów SRV i PTR. W blokach update-policy dodano również możliwość ustanowienia ograniczeń liczby rekordów, osobno dla każdego typu.
- W wyniku narzędzia dig dodano informacje o protokole transportowym (UDP, TCP, TLS, HTTPS) oraz prefiksach DNS64. W celu debugowania w dig dodano możliwość wskazania konkretnego identyfikatora zapytania (dig +qid=).
- Dodano wsparcie dla biblioteki OpenSSL 3.0.
- Aby rozwiązać problemy z fragmentacją IP przy przetwarzaniu dużych wiadomości DNS, oznaczonych przez inicjatywę DNS Flag Day 2020, z resolvera usunięto kod, który dostosowywał rozmiar bufora EDNS w przypadku braku odpowiedzi na zapytanie. Rozmiar bufora EDNS jest teraz ustawiany jako stały (edns-udp-size) dla wszystkich wychodzących zapytań.
- System budowy został przeniesiony na użycie zestawu autoconf, automake i libtool.
- Zaprzestano wsparcia dla plików stref w formacie „map” (masterfile-format map). Użytkownikom tego formatu zaleca się przekształcenie stref w format raw za pomocą narzędzia named-compilezone.
- Zaprzestano wsparcia dla starych sterowników DLZ (Dynamically Loadable Zones), które zostały zastąpione modułami DLZ.
- Zaprzestano wsparcia dla kompilacji i uruchamiania na platformie Windows. Ostatnią wersją, którą można zainstalować na Windows, pozostaje BIND 9.16.
Źródło: opennet.ru
