फ़ायरफ़ॉक्स डेवलपर्स о завершении тестирования поддержки DNS поверх HTTPS (DoH, DNS over HTTPS) и намерении в конце сентября включить данную технологию по умолчанию для пользователей из США. Включение будет производиться поступательно, вначале для нескольких процентов пользователей, а в случае отсутствия проблем постепенно доводя до 100%. После охвата США будет рассмотрена возможность включения DoH и в других странах.
Проводимые в течение года тесты показали надёжность и хорошую производительность сервиса, а также позволили выявить некоторые ситуации, когда DoH может приводить к проблемам, и разработать решения для их обхода (например, разобраны с оптимизацией трафика в сетях доставки контента, родительским контролем и корпоративными внутренними DNS-зонами).
Важность шифрования DNS-трафика оценивается как принципиально важный фактор защиты пользователей, поэтому DoH решено включить по умолчанию, но на первом этапе только для пользователей из США. После активации DoH пользователю будет выведено предупреждение, которое позволит при желании отказаться от обращения к централизованным DoH-серверам DNS и вернуться к традиционной схеме отправки незашифрованных запросов к DNS-серверу провайдера (вместо распределённой инфраструктуры резолверов DNS, в DoH использована привязка к определённому DoH-сервису, который может рассматриваться как единая точка отказа).
При активации DoH возможно нарушение работы систем родительского контроля и корпоративных сетей, использующих доступную только для внутренней сети структуру имён DNS для преобразования интранет-адресов и корпоративных хостов. Для решения проблем с подобными системами добавлена система проверок, автоматически отключающих DoH. Проверки выполняются при каждом запуске браузера или при определении изменения подсети.
Автоматический возврат на использование штатного резолвера операционной системы также предусмотрен при возникновении сбоев при резолвинге через DoH (например, при нарушении сетевой доступности с провайдером DoH или возникновении сбоев в его инфраструктуре). Смысл подобных проверок сомнителен, так как никто не мешает атакующим, контролирующим работу резолвера или способным вмешаться в трафик, симулировать подобное поведение для отключения шифрования DNS-трафика. Проблема решена добавлением в настройки пункта «DoH always» (по молчанию не активен), при установке которого автоматическое отключение не применяется, что является разумным компромиссом.
Для определения корпоративных резолверов выполняются проверки нетипичных доменов первого уровня (TLD) и возвращение системным резолвером интранет-адресов. Для определения включения родительского контроля осуществляется попытка резолвинга имени exampleadultsite.com и если результат не совпадает с фактическим IP, считается, что активна блокировка взрослого контента на уровне DNS. В качестве признаков также проверяются IP-адреса Google и YouTube на предмет их подмены на restrict.youtube.com, forcesafesearch.google.com и restrictmoderate.youtube.com. Дополнительно Mozilla внедрить единый проверочный хост , который могут использовать интернет-провайдеры и сервисы родительского контроля в качестве метки для отключения DoH (если хост не определяется, Firefox отключает DoH).
एकल DoH सेवा के माध्यम से काम करने से संभावित रूप से सामग्री वितरण नेटवर्क में ट्रैफ़िक अनुकूलन के साथ समस्याएं पैदा हो सकती हैं जो DNS का उपयोग करके ट्रैफ़िक को संतुलित करते हैं (सीडीएन नेटवर्क का DNS सर्वर रिज़ॉल्वर पते को ध्यान में रखते हुए एक प्रतिक्रिया उत्पन्न करता है और सामग्री प्राप्त करने के लिए निकटतम होस्ट प्रदान करता है) . ऐसे सीडीएन में उपयोगकर्ता के निकटतम रिज़ॉल्वर से DNS क्वेरी भेजने पर उपयोगकर्ता के निकटतम होस्ट का पता वापस आ जाता है, लेकिन केंद्रीकृत रिज़ॉल्वर से DNS क्वेरी भेजने पर DNS-ओवर-HTTPS सर्वर के निकटतम होस्ट का पता वापस आ जाएगा। . अभ्यास में परीक्षण से पता चला कि सीडीएन का उपयोग करते समय डीएनएस-ओवर-एचटीटीपी के उपयोग से सामग्री स्थानांतरण शुरू होने से पहले वस्तुतः कोई देरी नहीं हुई (तेज कनेक्शन के लिए, देरी 10 मिलीसेकंड से अधिक नहीं थी, और धीमे संचार चैनलों पर भी तेज प्रदर्शन देखा गया था) ). सीडीएन रिज़ॉल्वर को क्लाइंट स्थान की जानकारी प्रदान करने के लिए ईडीएनएस क्लाइंट सबनेट एक्सटेंशन के उपयोग पर भी विचार किया गया।
आइए याद रखें कि DoH प्रदाताओं के DNS सर्वरों के माध्यम से अनुरोधित होस्ट नामों के बारे में जानकारी के लीक को रोकने, MITM हमलों का मुकाबला करने और DNS ट्रैफ़िक को खराब करने, DNS स्तर पर अवरोधन का मुकाबला करने, या ऐसी स्थिति में कार्य को व्यवस्थित करने के लिए उपयोगी हो सकता है। DNS सर्वर तक सीधे पहुंचना असंभव है (उदाहरण के लिए, प्रॉक्सी के माध्यम से काम करते समय)। यदि सामान्य स्थिति में DNS अनुरोध सीधे सिस्टम कॉन्फ़िगरेशन में परिभाषित DNS सर्वर पर भेजे जाते हैं, तो DoH के मामले में, होस्ट के आईपी पते को निर्धारित करने का अनुरोध HTTPS ट्रैफ़िक में समाहित किया जाता है और HTTP सर्वर पर भेजा जाता है, जहां रिज़ॉल्वर प्रक्रिया करता है वेब एपीआई के माध्यम से अनुरोध। मौजूदा DNSSEC मानक केवल क्लाइंट और सर्वर को प्रमाणित करने के लिए एन्क्रिप्शन का उपयोग करता है, लेकिन ट्रैफ़िक को अवरोध से नहीं बचाता है और अनुरोधों की गोपनीयता की गारंटी नहीं देता है।
DoH को about:config में सक्षम करने के लिए, आपको नेटवर्क.trr.mode वेरिएबल का मान बदलना होगा, जो फ़ायरफ़ॉक्स 60 के बाद से समर्थित है। 0 का मान DoH को पूरी तरह से अक्षम कर देता है; 1 - DNS या DoH का उपयोग किया जाता है, जो भी तेज़ हो; 2 - DoH का उपयोग डिफ़ॉल्ट रूप से किया जाता है, और DNS का उपयोग फ़ॉलबैक विकल्प के रूप में किया जाता है; 3 - केवल DoH का उपयोग किया जाता है; 4 - मिररिंग मोड जिसमें DoH और DNS का उपयोग समानांतर में किया जाता है। डिफ़ॉल्ट रूप से, CloudFlare DNS सर्वर का उपयोग किया जाता है, लेकिन इसे नेटवर्क.trr.uri पैरामीटर के माध्यम से बदला जा सकता है, उदाहरण के लिए, आप "https://dns.google.com/experimental" या "https://9.9.9.9" सेट कर सकते हैं .XNUMX/डीएनएस-क्वेरी "
स्रोत: opennet.ru