Распрацоўнікі Firefox аб уключэнні па змаўчанні рэжыму DNS па-над HTTPS (DoH, DNS over HTTPS) для карыстачоў з ЗША. Шыфраванне DNS-трафіка разглядаецца як прынцыпова важны фактар абароны карыстачоў. Пачынальна з сённяшняга дня ва ўсіх новых усталёўках, выкананых карыстачамі з ЗША, DoH актываваны па змаўчанні. Існуючых карыстальнікаў з ЗША плануецца пераключыць на DoH на працягу некалькіх тыдняў. У Еўразвязе і іншых краінах актываваць DoH па змаўчанні пакуль .
Пасля актывацыі DoH карыстачу выводзіцца папярэджанне, якое дазваляе пры жаданні адмовіцца ад звароту да цэнтралізаваных DoH-серверам DNS і вярнуцца да традыцыйнай схемы адпраўкі незашыфраваных запытаў да DNS-серверу правайдэра. Замест размеркаванай інфраструктуры рэзавераў DNS, у DoH скарыстана прывязка да вызначанага DoH-сэрвісу, які можа разглядацца як адзіная кропка адмовы. У цяперашні час прапануецца праца праз два DNS-правайдэра – CloudFlare (па змаўчанні) і .
Змяніць правайдэра або адключыць DoH у наладах сеткавага злучэння. Напрыклад, можна пазначыць альтэрнатыўны сервер DoH "https://dns.google/dns-query" для звароту да сервераў Google, "https://dns.quad9.net/dns-query" - Quad9 і "https://doh .opendns.com/dns-query» - OpenDNS. У about:config таксама прадугледжана настройка network.trr.mode, праз якую можна змяніць рэжым працы DoH: значэнне 0 цалкам адключае DoH; 1 - выкарыстоўваецца DNS або DoH, у залежнасці ад таго, што хутчэй; 2 - выкарыстоўваецца DoH па змаўчанні, а DNS як запасны варыянт; 3 - выкарыстоўваецца толькі DoH; 4 - рэжым люстэркавання пры якім DoH і DNS задзейнічаны паралельна.
Нагадаем, што DoH можа апынуцца карысным для выключэння ўцечак звестак аб запытаных імёнах хастоў праз DNS-серверы правайдэраў, барацьбы з MITM-атакамі і падменай DNS-трафіку (напрыклад, пры падлучэнні да публічных Wi-Fi), супрацьстаяння блакаванням на ўзроўні DNS (DoH не можа замяніць VPN у вобласці абыходу блакіровак, рэалізаваных на ўзроўні DPI) або для арганізацыі працы ў выпадку немагчымасці прамога звароту да DNS-серверам (напрыклад, пры працы праз проксі). Калі ў звычайнай сітуацыі DNS-запыты напроста адпраўляюцца на вызначаныя ў канфігурацыі сістэмы DNS-серверы, то ў выпадку DoH запыт на вызначэнне IP-адрасы хаста інкапсулюецца ў трафік HTTPS і адпраўляецца на HTTP-сервер, на якім рэзалвер апрацоўвае запыты праз Web API. Існуючы стандарт DNSSEC выкарыстоўвае шыфраванне толькі для аўтэнтыфікацыі кліента і сервера, але не абараняе трафік ад перахопу і не гарантуе канфідэнцыйнасць запытаў.
Для адбору прапанаваных у Firefox правайдэраў DoH сфармуляваны да годных DNS-рэзалверам, у адпаведнасці з якімі DNS-аператар можа выкарыстоўваць атрыманыя для рэзалвінгу дадзеныя толькі для забеспячэння працы сэрвісу, не павінен захоўваць логі даўжэй 24 гадзін, не можа перадаваць дадзеныя трэцім асобам і абавязаны расчыняць звесткі аб метадах апрацоўкі дадзеных. Сэрвіс таксама павінен даць абавязацельствы не цэнзураваць, не фільтраваць, не ўмешвацца і не блакаваць DNS-трафік, за выключэннем сітуацый, прадугледжаных заканадаўствам.
Ужываць DoH варта з асцярожнасцю. Напрыклад, у РФ IP-адрасы 104.16.248.249 і 104.16.249.249, злучаныя з прапанаваным па змаўчанні ў Firefox DoH-серверам mozilla.cloudflare-dns.com, в па патрабаванні суда г. Стаўрапаля ад 10.06.2013.
Ужыванне DoH таксама можа прывесці да праблем у такіх галінах, як сістэмы бацькоўскага кантролю, доступ да ўнутраных прастор імёнаў у карпаратыўных сістэмах, выбар маршрутаў у сістэмах аптымізацыі дастаўкі кантэнту і выкананне судовых прадпісанняў у вобласці процідзеяння распаўсюджванню нелегальнага кантэнту і эксплуатацыі непаўналетніх. Для абыходу падобных праблем рэалізавана і пратэставаная сістэма праверак, якія аўтаматычна адключаюць DoH пры пэўных умовах.
Для вызначэння карпаратыўных рэзавераў выконваюцца праверкі нетыповых даменаў першага ўзроўня (TLD) і вяртанне сістэмным рэзалверам інтранэт-адрасоў. Для вызначэння ўключэння бацькоўскага кантролю ажыццяўляецца спроба рэзалвінгу імя exampleadultsite.com і калі вынік не супадае з фактычным IP, лічыцца, што актыўная блакіроўка дарослага кантэнту на ўзроўні DNS. У якасці прыкмет таксама правяраюцца IP-адрасы Google і YouTube на прадмет іх падмены на restrict.youtube.com, forcesafesearch.google.com і restrictmoderate.youtube.com. Дадзеныя праверкі даюць магчымасць атакавалым, кантралявалым працу рэзалвера ці здольным умяшацца ў трафік, сімуляваць падобныя паводзіны для адключэння шыфравання DNS-трафіку.
Праца праз адзіны DoH-сэрвіс таксама патэнцыйна можа прывесці да праблем з аптымізацыяй трафіку ў сетках дастаўкі кантэнту, якія выконваюць балансаванне трафіку з выкарыстаннем DNS (DNS-сервер CDN-сеткі фармуе адказ, улічваючы адрас рэзалвера і выдае бліжэйшы хост для атрымання кантэнту). Адпраўка DNS-запыту з найблізкага да карыстача рэзаверу ў такіх CDN прыводзіць да звароту адрасу найблізкага да карыстача хаста, але пры адпраўцы DNS-запыту з цэнтралізаванага рэзаверу будзе выдадзены адрас хаста, найблізкі да сервера DNS-over-HTTPS. Тэставанне на практыку паказала, што ўжыванне DNS-over-HTTP пры выкарыстанні CDN практычна не прыводзіла да затрымак перад пачаткам перадачы кантэнту (для хуткіх злучэнняў затрымкі не перавышалі 10 мілісекунд, а на павольных каналах сувязі назіралася нават паскарэнне працы). Для перадачы рэзалверу CDN звесткі аб месцазнаходжанні кліента таксама было разгледжана ўжыванне пашырэння EDNS Client Subnet.
Крыніца: opennet.ru