Migracja do Anycast i RFC 8484 DoH

W związku z wprowadzeniem w domenie dns.google znanej funkcji DoH (beta) w domenie dns.google.com używająca innych adresów IP usługa DoH używająca innych adresów IP została wycofana i zostanie wyłączona.

Eksperymentalna wersja interfejsu API RFC 8484 również została wycofana. Strona dns.google/experimental nie jest obsługiwana, a strona dns.google/experimental zostanie przeniesiona na stronę dns.google/dns-query.

Oś czasu

Data Etap wyłączania
2019-07-23 2019-08-01 dns.google.com/experimental przekierowuje do dns.google/dns-queryDONE
2019-08-05 2019-08-21 dns.google.com kieruje na publiczne adresy IP anycast GoogleDONE
2019-09-24 Stare adresy IP domeny dns.google.com przekierowują do dns.googleDONE
2020-06-23 Adres dns.google.com przekierowuje do dns.google wszędzie

Zmiany w tej harmonogramie są aktualizowane tutaj i publikowane w witrynie public-dns-announce. Aby otrzymywać najnowsze informacje, zasubskrybuj tę listę adresową.

Czwartek, 1 sierpnia 2019 r.

Żądania do https://dns.google.com/experimental otrzymują przekierowania HTTP 301 do https://dns.google/dns-query.

Nie ma to wpływu na aplikacje DoH korzystające z interfejsu JSON API w /resolve.

Środa, 21 sierpnia 2019 r.

dns.google.com przyjmuje adresy IP dowolnego publicznego serwera DNS Google.

Ta funkcja jest jasna w przypadku większości aplikacji DoH i nie wymaga wprowadzania zmian.

Wtorek, 24 września 2019 r.

Zapytania DoH wysyłane do byłych adresów IP dns.google.com otrzymują przekierowania HTTP 301 pod adres https://dns.google/.

Może to mieć wpływ na aplikacje DoH korzystające z interfejsu RFC 8484 lub interfejsu JSON API.

Aplikacje, które wysyłają żądania DoH na adresy IP zakodowane na stałe, konfigurowalne lub przechowywane w pamięci podręcznej na stałe, muszą obsługiwać co najmniej jeden z tych elementów:

Wtorek, 23 czerwca 2020 r.

Zapytania DoH wysyłane do dns.google.com pod adresami IP Anycast otrzymują przekierowania HTTP 301 do dns.google.

Może to mieć wpływ na aplikacje DoH korzystające z interfejsu RFC 8484 lub interfejsu JSON API.

Aby współpracować z Google DoH, aplikacje muszą obsługiwać co najmniej jeden z tych elementów:

Zmiany dotyczące klientów DoH

Śledzenie przekierowań HTTP

Serwery DoH to po prostu serwery HTTP obsługujące zapytania DNS. Dlatego mogą zwracać przekierowania HTTP (kody 301, 302, 307 lub 308), a klienty DoH powinny je stosować tak samo jak każdy inny klient HTTP.

Deweloperzy mogą sprawdzić obsługę przekierowań HTTP, używając https://8.8.8.8/experimental lub https://8.8.8.8/resolve jako podstawy adresów URL DoH. Zwracają one przekierowania HTTP 301 do https://dns.google/dns-query i https://dns.google/resolve (z zachowaniem wszystkich parametrów GET).

Używanie domeny dns.google na potrzeby usług DoH Google

Aplikacje DoH powinny używać dns.google zamiast dns.google.com. Niezależnie od tego, czy używasz interfejsu RFC 8484 czy JSON API, wszystkie aplikacje DoH z zakodowanymi na stałe lub skonfigurowaną listą resolverów DoH muszą zastąpić adres dns.google.com nazwą dns.google w adresach URL lub szablonach URI.

Użyj adresów IP Anycast publicznego serwera DNS Google

Aplikacje DoH, które wysyłają żądania DoH na zakodowaną na stałe lub skonfigurowaną listę adresów IP (nawet tylko na potrzeby wczytywania), muszą zastąpić poprzednie adresy dns.google.com adresami IP dowolnego publicznego DNS Google.

Szablony URI do konfiguracji

Aplikacje DoH powinny umożliwiać konfigurowanie punktów końcowych. Preferowanym i standardowym sposobem jest to przy użyciu szablonów identyfikatora URI. Deweloperzy aplikacji DoH z możliwością pełnej konfiguracji powinni powiadamiać użytkowników o nowym adresie URL (szablon URI: https://dns.google/dns-query{?dns}).

Użyj pola https://dns.google/dns-query dla RFC 8484 DoH

Aplikacje DoH z zakodowaną na stałe lub skonfigurowaną listą resolverów DoH muszą zastąpić adres URL https://dns.google.com/experimental interfejsu internetowego interfejsu API DoH w wersji roboczej https://dns.google/dns-query i potwierdzić pełną zgodność ze standardem RFC 8484.

Interfejs API /experimental (dostępny tylko na stronie dns.google.com) zaakceptował zapytania korzystające z niebezpiecznego kodowania Base64 i typu treści application/dns-udpwireformat, które są odrzucane przez interfejs /dns-query API (dostępne tylko na dns.google). Różnice te opisujemy w 2 kolejnych sekcjach.

Użyj kodowania Base64Url dla parametru GET dns

Użyj bezpiecznego kodowania Base64Url dla parametru dns w żądaniach GET, zastępując nim Base64 (+ /) (- _) i usuwając dopełnienie (=).

Zaakceptuj i wyślij: application/dns-message

Użyj kodu application/dns-message w nagłówku Accept (i w przypadku żądania POST zgodnego ze standardem RFC 8484 w nagłówku Content-Type) i zaakceptuj go jako typ treści odpowiedzi.

Użycie starego typu treści dla metody POST zakończy się niepowodzeniem w przypadku błędu 415 (Nieobsługiwany typ nośnika).

Aplikacje używające starego typu treści w nagłówku Accept będą otrzymywać odpowiedzi z użyciem atrybutu Content-Type application/dns-message. Aplikacje DoH, które je akceptują i nie ignorują z powodu nieoczekiwanego typu treści, będą nadal działać.