Twórcy serwera DNS BIND ogłosili dodanie obsługi serwerów dla technologii DNS over HTTPS (DoH, DNS over HTTPS) i DNS over TLS (DoT, DNS over TLS), a także mechanizmu XFR-over-TLS zapewniającego bezpieczne przesyłanie zawartości stref DNS pomiędzy serwerami. DoH jest dostępny do testowania w wersji 9.17, a obsługa DoT jest dostępna od wersji 9.17.10. Po ustabilizowaniu obsługa DoT i DoH zostanie przeniesiona do stabilnej gałęzi 9.17.7.
Implementacja protokołu HTTP/2 stosowanego w DoH opiera się na wykorzystaniu biblioteki nghttp2, która wchodzi w skład zależności assemblera (w przyszłości planowane jest przeniesienie biblioteki na szereg opcjonalnych zależności). Obsługiwane są zarówno szyfrowane (TLS), jak i nieszyfrowane połączenia HTTP/2. Przy odpowiednich ustawieniach pojedynczy nazwany proces może teraz obsługiwać nie tylko tradycyjne zapytania DNS, ale także zapytania wysyłane za pomocą DoH (DNS-over-HTTPS) i DoT (DNS-over-TLS). Obsługa protokołu HTTPS po stronie klienta (dig) nie została jeszcze zaimplementowana. Obsługa XFR-over-TLS jest dostępna zarówno dla żądań przychodzących, jak i wychodzących.
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;}; }
Wśród cech implementacji DoH w BIND integracja jest postrzegana jako ogólny transport, który może być używany nie tylko do przetwarzania żądań klientów do modułu rozpoznawania nazw, ale także podczas wymiany danych między serwerami, podczas przesyłania stref przez autorytatywny serwer DNS oraz podczas przetwarzania jakichkolwiek żądań obsługiwanych przez inne transporty DNS.
Kolejną funkcją jest możliwość przeniesienia operacji szyfrowania TLS na inny serwer, co może być konieczne w sytuacji, gdy certyfikaty TLS są przechowywane w innym systemie (na przykład w infrastrukturze z serwerami WWW) i obsługiwane przez inny personel. Obsługa niezaszyfrowanego DNS-over-HTTP została zaimplementowana w celu uproszczenia debugowania i jako warstwa do przesyłania dalej w sieci wewnętrznej, na podstawie której można zorganizować szyfrowanie na innym serwerze. Na zdalnym serwerze nginx może służyć do generowania ruchu TLS, podobnie jak w przypadku witryn internetowych zorganizowane jest powiązanie HTTPS.
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ń.
Źródło: opennet.ru