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





Внезапно, без предварительного анонса, на 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)

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (101):

  1. time2rfc
    /#19278113 / +1

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

    • zhovner
      /#19278127

      Я так понимаю зона работодатель.net существует только на одном резолвере и не существует в интернете? Это интересный вопрос. Полагаю, что можно на сервере развернуть knot и задать ему апстрим сервера которые знают об этой зоне. Ну а на клиенте уже настроить dns over tls до этого сервера.

    • ValdikSS
      /#19278143 / +1

      В некоторых дистрибутивах NetworkManager интегрирован с dnsmasq. Если у вас такой дистрибутив (проверить можно наличием запущенного dnsmasq и записью nameserver 127.0.0.2 или аналогичной в /etc/resolv.conf), можно прописать определенным зонам определенный сервер DNS, в /etc/dnsmasq.conf.

      • selivanov_pavel
        /#19278285

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


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

      • develop7
        /#19282367

        чуть менее, чем во всех. просто переключается ресолвер только из конфигов.

        • ValdikSS
          /#19282381

          Я встречал использование NetworkManager+dnsmasq по умолчанию только в Ubuntu-based.

    • inkvizitor68sl
      /#19286983

      Unbound так умеет.
      Там для форварда всех запросов делается так:
      forward-zone:
      name: "."
      ....


      Соответственно, отдельную зону форвардить можно в отдельные NS.

  2. wtigga
    /#19278347

    Теперь DNS 8.8.8.8 излечивает от Роскомнадзора? И если да, сколько недель пройдёт до блокировки этого адреса Ростелекомом?

    • DeeZ
      /#19278463

      Нет, не излечит. Но от определенных блокировок поможет. Например мой провайдер при DNS запросах к запрещенным сайтам возвращает IP своей заглушки. А весь трафик ДНС заворачивает на себя. От таких блокировок поможет.

      • snizovtsev
        /#19283011

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

        • TrueBers
          /#19283705

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

    • dollar
      /#19278483 / +1

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

      Кроме того, DNS over TLS/HTTPS не спасает от блокировки по SNI. Так что РКН, скорее всего, даже не будет смотреть в сторону блокировки 8.8.8.8. Кстати, вы статью вообще читали?

      • zhovner
        /#19280047 / +2

        Если все заблокированные сайты включат поддержку шифрования SNI, тогда обойти блокировку можно будет простой сменой резолвера на специальный, вроде сервиса Antizapret. В таком случае на стороне клиента не потребуется устанавливать VPN или прокси, или какой-либо сторонний софт.

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

        Возможно я где-то ошибаюсь, призываю ValdikSS раскидать по понятиям.

        • zhovner
          /#19280157 / +1

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

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

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

          Соудтрек этого комментария: youtube.com/watch?v=H8xwrF4sKsg

          • jryj
            /#19280261

            вы можете открыть любой сайт (youtube, gmail, google drive) обратившись к любому IP адресу google указав нужный заголовок Host:


            А можно поподробнее? Что и как делать?

            • zhovner
              /#19280333 / +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

          • snizovtsev
            /#19283037

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

            • zhovner
              /#19283145

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

        • ValdikSS
          /#19280425 / +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 в браузерах.

  3. ARad
    /#19278413 / +5

    Как настроить Windows?

  4. nerudo
    /#19278533 / +2

    > {'8.8.8.8', hostname='1.1.1.1'},

    Чтобы дополнительно запутать предполагаемого противника?

  5. ksenobayt
    /#19278639 / +2

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

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

    • lolmaus
      /#19279457

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

      • ksenobayt
        /#19279485

        Фиг знает, подтверждается минимум с четырёх разных точек у того же провайдера.
        Достаточно занятный момент, который, впрочем, сильно упрощает мне жизнь.

    • dollar
      /#19280013 / -3

      Как называется ваш провайдер?

  6. Teomit
    /#19279065

    Не знаю как сейчас, а раньше замечал 8.8.8.8 в небольшой фильтрации. Некоторые ресурсы, которые по мнению Google считаются пиратскими, не резолвились.
    В итоге плюнул и перешёл на DNSCrypt.

    • zhovner
      /#19279961 / +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'}
                      })))
      

  7. Feland
    /#19279399

    Как настроить в Ubuntu?

  8. Loriamar
    /#19279633

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

    Но я пытаюсь понять это что два разных стандарта? Или как? хттпс же работает через тлс итак?

    • zhovner
      /#19279843 / +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 должно быть чуть меньше накладных расходов на каждый запрос.

      • Loriamar
        /#19279923

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

        А DNScrypt во второй версии стал «Supports DNS-over-HTTPS (DoH) and DNSCrypt.»

        • zhovner
          /#19279979 / +1

          Надеюсь, скоро DoH и DoT встроят во все системные резолверы и весь этот сторонний софт будет ненужен.

      • mxms
        /#19283317

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

  9. Whuthering
    /#19279683 / +1

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

    • Loriamar
      /#19279811 / +1

      Хм логично. Но полагаю этим оверхедом можно пренебречь. Это же все-таки днс запросы, а не что-то другое. Или я не прав?

      • zhovner
        /#19279971 / +3

        Можно, да. Просто трафик для таких запросов будет чуть больше.

  10. legolegs
    /#19280341 / +1

    Пожалуйста, дополните ваш UPD. Интересно, чем всё-таки является DNSCrypt с технической точки зрения.
    Также прошу написать, яем всё это добро отличается от DNSSEC.

    Мне кажется, материал очень выиграет, если эти страшные слова будут разъяснены в одном месте.

    • zhovner
      /#19280437 / +1

      Готово.

      • legolegs
        /#19280657

        Спасибо!
        Теперь бы ещё обзор софта с поддержкой шифрованного DNS на винду/линукс/мак/мобилки/роутеры

  11. dMac
    /#19280699 / +3

    Тут один товарищ прикрутил DNS over TLS к рутованному микротику:
    https://forum.mikrotik.com/viewtopic.php?t=132678#p693725

    Кто может глянуть — возможно ли это сделать без рута?
    Думаю, на уровне маршрутизатора внедрить это дело было бы удобнее, чем на каждом конечном устройстве отдельно.

    • zhovner
      /#19280839

      Есть инструкция по настройке на OpenWRT (LEDE) от cloudflare blog.cloudflare.com/dns-over-tls-for-openwrt
      Сам не пробовал.

      • basilbasilbasil
        /#19283131

        попробовал, пашет, но сломал unbound'ом dhcp в локалке, как починить не знаю

        • ksenobayt
          /#19284691

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

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

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

          • YourChief
            /#19286041

            А поподробнее можно про верификацию можно? У меня был unbound на openwrt 18.04 с верификацией сертов.

            • ksenobayt
              /#19286153

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

              • YourChief
                /#19286213

                Да, иначе у меня резолвинг бы не работал. И когда я указывал проверяемый хостнейм неправильно, то он и действительно не работал. В данный момент я перешёл на stubby из-за меньшего объёма потребляемой памяти — она мне нужна для других важных фич.
                Возможно, разница в том, что я ставил самый последний ipk с unbound, который был доступен — в unbound из основного репозитория такой фичи не было вообще. Но проблема точно не в openssl, он проверяет сертификаты нормально во всех приложениях и никаких особенностей в отношении unbound тут нет.

  12. amarao
    /#19280829 / +3

    А почему они все хотят TCP? Почему не шифровать запросы в udp? Меня идея засунуть state в stateless-протокол напрягает.

    • zhovner
      /#19280867

      А мне наоборот нравится TCP, потому что тогда можно выставлять рекурсивный резолвер в интернет и при этом не превращаться в часть DDoS ботнета которого используют для UDP амплификации. Ну и TLS по UDP, наверное, не так просто реализовать.

      В firefox с его встроенным DNS over HTTPS используется keep-alive для TCP подключения, так что по сути резолв может работать подобно UDP: один пакет с запросом --> один ответ.

      • amarao
        /#19281063 / +1

        Вот именно это меня и напрягает. Если у нас пакеты шлются в существующий канал, то если этот канал ушёл в один из уголков TCP, то возвращаться он будет долго. Переупорядоченные пакеты, потерявшийся ack на dup, etc… Там же бездна.

        • clickfreak
          /#19281581

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

          • amarao
            /#19281735 / +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.

            • zhovner
              /#19281971

              сеть с 75% потерь

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

              Кстати в таких сетях отлично работает mosh для ssh. Хозяйке на заметку.

              • amarao
                /#19281993

                Иногда просто нет выбора. И тогда очень обидно, что всё ломается ещё на этапе dns.

              • arheops
                /#19283221

                Вы едете в поезде по степям Украины всего в 5км от ближайшего города с 4Г, ага.
                С обычным dns — у вас будет шанс загрузить чегото сильно больше(особенно учитывая, что каждая страничка отправляет до полусотни днс запросиков).

              • clickfreak
                /#19287827

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

            • clickfreak
              /#19287787

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


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

    • clickfreak
      /#19281509 / +1

      Есть экспериментальный 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

    • ValdikSS
      /#19282425 / +1

      Можно пользоваться DNSCrypt, протокол у него отличный, просто, по какой-то причине, они не заморочились с его публикацией в качестве RFC. dnscrypt-proxy поддерживает и DNSCrypt, и DNS over HTTPS.

      • chupasaurus
        /#19283203

        DoH поддерживает DNSCrypt v2, который писан на Go и уже не на всякий роутер закинешь :/

    • vagran
      /#19282607

      В TLS достаточно тяжеловесное установление сессии с использованием ассиметричной криптографии. Когда сессия установлена, данные быстро шифруются симметричным ключём, полученным при установлении сессии.

  13. int03e
    /#19280855

    Кто-то пробовал ставить по этой инструкции 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

    • zhovner
      /#19280901 / +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/

      • int03e
        /#19280937

        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
        

        • zhovner
          /#19280963 / +1

          Листинг лучше спрятать под спойлер. У вас наверное не установлен knot, хотя он должен был подтянуться в зависимостях. Установите его вручную:

          brew install knot 

          • int03e
            /#19281041

            Проблема с 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.

            • extempl
              /#19282165

              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.

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

  14. FakieStyle
    /#19281201 / +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?

    • zhovner
      /#19281283

      Я нашел домен для гугла в сертификате: 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

  15. morr
    /#19282215

    На 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. Можно ли как-то настроить автоматический моментальный перезапуск при падении?

    • onlinehead
      /#19283659

      Если не сложно, то можете попробовать другой вариант.
      Я для себя писал подобный прокси простенький на базе либы «miekg/dns», специально для DNS-over-TLS и DNS-over-HTTPS и максимально простым конфигом, локально у меня нормально работает. Вот исходники, он на Go, так что соберется и под Мак — github.com/Onlinehead/dns-to-dns-tls
      Plst для автозапуска правда не делал, потому что у меня в контейнере живет на сервачке.
      Правки приветствуются.

    • zhovner
      /#19283665

      Во первых создайте репорт об этой проблеме в багтрекере 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>


  16. CeyT
    /#19282413

    Ради минимальных приличий хоть напишите, что грязными лапами в список посещённых доменов после этого будут лезть Google и Cloudflare, и что это всё делается не ради помощи бедным пользователям и их безопасности, а для борьбы с конкурентами, получающими поведенческие данные в тех точках, куда указанным компаниям не дотянуться.

    • zhovner
      /#19282501 / +1

      Гугл и cloudflare по крайней мере не были замечены в инъекциях рекламы в HTTP трафик и модификации моих сайтов. В отличии от мегафона и билайна.

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

      • CeyT
        /#19283109

        Никого ничему история не учит: вы сейчас доказываете, что Microsoft большой (больше всех!), и что предложение добавить в веб OLE с внешним исполнимым кодом взлетит, «потому что это Microsoft, а не какая-то местная конторка».

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

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

        • dollar
          /#19283293 / +1

          А вы не думали, что Google собирает данные просто для ранжирования сайтов в выдаче?
          Это их основной продукт.

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

          • CeyT
            /#19283669

            «В какой бы магазин вы ни пошли купить мяса, вам в итоге навалят обрезков, костей, грязных тряпок, и ещё под зад пнут ногой».

            Не очень привычная логика, не находите?

  17. ZaEzzz
    /#19282621

    Это отличная новость!
    К примеру, ростелеком гарантированно меняет содержимое перенаправляя на рекламу своих пакетов. Техподдержка говорит, что РТ так доносит предложения, но на письмо на каком основании нет, они такой фигней не занимаются.

    • dimonoid
      /#19282777 / +1

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

      • ZaEzzz
        /#19282885 / +2

        На мой запрос по какой причине производится замена результата пришел ответ с адреса no-reply@rt.ru:

        Уважаемый абонент, Ваша претензия № 47511808 рассмотрена По фактам, указанным в Вашем обращении, проведена проверка. Редирект произведен с сайта store.steampowered.com. Это могло произойти как как на стороне сервера, так и на стороне клиента (в браузере). Средствами АСР Ростелеком редирект не производится.

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

        В сухом остатке: видя, что я хочу перейти на игровой портал мне предлагают игровой тариф и говорят, что это не они устраивают MITM, а валв переводит трафик к своим конкурентам в надежде снизить посещаемость и продажи.
        Простите, но это смешно.

  18. nlykl
    /#19282749

    Ждём гайда по настройке этого в OpenWRT.

    • zhovner
      /#19282759

      blog.cloudflare.com/dns-over-tls-for-openwrt

      Сам не пробовал.

      • YourChief
        /#19283661

        Это старое руководство для старой версии unbound (<1.6.1), которая не валидирует SAN сертификата. В таком виде DoT бесполезен. Вот статья, освещающая проблему и предоставляющая правильную конфигурацию.

  19. Paskin
    /#19282939

    А как теперь будут работать CDNы, локальные копии и тому подобное?

  20. konchok
    /#19282995 / -1

    Посоветовал бы не пускать все DNS по крипте, а оставить какие-то открытыми. Пользователь без DNS запросов привлекает повышенное внимание.

    • zhovner
      /#19283007 / +1

      Ох как бы не вызвать подозрений.

    • dollar
      /#19283345 / +1

      Хотите сказать, что к вам приедут с обыском и конфискацией оборудования, потому что у вас нет DNS запросов?

  21. IGHOR
    /#19283331

    Что мешает провайдеру заблокировать все исходящие запросы на 853 порт?
    Тем самым вынудить всех использовать стандартный, легко модифицируемый протокол по 53 порту.

    • dollar
      /#19283369

      Теоретически ничто не мешает. Но это уже проблема сетевого нейтралитета. Если его у нас узаконят, то будет закон, который и будет мешать. С другой стороны, ничто не мешает ввести закон, запрещающий порт 853 в принципе, или любой другой бредовый закон. С фантазией в нашей стране проблем нет, так что законы всё «лучше» и «лучше».

    • zhovner
      /#19283391

      Тогда будем использовать DNS over HTTPS. Его будет крайне сложно запретить не сломав при этом интернет целиком.

  22. firehunt
    /#19283593

    DoH ломает концепцию, что DNS является «Control Plane» Интернет. Внезапно DNS оказывается на «Data Plane». Это не мои слова, это Paul Vixie.
    Скорости работы ни от DoT ни от DoH ждать не приходится.

    По скорости, среднем в РФ у провайдеров DNS сервера медленнее гуглового сервиса, иногда в разы.
    За исключением Ростелекома Северо-Западного макро филиала, DNS сервера которого работают быстрее чем Google Public DNS уже несколько лет.

  23. TrueBers
    /#19283741

    А что со скоростью резолва, собственно? Сколько раньше ни попробовал, меньше 500-700ms на холодную не получалось добиться. А это совсем не юзабельно. Может, не так что-то делал? Накручивал всякие fast open, keepalive, etc. Бестолку.
    При том, что чистый днс ходит на гугл за 10-15мс.