DNS-over-HTTPS (DoH)

Publiczny serwer DNS Google udostępnia 2 różne interfejsy API DoH w tych punktach końcowych:

  • https://dns.google/dns-query – RFC 8484 (GET i POST)
  • https://dns.google/resolve? – JSON API (GET).

Strona Omówienie protokołu TLS zawiera przykłady korzystania z wiersza poleceń curl do używania zarówno interfejsów API, jak i szczegóły dotyczące TLS oraz innych funkcji wspólnych dla połączeń DNS przez TLS (DoT) i DoH.

DoH jest też obsługiwany w przypadku publicznej usługi DNS Google64 obejmującej tylko protokół IPv6.

Publiczny serwer DNS Google nie obsługuje niezabezpieczonych adresów URL http: w przypadku wywołań interfejsu API.

Metody HTTP

GET
Metoda GET może skrócić czas oczekiwania, ponieważ jest lepiej przechowywana w pamięci podręcznej. Żądania GET RFC 8484 muszą mieć parametr zapytania ?dns= z wiadomością DNS zakodowaną w standardzie Base64Url. Metoda GET to jedyna metoda obsługiwana w interfejsie JSON API.
POST
Metoda POST jest obsługiwana tylko przez interfejs RFC 8484 API i używa binarnego komunikatu DNS z aplikacją Content-Type/wiadomością dns w treści żądania i w odpowiedzi HTTP DoH.
HEAD
Element HEAD nie jest obecnie obsługiwany i zwraca błąd 400 „Nieprawidłowe żądanie”.

Inne metody zwracają błędy 501 „Nie zaimplementowano”.

Kody stanów HTTP

Google Public DNS DoH zwraca te kody stanu HTTP:

Gotowe

200 OK
Analiza składni HTTP i komunikacja z mechanizmem rozpoznawania nazw DNS zakończyła się powodzeniem, a treść odpowiedzi to odpowiedź DNS w kodowaniu binarnym lub JSON (w zależności od punktu końcowego zapytania, parametrów Accept nagłówka i parametrów GET).

Przekierowania

301 Przeniesiono na stałe
Klienci powinni spróbować ponownie, korzystając z adresu URL podanego w nagłówku Location:. Jeśli pierwotne zapytanie było żądaniem POST, klienci powinni ponawiać próbę użycia metody GET tylko wtedy, gdy nowy adres URL zawiera argument parametru GET dns. W przeciwnym razie klient powinien ponowić próbę użycia metody POST.

W przyszłości możesz używać innych kodów, takich jak 302 Found, 307 Temporary Redirect lub 308 Permanent Redirect, a klienty DoH powinny obsługiwać wszystkie 4 kody.

Odpowiedzi ze stałymi kodami 301 i 308 należy przechowywać w pamięci podręcznej w nieskończoność. W razie potrzeby użytkownicy mogą zostać poproszeni o zaktualizowanie pierwotnej konfiguracji przy użyciu nowego adresu URL.

Żądania POST, które otrzymują odpowiedzi 307 lub 308, należy zawsze ponowić z użyciem metody POST.

Błędy

Odpowiedzi związane z błędami będą zawierać wyjaśnienie stanu HTTP w treści HTML lub zwykłego tekstu.

400 Nieprawidłowe żądanie
Problemy z analizą parametrów GET lub komunikatem nieprawidłowego żądania DNS. W przypadku nieprawidłowych parametrów GET treść HTTP powinna zawierać wyjaśnienie błędu. W przypadku większości nieprawidłowych wiadomości DNS zwracany jest błąd 200 OK z użyciem FORMERR. Błąd HTTP jest zwracany w przypadku nieczytelnych wiadomości bez sekcji Question, flagi QR wskazującej odpowiedź lub innych bezsensownych kombinacji flag z binarnymi błędami analizy DNS.
413 Za dużo ładunku
Treść żądania POST w standardzie RFC 8484 przekracza maksymalny rozmiar wiadomości wynoszący 512 bajtów.
414 Identyfikator URI jest za długi
Nagłówek zapytania GET był za duży lub parametr dns zawierał wiadomość DNS zakodowaną w standardzie Base64Url, która przekraczała maksymalny rozmiar 512 bajtów.
415 Nieobsługiwany typ multimediów
Treść POST nie miała nagłówka Content-Type application/dns-message.
429 Zbyt wiele żądań
Klient wysłał zbyt wiele żądań w danym okresie. Klienci powinni przestać wysyłać żądania do czasu określonego w nagłówku Retry-After (względnego czasu w sekundach).
500 Wewnętrzny błąd serwera
Błędy wewnętrznego DoH w publicznym DNS Google.
501 Nie zaimplementowano
Wdrożone są tylko metody GET i POST; w przypadku innych metod występuje ten błąd.
502 Nieprawidłowa brama
Usługa DoH nie mogła skontaktować się z publicznymi resolverami DNS Google.

