Publiczny serwer DNS Google udostępnia 2 różne interfejsy API DoH w tych punktach końcowych:
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 GETdns. 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
dnszawierał 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.