Четвёртый этап тестирования DNS-over-HTTPS в Firefox
Разработчики Mozilla сообщили о проведении четвёртого этапа тестирования функции обращения к DNS поверх HTTPS (DoH, DNS over HTTPS), который будет сосредоточен на оценке изменения производительности при применении DNS-over-HTTPS в условиях работы через сети доставки контента. На этой неделе небольшой части пользователей релизов Firefox из США будет предложено активировать DoH (при нежелании пользователь сможет отказаться). Как и раньше в качестве основного будет использован DNS-сервер CloudFlare, но в будущем планируется расширить число участвующих в тесте DNS-провайдеров.
Необходимость дополнительного тестирования DNS-over-HTTPS при работе через сети доставки контента связана с тем, что DNS-сервер CDN-сети формирует ответ, учитывая адрес резолвера и выдаёт ближайший хост для получения контента. Таким образом, отправка DNS-запроса c ближайшего к пользователю резолвера приведёт к тому, что CDN вернёт адрес ближайшего хоста, но при отправке DNS-запроса с централизованного резолвера DNS-over-HTTPS ближайший к пользователю хост определить не получится и будет выдан адрес хоста, ближайший к серверу DNS-over-HTTPS.
Указанная особенность сводит на нет средства оптимизации трафика в CDN, поэтому в процессе принятия решения о внедрении DNS-over-HTTPS необходимо учитывать не только производительность операций с DNS, но и дополнительные задержки, которые могут возникнуть из-за снижения эффективности загрузки контента через CDN. В прошлом году были проведены первые тесты для комплексной оценке задержек при использовании CDN, которые показали минимальное влияние применения DNS-over-HTTPS на задержки перед началом передачи контента (для быстрых соединений задержки не превышали 10 миллисекунд, а для медленных каналах связи наблюдалось даже ускорение работы).
При этом также были замечены подозрительные особенности, требующие дополнительного тестирования. Например, в прошлом тесте работы через CDN выявлено увеличение интенсивности появления ошибок при отправке DNS-запросов, независимо от использования DNS-over-HTTPS. В новом тесте планируется собрать более детальные данные об возникающих ошибках. Также планируется протестировать расширение EDNS Client Subnet, позволяющее передать резолверу CDN более дательные сведения о местоположении клиента для выбора ближайшей к нему точки отдачи трафика.
Так как обращение к финальному резолверу производится без шифрования и может привести к утечке сведений третьим лицам, решено ограничить применение EDNS Client Subnet только обращениями к Facebook через Cloudflare по совместной договорённости этих компаний и с применением шифрования DNS-трафика между ними (будет применяться DNS-over-TLS и прямое обращение к резолверу Facebook, что исключит из цепочки третьих лиц). При наличии в браузере Cookie от Facebook и при согласии пользователя на участие в эксперименте, браузер будет раз в день отправлять тестовые запросы к Facebooк (без передачи cookie) и измерять время отклика.
Для включения DoH на системах не приглашённых для участия в тестировании, достаточно в about: config изменить значение переменной network.trr.mode, которая поддерживается начиная с Firefox 60. Значение 0 полностью отключает DoH; 1 — используется DNS или DoH, в зависимости от того, что быстрее; 2 — используется DoH по умолчанию, а DNS как запасной вариант; 3 — используется только DoH; 4 — режим зеркалирования при котором DoH и DNS задействованы параллельно. По умолчанию используется DNS-сервер CloudFlare, но его можно изменить через параметр network.trr.uri, например, можно установить «https://dns.google.com/experimental» или «https://9.9.9.9/dns-query».
Напомним, что DoH может оказаться полезным для исключения утечек сведений о запрашиваемых именах хостов через DNS-серверы провайдеров, борьбы с MITM-атаками и подменой DNS-трафика, противостояния блокировкам на уровне DNS или для организации работы в случае невозможности прямого обращения к DNS-серверам (например, при работе через прокси). Если в обычной ситуации DNS-запросы напрямую отправляются на определённые в конфигурации системы DNS-серверы, то в случае DoH запрос на определение IP-адреса хоста инкапсулируется в трафик HTTPS и отправляется на HTTP-сервер, на котором резолвер обрабатывает запросы через Web API. Существующий стандарт DNSSEC использует шифрование лишь для аутентификации клиента и сервера, но не защищает трафик от перехвата и не гарантирует конфиденциальность запросов.
Необходимость дополнительного тестирования DNS-over-HTTPS при работе через сети доставки контента связана с тем, что DNS-сервер CDN-сети формирует ответ, учитывая адрес резолвера и выдаёт ближайший хост для получения контента. Таким образом, отправка DNS-запроса c ближайшего к пользователю резолвера приведёт к тому, что CDN вернёт адрес ближайшего хоста, но при отправке DNS-запроса с централизованного резолвера DNS-over-HTTPS ближайший к пользователю хост определить не получится и будет выдан адрес хоста, ближайший к серверу DNS-over-HTTPS.
Указанная особенность сводит на нет средства оптимизации трафика в CDN, поэтому в процессе принятия решения о внедрении DNS-over-HTTPS необходимо учитывать не только производительность операций с DNS, но и дополнительные задержки, которые могут возникнуть из-за снижения эффективности загрузки контента через CDN. В прошлом году были проведены первые тесты для комплексной оценке задержек при использовании CDN, которые показали минимальное влияние применения DNS-over-HTTPS на задержки перед началом передачи контента (для быстрых соединений задержки не превышали 10 миллисекунд, а для медленных каналах связи наблюдалось даже ускорение работы).
При этом также были замечены подозрительные особенности, требующие дополнительного тестирования. Например, в прошлом тесте работы через CDN выявлено увеличение интенсивности появления ошибок при отправке DNS-запросов, независимо от использования DNS-over-HTTPS. В новом тесте планируется собрать более детальные данные об возникающих ошибках. Также планируется протестировать расширение EDNS Client Subnet, позволяющее передать резолверу CDN более дательные сведения о местоположении клиента для выбора ближайшей к нему точки отдачи трафика.
Так как обращение к финальному резолверу производится без шифрования и может привести к утечке сведений третьим лицам, решено ограничить применение EDNS Client Subnet только обращениями к Facebook через Cloudflare по совместной договорённости этих компаний и с применением шифрования DNS-трафика между ними (будет применяться DNS-over-TLS и прямое обращение к резолверу Facebook, что исключит из цепочки третьих лиц). При наличии в браузере Cookie от Facebook и при согласии пользователя на участие в эксперименте, браузер будет раз в день отправлять тестовые запросы к Facebooк (без передачи cookie) и измерять время отклика.
Для включения DoH на системах не приглашённых для участия в тестировании, достаточно в about: config изменить значение переменной network.trr.mode, которая поддерживается начиная с Firefox 60. Значение 0 полностью отключает DoH; 1 — используется DNS или DoH, в зависимости от того, что быстрее; 2 — используется DoH по умолчанию, а DNS как запасной вариант; 3 — используется только DoH; 4 — режим зеркалирования при котором DoH и DNS задействованы параллельно. По умолчанию используется DNS-сервер CloudFlare, но его можно изменить через параметр network.trr.uri, например, можно установить «https://dns.google.com/experimental» или «https://9.9.9.9/dns-query».
Напомним, что DoH может оказаться полезным для исключения утечек сведений о запрашиваемых именах хостов через DNS-серверы провайдеров, борьбы с MITM-атаками и подменой DNS-трафика, противостояния блокировкам на уровне DNS или для организации работы в случае невозможности прямого обращения к DNS-серверам (например, при работе через прокси). Если в обычной ситуации DNS-запросы напрямую отправляются на определённые в конфигурации системы DNS-серверы, то в случае DoH запрос на определение IP-адреса хоста инкапсулируется в трафик HTTPS и отправляется на HTTP-сервер, на котором резолвер обрабатывает запросы через Web API. Существующий стандарт DNSSEC использует шифрование лишь для аутентификации клиента и сервера, но не защищает трафик от перехвата и не гарантирует конфиденциальность запросов.
Ещё новости по теме:
18:20