«DNS over HTTPS» оформлен в RFC 8484 — но не все им довольны

    В конце октября Инженерный совет интернета (IETF) представил стандарт DNS over HTTPS (DoH) для шифрования DNS-трафика, оформив его в виде RFC 8484. Его одобрили многие крупные компании, но были и те, кто остался недоволен решением IETF. Среди последних был один из создателей системы DNS Пол Викси (Paul Vixie). Сегодня мы расскажем, в чем здесь суть.


    / фото Martinelle PD

    Проблема DNS


    Протокол DNS не шифрует запросы от пользователя к серверу и ответы на них. Данные транслируются в виде текста. Таким образом, запросы содержат имена хостов, которые посещает пользователь. Отсюда появляется возможность «подслушать» канал связи и перехватить незащищенные персональные данные.

    В чем суть DNS over HTTPS


    Чтобы исправить ситуацию, был предложен стандарт DNS over HTTPS, или «DNS поверх HTTPS». В IETF начали работать над ним в мае 2017 года. Его авторами выступили инженеры Пол Хоффман (Paul Hoffman) из ICANN — корпорации по управлению доменными именами и IP-адресами — и Патрик Макманус (Patrick McManus) из Mozilla.

    Особенность DoH заключается в том, что запросы на определение IP-адреса отправляются не DNS-серверу, а инкапсулируются в трафик HTTPS и передаются HTTP-серверу, на котором специальный резолвер обрабатывает их с помощью API. DNS-трафик маскируется под обычный HTTPS-трафик, а связь клиента и сервера происходит через стандартный для HTTPS порт 443. Содержание запросов и факт использования DoH остаются скрытыми.

    В RFC 8484 Инженерный совет приводит примеры DNS-запросов к example.com с DoH. Вот запрос с методом GET:

       :method = GET
       :scheme = https
       :authority = dnsserver.example.net
       :path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
       accept = application/dns-message
    

    Аналогичный запрос с использованием POST:

    :method = POST
       :scheme = https
       :authority = dnsserver.example.net
       :path = /dns-query
       accept = application/dns-message
       content-type = application/dns-message
       content-length = 33
    
       <33 bytes represented by the following hex encoding>
       00 00 01 00 00 01 00 00  00 00 00 00 03 77 77 77
       07 65 78 61 6d 70 6c 65  03 63 6f 6d 00 00 01 00
       01
    

    Многие из представителей ИТ-индустрии выступили в поддержку стандарта IETF. Например, ведущий исследователь интернет-регистратора APNIC Джефф Хьюстон (Geoff Houston).

    Разработку протокола поддержали крупные интернет-компании. С начала года (когда протокол еще находился на этапе драфта) DoH тестируют Google/Alphabet и Mozilla. Одно из подразделений Alphabet, выпустило приложение Intra для шифрования DNS-трафика пользователей. Браузер Mozilla Firefox поддерживает DNS over HTTPS с июня этого года.

    DoH внедрили и DNS-сервисы — Cloudflare и Quad9. В Cloudflare недавно выпустили приложение (об этом была статья на Хабре) для работы с новым протоколом на Android и iOS. Оно выступает в роли VPN к собственному устройству (на адрес 127.0.0.1). DNS-запросы начинают отправляться в Cloudflare с использованием DoH, а трафик идет «обычным» маршрутом.

    Список браузеров и клиентов с поддержкой DoH можно найти на GitHub.

    Критика стандарта DoH


    Не все участники индустрии положительно отозвались о решении IETF. Противники стандарта считают, что DoH — шаг в неправильном направлении и он только снизит уровень безопасности соединения. Наиболее резко о новом протоколе высказался Пол Викси, один из разработчиков системы DNS. У себя в Twitter он назвал DoH «полнейшей чушью с точки зрения информационной безопасности».

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


    / фото TheAndrasBarta PD

    Противники DoH предлагают использовать другой подход — протокол DNS over TLS, или DoT. Эта технология принята как стандарт IETF и описана в документах RFC 7858 и RFC 8310. Как и DoH, протокол DoT скрывает содержимое запросов, но отправляет их не по HTTPS, а использует TLS. Для подключения к DNS-серверу при этом используется отдельный порт — 853. Из-за этого отправка DNS-запроса не скрывается, как в случае с DoH.

    Технология DoT тоже подвергается критике. В частности, эксперты отмечают: из-за того, что протокол работает с выделенным портом, третья сторона сможет отслеживать использование защищенного канала и при необходимости блокировать его.

    Что ждет протоколы дальше


    По словам экспертов, пока неясно, какой из способов защиты DNS-запросов станет более распространен.

    Сейчас и Cloudflare, и Quad9, и Alphabet поддерживают оба стандарта. Если DoH Alphabet использует в упомянутом выше приложении Intra, то протокол DoT применили для защиты трафика в Android Pie. Также Google включил поддержку DoH и DoT в Google Public DNS — причем внедрение второго стандарта никак не анонсировали.

    Издание The Register пишет, что конечный выбор между DoT и DoH будет зависеть от пользователей и провайдеров, и сейчас ни у одного из стандартов нет явного преимущества. В частности, по прогнозам ИТ-специалистов, для широкого распространения протокола DoH на практике потребуется пара десятилетий.



    P.S. Другие материалы из нашего корпоративного блога об IaaS:


    P.P.S. Наш канал в Telegram — о технологиях виртуализации:

    ИТ-ГРАД
    263,00
    vmware iaas provider
    Поделиться публикацией

    Комментарии 55

      +5
      По его мнению, новая технология не даст эффективно контролировать работу сетей. Например, системные администраторы не смогут блокировать потенциально вредоносные сайты, а рядовые пользователи будут лишены возможности организации родительского контроля в браузерах.
      это как критиковать строителей моста что после постройки, плохие люди смогут убегать по мосту на другой берег О_о! ну так и хорошие смогут, для этого мост и делают.
        +1

        Там ещё в комментариях забавно. "network operators must be able to monitor and filter it.Use DoT, never DoH.".


        То есть конкурирующий DoT сразу разрабатывается с прицелом на возможность фильтрации. Зря Гугл его за компанию поддерживает, их голос мог быть решающим.

          0

          А чем конкретно DoT отличается настолько принципиально, что создаёт возможность просматривать/фильтровать трафик? Если речь о том, что будет использовать MItM на левых сертификатах, то с DoH можно делать ровно то же самое, просто чуток сложнее — надо не просто перехватить запрос и ответить самостоятельно, а перехватить, проанализировать это запрос к /dns-query или нет, в первом случае ответить самостоятельно, во втором проксировать запрос реальному серверу.

            +1
            Написано же в статье.

            DoT использует отдельный порт 853 и провайдер может просто его заблокировать и тем самым отключить DoT и вынудить клиента использовать нешифрованный DNS. Чтобы провайдер мог блокировать нехорошие сайты и продавать аналитику о пользователях.

            DoH с виду выглядит как HTTPS и его блокировать труднее.

              0

              У меня была такая мысль, но, всё же, есть разница между "заблокировать" и "просматривать/фильтровать". Так что я понадеялся, что дело в чём-то другом.

                0
                Заблокировать это цель, фильтровать — метод достижения цели
                0

                Но для резолва через DoH все равно нужен IP адрес.
                Ну будут блокировать 1.1.1.1:443 вместо 1.1.1.1:853, невелика беда.

                  +1
                  Это сложнее, так как любой может поднять DoH сервер и сообщить о нем в чатике по интересам, и надо тратить силы на поиск всех этих серверов. Как с Телеграмом.
                    0

                    DoT не запрещает использовать любой другой порт, так что в теории и с ним это возможно, если есть возможность сконфигурировать.
                    Но так клиент должен тоже уметь возможность настраивать порт для DNS-сервера. Либо в домашних условиях можно поднять сервер в локальной сети, который может соединяться посредством DoT и с него раздавать устройствам.
                    Варианты, в общем, есть. Но это конечно уже не добавил и пошёл, как в случае с DoH, тут вы правы.

          0
          для широкого распространения протокола DoH на практике потребуется пара десятилетий

          Не слишком ли долго на распространение технологии? Ее и сейчас уже активно используют через приложение от Claudflare.
            0

            В этот момент google с chrome: Hold my beer… 1 релиз и огромное количество пользователей браузера юзают DOH.


            Причём Гугл может сделать красиво — если провайдер не предложил по DHCP использовать DOH, использовать от гугл. Тут вот вообще ни от кого претензий не будет.

            +7
            А то, что в DoH перформанс просто никакой относительно обычного DNS почему не упомянуто? Т.е. вместо одного UDP-запроса и ответа надо поднять TCP (3-4 пакета), установить SSL (ещё 3 пакета? не помню уже), обернуть весь запрос в http, увеличив payload, с той стороны распарсить и вернуть.
            А если DoH-сервер решит идти к вышестоящим по DoH… Явно направление неверное.

            DoT всё-же чуть легче, но тоже в целом, тяжеловат, а проблемы с тем, что используется отдельный порт мне не кажутся проблемами, если не видно, что происходит внутри. Любой компьютер посылает DNS-запросы, это не является проблемой и экзотикой. Будет просто посылать через другой порт. А вот если компьютер не посылает запросы, но при этом ходит в интернет, это уже подозрительная личность.
              +1
              А то, что в DoH перформанс просто никакой относительно обычного DNS почему не упомянуто?

              Тут выбор между «совсем никакой… вообще никак ибо заблокировали» и «медленне, но как-то работает».
              Явно направление неверное.

              Работающее «как-то» явно лучше неработающего «вообще никак» :)
                0
                Вот именно. Что мне толку от перформанса, если я не могу вообще попасть на нужный сайт, а вижу вместо него заглушку провайдера о том, что какой-то И.П Рак вдруг решил, что этот сайт мне посещать не следует.
                  0
                  Именно DoH просто не даёт возможности оператору сделать переадресацию и соответственно заглушку.
                  Единственным способом блокирования остается блокирование по IP, что чревато, см. сагу «РосКомНадзор vs Телега» и суды после этого.
                  0
                  +1
                  Когда у меня в Крыму отрубился ДНС провайдера (профукали сертификаты, говорят), то включение RTT в Firefox «внезапно»™ решило проблему, пока народ двое суток повизгивал в единственном средстве коммуникации с провайдером — вконтактике с мобильного :/

                  Уже с месяц RTT (т.е. DoH) включён принудительно и совершенно не испытываю проблем с задержками. Если не брать ситуацию, когда мне надо опросить 100500 разных dns имен подряд, то, с учетом даже минимального кеширования, разница не ощутима.

                  ЗЫ: вторую неделю неспешно «мечтаю» прикрутить это дело к микротику, но ничего, кроме MetaRouter пока не вырисовывается, а оно глючное…
                    0
                    Что-то не могу нагуглить, как включить, поделитесь, плиз.
                      0
                      Где-то недавно мелькало, могу всё не вспомнить:
                      * about:config
                      * networking.trr.mode = 2
                      * networking.trr.uri = 'https://cloudflare-dns.com/dns-query'

                      смотреть, что оно работает через about:networking -> dns

                      Про варианты trr.mode — гуглить возможные варианты (2 = предпочитать DoH, fallback to DNS)

                      ЗЫ: Firefox должен быть достаточно свежий, точно не помню, но, что-то типа выше 60.3
                        0
                        Начиная с Firefox 63 это настраивается в обычных графических настройках, в настройках сети.
                        +1
                        вторую неделю неспешно «мечтаю» прикрутить это дело к микротику
                        forum.mikrotik.com/viewtopic.php?f=2&t=132678#p693725
                          0
                          До этого момента полагал (точнее даже не задумывался), что у микротиков просто «своя» ось. А оно, вона как! О_о

                          Погуглил. Не, судя по процедуре рутования, пока потерплю :)
                      +2
                      Ну, с приходом TLS 1.3 и 0-RTT Handshake все уже не так плохо. Первое соединение будет долгое, да. А повторные уже будут устанавливаться намного быстрее. Да и в http есть keep-alive.

                      Тем более, в RFC указан HTTP/2 как минимально рекомендуемый стандарт. То есть, в будущем скорее всего будет и HTTP/3, который сделан поверх UDP/QUIC.
                        0

                        С точки зрения серверов — возможно. Мне, как пользователю всё равно. Как ниже отметили, я лучше подожду 6 пакетов до результата, чем один пакет до заглушки.

                        0
                        Мне вот другое интересно. DNS это дерево кэширующих серверов. Когда я обращаюсь к серверу провайдера, он кэширует последние ответы, его вышестоящий кэширует и т.д., снижая нагрузку на корневые серверы. С DoH и DoT мы централизируемся?
                          0
                          Нет, просто можно считать другим протоколом для общения с DNS-сервером.
                            0
                            Я тогда не понимаю. Ну, допустим мы обращаемся к 127.0.0.1:53@udp локально, он связывается со своим 1.1.1.1 на амазоне. А дальше? Амазон использует обычный DNS и это защита от манипуляций со стороны провайдера и не более? Как, например, это остановит манипуляции со стороны амазона?
                              0
                              1.1.1.1 — на CloudFlare, дальше он может пойти тем же протоколом, это ничему не мешает, но скорее всего пойдёт обычным DNS или DNSSec.
                              В основном, эта защита именно от манипуляций со стороны провайдера.
                                0
                                Да вроде уже не мало — DoH и не должен был решить сразу все проблемы
                                  0
                                  Тут надо разделять приватность и целостность. Обертки типа DoH и DoT обеспечивают исключительно приватность от клиента до сервера, к которому направляется запрос. Если же DNS-сервис, TLD и запрашиваемый домен поддерживают DNSSec и соответствующая информация возвращается в запросе (так делает, например, 1.1.1.1), записи DNSSec позволяют автоматически осуществить именно проверку целостности: не подменил ли кто-то ответ.
                              +2
                              Хорошо, я включу эту опцию в Firefox. Так у меня перестанут работать сайты, у которых есть разные внутренние и наружние адреса. Всё будет как будто я не внутри сети, а снаружи.
                                0

                                Почему?

                                  +1
                                  Допустим есть адрес внутренней сети организации server.my.net, которому соответствует адрес 192.168.0.111 из приватного диапазона внутри сети и 12.34.56.78 снаружи. По первому адресу доступны корпоративные ресурсы, по второму — только интерфейс для клиентов. Так как в DoH запрос пойдёт скорее всего напрямую до какого-нибудь гугла, он вернёт естественно публичный адрес. Но тут другой вопрос, если такие сложности с одной довольно редкой ситуацией, почему просто не добавить в закладки браузера нужный внутренний айпишник?
                                    +1
                                    Это что за организация такая, где можно делать в сети то, что хочешь? Если вы админ, то найдёте способ как это обойти, а если пользователь сети, то посоветуйтесь с админом. Хотя, в большинстве случаев просто получите звиздюдей от начальника за то, что в рабочее время занимаетесь не тем, чем надо :)
                                      +2
                                      Мне тоже кажется, что ситуация надуманная, просто попытался ответить на вопрос выше :) Меня, как человека, использующего свой DNS в том числе для борьбы с рекламой и трекингом, больше волнует, что распространение DoH снизит эффективность такого подхода или вообще сведет его на нет, если каждое приложение и браузер будут лезть в свой DNS ресолвер через туннель
                                        0
                                        Мне тоже DoH не нужен от слово совсем ибо это тормоза и ужас, у меня есть быстрый кэширующий DNS, который отвечает из локалки за 0.5-0.6 мс, а любой запрос которого нет в кэше получает за 2-7 мс от серверов (провайдера (Онлайм), Google, Яндекс, Cloudflare и системы OpenNIC), и только редкие запросы уходят от DNS к которым обращаюсь дальше к корням. В общем вся инфраструктура недалеко от меня и переводить эту красоту на убогий HTTPS это бред и деградация.

                                        Снизить эффективность выкрамсывания следилок и мусора может но не досконально ибо если есть свой DNS, то вместо, например, dns.google.com возвращай 255.255.255.255. Да и если есть свой DNS то и маршрутизация своя обычно есть, так что отправка серверов DoH по IP в drop решает все проблемы. В общем просто списки источников жучков и мусора станут чуть больше, а принципиально ничего не изменится.
                                        P.S.
                                        ЧТД - тормоза уже на этапе mtr, а там ещё TCP, SSL, и ну его в баню.
                                        image
                                        image
                                        0
                                        Что значит «можно делать в сети то, что хочешь»???
                                        Firefox либо использует DoH на 100% или не использует совсем.
                                        0
                                        Далеко не всегда получится. Например, если используется reverse proxy.
                                        0
                                        Простая ситуация — мой у моего работодателя есть сервис, который доступен глобально (с ограниченной функциональностью) и локально (из офиса — с полной функциональностью).
                                        Если я использую DoH, то я не смогу использовать внутренние ресурсы.
                                          0
                                          Почему? Чем это отличается от SSL VPN?
                                            0
                                            потому, что из внутренней сети я всё-равно получу внешний IP сервиса.
                                              0
                                              А это еще почему ?!
                                                0
                                                потому, что, например, Firefox будет обращаться к 1.1.1.1 и, соответственно, получит внешний IP.
                                                  0
                                                  потому, что, например, Firefox будет обращаться к 1.1.1.1 и, соответственно, получит внешний IP.

                                                  Если «гвоздями прибить» адреса, то так любое будет работать.
                                                  Опять же обратимся к стандарту:
                                                  3. Selection of DoH Server

                                                  Note that configuration might be manual (such as a user typing URI Templates in a user interface for «options») or automatic (such as URI Templates being supplied in responses from DHCP or similar protocols). DoH servers MAY support more than one URI Template. This allows the different endpoints to have different properties, such as different authentication requirements or service-level guarantees.

                                                  Раз динамическая конфигурация поддерживается, то ее нужно просто корректно настроить, то что не доимплеменировано — дописать корректно в приложениях и серверах. Зачем ссылаться на частный случай плохой реализции?
                                      +3
                                      Кстати, с моей точки зрения у DoH есть еще одна проблема — сейчас различные CDN могут отдавать мне IP адрес ближайшего сервера на основании моего IP адреса, а при переходе на DoH я буду пользоваться CDN сервером, ближайшим к DNS серверу DoH.
                                        0
                                        А представьте, что вам обычный DNS даст несколько IP а не один? как-то же работает такая схема сейчас. Ничего не поменялось
                                          0
                                          Видимо вы не разбираетесь в вопросе. Не буду с вами спорить.
                                            +1
                                            А что тут сложного? Или у вас один IP в ответе или несколько. Или идете в один адрес без вариатнов или выбираете один из нескольких. Сейчас вы можете кинуть запрос на несколько DNS серверов одновременно, кто первый ответит — туда и пойдете. Какая разница кто и куда вас отправит, если вы все равно не контролируетете ответы и даже не понимаете почему именно такой ответ? От того, что ответ пришел вам в https/tls, а не «Raw» что-то поменяется принципиально?
                                              +1
                                              Если сервер для DoH это что-то близкое к вам, то отвечатаю серверу DoH ДНС от CDN сети даст вам адрес ближайшего к вам сервера, если же DoH сервер это что-то далекое, то DNS сервер от CDN вернет вам адрес делёкого сервера и скорость у вас будет ниже. Клиенту что надо? Нужно быстро открыть видео или что-то еще. Провайдеру что надо? Отдать клиенту видео с более близкого, часто значит и дешевого сервера.
                                              То, что клиент не может получить в ответе несколько IP адресов не имеет значения для описанной мною ситуации.
                                                0
                                                Если сервер для DoH это что-то близкое к вам, то отвечатаю серверу DoH ДНС от CDN

                                                А где в стандарте упомянут CDN? Они то тут вообще причем?
                                                В стандарте написано:
                                                3. Selection of DoH Server
                                                The DoH client is configured with a URI Template [RFC6570], which describes how to construct the URL to use for resolution. Configuration, discovery, and updating of the URI Template is done out of band from this protocol. Note that configuration might be manual (such as a user typing URI Templates in a user interface for «options») or automatic (such as URI Templates being supplied in responses from DHCP or similar protocols). DoH servers MAY support more than one URI Template. This allows the different endpoints to have different properties, such as different authentication requirements or service-level guarantees.

                                                В числе первых CDN реализовали тестовую среду для этого стандарта. Пропишите, например, руками у себя OpenDns URI Template для DoH и пользуйтесь на здоровье.
                                                Вам просто добавили еще один транспорт для DNS, оставив логику приложения «как есть».
                                          0
                                          Разве кто-то из крупных игроков нынче осуществляет геобалансировку посредством DNS? У этого подхода есть куча проблем и далеко не только те, что вы описали.
                                          В качестве костыля, кстати, когда-то даже придумали EDNS Client Subnet, но количество серверов с его поддержкой мало.
                                          0
                                          Имхо, данные технологии имеют смысл в мобильных устройствах и, возможно, как включаемые функции в браузерах, но ни в коем случае не как замена классическому dns на 53 порту.
                                          В домашней сети куда более эффективнее и проще заворачивать нешифрованный dns в обычный vpn туннель.
                                            0

                                            А чем мобильные отличаются? Их в VPN заворачивать даже важнее, чем домашнюю сеть, потому что мобильные вечно через левые WiFi работают.

                                              0
                                              Возможно. Хотя я этого не делаю. Дома у меня интернет раздается устройствам уже пропущенный через vpn, а вне дома я им практически не пользуюсь. Vpn клиент на телефоне тоже есть, конечно, но держать его постоянно включенным это лишняя нагрузка на батарею.

                                              Вот сейчас подумал, что включенный по умолчанию данный способ общения с dns конкретно в моей сети существенно скажется на скорости резолвинга. Потому что вместо нешифрованного запроса на локальный кеширующий dns сервер, запрос будет пересылаться куда-то в интернет, еще и с установлением tls сессии каждый раз.

                                              В общем технологии хорошие и интересные, но это не замена dns на 53 порту.
                                              Хорошо, наверное, их будет применять на локальном dns сервере внутри сети в качестве способа запроса к вышестоящему dns серверу, для чего раньше использовался dnscrypt.
                                                0

                                                Я не замечал от OpenVPN for Android никакой дополнительной нагрузки. Плюс, дополнительная фича, все мобильные устройства подключаются к домашнему VPN-серверу, что даёт им прямой доступ в домашнюю локалку — ну и дальше в инет они идут из домашней сети как все остальные домашние устройства, через второй VPN.


                                                Что касается DoH/DoT — мне не очень нравится идея использовать для всего ресолвинга сервера одной коммерческой компании, будь то CloudFlare или Google — они гарантированно будут делать всё, чтобы воспользоваться этими данными для отслеживания и сбора информации для таргетинга рекламы. Как по мне, то VPN в другую страну, не страдающую манией фильтрации трафика, и дальше обычный DNS обеспечит большую приватность.

                                                  0
                                                  У меня такая же фича с доступом в домашнюю сеть, за исключением того, что все подключения происходят на адрес vps сервера. Белый ip от провайдера — сегодня это недоступная роскошь.

                                                  Я с dns все проблемы решил поднял у себя в локалке dns резолвер (не форвардер, как все обычно делают), больше года такая конфигурация у меня работает и ни одного сбоя, плюс независимость от централизованных dns серверов. Не понимаю, почему так не делают все. А раньше dnscrypt`ом пользовался, вот там периодически происходили отказы серверов и приходилось срочно искать новый.

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                          Самое читаемое