BIND DNS ma teraz eksperymentalną obsługę DNS przez HTTPS

Przedstawiono twórców serwera DNS BIND kilka dni temu dołączenie do oddziału eksperymentalnego 9.17, implementacja wsparcie serwer technologii DNS przez HTTPS (DoH, DNS przez HTTPS) i DNS przez TLS (DoT, DNS over TLS), a także XFR.

Implementacja protokołu HTTP / 2 używanego w DoH opiera się na wykorzystaniu biblioteki nghttp2, który jest zawarty w zależnościach budowania (w przyszłości planowane jest przeniesienie biblioteki do opcjonalnych zależności).

Przy odpowiedniej konfiguracji pojedynczy nazwany proces może teraz obsługiwać nie tylko tradycyjne żądania DNS, ale także żądania wysyłane za pomocą DoH (DNS przez HTTPS) i DoT (DNS przez TLS).

Obsługa HTTPS po stronie klienta (dig) nie została jeszcze zaimplementowana, podczas gdy obsługa XFR-over-TLS jest dostępna dla żądań przychodzących i wychodzących.

Przetwarzanie żądań za pomocą DoH i DoT jest włączana przez dodanie opcji http i tls do dyrektywy nasłuchiwania. Aby obsługiwać niezaszyfrowany DNS przez HTTP, musisz określić w konfiguracji opcję „tls none”. Klucze są zdefiniowane w sekcji „tls”. Standardowe porty sieciowe 853 dla DoT, 443 dla DoH i 80 dla DNS przez HTTP można zastąpić za pomocą parametrów tls-port, https-port i http-port.

Wśród funkcji implementacji DoH w BIND, należy zauważyć, że istnieje możliwość przeniesienia operacji szyfrowania dla TLS na inny serwer, Może to być konieczne w warunkach, gdy przechowywanie certyfikatów TLS odbywa się w innym systemie (na przykład w infrastrukturze z serwerami WWW) i jest nadzorowane przez inny personel.

Wsparcie dla Niezaszyfrowany DNS przez HTTP został zaimplementowany w celu uproszczenia debugowania oraz jako warstwa do przekazywania 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, analogicznie do sposobu, w jaki organizowane jest powiązanie HTTPS dla witryn.

Kolejną cechą jest integracja DoH jako transportu ogólnego, który może być używany nie tylko do przetwarzania żądań klientów do resolwera, ale także podczas wymiany danych między serwerami, podczas przesyłania stref za pomocą autorytatywnego serwera DNS oraz podczas przetwarzania wszelkich żądań obsługiwanych przez inne transporty DNS.

Wśród niedociągnięć, które można nadrobić wyłączając kompilację z DoH / DoT lub przenosząc szyfrowanie na inny serwer, Podkreślono ogólne komplikacje związane z bazą kodu- Do kompozycji dodawany jest wbudowany serwer HTTP i biblioteka TLS, które mogą potencjalnie zawierać luki i działać jako dodatkowe wektory ataku. Ponadto, gdy używane jest DoH, zwiększa się ruch.

Musimy to pamiętać DNS-over-HTTPS może być przydatny, aby uniknąć wycieków informacjipracować na żądanych nazwach hostów za pośrednictwem serwerów DNS dostawców, zwalczać ataki MITM i fałszywy ruch DNS, przeciwdziałać blokowaniu na poziomie DNS lub organizować pracę w przypadku braku możliwości bezpośredniego dostępu do serwerów DNS.

Jeśli w normalnej sytuacji żądania DNS są wysyłane bezpośrednio do serwerów DNS zdefiniowanych w konfiguracji systemu, to w przypadku DNS przez HTTPS, żądanie określenia adresu IP hosta jest hermetyzowany w ruchu HTTPS i przesyłany do serwera HTTP, w którym program do rozpoznawania nazw przetwarza żądania za pośrednictwem internetowego interfejsu API.

„DNS przez TLS” różni się od „DNS przez HTTPS” tym, że używa standardowego protokołu DNS (zwykle używany jest port sieciowy 853) zawiniętego w zaszyfrowany kanał komunikacyjny zorganizowany przy użyciu protokołu TLS z walidacją hosta za pomocą certyfikatów TLS / SSL poświadczonych certyfikatem. autorytet. 

Wreszcie jest o tym mowa DoH jest dostępne do testowania w wersji 9.17.10 i wsparcie DoT istnieje od 9.17.7, a po ustabilizowaniu wsparcie dla DoT i DoH zostanie przeniesione do stabilnej gałęzi 9.16.


Treść artykułu jest zgodna z naszymi zasadami etyka redakcyjna. Aby zgłosić błąd, kliknij tutaj.

Bądź pierwszym który skomentuje

Zostaw swój komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

*

*

  1. Odpowiedzialny za dane: Miguel Ángel Gatón
  2. Cel danych: kontrola spamu, zarządzanie komentarzami.
  3. Legitymacja: Twoja zgoda
  4. Przekazywanie danych: Dane nie będą przekazywane stronom trzecim, z wyjątkiem obowiązku prawnego.
  5. Przechowywanie danych: baza danych hostowana przez Occentus Networks (UE)
  6. Prawa: w dowolnym momencie możesz ograniczyć, odzyskać i usunąć swoje dane.