W przypadku odpowiedzi 502 chociaż ponowienie próby na alternatywnym publicznym adresie DNS Google może pomóc, skuteczniejszą odpowiedzią jest skorzystanie z innej usługi DoH albo przejście na tradycyjny protokół UDP lub TCP DNS pod adresem 8.8.8.8.

Zalety DoH

Używanie protokołu HTTPS, nie tylko szyfrowania TLS, niesie ze sobą kilka praktycznych korzyści:

  • Powszechnie dostępne i dobrze obsługiwane interfejsy API HTTPS upraszczają wdrażanie zarówno na potrzeby publicznego serwera DNS Google, jak i potencjalnych klientów.
  • Usługa HTTPS zapewnia aplikacjom internetowym dostęp do wszystkich typów rekordów DNS, co pozwala uniknąć ograniczeń istniejących interfejsów API DNS w przeglądarce i systemie operacyjnym, które zwykle obsługują tylko wyszukiwanie informacji między hostami.
  • Klienty, które implementują obsługę protokołu HTTPS opartego na protokole QUIC UDP, mogą uniknąć problemów, takich jak blokowanie na początku wiersza, które mogą wystąpić podczas korzystania z transportu TCP.

Sprawdzone metody ochrony prywatności dotyczące organizacji DoH

Deweloperzy aplikacji DoH powinni wziąć pod uwagę sprawdzone metody ochrony prywatności opisane w RFC 8484 oraz poniżej:

  • Ograniczenie używania nagłówków HTTP

    Nagłówki HTTP ujawniają informacje o implementacji DoH klienta i mogą służyć do anonimizacji klientów. Nagłówki takie jak Cookie, User-Agent i Accept-Language powodują najwięcej błędów, ale nawet zestaw wysyłanych nagłówków może być ujawniany. Aby zminimalizować to ryzyko, wysyłaj tylko nagłówki HTTP wymagane przez DoH: Host, Content-Type (POST) i w razie potrzeby – Accept. We wszystkich wersjach programistycznych lub testowych należy uwzględnić klienta użytkownika.

  • Użyj opcji dopełnienia EDNS

    Postępuj zgodnie ze wskazówkami zawartymi w RFC 8467, aby użyć opcji dopełnienia EDNS w celu wypełnienia zapytań DoH do kilku typowych długości, co zapewnia ochronę przed analizą ruchu. Użycie dopełnienia HTTP/2 jest również możliwe, ale w przeciwieństwie do dopełnienia EDNS nie wywołuje dopełnienia w odpowiedziach z serwerów DoH.

  • Używaj metody POST RFC 8484 tylko w przypadku trybów przeglądarki i aplikacji wymagających ochrony prywatności

    Używanie metody POST w przypadku zapytań DoH zmniejsza możliwość buforowania odpowiedzi i może zwiększyć opóźnienie DNS, więc ogólnie nie jest zalecane. Jednak zmniejszenie ilości pamięci podręcznej jest prawdopodobnie korzystne w przypadku aplikacji wrażliwych na ochronę prywatności i może uchronić przed atakami polegającymi na synchronizacji z aplikacjami internetowymi, które próbują ustalić, jakie domeny ostatnio odwiedzał użytkownik.

Problemy

Aby zgłosić błąd lub poprosić o nową funkcję, otwórz problem dotyczący DoH.