Google Public DNS тихо включили поддержку DNS over TLS



    Внезапно, без предварительного анонса, на 8.8.8.8 заработал DNS over TLS. Ранее Google анонсировал только поддержку DNS over HTTPS.

    Публичный резолвер от компании CloudFlare с IP-адресом 1.1.1.1 поддерживает DNS over TLS с момента запуска проекта.

    Зачем это нужно


    При использовании классической схемы DNS, провайдеры могут лезть своими грязными лапами в ваши DNS-пакеты, просматривать, какие домены вы запрашиваете, и подменять ответы как угодно. Этим же занимаются мошенники, подменяя резолверы на взломанных роутерах, чтобы направить пользователя на поддельный сервер.

    C DNS over TLS/HTTPS запросы посылаются внутри зашифрованного тоннеля так, что провайдер не может подменить или просмотреть запрос.

    А с приходом шифрования имени домена в сертификатах X.509 (ESNI) станут невозможны блокировки через DPI по SNI (Server Name Indication, специальное поле, в котором передается имя домена в первом TLS-пакете), которые сейчас применяются у некоторых крупных провайдеров.

    Как это работает


    На порт TCP:853 выполняется TLS-подключение, при этом проверка сертификата резолвера происходит с использованием системных корневых сертификатов, точно так же, как HTTPS в браузере. Это избавляет от необходимости добавлять какие-либо ключи вручную. Внутри тоннеля выполняется обычный DNS-запрос. Это создает меньше накладных расходов по сравнению с DNS over HTTPS, который добавляет HTTP-заголовки к запросу и ответу.

    К сожалению, на текущий момент только в Android 9 (Pie) поддержка DNS over TLS встроена в системный резолвер. Инструкция по настройке для Android 9.

    Для остальных систем предлагается использовать сторонний демон, а системный резолвер направлять на localhost (127.0.0.1).

    Настройка на macOS


    Разберем настройку DNS over TLS на последней версии macOS, на примере резолвера knot

    Установка


    brew install knot-resolver

    По умолчанию knot будет работать как обычный рекурсивный резолвер, подобно dnsmasq.

    Редактируем конфиг


    nano /usr/local/etc/kresd/config


    И добавляем в конец файла:
    
    policy.add(
            policy.all(
                    policy.TLS_FORWARD({
                            {'8.8.8.8', hostname='8.8.8.8'},
                            {'8.8.4.4', hostname='8.8.4.4'}
                    })))
    

    В итоге мой конфиг выглядит так:
    Раскрыть спойлер
    -- Config file example useable for personal resolver.
    -- The goal is to have a validating resolver with tiny memory footprint,
    -- while actively tracking and refreshing frequent records to lower user latency.
    -- Refer to manual: https://knot-resolver.readthedocs.io/en/latest/daemon.html#configuration
    
    -- Listen on localhost (default)
    -- net = { '127.0.0.1', '::1' }
    
    -- Drop root privileges
    -- user('knot-resolver', 'knot-resolver')
    
    -- Auto-maintain root TA
    trust_anchors.file = 'root.keys'
    
    -- Load Useful modules
    modules = {
            'policy',   -- Block queries to local zones/bad sites
            'hints',    -- Load /etc/hosts and allow custom root hints
            'stats',    -- Track internal statistics
            'predict',  -- Prefetch expiring/frequent records
    }
    
    -- Smaller cache size
    cache.size = 10 * MB
    
    policy.add(
            policy.all(
                    policy.TLS_FORWARD({
                            {'8.8.8.8', hostname='8.8.8.8'},
                            {'8.8.4.4', hostname='8.8.4.4'}
                    })))
    


    Подробнее про hostname и проверку подлинности TLS-сертификата
    Параметр hostname в данном случае — Common Name (CN) или Subject Alt Name (SAN) сертификата. То есть, доменное имя, для которого выпущен сертификат. По нему проверяется подлинность сертификата сервера.

    Вот какие значения SAN у сертификата, который используется при подключении на 8.8.8.8:853
    dns.google
    8888.google
    8.8.4.4
    8.8.8.8 
    2001:4860:4860:0:0:0:0:64 
    2001:4860:4860:0:0:0:0:6464
    2001:4860:4860:0:0:0:0:8844
    2001:4860:4860:0:0:0:0:8888
    

    Любое из этих значений можно использовать в качестве параметра hostname. Если же вы будете разворачивать собственный публичный рекурсивный резолвер, у вас вряд ли получится выпустить X.509-сертификат на IP-адрес, поэтому в параметре hostname придется указывать доменное имя.

    Запуск демона


    sudo brew services start knot-resolver

    Проверить, успешно ли запустился демон, можно командой:

    sudo lsof -i -P -n | grep kresd

    процесс kresd должен слушать порт 53 на localhost.

    Если что-то пошло не так, смотрим лог ошибок:

    cat  /usr/local/var/log/kresd.log

    Проверка работы резолвера


    dig @127.0.0.1 habr.com

    Проверяем, что локальный резолвер отвечает корректно.

    Установка в качестве системного резолвера


    Если все работает правильно, можно назначить системный резолвер в свойствах сетевого адаптера:



    UPD

    В чем разница между DNSCrypt, DNSSEC, DNS over TLS/HTTPS.


    DNSCrypt может работать по UDP и TCP. Подключение на порт 443. Для шифрования используется собственный протокол, который отличается от HTTPS. Может быть легко выделен с помощью DPI. Это скорее черновик, который тестировали до внедрения DNS over TLS/HTTPS, так как он не имеет RFC, то есть не является официальным стандартом интернета. Вероятнее всего, в скором, времени он будет полностью вытеснен последними.

    DNS over TLS (DoT) — TCP-подключение происходит на порт 853, внутри тоннеля передается обычный DNS-запрос. Провайдер видит, что это DNS запрос но не может в него вмешаться. При прочих равных, в DNS over TLS должно быть чуть меньше накладных расходов на каждый запрос, чем в over HTTPS.

    DNS over HTTP (DoH) — TCP-подключение на порт 443, подобно обычному HTTPS. Внутри другой формат запроса, с HTTP-заголовками. Однако для провайдера такой запрос будет виден как обычное HTTPS-подключение. Полагаю, этот протокол был придуман на случай, когда DNS-запросы к чужим серверам будут заблокированы, чтобы маскировать под обычный веб трафик. А также, чтобы браузеры могли сами резолвить домены и не создавать при этом аномальный трафик.

    По сути, DNS over HTTPS и over TLS — одно и то же, с немного отличающемся форматом запросов. Оба эти протокола приняты в качестве стандартов и имеют RFC. Вероятнее всего, в ближайшее время мы увидим массовое распространение их обоих.

    DNSSEC — протокол цифровой подписи DNS-записей. Не имеет отношения к шифрованию, так как все запросы передаются в открытом виде. Может работать как по старому классическому протоколу DNS, то есть UDP/TCP на порту 53, так и внутри DNS over TLS/HTTPS. Целью DNSSEC является подтверждение подлинности DNS-записи. Владелец домена может добавить публичный ключ на корневые сервера своей доменной зоны и подписывать все записи на мастер NS-серверах. По сути, к каждой DNS записи, например, A-записи или MX-записи, добавляется еще одна запись типа RRSIG, содержащая подпись. Процедура валидации DNSSEC на рекурсивном резолвере позволяет установить, действительно эта запись была создана владельцем домена.

    Более подробное сравнение всех протоколов dnscrypt.info/faq (абзац Other protocols)
    Поделиться публикацией

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

      +1

      Господа, что можно настроить под linux без долгой ругани, с возможностью часть доменной зоны(например работодатель.net) отдать на откуп вышестоящему dns работающему по-старинке.

        0
        Я так понимаю зона работодатель.net существует только на одном резолвере и не существует в интернете? Это интересный вопрос. Полагаю, что можно на сервере развернуть knot и задать ему апстрим сервера которые знают об этой зоне. Ну а на клиенте уже настроить dns over tls до этого сервера.
          +3
          В некоторых дистрибутивах NetworkManager интегрирован с dnsmasq. Если у вас такой дистрибутив (проверить можно наличием запущенного dnsmasq и записью nameserver 127.0.0.2 или аналогичной в /etc/resolv.conf), можно прописать определенным зонам определенный сервер DNS, в /etc/dnsmasq.conf.
            +1

            Точнее, прописывать надо в /etc/NetworkManager/dnsmasq.d/*.conf.


            Потому что NetworkManager запускает dnsmasq с опциями --conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq.d.

              0
              чуть менее, чем во всех. просто переключается ресолвер только из конфигов.
                0
                Я встречал использование NetworkManager+dnsmasq по умолчанию только в Ubuntu-based.
              +1
              Unbound, например.
              Там весь конфиг можно в 20 строчек уложить. И локальные ресолверы на зоны настроить.
              wiki.archlinux.org/index.php/unbound#Include_local_DNS_server
                0
                Unbound так умеет.
                Там для форварда всех запросов делается так:
                forward-zone:
                name: "."
                ....


                Соответственно, отдельную зону форвардить можно в отдельные NS.
                +1
                Теперь DNS 8.8.8.8 излечивает от Роскомнадзора? И если да, сколько недель пройдёт до блокировки этого адреса Ростелекомом?
                  +3
                  Нет, не излечит. Но от определенных блокировок поможет. Например мой провайдер при DNS запросах к запрещенным сайтам возвращает IP своей заглушки. А весь трафик ДНС заворачивает на себя. От таких блокировок поможет.
                    +1

                    Что за провайдер, если не секрет? Потенциальные новые клиенты должны знать героев, которые бегут вперёд паровоза РКН и заворачивают ДНС.

                      0
                      Да таких десятки по стране. Как минимум, лично сталкивался с дюжиной. Всех перечислять что ли? Часто это мелкие локальные провайдеры, которые ресейлят всяких Ростелекомов.
                        0
                        Что за провайдер, если не секрет?
                        Дом.ру, например.

                        героев, которые бегут вперёд паровоза РКН
                        Фильтрация DNS — официально рекомендуемый РКН способ для провайдеров с пониженной социальной ответственностью, не способных потянуть DPI:
                        Операторам связи, не использующим DPI и осуществляющим ограничение доступа к доменному имени при помощи иных программных, аппаратных или программно-аппаратных средств, рекомендуется ограничивать доступ к доменному имени посредством фильтрации запросов ко всем DNS-серверам.

                        Да, я согласен, что за такое в приличных домах бьют канделябром по морде ибо нарушение связности.
                      +4
                      Пока что речи о нативной поддержке не идёт. В статье говорится, что это возможно только для Android 9. А с помощью стороннего софта и раньше можно было «излечиваться» от РКН (то есть избегать перенаправления DNS запросов).

                      Кроме того, DNS over TLS/HTTPS не спасает от блокировки по SNI. Так что РКН, скорее всего, даже не будет смотреть в сторону блокировки 8.8.8.8. Кстати, вы статью вообще читали?
                        +2
                        Если все заблокированные сайты включат поддержку шифрования SNI, тогда обойти блокировку можно будет простой сменой резолвера на специальный, вроде сервиса Antizapret. В таком случае на стороне клиента не потребуется устанавливать VPN или прокси, или какой-либо сторонний софт.

                        Я вижу это так: специальным образом сконфигурированный DNS over TLS/HTTPS резолвер выборочно обрабатывает заблокированные сайты, подменяя их реальные IP на свои DNAT прокси. При этом проксируя только TCP. А так как SNI зашифрован, DPI не увидит к какому сайту запрос. Однако это может сломать DNSSEC, если владелец заблокированного домена решит подписать зону.

                        Возможно я где-то ошибаюсь, призываю ValdikSS раскидать по понятиям.
                          +3
                          Надеюсь, все движется к тому, что блокировки сайтов станут невозможными. Этому должно помочь распространение ESNI, шифрованного DNS и IPv6.

                          Вангую, что в ближайшем будущем, любые веб-сайты будут открываться с любых IP. Как это сейчас сделано с веб-фронтендом гугла: вы можете открыть любой сайт (youtube, gmail, google drive) обратившись к любому IP адресу google указав нужный заголовок Host:.

                          Конечно, всегда остается тупая блокировка по IP, но с приходом IPv6 обычному владельцу сайта станут доступны миллиарды адресов почти бесплатно. Поэтому на каждый DNS запрос можно будет резолвить разный адрес, даже из разных сетей. Наверняка у сервисов вроде Cloudflare появится опция типа IP mixer, как раз для защиты сайтов от государственной цензуры. В такой системе блокировать сайты можно будет только заблокировав большую часть интернета.

                          Соудтрек этого комментария: youtube.com/watch?v=H8xwrF4sKsg
                            0
                            вы можете открыть любой сайт (youtube, gmail, google drive) обратившись к любому IP адресу google указав нужный заголовок Host:


                            А можно поподробнее? Что и как делать?
                              +1
                              Есть некоторые мобильные операторы, которые для корректной работы Android пропускают трафик к определенным служебным адресам google. Это позволяет смотреть youtube при отрицательном балансе :)

                              Пробуем найти случайный IP адрес google.com:
                              $ ping google.com
                              PING google.com (74.125.140.100): 56 data bytes
                              64 bytes from 74.125.140.100: icmp_seq=0 ttl=46 time=71.698 ms
                              64 bytes from 74.125.140.100: icmp_seq=1 ttl=46 time=71.703 ms
                              


                              Пробуем запросить по этому адресу сайт Youtube.com. По заголовкам видим, что попали на youtube.
                              
                              $ curl -v -I  --resolve www.youtube.com:443:74.125.140.100 https://www.youtube.com
                              
                              ...
                              *  subjectAltName: host "www.youtube.com" matched cert's "*.youtube.com"
                              ....
                              server: YouTube Frontend Proxy
                              ...
                              set-cookie: PREF=f1=40000000; path=/; domain=.youtube.com;
                              


                              Иначе это можно было сделать добавив в файл hosts такую запись:
                              74.125.140.100 www.youtube.com
                              0

                              Боюсь с приходом IPv6 у облачных провайдеров будет возможность привязывать к клиенту (юр. или физ. лицу) статическую подсеть вместо плавающего публичного IP из общего пула, что лишь поможет РКН точнее блокировать сайты даже без DPI.

                                0
                                Ну вообще-то и сейчас, по-хорошему клиенту должна выдаваться сеть /64 на каждый сервер. Но даже в этом случае IP адреса становятся сильно дешевле и их можно закупать у разных хостеров и обновлять хоть каждую минуту.
                                  –2

                                  Разве не на VLAN? Куда одному серверу столько?

                                    0
                                    Например, чтобы виртуалки на этом сервере могли получать IPv6-адрес, используя нативный механизм назначения адресов, без DHCP. В IPv6 принято иерархическое деление адресного пространства, и клиент получает куски, которые удобно дальше делить под свои нужды самостоятельно.
                                      0
                                      Так ничего не мешает выпускать ВМ или контейнеры через бридж.
                                        0
                                        Ну как раз и хорошо, если они подключены через бридж в основную сеть. Только всё равно нужен префикс /64 на машину, чтобы они могли нативно адреса получать.
                                          0
                                          Адресов из /64 хватит, чтобы выдать миллиарды адресов на каждый сервер в ЦОДе. Не будет сегментации между клиентами, но это дополнительная фича и решается через distributed firewall в SDN.
                                            0
                                            Отлично! А зачем, если можно раздать на каждую машину /64 и каждое сетевое устройство сможет использовать IPv6 SLAAC?
                                              0
                                              Устройства (ВМ с контейнерами на них) и будут получать адреса через SLAAC из одной большой сети.

                                              DO ведь не даёт по /64 на дроплет и в AWS такая сеть выделается на VPC (фактически VLAN), а не на каждый инстанс EC2.
                                                0
                                                У меня как раз есть виртуалка на DO, и мне доступно 16 IPv6-адресов из строго выделенного диапазона. Для того, чтобы назначать IPv6-адреса VPN-клиентам, мне нужно на каждый адрес поднимать neighbor proxy на отдельный адрес при подключении или вообще постоянно. Я не рад такому положению вещей и для меня это недостаток.

                                                У хостера online.net каждый клиент получает префикс /48 и сам нарезает его для разных DUID на блоки размерами по /56 и /64. Серверы запрашивают делегацию префикса по DHCPv6, используя заданный DUID, и дальше распоряжаются адресами на своём уровне иерархии совершенно свободно.

                                                Такой принцип распределения соответствует целям стандарта и на голову выше колхоза, который предлагают хостеры со своими фиксированными мелкими диапазонами. Впрочем, на DO в этом смысле особо равняться не стоит — они и failover IP навешивают через костыль в виде серого адреса — это всё продиктовано удобством реализации для них.
                                                  +1
                                                  Для того, чтобы назначать IPv6-адреса VPN-клиентам, мне нужно на каждый адрес поднимать neighbor proxy

                                                  Согласен, неудобно. Впрочем, если бы на каждый сервер выдавалась сеть /64, это бы тоже не позволило выдавать VPN-клиентам адреса без костылей. Мне нравится как делает Linode и Veesp: на сервер выдается 1 ipv6 адрес и на него отдельная /64 или /48 сеть, маршрутизируемая через первый адрес. Это позволяет мне выдавать VPN клиентам ipv6 адреса ВООБЩЕ без настройки. Достаточно включить форвардинг ipv6 в sysctl.
                                                    0
                                                    Такой принцип распределения соответствует целям стандарта и на голову выше колхоза, который предлагают хостеры со своими фиксированными мелкими диапазонами.

                                                    Согласен, круто иметь VPC в базе.

                                                    Только ветка началась с моего удивления требованию выделять /64 на сервер, что противоречит стандарту (он оперирует клиентами), потребует дополнительной настройки и будет гонять трафик между серверами в стойке через шлюз.
                                +4
                                Я вижу два возможных сценария блокировки соединения при распространении ESNI:

                                1. DNS-серверы провайдера будут блокировать запросы на поддомен _esni.domain.com, на котором размещается публичный ключ для шифрования SNI, заставляя клиента отключать использование ESNI. Можно обойти с помощью стороннего DNS или DNS over TLS/HTTPS. Последний уже встраивается в браузеры.

                                2. Системы DPI провайдера будут блокировать соединения с использованием ESNI. Для шифрованного SNI используется отдельное поле в пакете TLS ClientHello, и для DPI это выглядит так, будто TLS-сессия устанавливается без использования SNI. Некоторые DPI разрывают такие соединения, если они устанавливаются к IP-адресу, на котором расположен заблокированный домен с этим IP-адресом, из-за того, что нельзя понять, к какому домену происходит обращение.

                                Чтобы системы с подставными перенаправляющими DNS-ответами работали корректно, нужно отключать DNSSEC и DNS over HTTPS в браузерах.
                                  +1
                                  Ты должен был бороться со злом, а не примкнуть к нему! ©
                            +6
                            Как настроить Windows?
                            +5
                            > {'8.8.8.8', hostname='1.1.1.1'},

                            Чтобы дополнительно запутать предполагаемого противника?
                              0
                              fixed
                                +4
                                Зря!
                                  0
                                  В примере забыли.
                                +4
                                Немного оффтопик, но раз уж мы говорим за блокировки: с удивлением для себя обнаружил, что мой провайдер отдаёт нефильтрованный трафик в том случае, если клиент заказал себе белый IP. Из технических нюансов — адрес выдаётся из другой автономки, нежели та, из которой берутся адреса для NAT, плюс перестали, наконец, спуфить DNS.

                                Я всё пытаюсь понять, чем это обсуловлено. Я почти уверен, что на каждого клиента, попросившего белый IP, маршрутизацию пишут вручную — ибо это, прости господи, в 2018-м году потребовало приезда монтажника (!!!), который полчаса ковырялся в несчастном 3Com'е, и заняло в целом четыре дня. Таким образом, завернуть трафик на фильтрацию становится технически едва ли не проще.
                                  +3

                                  Просто накосячили или поленились нормально настроить.

                                    +1
                                    Фиг знает, подтверждается минимум с четырёх разных точек у того же провайдера.
                                    Достаточно занятный момент, который, впрочем, сильно упрощает мне жизнь.
                                    –3
                                    Как называется ваш провайдер?
                                      +6

                                      Вам, собственно, зачем?

                                      0
                                      Это случаем не ТТК? Я заказывал у них подключение со статическим IP. Приехали, долго тыкались в существующем подключении, сказали надо менять порт. Нашли ключи, порт поменяли, заработало. Но статического IP нет, говорят позже будет. Жду вечера, день, два… звоню в ТП, мол где мой статический IP. Пожали плечами, мол заявку оформляю. Жду день, два, три… Звоню снова в ТП. Говорят перезвоним. На следующий день звонок, мол вам нужно приехать в офис (а он один на весь Новосибирск), написать письменное заявление на статический IP адрес, потому что «в вшаем доме не прописан нужный VLAN»!!! Подключил другого провайдера и послал их лесом. Правда в офис всё-таки пришлось ехать договор расторгать.
                                        +1

                                        Нет, что вы, это контора куда скромнее.
                                        Культура работы и общения с клиентами у них не слишком далеко ушла от районных сетей середины нулевых, но к стабильности докопаться не могу — все работает как часы. Даунтаймы бывают, но в основном, по вине третьих лиц вроде коммунальщиков или водятлов, сваливших столб с оптикой.

                                      0
                                      Не знаю как сейчас, а раньше замечал 8.8.8.8 в небольшой фильтрации. Некоторые ресурсы, которые по мнению Google считаются пиратскими, не резолвились.
                                      В итоге плюнул и перешёл на DNSCrypt.
                                        +3
                                        А если использовать
                                        • 1.1.1.1
                                        • 1.0.0.1
                                        • 2606:4700:4700::1111
                                        • 2606:4700:4700::1001

                                        — там вроде обещали без цензуры?
                                          +1
                                          Вот вам альтернативные конфигурации knot-resolver на всякий случай:

                                          Cloudflare (обещает вообще без фильтрации):
                                          policy.TLS_FORWARD({
                                                                  {'1.1.1.1', hostname='1.1.1.1'},
                                                                  {'1.0.0.1', hostname='1.0.0.1'}
                                                          })))
                                          


                                          Quad9 (вариант с валидацией DNSSEC, фильтрация вредоносных доменов):
                                          policy.TLS_FORWARD({
                                                                  {'9.9.9.9', hostname='9.9.9.9'},
                                                                  {'149.112.112.112', hostname='149.112.112.112'}
                                                          })))
                                          


                                          Quad9 (вариант без валидации DNSSEC, без фильтрации доменов):
                                          policy.TLS_FORWARD({
                                                                  {'9.9.9.10', hostname='9.9.9.10'},
                                                                  {'149.112.112.112', hostname='149.112.112.10'}
                                                          })))
                                          
                                            0

                                            Спасибо огромное !

                                          +1
                                          Как настроить в Ubuntu?
                                            0
                                            Кто-нибудь объясните мне на пальцах в чем разница между DNS-pver-HTTPS и DNS-over-TLS (сам я пользуюсь github.com/jedisct1/dnscrypt-proxy)

                                            Но я пытаюсь понять это что два разных стандарта? Или как? хттпс же работает через тлс итак?
                                              +3
                                              DNScrypt это скорее черновик, который тестировали до внедрения DNS over TLS/HTTPS, так как он не имеет RFC, то есть не является официальным стандартом интернета. Вероятнее всего, в скором времени он будет полностью вытеснен последними.

                                              В чем разница между DNS over TLS и over HTTPS.
                                              По сути это почти одно и то же, с некоторыми нюансами.

                                              DNS over TLS — TCP подключение происходит на порт 853, внутри тоннеля обычный DNS запрос. Провайдер видит что это DNS запрос но не может в него вмешаться.

                                              DNS over HTTP — TCP подключение на порт 443, подобному обычному HTTPS. Внутри другой формат запроса, с HTTP заголовками. Однако для провайдера такой запрос будет виден как обычное HTTPS подключение. Полагаю, этот протокол был придуман на случай, когда DNS запросы к чужим серверам будут заблокированы, чтобы маскировать под обычный веб трафик. А так же, чтобы браузеры могли сами резолвить домены и не создавать при этом аномальный трафик.

                                              При прочих равных, в DNS over TLS должно быть чуть меньше накладных расходов на каждый запрос.
                                                0
                                                Т.е через ХТТПС имеет оверхед но скрыт от провайдера, через ТЛС без оверхеда и виден как обычный ДНС запрос, но толкьо шифрованный. Всё. Поня.

                                                А DNScrypt во второй версии стал «Supports DNS-over-HTTPS (DoH) and DNSCrypt.»
                                                  +1
                                                  Надеюсь, скоро DoH и DoT встроят во все системные резолверы и весь этот сторонний софт будет ненужен.
                                                  0

                                                  DNScrypt (к слову, ужасная мешанина технологий и пример оверинжиниринга) не имеет отношения к DNS-over-TLS.
                                                  Последний удобен, быстр и просто в настройке.

                                                +1

                                                В случае с https есть дополнительный оверхед на http-заголовки.

                                                  +1
                                                  Хм логично. Но полагаю этим оверхедом можно пренебречь. Это же все-таки днс запросы, а не что-то другое. Или я не прав?
                                                    +3
                                                    Можно, да. Просто трафик для таких запросов будет чуть больше.
                                                  +1
                                                  Пожалуйста, дополните ваш UPD. Интересно, чем всё-таки является DNSCrypt с технической точки зрения.
                                                  Также прошу написать, яем всё это добро отличается от DNSSEC.

                                                  Мне кажется, материал очень выиграет, если эти страшные слова будут разъяснены в одном месте.
                                                    +1
                                                    Готово.
                                                      0
                                                      Спасибо!
                                                      Теперь бы ещё обзор софта с поддержкой шифрованного DNS на винду/линукс/мак/мобилки/роутеры
                                                    +3
                                                    Тут один товарищ прикрутил DNS over TLS к рутованному микротику:
                                                    https://forum.mikrotik.com/viewtopic.php?t=132678#p693725

                                                    Кто может глянуть — возможно ли это сделать без рута?
                                                    Думаю, на уровне маршрутизатора внедрить это дело было бы удобнее, чем на каждом конечном устройстве отдельно.
                                                      0
                                                      Есть инструкция по настройке на OpenWRT (LEDE) от cloudflare blog.cloudflare.com/dns-over-tls-for-openwrt
                                                      Сам не пробовал.
                                                        0
                                                        попробовал, пашет, но сломал unbound'ом dhcp в локалке, как починить не знаю
                                                          0
                                                          Это распространённая проблема.
                                                          Поэтому я предпочитаю резолвер держать на одноплатнике внутри сети, и просто на него перенаправлять запросы от dnsmasq, который их уже кеширует.

                                                          ЗЫ: кстати, еще одна проблема подобного конфига с OpenWRT будет заключаться в том, что у них покамест даже в 18.04 и снэпшотах, используется слегка устаревшая версия OpenSSL, функционала которой недостаточно для проверки сертификатов.

                                                          Таким образом, верифицировать подпись DNS-сервера на OpenWRT вам не удастся. Единственный рабочий вариант сейчас — форсить игнор проверки подписи, что СЛЕГКА нивелирует весь смысл затеи.
                                                            0
                                                            А поподробнее можно про верификацию можно? У меня был unbound на openwrt 18.04 с верификацией сертов.
                                                              0

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

                                                                0
                                                                Да, иначе у меня резолвинг бы не работал. И когда я указывал проверяемый хостнейм неправильно, то он и действительно не работал. В данный момент я перешёл на stubby из-за меньшего объёма потребляемой памяти — она мне нужна для других важных фич.
                                                                Возможно, разница в том, что я ставил самый последний ipk с unbound, который был доступен — в unbound из основного репозитория такой фичи не было вообще. Но проблема точно не в openssl, он проверяет сертификаты нормально во всех приложениях и никаких особенностей в отношении unbound тут нет.
                                                      +4
                                                      А почему они все хотят TCP? Почему не шифровать запросы в udp? Меня идея засунуть state в stateless-протокол напрягает.
                                                        0
                                                        А мне наоборот нравится TCP, потому что тогда можно выставлять рекурсивный резолвер в интернет и при этом не превращаться в часть DDoS ботнета которого используют для UDP амплификации. Ну и TLS по UDP, наверное, не так просто реализовать.

                                                        В firefox с его встроенным DNS over HTTPS используется keep-alive для TCP подключения, так что по сути резолв может работать подобно UDP: один пакет с запросом --> один ответ.
                                                          +1
                                                          Вот именно это меня и напрягает. Если у нас пакеты шлются в существующий канал, то если этот канал ушёл в один из уголков TCP, то возвращаться он будет долго. Переупорядоченные пакеты, потерявшийся ack на dup, etc… Там же бездна.
                                                            0

                                                            В libc по умолчанию таймаут в 5 секунд (man resolv.conf), если явно в resolv.conf не исправить на что-то поменьше.
                                                            Persistent DNS Connections for Reliability and Performance

                                                              +3
                                                              Прочитал. «it is slower than using UDP but only by a factor of 4».

                                                              Я понимаю их аргументы, я понимаю, что там есть таймауты, но я точно знаю, что tcp за счёт гарантий доставки более капризный, чем udp. Он делает гарантированную доставку, но так долго, что лучше не.

                                                              Я могу дать простой пример: сеть с 75% потерь. Мне нужно в среднем около 6 попыток, чтобы получить UDP/DNS ответ в такой сети. 6*5 = 30 секунд. Теперь вопрос, а сколько мне нужно попыток, чтобы установить tcp соединение и передать через него запрос? Удвоение числа пакетов, нужных для успешной отправки резко ухудшает мои шансы.

                                                              Заметим, в случае в UDP-повторами мне всё равно какой из ответов я получу. Любой из прорвавшихся ответов меня устроит. В случае с TCP, даже если мне придёт запоздалый ответ, я в ответ пришлю rst, потому что это «не в ту сессию».

                                                              Короче, у меня скепсис насчёт tcp/dns.
                                                                0
                                                                сеть с 75% потерь

                                                                А каким транспортным протоколом можно пользоваться в такой сети для решения каких-либо прикладных задач? Я не говорю что такие ситуации нереальны, но в действительно же будет почти невозможно пользоваться ничем.

                                                                Кстати в таких сетях отлично работает mosh для ssh. Хозяйке на заметку.
                                                                  0
                                                                  Иногда просто нет выбора. И тогда очень обидно, что всё ломается ещё на этапе dns.
                                                                    0
                                                                    Вы едете в поезде по степям Украины всего в 5км от ближайшего города с 4Г, ага.
                                                                    С обычным dns — у вас будет шанс загрузить чегото сильно больше(особенно учитывая, что каждая страничка отправляет до полусотни днс запросиков).
                                                                      0

                                                                      Вспоминаю как я пытался на Кипре залить на сервер в Питере 100 гигов и отказался от этой затеи как раз из-за сети с кучей потерь, там это почти норма.

                                                                        0
                                                                        но в действительно же будет почти невозможно пользоваться ничем.
                                                                        Некоторые шутеры могут и не заметить (не уверен про 75%, но до 50% держат по крайней мере два). Потому что их разработчики уже наматюкались на TCP уже при 1% потерь пакетов.
                                                                        0

                                                                        Тут как раз трюк в том что соединения не прибиваются, аля мы "экономим" на хендшейке. Cкепсис правильный, работая с серверами я забыл что потери бывают разные.


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

                                                                  +2

                                                                  Есть экспериментальный RFC 8094 "DNS over DTLS", в нём есть такие строчки:


                                                                  DTLS session resumption consumes one round trip, whereas TLS session resumption can start only after the TCP handshake is complete. However, with TCP Fast Open [RFC7413], the implementation can achieve the same RTT efficiency as DTLS.

                                                                  DNS ходит по UDP по историческим причинам, 30 лет назад сети были мееедленные. Хотя и тогда никто не запрещал ходить по TCP.


                                                                  На тему современных отношений DNS и TCP, копипаста ответа Anand Buddhdev на вопрос почему зона .org отваливается если включить валидацию DNSSEC на рекурсоре (и забыть убрать опцию tcp: no):


                                                                  Don't disable TCP. TCP is required for proper operation of DNS, especially if you want to do DNSSEC validation. Many of the signed responses can be large. For example, the DNSKEY response for .ORG is 1625 bytes, and sometimes TCP is required in order to retrieve such large responses. Disabling TCP can cause DNSSEC validation to fail.

                                                                  Ещё есть интересная затея с DNS over QUIC

                                                                    +2
                                                                    Можно пользоваться DNSCrypt, протокол у него отличный, просто, по какой-то причине, они не заморочились с его публикацией в качестве RFC. dnscrypt-proxy поддерживает и DNSCrypt, и DNS over HTTPS.
                                                                      0
                                                                      DoH поддерживает DNSCrypt v2, который писан на Go и уже не на всякий роутер закинешь :/
                                                                      0
                                                                      В TLS достаточно тяжеловесное установление сессии с использованием ассиметричной криптографии. Когда сессия установлена, данные быстро шифруются симметричным ключём, полученным при установлении сессии.
                                                                      0
                                                                      Кто-то пробовал ставить по этой инструкции knot-resolver на Mojave?
                                                                      Была ли у вас такая ошибка?

                                                                      cat  /usr/local/var/log/kresd.log
                                                                      [system] error ...cal/Cellar/knot-resolver/3.0.0/lib/kdns_modules/kres.lua:11: dlopen(libknot.8.dylib, 5): image not found
                                                                        +1
                                                                        У меня Mojave, работает без проблем. Покажите конфиг knot-resolver и еще это:

                                                                        ls -la /usr/local//lib/libknot.8.dylib
                                                                        ls -la /usr/local//Cellar/knot-resolver/3.0.0/lib/kdns_modules/
                                                                          0
                                                                          ls -la
                                                                          ls -la /usr/local/Cellar/knot-resolver/3.0.0/lib/kdns_modules/
                                                                          total 712
                                                                          drwxr-xr-x  33 int03e  staff   1056 Oct 25 14:57 .
                                                                          drwxr-xr-x   6 int03e  staff    192 Aug 20 11:20 ..
                                                                          -r--r--r--   1 int03e  staff  31760 Oct 25 14:57 ahocorasick.dylib
                                                                          -r--r--r--   1 int03e  staff  17104 Oct 25 14:57 bogus_log.dylib
                                                                          drwxr-xr-x   3 int03e  staff     96 Aug 20 11:20 daf
                                                                          -r--r--r--   1 int03e  staff   8627 Aug 20 11:20 daf.lua
                                                                          -r--r--r--   1 int03e  staff   1240 Aug 20 11:20 detect_time_jump.lua
                                                                          -r--r--r--   1 int03e  staff   2329 Aug 20 11:20 detect_time_skew.lua
                                                                          -r--r--r--   1 int03e  staff   3552 Aug 20 11:20 dns64.lua
                                                                          -r--r--r--   1 int03e  staff  39820 Oct 25 14:57 dnstap.dylib
                                                                          -r--r--r--   1 int03e  staff   1212 Aug 20 11:20 etcd.lua
                                                                          -r--r--r--   1 int03e  staff   3199 Aug 20 11:20 graphite.lua
                                                                          -r--r--r--   1 int03e  staff  39860 Oct 25 14:57 hints.dylib
                                                                          drwxr-xr-x  21 int03e  staff    672 Aug 20 11:20 http
                                                                          -r--r--r--   1 int03e  staff  11169 Aug 20 11:20 http.lua
                                                                          -r--r--r--   1 int03e  staff   3015 Aug 20 11:20 http_trace.lua
                                                                          -r--r--r--   1 int03e  staff  12191 Aug 20 11:20 kres-gen.lua
                                                                          -r--r--r--   1 int03e  staff  26898 Aug 20 11:20 kres.lua
                                                                          -r--r--r--   1 int03e  staff  21422 Aug 20 11:20 policy.lua
                                                                          -r--r--r--   1 int03e  staff   5369 Aug 20 11:20 predict.lua
                                                                          -r--r--r--   1 int03e  staff   5780 Aug 20 11:20 prefill.lua
                                                                          -r--r--r--   1 int03e  staff   4236 Aug 20 11:20 priming.lua
                                                                          -r--r--r--   1 int03e  staff   4588 Aug 20 11:20 prometheus.lua
                                                                          -r--r--r--   1 int03e  staff   3357 Aug 20 11:20 rebinding.lua
                                                                          -r--r--r--   1 int03e  staff   3671 Aug 20 11:20 renumber.lua
                                                                          -r--r--r--   1 int03e  staff   1191 Aug 20 11:20 serve_stale.lua
                                                                          -r--r--r--   1 int03e  staff  32728 Oct 25 14:57 stats.dylib
                                                                          -r--r--r--   1 int03e  staff   2515 Aug 20 11:20 ta_sentinel.lua
                                                                          -r--r--r--   1 int03e  staff   1818 Aug 20 11:20 ta_signal_query.lua
                                                                          -r--r--r--   1 int03e  staff  15721 Oct 25 14:57 trust_anchors.lua
                                                                          -r--r--r--   1 int03e  staff   2737 Aug 20 11:20 view.lua
                                                                          -r--r--r--   1 int03e  staff   1658 Aug 20 11:20 workarounds.lua
                                                                          -r--r--r--   1 int03e  staff   2405 Aug 20 11:20 zonefile.lua
                                                                          
                                                                          ls -la /usr/local/lib/libknot.8.dylib
                                                                          ls: /usr/local/lib/libknot.8.dylib: No such file or directory
                                                                          


                                                                          Конфиг 1:1 как у вас. Странно, что не находит libknot.8.dylib…
                                                                            +1
                                                                            Листинг лучше спрятать под спойлер. У вас наверное не установлен knot, хотя он должен был подтянуться в зависимостях. Установите его вручную:

                                                                            brew install knot 
                                                                              0
                                                                              Проблема с knot немного в другом, как оказывается:
                                                                              brew install knot
                                                                              brew install knot
                                                                              Warning: knot 2.7.2 is already installed, it's just not linked
                                                                              You can use `brew link knot` to link this version.
                                                                              ➜  sapience git:(development) brew link knot
                                                                              Linking /usr/local/Cellar/knot/2.7.2...
                                                                              Error: Could not symlink sbin/keymgr
                                                                              /usr/local/sbin is not writable.


                                                                              Теперь понятно куда копать, спасибо.
                                                                                0

                                                                                https://docs.brew.sh/Troubleshooting


                                                                                If commands fail with permissions errors, check the permissions of /usr/local’s subdirectories. If you’re unsure what to do, you can run
                                                                                cd /usr/local && sudo chown -R $(whoami) bin etc include lib sbin share var opt Cellar Caskroom Frameworks.

                                                                                После этого всё ещё может не завестись. Пришлось сделать реинсталл, после стопнуть и запустить сервис заново (рестарт не помогал). Может быть реинсталл лишний.

                                                                        +1
                                                                        для настройки DoH в Android 9 нужно указать один домен через которых произойдет автоконфигурация. В случае с cloudflare это домен 1dot1dot1dot1.cloudflare-dns.com.

                                                                        Судя по всему это домен у которого оба резолвера указаны в A и AAAA записях соответственно:
                                                                        1dot1dot1dot1.cloudflare-dns.com. 253 IN A 1.0.0.1
                                                                        1dot1dot1dot1.cloudflare-dns.com. 253 IN A 1.1.1.1
                                                                        1dot1dot1dot1.cloudflare-dns.com. 253 IN AAAA 2606:4700:4700::1001
                                                                        1dot1dot1dot1.cloudflare-dns.com. 253 IN AAAA 2606:4700:4700::1111
                                                                        


                                                                        А есть ли такой же домен для гугл dns?
                                                                          0
                                                                          Я нашел домен для гугла в сертификате: dns.google
                                                                          У него так же как и cloudflare сделано:

                                                                          $ dig A dns.google
                                                                          ;; ANSWER SECTION:
                                                                          dns.google.		825	IN	A	8.8.4.4
                                                                          dns.google.		825	IN	A	8.8.8.8
                                                                          
                                                                          $ dig AAAA dns.google
                                                                          ;; ANSWER SECTION:
                                                                          dns.google.		808	IN	AAAA	2001:4860:4860::8844
                                                                          dns.google.		808	IN	AAAA	2001:4860:4860::8888
                                                                          0
                                                                          На OSX mojave спустя разные интервалы времени 1-4 часа сервис падает с сообщением в логе

                                                                          Assertion failed: (map_contains(&worker->tcp_connected, key) == 0), function worker_add_tcp_connected, file daemon/worker.c, line 1997.

                                                                          После падения соответственно DNS перестаёт работать до перезапуска вручную sudo brew services restart knot-resolver. Можно ли как-то настроить автоматический моментальный перезапуск при падении?
                                                                            0
                                                                            Если не сложно, то можете попробовать другой вариант.
                                                                            Я для себя писал подобный прокси простенький на базе либы «miekg/dns», специально для DNS-over-TLS и DNS-over-HTTPS и максимально простым конфигом, локально у меня нормально работает. Вот исходники, он на Go, так что соберется и под Мак — github.com/Onlinehead/dns-to-dns-tls
                                                                            Plst для автозапуска правда не делал, потому что у меня в контейнере живет на сервачке.
                                                                            Правки приветствуются.
                                                                              0
                                                                              Во первых создайте репорт об этой проблеме в багтрекере gitlab.labs.nic.cz/knot/knot-resolver/issues (можно войти с аккаунтом github)

                                                                              Вот измененный конфиг launchd который будет перезапускать knot в случае падения
                                                                              /Library/LaunchDaemons/homebrew.mxcl.knot-resolver.plist
                                                                              <?xml version="1.0" encoding="UTF-8"?>
                                                                              <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
                                                                              <plist version="1.0">
                                                                              <dict>
                                                                              	<key>KeepAlive</key>
                                                                              	<true/>
                                                                              	<key>Label</key>
                                                                              	<string>homebrew.mxcl.knot-resolver</string>
                                                                              	<key>ProgramArguments</key>
                                                                              	<array>
                                                                              		<string>/usr/local/Cellar/knot-resolver/3.0.0/sbin/kresd</string>
                                                                              		<string>-c</string>
                                                                              		<string>/usr/local/etc/kresd/config</string>
                                                                              	</array>
                                                                              	<key>RunAtLoad</key>
                                                                              	<true/>
                                                                              	<key>StandardErrorPath</key>
                                                                              	<string>/usr/local/var/log/kresd.log</string>
                                                                              	<key>StandardInPath</key>
                                                                              	<string>/dev/null</string>
                                                                              	<key>StandardOutPath</key>
                                                                              	<string>/dev/null</string>
                                                                              	<key>WorkingDirectory</key>
                                                                              	<string>/usr/local/var/kresd</string>
                                                                              </dict>
                                                                              </plist>


                                                                                0
                                                                                спасибо
                                                                                0
                                                                                Столкнулся с аналогичной проблемой, периодически после выхода мака из сна сервис падал с сообщением в логе:

                                                                                Assertion failed: (map_contains(&worker->tcp_connected, key) == 0), function worker_add_tcp_connected, file daemon/worker.c, line 1997.

                                                                                DNS перестает работать, sudo brew services restart knot-resolver не помогает, спасает перезагрузка мака.

                                                                                Создал соответствующий багрепорт: gitlab.labs.nic.cz/knot/knot-resolver/issues/416. Разработчики говорят, что в версии 3.1.0 пофиксили ряд багов, связанных с подобного рода проблемами.
                                                                                –1
                                                                                Ради минимальных приличий хоть напишите, что грязными лапами в список посещённых доменов после этого будут лезть Google и Cloudflare, и что это всё делается не ради помощи бедным пользователям и их безопасности, а для борьбы с конкурентами, получающими поведенческие данные в тех точках, куда указанным компаниям не дотянуться.
                                                                                  +1
                                                                                  Гугл и cloudflare по крайней мере не были замечены в инъекциях рекламы в HTTP трафик и модификации моих сайтов. В отличии от мегафона и билайна.

                                                                                  Вообще я сомневаюсь что данные о резолвах открывают такое больше поле для аналитики. При обычном серфинге, вы, скорее всего, зарезолвите все те же ресурсы, что и при целевом посещении. Условно говоря, при поиске товаров для животных вы так или иначе зарезолвите vk.com, youtube.com, google.com и еще кучу доменов. Как из этого можно сделать поведенческий профиль? Резолв не дает так много информации, как например, трекеры на сайтах. Так что полагаю, что скорее всего, эти сервисы сделаны больше для того, чтобы доставлять свою рекламу в неизменном виде, чтобы по пути ее не резали блокировщиками и не подменяли на другую, а не столько для трекинга пользователей.
                                                                                    0
                                                                                    Никого ничему история не учит: вы сейчас доказываете, что Microsoft большой (больше всех!), и что предложение добавить в веб OLE с внешним исполнимым кодом взлетит, «потому что это Microsoft, а не какая-то местная конторка».

                                                                                    Вы сомневаетесь, а они не сомневаются. Это не благотворительные организации; то, что не приносит дохода, закрывается. Запросы к DNS дают не просто список доменов, а список доменов с точным временем перехода к ним — это и круглосуточный портрет пользователя, и статистика для всех сайтов (даже не имеющих ни одного трекера, даже при использовании блокировщика ни клиенте), и возможность легко объединить посещения конкретного пользователя со статистикой GA по нему. Cloudflare не сомневается, что халявный трафик через их сервера для любого желающего приносит прибыль, а не одни лишь убытки. Подрезали Google крылышки GDPR — встроенные карты тут же стали платными, потому что контент жирный, а сбор с него информации впрок теперь запрещён. Сравните старые и новые цены за доступ к технологии, чтобы прикинуть, во сколько это обходится.

                                                                                    Мы имеем то, что имеем, не в результате того, что кто-то пришёл с ружьём и всех заставил, а в результате множества таких вот компромиссов, но даже предложение признать проблему — не говоря уж об отказе от использования — встречается с недоумением. С таким вот диджитал резистанс все причастные могут спать спокойно.
                                                                                      +2
                                                                                      А вы не думали, что Google собирает данные просто для ранжирования сайтов в выдаче?
                                                                                      Это их основной продукт.

                                                                                      В любом случае, какой бы DNS вы ни использовали, данные будут кому-то утекать. Что ж, теперь, вообще Интернетом не пользоваться?
                                                                                        0
                                                                                        «В какой бы магазин вы ни пошли купить мяса, вам в итоге навалят обрезков, костей, грязных тряпок, и ещё под зад пнут ногой».

                                                                                        Не очень привычная логика, не находите?
                                                                                          +1
                                                                                          Я давно пропагандирую среди знакомых ставить локально или в приватной сети резолвер, который ходит прямо в рутовые сервера. unbound без форвардинга например, заодно и свою зону можно завести. Он даже биндовые файлы зон умеет.

                                                                                          Рутовые сервера пропускают через себя слишком обезличенный и огромный поток, и контролируются хотя бы не корпорацией напрямую.

                                                                                          Если кто боится, что это нагрузит рутовые сервера днс — смешно. Запас мощности там на несколько порядков.
                                                                                    0
                                                                                    Это отличная новость!
                                                                                    К примеру, ростелеком гарантированно меняет содержимое перенаправляя на рекламу своих пакетов. Техподдержка говорит, что РТ так доносит предложения, но на письмо на каком основании нет, они такой фигней не занимаются.
                                                                                      +2
                                                                                      Проверьтесь на вирусы/используйте другой компьютер. Есть небольшой шанс что они не врут. AdwCleaner может помочь. У меня такая фигня както раз была, большинство антивирусов ничего не находят, тк реклама по их мнению не вирус, а нежелательное по.
                                                                                        +3
                                                                                        На мой запрос по какой причине производится замена результата пришел ответ с адреса no-reply@rt.ru:
                                                                                        Уважаемый абонент, Ваша претензия № 47511808 рассмотрена По фактам, указанным в Вашем обращении, проведена проверка. Редирект произведен с сайта store.steampowered.com. Это могло произойти как как на стороне сервера, так и на стороне клиента (в браузере). Средствами АСР Ростелеком редирект не производится.

                                                                                        Есть нюансы:
                                                                                        1 — Все, что происходит в системе я знаю, никаких сюрпризов нет и AdwCleaner у меня запустится только в виртуалке или под вайном. Ну не использую я винду и хорошо знаю что у меня в лялихе крутится.
                                                                                        2 — ТП в РТ сообщал о том, что это способ донести предложение. Цитирую: «Ростелеком старается предоставлять различным способами, включая показ при открытии сайтов. Очень жаль, если данный вариант Вас огорчил.» Но в письме с no-reply@rt.ru «Средствами АСР Ростелеком редирект не производится.»
                                                                                        3 — Редирект произошел после того, как я руками вбил в адресную строку store.steampowered.com (то есть не переход по ссылке) и открылась реклама тарифа РТ с каким-то аккаунтом танков и с доп танками.

                                                                                        В сухом остатке: видя, что я хочу перейти на игровой портал мне предлагают игровой тариф и говорят, что это не они устраивают MITM, а валв переводит трафик к своим конкурентам в надежде снизить посещаемость и продажи.
                                                                                        Простите, но это смешно.
                                                                                      0
                                                                                      Ждём гайда по настройке этого в OpenWRT.
                                                                                        0
                                                                                        blog.cloudflare.com/dns-over-tls-for-openwrt

                                                                                        Сам не пробовал.
                                                                                          0
                                                                                          Это старое руководство для старой версии unbound (<1.6.1), которая не валидирует SAN сертификата. В таком виде DoT бесполезен. Вот статья, освещающая проблему и предоставляющая правильную конфигурацию.
                                                                                        0
                                                                                        А как теперь будут работать CDNы, локальные копии и тому подобное?
                                                                                          –2
                                                                                          Посоветовал бы не пускать все DNS по крипте, а оставить какие-то открытыми. Пользователь без DNS запросов привлекает повышенное внимание.
                                                                                            +1
                                                                                            Ох как бы не вызвать подозрений.
                                                                                              +2
                                                                                              Хотите сказать, что к вам приедут с обыском и конфискацией оборудования, потому что у вас нет DNS запросов?
                                                                                              0
                                                                                              Что мешает провайдеру заблокировать все исходящие запросы на 853 порт?
                                                                                              Тем самым вынудить всех использовать стандартный, легко модифицируемый протокол по 53 порту.
                                                                                                0
                                                                                                Теоретически ничто не мешает. Но это уже проблема сетевого нейтралитета. Если его у нас узаконят, то будет закон, который и будет мешать. С другой стороны, ничто не мешает ввести закон, запрещающий порт 853 в принципе, или любой другой бредовый закон. С фантазией в нашей стране проблем нет, так что законы всё «лучше» и «лучше».
                                                                                                  +1
                                                                                                  Тогда будем использовать DNS over HTTPS. Его будет крайне сложно запретить не сломав при этом интернет целиком.
                                                                                                  0
                                                                                                  DoH ломает концепцию, что DNS является «Control Plane» Интернет. Внезапно DNS оказывается на «Data Plane». Это не мои слова, это Paul Vixie.
                                                                                                  Скорости работы ни от DoT ни от DoH ждать не приходится.

                                                                                                  По скорости, среднем в РФ у провайдеров DNS сервера медленнее гуглового сервиса, иногда в разы.
                                                                                                  За исключением Ростелекома Северо-Западного макро филиала, DNS сервера которого работают быстрее чем Google Public DNS уже несколько лет.
                                                                                                    +1
                                                                                                    На счет медленнее гуглового.
                                                                                                    1. Dnscrypt можно было запускать как два сервиса на разных портах и разный сервер, а при связке с Dnsmasq можно было давать команду «all-servers» и в «server» указывать данную пару. В итоге получалось что запрос от dnamasq уходил по двум направлениям Dnscrypt с разными серверами, который ответ быстрей приходил тот и активный в итоге.
                                                                                                    2. Dnscrypt 2 уже использует алгоритм определения быстрого сервера из заданного списка «server_names». Определяет «Server with the lowest initial latency» и берет самый наименьший.
                                                                                                    При использовании
                                                                                                    server_names = ['cloudflare', '...1', '...2', '...3']
                                                                                                    ...
                                                                                                    # Use servers implementing the DNSCrypt protocol
                                                                                                    dnscrypt_servers = true
                                                                                                    # Use servers implementing the DNS-over-HTTPS protocol
                                                                                                    doh_servers = true
                                                                                                    ....
                                                                                                    [static.'cloudflare']
                                                                                                    #Cloudflare DNS (anycast) - aka 1.1.1.1 / 1.0.0.1
                                                                                                    stamp = 'sdns://AgcAAAA...........................bnMtcXVlcnk'


                                                                                                    Данный сервер «cloudflare» ни когда не попадает в «latency» меньше чем у трех серверов ...1,...2,...3 у которых значение по логу dnscrypt от «rtt:17-40ms».

                                                                                                    [2018-10-25 12:29:03] [NOTICE] [cloudflare] OK (DoH) - rtt: 50ms

                                                                                                    Хоть и собран dnscrypt 2 на GO и в итоге
                                                                                                    Name: dnscrypt-proxy
                                                                                                    ...
                                                                                                    VmPeak: 671020 kB
                                                                                                    VmSize: 671020 kB
                                                                                                    VmLck: 0 kB
                                                                                                    VmPin: 0 kB
                                                                                                    VmHWM: 12280 kB
                                                                                                    VmRSS: 9312 kB
                                                                                                    VmData: 662296 kB
                                                                                                    VmStk: 136 kB
                                                                                                    VmExe: 4372 kB
                                                                                                    VmLib: 0 kB
                                                                                                    VmPTE: 32 kB
                                                                                                    VmSwap: 0 kB
                                                                                                    Threads: 11

                                                                                                    При размере исходника на тек.момент - 8 885 824 байт

                                                                                                    PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
                                                                                                    ....
                                                                                                    974 root 20 0 655M 9288 5076 S 0.7 7.4 1:44.62 dnscrypt-proxy
                                                                                                    662 root 20 0 655M 9288 5076 S 0.7 7.4 11:45.45 dnscrypt-proxy
                                                                                                    ....


                                                                                                    3. Быстродействие того или иного сервера DNS лучше оценить например такой старенькой программкой DNSBench.
                                                                                                    0
                                                                                                    А что со скоростью резолва, собственно? Сколько раньше ни попробовал, меньше 500-700ms на холодную не получалось добиться. А это совсем не юзабельно. Может, не так что-то делал? Накручивал всякие fast open, keepalive, etc. Бестолку.
                                                                                                    При том, что чистый днс ходит на гугл за 10-15мс.
                                                                                                      0
                                                                                                      Здорово, спасибо. Грешным делом подумал, что это поможет заходить на заблокированные сайты, установил и вспомнил, что блокад по айпи) Кстати, после установки сломался xcodebuild, исправил с помощью sudo xcode-select -s /Applications/Xcode.app/Contents/Developer.
                                                                                                        –2
                                                                                                        Только в отличие от 1.1.1.1 у 8.8.8.8 нет сертификата на 8.8.8.8. Но забавно. Судя по всему там и DoH есть
                                                                                                          +1
                                                                                                          Всё там есть. И сертификат даже IPv6-адреса покрывает. DoH они уже давно запустили, вроде даже первыми.
                                                                                                            +1
                                                                                                            А, точно, лоханул. Я на 443 посмотрел. Там — нет. DoH они запустили, но не на 8.8.8.8
                                                                                                            +1
                                                                                                            Только в отличие от 1.1.1.1 у 8.8.8.8 нет сертификата на 8.8.8.8.

                                                                                                            Вы ошибаетесь, сертификат у них есть на все IP, в том числе и ipv6. Это можно проверить так:
                                                                                                            Раскрыть спойлер
                                                                                                            Получить x509 сертификат подключившись к порту 853:
                                                                                                            openssl s_client -connect 8.8.8.8:853


                                                                                                            Берем сертификат
                                                                                                            -----BEGIN CERTIFICATE-----
                                                                                                            MIIE2zCCA8OgAwIBAgIICRK9jQnza7EwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UE
                                                                                                            BhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczElMCMGA1UEAxMc
                                                                                                            R29vZ2xlIEludGVybmV0IEF1dGhvcml0eSBHMzAeFw0xODEwMDkxMzA5MjdaFw0x
                                                                                                            OTAxMDExMzA5MDBaMGQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
                                                                                                            MRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKDApHb29nbGUgTExDMRMw
                                                                                                            EQYDVQQDDApkbnMuZ29vZ2xlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
                                                                                                            AQEAsht4BBijm9L90m0idDzIiJvRyYWx5a8RE9NgHzA0NyJs+YKF1corJ9dC16qC
                                                                                                            eVZ5QBm543PYMQOYZzW8vfecJddO12cohE7nIvKT5ayOUZiVZs1fQVaSrIvt0Dt/
                                                                                                            KbORYkaPihqNcqtOewYSowQJTzJAo4jx5oPxD3i980vlo5eDG0lTSecKBm2oo/2R
                                                                                                            vqW7Y2PfChKkYRBwfgyEPZxWhe762ra6sC7MrVJRzkmrdTSIH5XFEWVj/g3WHY+6
                                                                                                            kzqtRVTeAf2VlYsOrBuvoWc0bVtXfx/XdsZHVufGdk+BeO1QF9GgUctP5hxq6gPC
                                                                                                            8599GlI/P+y+tapLhgVBoplncQIDAQABo4IBnzCCAZswEwYDVR0lBAwwCgYIKwYB
                                                                                                            BQUHAwEwdgYDVR0RBG8wbYIKZG5zLmdvb2dsZYcQIAFIYEhgAAAAAAAAAAAAZIcQ
                                                                                                            IAFIYEhgAAAAAAAAAABkZIcQIAFIYEhgAAAAAAAAAACIRIcQIAFIYEhgAAAAAAAA
                                                                                                            AACIiIcECAgEBIcECAgICIILODg4OC5nb29nbGUwaAYIKwYBBQUHAQEEXDBaMC0G
                                                                                                            CCsGAQUFBzAChiFodHRwOi8vcGtpLmdvb2cvZ3NyMi9HVFNHSUFHMy5jcnQwKQYI
                                                                                                            KwYBBQUHMAGGHWh0dHA6Ly9vY3NwLnBraS5nb29nL0dUU0dJQUczMB0GA1UdDgQW
                                                                                                            BBT89DCv+M274s12jvrQIdgouMRHXjAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaA
                                                                                                            FHfCuFCaZ3Z2sS3ChtCDoH6mfrpLMCEGA1UdIAQaMBgwDAYKKwYBBAHWeQIFAzAI
                                                                                                            BgZngQwBAgIwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC5wa2kuZ29vZy9H
                                                                                                            VFNHSUFHMy5jcmwwDQYJKoZIhvcNAQELBQADggEBABJxRYN15J4Gt2sQHx7VhAE5
                                                                                                            kQShFo388NPFg5mHqA+cohOGcB38ODyLl1U8K5mj9zQWpDKGNVtusYn+X4PG/oNO
                                                                                                            e98fXjk/qaYUHO++m+7iDKsvaFzKYjRV8YsVTop0WIWPNQUFVx+m5RapIWfQixlK
                                                                                                            xquR94U5Zoma1IiXz4agBUbcGZ9E56S/vWL5DjSKvO3RyoLlNOaqqO6igCuZyhkV
                                                                                                            m60kh0LXoLWsQh9Da4Jclm7xN0DKDkeQk3KbnGhBN+GSg3thWm0JUjqwU9g0Qhm2
                                                                                                            9pDrQ8otjX02mhnOCf60l9OKkG+TRzhlenhPtkt5v0YmW3XDr4qKD+0Yj+5W2lk=
                                                                                                            -----END CERTIFICATE-----
                                                                                                            


                                                                                                            И смотрим SAN:
                                                                                                            openssl x509 -noout -text -in cert.pem | grep DNS
                                                                                                            
                                                                                                            DNS:dns.google, IP Address:2001:4860:4860:0:0:0:0:64, IP Address:2001:4860:4860:0:0:0:0:6464, IP Address:2001:4860:4860:0:0:0:0:8844, IP Address:2001:4860:4860:0:0:0:0:8888, IP Address:8.8.4.4, IP Address:8.8.8.8, DNS:8888.google
                                                                                                            



                                                                                                            Судя по всему там и DoH есть

                                                                                                            Да, об этом написано в первой строчке поста.
                                                                                                              0
                                                                                                              Да, сертификат я на 443 смотрел. Там — нет. В первой строчке чушь написана. Это не про 8.8.8.8. И кстати по ссылке посмотрите, что у гугля написано. Я даже каментом ниже упомянул это.
                                                                                                                +1
                                                                                                                То, что dns.google.com не резолвится на 8.8.8.8 вовсе не значит, что он не является от этого сервисом под названием Google Public DNS.
                                                                                                                  0
                                                                                                                  Это я и не оспариваю. Но это не восьмёрки. Не знаю насчёт кто первый анонсировал, разработчик драфта — Мозилла. А гугл как-то долго ваньку валял. И у них этот их JSON-API… Вы ссылку правильную по которой к DoH обращаться у Google ещё найдите. Я не смог
                                                                                                            0
                                                                                                            И очень странный обзор технологий. DNSCrypt это адаптация DNSCurve, сделанная opendns для ресолверов. А DNSCurve это детище Даниэля Бернштейна, которому не нравился DNSSEC, но зато он разработал Ecliptic Curves. Т.е. это вообще ни разу не тестирование перед DoH. Кстати, DoH бывают два :) Один который DoH, а другой — JSON API Google. И да, Google поддерживает оба
                                                                                                              +1
                                                                                                              Возможно это прозвучит странно, но есть серьезные сомнения в квалификации сотрудников Google, которые занимаются Google Public DNS. Яркий пример — они делали общий, разделяемый несколькими нодами кеш для разных инстансов сервиса. При том, что при их (большой) нагрузке это не могло привести к улучшению наполненности и актуальности кеша, если каждый инстанс обслуживает от 50,000 QPS и выше. Давление на кеш при такой нагрузке уже нормальное и он вполне себе наполнен актуальной информацией. Выигрыша от разделяемого кеша DNS между нодами в таком случае нет совсем или, даже если он и есть, то мизерный и смысла бороться за него серьезным увеличением сложности не стоило.
                                                                                                              Теперь DoH, который ну совсем никак ни про производительность, ни про задержки, а только слом концепции, что DNS это «Control Plane» Интернет.
                                                                                                                +1
                                                                                                                DoH это не гуглевская тема. Да, на сегодняшнем уровне развития и серверного оборудования, и каналов — проблема «Control Plane» Интернет стала более актуальной. Правда, у Google действительно странный подход к DNS. Они например придумали DANE и сами же его убили и лет пять потом не проявляли интереса вообще к DNSSEC
                                                                                                                  0
                                                                                                                  И правильно делают, этому протоколу суждено скончаться, не увидев массового внедрения. Все причины, почему ему не (стоит) жить, изложены во множестве статей — не буду приводить ссылки. Однако приведу одну другую, на блог APNIC, где можно найти интересное предложение как DoT может заменить DNSSEC, если будет использоваться ещё и между рекурсорами и авторитативными серверами. Как по мне, то у такой схемы гораздо больше шансов случиться.
                                                                                                                    0
                                                                                                                    www.slideshare.net/schors/a-popular-dns-security-overview-modern-theory-and-practice-116166410
                                                                                                                    Я тут вкратце, но объясняю проблемы DNSCurve. С DoT будет примерно так же. Плюс DNSSEC изначально незвисимая от SSL PKI тема, как независимая дублирующая в чем-то. У DNSSEC конечно тоже пачка своих проблем, но всё же.

                                                                                                                    изложены во множестве статей


                                                                                                                    Да уж давайте. Большинство этих статей или уже неактульны, или нытьё.
                                                                                                                      0
                                                                                                                      В вашем случае далеко ходить не нужно:
                                                                                                                      Нигде нет DNSSEC. Значит, так он важен для всех.

                                                                                                                      Плюс DNSSEC изначально незвисимая от SSL PKI тема, как независимая дублирующая в чем-то.

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

                                                                                                                      Одна из статей, которую смог найти и она заслуживает внимания.

                                                                                                                      Из личных впечатлений — для того, чтобы иметь гарантии, которые DNSSEC должен предоставлять, я должен держать непосредственно на моём устройстве валидирующий dnssec резолвер. Я обхожусь на ноутбуке dnssec-trigger и unbound на ноутбуке, однако это дно и это нужно сжечь огнём. Проблема с NSEC и NSEC3 действительно актуальна, и пока кое-какое костыльное решение смогли предоставить только Cloudflare в своей реализации DNSSEC. И то, ценой того, что авторитативный сервер всё же имеет доступ к ключам для подписи.

                                                                                                                      Сегодня DNSSEC, как и IPv6 — игрушки для гиков, реальный бизнес от них не зависит.
                                                                                                                        0
                                                                                                                        Нигде нет DNSSEC. Значит, так он важен для всех.

                                                                                                                        У меня! У меня есть! zhovner.com
                                                                                                                        Хотя согласен, особой пользы от него нет.
                                                                                                                          0
                                                                                                                          У меня тоже, на vm-0.com. И мы с тобой оба гики. Это что же получается…

                                                                                                                          Я только ради SMTP DANE сделал. Это всё-таки кое-где да поддерживается. Ну и SSHFP и OPENPGPKEY — приятности.
                                                                                                                            0
                                                                                                                            Угу. Кстати да, я в докладе упомянул SMTP, где шифрование, и DANE тоже мало полезны :) SMTP в протоколе не умеет проверять сертификат. Не с чем сравнивать
                                                                                                                          0
                                                                                                                          usher2.club
                                                                                                                          Нигде нет DNSSEC. Значит, так он важен для всех.


                                                                                                                          Точно нет?

                                                                                                                          Подконтрольная одному государству


                                                                                                                          Интернет вообще подконтролен так или иначе этому одному государству. Система PKI тоже.И даже в первую очередь. Да, кейс с DS конечно несколько облегчает задачу. Но напомните мне кейсы такого? Кстати, а современные УЦ вызывают доверие? Это после целого ряда скандалов за буквально пару лет?

                                                                                                                          Одна из статей, которую смог найти и она заслуживает внимания.


                                                                                                                          Набор неинженерного нытья и голословных утверждений на основании «очевидно». Единственное, что там правда — сложность DNSSEC.

                                                                                                                          для того, чтобы иметь гарантии, которые DNSSEC должен предоставлять, я должен держать непосредственно на моём устройстве валидирующий dnssec резолвер.


                                                                                                                          Тренд сейчас вообще проверять на софтине. Для пассивного использования достаточно комбинировать с удаленным ресолвером, который сам валидирует. Например, через DoT и DoH

                                                                                                                          Проблема с NSEC и NSEC3 действительно актуальна,


                                                                                                                          Есть такое. Причем всегда будет. Нет хорошего способа решения подписи отрицательного ответа.

                                                                                                                          «Костыльное» решение Cloudflare покрывается RFC 4470 и 4471. Ну почти. «Чёрной лжи» в RFC вроде нету. Реализация «чёрной лжи» кроме Cloudflare есть
                                                                                                                          у серверов CoreDNS и KNOT. А вот с доступом к ключам тут сложно. Оверинжиниринг на мой взгляд. У сайтов к своим ключам тоже доступ есть. Да, это действительно немнго уменьшает секьюрность. Но всё-таки.

                                                                                                                          Сегодня DNSSEC, как и IPv6 — игрушки для гиков, реальный бизнес от них не зависит.


                                                                                                                          Хорошо, поговорите об этом с Cloudflare например. Сразу перед беседой EBITDA'у свою достаньте, чтобы ваш разговор так скажем был на одном уровне :)

                                                                                                                          Я собственно не то чтобы прямо хотел с кем-то поругаться или там осквернить :) Но вот это «это сложно», «это никому не нужно»… Да это просто что-то новое и интересно :)) Этого достаточно, чтобы прекращать ныть и искать решения. Как вот делает Cloudflare и CZ.NIC например.
                                                                                                                            +1
                                                                                                                            Точно нет?

                                                                                                                            Да, на одном есть — проморгал.
                                                                                                                            Но напомните мне кейсы такого?
                                                                                                                            Кейсы внедрения самого DNSSEC не так часты, а уж тем более завязывания сертификатов на него. Провинившийся PKI CA можно легко выкинуть из хранилища доверенных корневых сертов. Тут либо небольшое преимущество обычного PKI, либо паритет — понять пока трудно, цепь доверия DNSSEC в дикой природе используется не так давно, не так активно.
                                                                                                                            Набор неинженерного нытья и голословных утверждений на основании «очевидно».
                                                                                                                            Навешивание ярлыков, которое применимо и к вашим высказываниям.
                                                                                                                            Тренд сейчас вообще проверять на софтине. Для пассивного использования достаточно комбинировать с удаленным ресолвером, который сам валидирует. Например, через DoT и DoH
                                                                                                                            Про тренд — сильное утверждение, проверять я его конечно не буду. Про комбинацию с DoT, DoH — вот и получается, что технология сама даже со своей функцией не справляется. На этом фоне решение использовать DoT между резолвером и авторитативным сервером выглядит гораздо привлекательнее, DNSSEC опять лишний выходит. Как правильно замечено в той статье, DNSSEC не обязан случиться. Если бы в него кто-то верил, стандарт MTA-STS не появился бы. Его бросили все крупные компании и авторы стандартов, увы.

                                                                                                                            Хорошо, поговорите об этом с Cloudflare например. Сразу перед беседой EBITDA'у свою достаньте, чтобы ваш разговор так скажем был на одном уровне :)
                                                                                                                            Демагогический приём «сперва добейся». Бизнес Cloudflare никак не поменяется от отсутствия DNSSEC. И IPv6 у них тоже постольку-поскольку всё должно быть. Вернёмся за примером к двум сайтам вначале моего предыдущего сообщения: у одного нет IPv6, у другого нет DNSSEC, и никакой пользы нет, если они появятся.

                                                                                                                            А вот с доступом к ключам тут сложно. Оверинжиниринг на мой взгляд. У сайтов к своим ключам тоже доступ есть. Да, это действительно немнго уменьшает секьюрность. Но всё-таки.

                                                                                                                            Я согласен. Я считаю, кто прям сильно хочет — пусть ключ свой на HSM выносит.
                                                                                                                0
                                                                                                                На самом деле интересно что будет дальше…
                                                                                                                Предположим, что Google включил DoT и DoH у себя на серверах. Означает ли это, что в обозримом будущем все Андроид-устройства перейдут на DoT/DoH? Если Да, то какие сервера они для этого будут использовать? Если Google выберет для этого свои сервера, то им придется чуток их «расширить и углубить». DNS трафика от мобильных абонентов реально много и сейчас только несколько процентов из них идут не на резолверы оператора, а на те же 8.8.8.8/8.8.4.4. Или предполагается, что операторы будут поднимать на своих резолверах DoT/DoH?
                                                                                                                Еще интересно что по этому поводу думает Apple и Microsoft?
                                                                                                                  0
                                                                                                                  В 9-ом Андроиде уже
                                                                                                                    0
                                                                                                                    Что уже? Он уже ходит на сервера Google?
                                                                                                                      0
                                                                                                                      Он уже DoH из коробки
                                                                                                                        0
                                                                                                                        Вопрос не в том что у него «из коробки», а какие резолверы он использует и можно ли это поменять? Оператором это может облегчить жизнь как минимум тем, что не нужно будет расширять резолверы. А вот если адреса нельзя поменять, то Google может нарваться на иск от того же Yandex, что нельзя использовать «Семейный DNS».
                                                                                                                          0
                                                                                                                          Может нарваться. Но снйчас одни хрен нельзя использовать этот семейный DNS :)))
                                                                                                                  0
                                                                                                                  Если что-то пошло не так, смотрим лог ошибок

                                                                                                                  Что-то не рабочий этот конфиг, так и не понял почему лыжи не едут. Гугление не даёт вменяемых результатов, knot из Ubuntu 16.04

                                                                                                                  Started Knot DNS Resolver.
                                                                                                                  [ ta ] warning: root anchor bootstrapped, you SHOULD check the key manually, see: https://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.html#sigs
                                                                                                                  [hint] reading '/etc/hosts'
                                                                                                                  [hint] loaded 8 hints
                                                                                                                  config:31: attempt to call field 'TLS_FORWARD' (a nil value)
                                                                                                                  knot-resolver.service: Main process exited, code=exited, status=1/FAILURE
                                                                                                                    0
                                                                                                                    Что-то не рабочий этот конфиг

                                                                                                                    В репозитория ubuntu 16 версия knot 1.0.0, а в brew весрия 3.0.0. Так что ваш knot еще не знает о таких опциях.
                                                                                                                    0
                                                                                                                    на всякий случай: www.securitylab.ru/vulnerability/495369.php

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

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