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