DNS через HTTPS (DoH)

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

  • https://dns.google/dns-query — RFC 8484 (GET и POST)
  • https://dns.google/разрешить? – JSON API (ПОЛУЧИТЬ)

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

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

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

HTTP-методы

ПОЛУЧИТЬ
Использование метода GET может уменьшить задержку, поскольку он кэшируется более эффективно. Запросы RFC 8484 GET должны иметь параметр запроса ?dns= с DNS-сообщением в кодировке Base64Url. Метод GET — единственный метод, поддерживаемый JSON API.
ПОЧТА
Метод 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 OK с FORMERR; ошибка HTTP возвращается для искаженных сообщений без раздела «Вопрос», флага QR, указывающего на ответ, или других бессмысленных комбинаций флагов с двоичными ошибками синтаксического анализа DNS.
413 Слишком большая полезная нагрузка
Тело запроса POST RFC 8484 превысило максимальный размер сообщения в 512 байт.
414 URI слишком длинный
Заголовок запроса GET был слишком большим, или параметр dns содержал DNS-сообщение в кодировке Base64Url, превышающее максимальный размер сообщения в 512 байт.
415 Неподдерживаемый тип носителя
В теле POST не было заголовка application/dns-message Content-Type.
429 Слишком много запросов
Клиент отправил слишком много запросов за заданный промежуток времени. Клиенты должны прекратить отправку запросов до времени, указанного в заголовке Retry-After (относительное время в секундах).
внутренняя ошибка сервера 500
Внутренние ошибки DoH Google Public DNS.
501 Не реализовано
Реализованы только методы GET и POST, другие методы получают эту ошибку.
502 Неверный шлюз
Службе DoH не удалось связаться с преобразователями Google Public DNS.

В случае ответа 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

Разработчики приложений 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 .