DNS-over-HTTPS (DoH)

Google Public DNS предоставляет два разных API DoH на этих конечных точках:

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

На странице «Обзор безопасного транспорта» приведены примеры командной строки curl для использования обоих API, а также подробные сведения о TLS и других функциях, общих как для DNS через TLS (DoT), так и для DoH.

DoH также поддерживается для службы Google Public DNS64, поддерживающей только IPv6.

Google Public DNS не поддерживает небезопасные URL-адреса http: для вызовов API.

HTTP-методы

ПОЛУЧАТЬ
Использование метода GET может уменьшить задержку, поскольку он кэшируется более эффективно. Запросы GET RFC 8484 должны иметь параметр запроса ?dns= с DNS-сообщением в кодировке Base64Url. Метод GET — единственный метод, поддерживаемый API JSON.
ПОЧТА
Метод POST поддерживается только для API RFC 8484 и использует двоичное сообщение DNS с приложением Content-Type/dns-сообщением в теле запроса и в HTTP-ответе DoH.
ГОЛОВА
HEAD в настоящее время не поддерживается и возвращает ошибку 400 Bad Request .

Другие методы возвращают ошибку 501 Not Implemented.

Коды состояния HTTP

Google Public DNS DoH возвращает следующие коды состояния HTTP:

Успех

200 ОК
Анализ HTTP и связь с преобразователем DNS прошли успешно, а содержимое тела ответа представляет собой ответ DNS в двоичной кодировке или кодировке JSON, в зависимости от конечной точки запроса, заголовка Accept и параметров GET.

Перенаправления

301 Переехал навсегда
Клиентам следует повторить попытку по URL-адресу, указанному в заголовке Location: Если исходный запрос был запросом POST, клиенты должны повторять попытку с помощью GET только в том случае, если новый URL-адрес указывает аргумент параметра dns GET; в противном случае клиентам следует повторить попытку с помощью POST.

Другие коды, такие как 302 Found, 307 Temporary Redirect или 308 Permanent Redirect, могут использоваться в будущем, и клиенты DoH должны обрабатывать все четыре кода.

Ответы с постоянными кодами 301 и 308 должны кэшироваться на неопределенный срок, и, если это возможно, пользователям может быть предложено обновить исходную конфигурацию, используя новый URL-адрес.

Запросы POST, которые получают ответы 307 или 308, всегда следует повторять с помощью POST.

Ошибки

Ответы об ошибках будут содержать объяснение статуса HTTP в тексте с использованием HTML или обычного текста.

ошибка 400, неверный запрос
Проблемы с анализом параметров GET или неверное сообщение запроса DNS. Для неправильных параметров GET тело HTTP должно объяснить ошибку. Большинство недействительных DNS-сообщений получают 200 ОК с FORMERR; ошибка HTTP возвращается для искаженных сообщений без раздела вопросов, флажка QR, обозначающего ответ, или других бессмысленных комбинаций флагов с ошибками двоичного анализа DNS.
413 Полезная нагрузка слишком велика
Тело запроса POST RFC 8484 превысило максимальный размер сообщения в 512 байт.
414 URI слишком длинный
Заголовок запроса GET был слишком большим, или параметр dns содержал DNS-сообщение в кодировке Base64Url, превышающее максимальный размер сообщения в 512 байт.
415 Неподдерживаемый тип носителя
В теле POST не было заголовка Content-Type application/dns-message .
429 Слишком много запросов
Клиент отправил слишком много запросов за определенный промежуток времени. Клиенты должны прекратить отправку запросов до времени, указанного в заголовке Retry-After (относительное время в секундах).
500 - внутренняя ошибка сервера
Внутренние ошибки DoH Google Public DNS.
501 Не реализовано
Реализованы только методы GET и POST, другие методы вызывают эту ошибку.
502 Неверный шлюз
Службе DoH не удалось связаться с преобразователями общедоступных DNS Google.

В случае ответа 502, хотя повторная попытка использования альтернативного общедоступного DNS-адреса Google может помочь, более эффективным резервным ответом будет попробовать другую службу DoH или переключиться на традиционный UDP или TCP DNS по адресу 8.8.8.8.

Преимущества DoH

Использование HTTPS, а не только шифрования TLS, имеет некоторые практические преимущества:

  • Широко доступные и хорошо поддерживаемые API-интерфейсы HTTPS упрощают внедрение как для самого Google Public DNS, так и для потенциальных клиентов.
  • Служба HTTPS предоставляет веб-приложениям доступ ко всем типам записей DNS, избегая ограничений существующих API-интерфейсов DNS браузера и ОС, которые обычно поддерживают только поиск между хостом и адресом.
  • Клиенты, реализующие поддержку HTTPS на основе QUIC UDP, могут избежать таких проблем, как блокировка начала строки, которые могут возникнуть при использовании транспорта TCP.

Рекомендации по обеспечению конфиденциальности для Министерства здравоохранения

Разработчикам приложений DoH следует учитывать передовые методы обеспечения конфиденциальности, изложенные в RFC 8484 и подробно описанные ниже:

  • Ограничьте использование HTTP-заголовков

    Заголовки HTTP раскрывают информацию о реализации DoH клиента и могут использоваться для деанонимизации клиентов. Такие заголовки, как Cookie, User-Agent и Accept-Language, являются худшими нарушителями, но даже набор отправленных заголовков может быть показательным. Чтобы свести к минимуму этот риск, отправляйте только HTTP-заголовки, необходимые для DoH: Host, Content-Type (для POST) и, если необходимо, Accept. User-Agent должен быть включен во все разрабатываемые или тестируемые версии.

  • Использовать параметры заполнения EDNS

    Следуйте инструкциям в RFC 8467 по использованию параметров заполнения EDNS для дополнения запросов DoH до нескольких распространенных длин для защиты от анализа трафика. Использование заполнения HTTP/2 также возможно, но, в отличие от заполнения EDNS, оно не будет вызывать заполнение ответов от серверов DoH.

  • Используйте RFC 8484 POST только для приложений, чувствительных к конфиденциальности, или режимов браузера.

    Использование POST для запросов DoH снижает кэшируемость ответов и может увеличить задержку DNS, поэтому обычно не рекомендуется. Однако сокращение кэширования, вероятно, желательно для приложений, чувствительных к конфиденциальности, и может защитить от атак по времени со стороны веб-приложений, пытающихся определить, какие домены пользователь посещал в последнее время.

Проблемы

Чтобы сообщить об ошибке или запросить новую функцию, откройте проблему в DoH .