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/solutions? – JSON API (GET)

Na stronie Omówienie transportu publicznego znajdziesz curl wierszy poleceń z informacjami o korzystaniu z interfejsów API oraz o funkcjach TLS i innych funkcjach typowych dla serwerów DNS przez TLS (DoT) i DoH.

DoH jest również obsługiwane tylko w przypadku publicznej usługi DNS66 Google przeznaczonej wyłącznie dla protokołu IPv6.

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

Metody HTTP

SPRAWDŹ
Użycie metody GET może zmniejszyć opóźnienie, ponieważ pamięć podręczna jest skuteczniejsza. Żądania GET RFC 8484 muszą zawierać parametr zapytania ?dns= z wiadomością DNS zakodowaną w Base64Url. Metoda GET to jedyna metoda obsługiwana w przypadku interfejsu JSON API.
POST
Metoda POST jest obsługiwana tylko w przypadku interfejsu RFC 8484 API i używa binarnej wiadomości DNS z aplikacją Content-Type/dns-message w treści żądania i w odpowiedzi HTTP DoH.
GŁÓWNA
HEAD nie jest obecnie obsługiwany i zwraca błąd 400 Bad Request.

Inne metody zwracają błędy 501 Niezaimplementowane.

Kody stanów HTTP

Google Public DNS DoH zwraca następujące kody stanu HTTP:

Sukces

200 OK
Analiza HTTP i komunikacja z resolverem 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, nagłówka Accept i GET.

Przekierowania

301 Przeniesiono na stałe
Klient powinien spróbować ponownie pod adresem URL podanym w nagłówku Location:. Jeśli pierwotne zapytanie było żądaniem POST, klient powinien ponowić próbę z użyciem GET tylko wtedy, gdy nowy URL określa argument parametru dns GET. W przeciwnym razie klient powinien spróbować ponownie za pomocą POST.

W przyszłości można używać innych kodów, takich jak 302 Found, 307 Redirect Redirect lub 308 trwałe przekierowanie. Klienty DoH powinny obsługiwać wszystkie 4 kody.

Odpowiedzi ze stałymi kodami 301 i 308 powinny być przechowywane w pamięci podręcznej na stałe. Jeśli jest to praktyczne, użytkownicy mogą zostać poproszeni o zaktualizowanie pierwotnej konfiguracji za pomocą nowego adresu URL.

Żądania POST, które otrzymują odpowiedzi 307 lub 308, powinny być zawsze ponawiane za pomocą metody POST.

Błędy

Odpowiedzi na pytania o błędy zawierają wyjaśnienie stanu HTTP w treści w postaci kodu HTML lub zwykłego tekstu.

400 Nieprawidłowe żądanie
Problemy z analizą parametrów GET lub nieprawidłową wiadomością żądania DNS. W przypadku nieprawidłowych parametrów GET treść HTTP powinna wyjaśniać błąd. Większość nieprawidłowych wiadomości DNS otrzymuje OK 200 z formularzem FORMERR. Błąd HTTP zwraca się w przypadku nieczytelnych wiadomości bez sekcji Question, flagi QR wskazującej odpowiedź lub innych bezsensownych kombinacji flag z binarnymi analizami DNS.
413 Ładunek jest za duży
Treść żądania POST w standardzie RFC 8484 przekracza maksymalny rozmiar 512 bajtów wiadomości.
Identyfikator URI 414 jest za długi
Nagłówek zapytania GET był za duży lub parametr dns zawierał zakodowany w formacie Base64Url komunikat o rozmiarze przekraczającym maksymalny rozmiar wiadomości 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 określonym czasie. Klienty powinny blokować wysyłanie żądań do czasu określonego w nagłówku Ponów próbę po czasie (czas względny w sekundach).
500 – wewnętrzny błąd serwera
Błędy wewnętrzne wewnętrznego systemu DNS Google.
501 Nie wdrożono
Tylko metody GET i POST są wdrażane. Inne metody zgłaszają ten błąd.
502 niewłaściwa brama
Usługa DoH nie może skontaktować się z resolverami Google publicznego DNS.

W przypadku odpowiedzi 502 może pomóc ponowienie próby z alternatywnym adresem DNS Google, jednak lepszym sposobem jest zastąpienie innej usługi DoH albo przełączenie się na tradycyjną sieć UDP lub TCP w wersji 8.8.8.8.

Zalety Departamentu Zdrowia

Stosowanie protokołu HTTPS, a nie tylko szyfrowania TLS, ma kilka praktycznych korzyści:

  • Szeroko dostępne i obsługiwane interfejsy API protokołu HTTPS upraszczają implementację zarówno samego publicznego 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 przeglądarki i systemu operacyjnego DNS, które zwykle obsługują tylko wyszukiwanie z użyciem hosta w adresie.
  • Klienty stosujące obsługę protokołu HTTPS na podstawie protokołu QUIC mogą uniknąć problemów, takich jak blokowanie wiersza poleceń, które mogą wystąpić podczas korzystania z transportu TCP.

Sprawdzone metody ochrony prywatności dla DoH

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

  • Ogranicz używanie nagłówków HTTP

    Nagłówki HTTP ujawniają informacje o implementacji DoH klienta. Można ich używać do anonimizacji klientów. Nagłówki, takie jak Cookie, User-Agent i Accept-Language, są najgorszymi sprawcami, ale ujawnią się nawet wysłane nagłówki. Aby zminimalizować to ryzyko, wysyłaj tylko nagłówki HTTP wymagane przez DoH: Host, Content-Type (POST) i w razie potrzeby Akceptuj. W wersjach programistycznych i testowych należy uwzględnić klienta użytkownika.

  • Użyj opcji dopełniania EDNS

    Postępuj zgodnie ze wskazówkami w specyfikacji RFC 8467, aby wykorzystać opcje dopełniania EDNS do wstawienia zapytań DoH na kilka typowych długości w celu ochrony przed analizą ruchu. Możesz też użyć dopełnienia HTTP/2, ale w przeciwieństwie do dopełnienia EDNS dopełnienie z serwerów DoH nie spowoduje wywołania dopełnienia.

  • RFC 8484 POST używaj tylko aplikacji lub trybów przeglądarki poufnych

    Korzystanie z metody POST w przypadku zapytań DoH zmniejsza pamięć podręczną odpowiedzi i może zwiększyć opóźnienie DNS, więc nie jest to zwykle zalecane. Ograniczenie zapisywania w pamięci podręcznej jest często zalecane w przypadku aplikacji, które wymagają ochrony prywatności, i może uchronić się przed atakami mającymi na celu wykrycie domen, które użytkownik ostatnio odwiedzał.

Problemy

Aby zgłosić błąd lub poprosić o dodanie nowej funkcji, otwórz problem dla DoH.