Deweloperzy serwera DNS BIND ogłosili o dodaniu do eksperymentalnej gałęzi 9.17 wsparcia serwera dla technologii 'DNS przez HTTPS' (DoH, DNS over HTTPS) oraz DNS przez TLS (DoT, DNS over TLS), a także mechanizmu XFR-over-TLS do bezpiecznego przesyłania zawartości stref DNS między serwerami. DoH jest dostępny do testowania w wydaniu 9.17.10, a wsparcie DoT jest dostępne od wersji 9.17.7. Po stabilizacji, wsparcie DoT i DoH zostanie przeniesione do stabilnej gałęzi 9.16.
Implementacja protokołu HTTP/2, używanego w DoH, opiera się na bibliotece nghttp2, która jest wliczona w skład zależności budowy (w przyszłości planuje się przekształcenie tej biblioteki w zależność opcjonalną). Obsługiwane są zarówno szyfrowane (TLS), jak i nieszyfrowane połączenia przez HTTP/2. Przy odpowiednich ustawieniach, jeden proces named może teraz obsługiwać nie tylko tradycyjne zapytania DNS, ale także zapytania wysyłane z użyciem DoH (DNS-over-HTTPS) i DoT (DNS-over-TLS). Wsparcie HTTPS po stronie klienta (dig) wciąż nie zostało wdrożone. Obsługa XFR-over-TLS jest dostępna zarówno dla zapytań przychodzących, jak i wychodzących.
Obsługa zapytań z użyciem DoH i DoT jest włączana poprzez dodanie opcji http i tls w dyrektywie listen-on. Aby wspierać nieszyfrowany DNS-over-HTTP w ustawieniach należy określić 'tls none'. Klucze definiuje się w sekcji 'tls'. Standardowe porty sieciowe 853 dla DoT, 443 dla DoH i 80 dla DNS-over-HTTP można nadpisać poprzez 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 zaznacza się integracja jako wspólny transport, który może być używany nie tylko do obsługi zapytań klientów do resolvera, ale także przy wymianie danych między serwerami, podczas przesyłania stref przez autorytatywny serwer DNS oraz przy obsłudze wszelkich zapytań wspieranych przez inne transporty DNS.
Inną cechą jest możliwość przeniesienia operacji szyfrowania dla TLS na inny serwer, co może być konieczne w sytuacjach, gdy certyfikaty TLS są przechowywane na innej systemie (na przykład w infrastrukturze z serwerami webowymi) i są obsługiwane przez inny personel. Wsparcie dla nieszyfrowanego DNS-over-HTTP zostało wdrożone w celu uproszczenia debugowania i jako poziom do przechwytywania w sieci wewnętrznej, na podstawie którego na innym serwerze może być zorganizowane szyfrowanie. Na zdalnym serwerze do generowania ruchu TLS można używać nginx, podobnie jak w przypadku organizacji obudowy HTTPS dla stron.
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ń.
Źródło: opennet.ru
