Внезапно, без предварительного анонса, на 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 в данном случае — 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)
wtigga
25.10.2018 05:49Теперь DNS 8.8.8.8 излечивает от Роскомнадзора? И если да, сколько недель пройдёт до блокировки этого адреса Ростелекомом?
DeeZ
25.10.2018 07:29Нет, не излечит. Но от определенных блокировок поможет. Например мой провайдер при DNS запросах к запрещенным сайтам возвращает IP своей заглушки. А весь трафик ДНС заворачивает на себя. От таких блокировок поможет.
snizovtsev
25.10.2018 22:13Что за провайдер, если не секрет? Потенциальные новые клиенты должны знать героев, которые бегут вперёд
паровозаРКН и заворачивают ДНС.TrueBers
26.10.2018 02:21Да таких десятки по стране. Как минимум, лично сталкивался с дюжиной. Всех перечислять что ли? Часто это мелкие локальные провайдеры, которые ресейлят всяких Ростелекомов.
dollar
25.10.2018 07:43+1Пока что речи о нативной поддержке не идёт. В статье говорится, что это возможно только для Android 9. А с помощью стороннего софта и раньше можно было «излечиваться» от РКН (то есть избегать перенаправления DNS запросов).
Кроме того, DNS over TLS/HTTPS не спасает от блокировки по SNI. Так что РКН, скорее всего, даже не будет смотреть в сторону блокировки 8.8.8.8. Кстати, вы статью вообще читали?zhovner Автор
25.10.2018 12:52+2Если все заблокированные сайты включат поддержку шифрования SNI, тогда обойти блокировку можно будет простой сменой резолвера на специальный, вроде сервиса Antizapret. В таком случае на стороне клиента не потребуется устанавливать VPN или прокси, или какой-либо сторонний софт.
Я вижу это так: специальным образом сконфигурированный DNS over TLS/HTTPS резолвер выборочно обрабатывает заблокированные сайты, подменяя их реальные IP на свои DNAT прокси. При этом проксируя только TCP. А так как SNI зашифрован, DPI не увидит к какому сайту запрос. Однако это может сломать DNSSEC, если владелец заблокированного домена решит подписать зону.
Возможно я где-то ошибаюсь, призываю ValdikSS раскидать по понятиям.zhovner Автор
25.10.2018 13:08+1Надеюсь, все движется к тому, что блокировки сайтов станут невозможными. Этому должно помочь распространение ESNI, шифрованного DNS и IPv6.
Вангую, что в ближайшем будущем, любые веб-сайты будут открываться с любых IP. Как это сейчас сделано с веб-фронтендом гугла: вы можете открыть любой сайт (youtube, gmail, google drive) обратившись к любому IP адресу google указав нужный заголовок Host:.
Конечно, всегда остается тупая блокировка по IP, но с приходом IPv6 обычному владельцу сайта станут доступны миллиарды адресов почти бесплатно. Поэтому на каждый DNS запрос можно будет резолвить разный адрес, даже из разных сетей. Наверняка у сервисов вроде Cloudflare появится опция типа IP mixer, как раз для защиты сайтов от государственной цензуры. В такой системе блокировать сайты можно будет только заблокировав большую часть интернета.
Соудтрек этого комментария: youtube.com/watch?v=H8xwrF4sKsgjryj
25.10.2018 13:25вы можете открыть любой сайт (youtube, gmail, google drive) обратившись к любому IP адресу google указав нужный заголовок Host:
А можно поподробнее? Что и как делать?zhovner Автор
25.10.2018 13:37+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
25.10.2018 22:20Боюсь с приходом IPv6 у облачных провайдеров будет возможность привязывать к клиенту (юр. или физ. лицу) статическую подсеть вместо плавающего публичного IP из общего пула, что лишь поможет РКН точнее блокировать сайты даже без DPI.
zhovner Автор
25.10.2018 22:59Ну вообще-то и сейчас, по-хорошему клиенту должна выдаваться сеть /64 на каждый сервер. Но даже в этом случае IP адреса становятся сильно дешевле и их можно закупать у разных хостеров и обновлять хоть каждую минуту.
ValdikSS
25.10.2018 13:56+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 в браузерах.
ksenobayt
25.10.2018 08:42+2Немного оффтопик, но раз уж мы говорим за блокировки: с удивлением для себя обнаружил, что мой провайдер отдаёт нефильтрованный трафик в том случае, если клиент заказал себе белый IP. Из технических нюансов — адрес выдаётся из другой автономки, нежели та, из которой берутся адреса для NAT, плюс перестали, наконец, спуфить DNS.
Я всё пытаюсь понять, чем это обсуловлено. Я почти уверен, что на каждого клиента, попросившего белый IP, маршрутизацию пишут вручную — ибо это, прости господи, в 2018-м году потребовало приезда монтажника (!!!), который полчаса ковырялся в несчастном 3Com'е, и заняло в целом четыре дня. Таким образом, завернуть трафик на фильтрацию становится технически едва ли не проще.
Teomit
25.10.2018 10:36Не знаю как сейчас, а раньше замечал 8.8.8.8 в небольшой фильтрации. Некоторые ресурсы, которые по мнению Google считаются пиратскими, не резолвились.
В итоге плюнул и перешёл на DNSCrypt.achekalin
25.10.2018 10:50А если использовать
- 1.1.1.1
- 1.0.0.1
- 2606:4700:4700::1111
- 2606:4700:4700::1001
— там вроде обещали без цензуры?
zhovner Автор
25.10.2018 12:40+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'} })))
Loriamar
25.10.2018 11:56Кто-нибудь объясните мне на пальцах в чем разница между DNS-pver-HTTPS и DNS-over-TLS (сам я пользуюсь github.com/jedisct1/dnscrypt-proxy)
Но я пытаюсь понять это что два разных стандарта? Или как? хттпс же работает через тлс итак?zhovner Автор
25.10.2018 12:22+3DNScrypt это скорее черновик, который тестировали до внедрения 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
25.10.2018 12:35Т.е через ХТТПС имеет оверхед но скрыт от провайдера, через ТЛС без оверхеда и виден как обычный ДНС запрос, но толкьо шифрованный. Всё. Поня.
А DNScrypt во второй версии стал «Supports DNS-over-HTTPS (DoH) and DNSCrypt.»zhovner Автор
25.10.2018 12:44+1Надеюсь, скоро DoH и DoT встроят во все системные резолверы и весь этот сторонний софт будет ненужен.
mxms
25.10.2018 23:42DNScrypt (к слову, ужасная мешанина технологий и пример оверинжиниринга) не имеет отношения к DNS-over-TLS.
Последний удобен, быстр и просто в настройке.
legolegs
25.10.2018 13:39+1Пожалуйста, дополните ваш UPD. Интересно, чем всё-таки является DNSCrypt с технической точки зрения.
Также прошу написать, яем всё это добро отличается от DNSSEC.
Мне кажется, материал очень выиграет, если эти страшные слова будут разъяснены в одном месте.
dMac
25.10.2018 14:45+3Тут один товарищ прикрутил DNS over TLS к рутованному микротику:
https://forum.mikrotik.com/viewtopic.php?t=132678#p693725
Кто может глянуть — возможно ли это сделать без рута?
Думаю, на уровне маршрутизатора внедрить это дело было бы удобнее, чем на каждом конечном устройстве отдельно.zhovner Автор
25.10.2018 15:07Есть инструкция по настройке на OpenWRT (LEDE) от cloudflare blog.cloudflare.com/dns-over-tls-for-openwrt
Сам не пробовал.basilbasilbasil
25.10.2018 22:55попробовал, пашет, но сломал unbound'ом dhcp в локалке, как починить не знаю
ksenobayt
26.10.2018 10:20Это распространённая проблема.
Поэтому я предпочитаю резолвер держать на одноплатнике внутри сети, и просто на него перенаправлять запросы от dnsmasq, который их уже кеширует.
ЗЫ: кстати, еще одна проблема подобного конфига с OpenWRT будет заключаться в том, что у них покамест даже в 18.04 и снэпшотах, используется слегка устаревшая версия OpenSSL, функционала которой недостаточно для проверки сертификатов.
Таким образом, верифицировать подпись DNS-сервера на OpenWRT вам не удастся. Единственный рабочий вариант сейчас — форсить игнор проверки подписи, что СЛЕГКА нивелирует весь смысл затеи.YourChief
26.10.2018 13:29А поподробнее можно про верификацию можно? У меня был unbound на openwrt 18.04 с верификацией сертов.
ksenobayt
26.10.2018 13:43А вы уверены, что она работала?
Проверьте логи, у меня при попытке зафорсить ее включение, в логах были месседжи об ошибке проверки подписи.YourChief
26.10.2018 13:51Да, иначе у меня резолвинг бы не работал. И когда я указывал проверяемый хостнейм неправильно, то он и действительно не работал. В данный момент я перешёл на stubby из-за меньшего объёма потребляемой памяти — она мне нужна для других важных фич.
Возможно, разница в том, что я ставил самый последний ipk с unbound, который был доступен — в unbound из основного репозитория такой фичи не было вообще. Но проблема точно не в openssl, он проверяет сертификаты нормально во всех приложениях и никаких особенностей в отношении unbound тут нет.
amarao
25.10.2018 15:06+3А почему они все хотят TCP? Почему не шифровать запросы в udp? Меня идея засунуть state в stateless-протокол напрягает.
zhovner Автор
25.10.2018 15:11А мне наоборот нравится TCP, потому что тогда можно выставлять рекурсивный резолвер в интернет и при этом не превращаться в часть DDoS ботнета которого используют для UDP амплификации. Ну и TLS по UDP, наверное, не так просто реализовать.
В firefox с его встроенным DNS over HTTPS используется keep-alive для TCP подключения, так что по сути резолв может работать подобно UDP: один пакет с запросом --> один ответ.amarao
25.10.2018 15:34+1Вот именно это меня и напрягает. Если у нас пакеты шлются в существующий канал, то если этот канал ушёл в один из уголков TCP, то возвращаться он будет долго. Переупорядоченные пакеты, потерявшийся ack на dup, etc… Там же бездна.
clickfreak
25.10.2018 17:07В libc по умолчанию таймаут в 5 секунд (
man resolv.conf), если явно в resolv.conf не исправить на что-то поменьше.
Persistent DNS Connections for Reliability and Performanceamarao
25.10.2018 17:32+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 Автор
25.10.2018 18:12сеть с 75% потерь
А каким транспортным протоколом можно пользоваться в такой сети для решения каких-либо прикладных задач? Я не говорю что такие ситуации нереальны, но в действительно же будет почти невозможно пользоваться ничем.
Кстати в таких сетях отлично работает mosh для ssh. Хозяйке на заметку.amarao
25.10.2018 18:16Иногда просто нет выбора. И тогда очень обидно, что всё ломается ещё на этапе dns.
arheops
25.10.2018 23:17Вы едете в поезде по степям Украины всего в 5км от ближайшего города с 4Г, ага.
С обычным dns — у вас будет шанс загрузить чегото сильно больше(особенно учитывая, что каждая страничка отправляет до полусотни днс запросиков).
clickfreak
26.10.2018 17:41Вспоминаю как я пытался на Кипре залить на сервер в Питере 100 гигов и отказался от этой затеи как раз из-за сети с кучей потерь, там это почти норма.
clickfreak
26.10.2018 17:35Тут как раз трюк в том что соединения не прибиваются, аля мы "экономим" на хендшейке. Cкепсис правильный, работая с серверами я забыл что потери бывают разные.
Мобильные телефоны как раз регулярно имеют дело с потерями пакетов и у них, как я понял, stub резолвер умный и уже приспособлен к описанной ситуации.
clickfreak
25.10.2018 16:56+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
25.10.2018 19:51+1Можно пользоваться DNSCrypt, протокол у него отличный, просто, по какой-то причине, они не заморочились с его публикацией в качестве RFC. dnscrypt-proxy поддерживает и DNSCrypt, и DNS over HTTPS.
chupasaurus
25.10.2018 23:13DoH поддерживает DNSCrypt v2, который писан на Go и уже не на всякий роутер закинешь :/
vagran
25.10.2018 20:42В TLS достаточно тяжеловесное установление сессии с использованием ассиметричной криптографии. Когда сессия установлена, данные быстро шифруются симметричным ключём, полученным при установлении сессии.
int03e
25.10.2018 15:10Кто-то пробовал ставить по этой инструкции 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 foundzhovner Автор
25.10.2018 15:15+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
25.10.2018 15:20ls -lals -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 directoryzhovner Автор
25.10.2018 15:23+1Листинг лучше спрятать под спойлер. У вас наверное не установлен knot, хотя он должен был подтянуться в зависимостях. Установите его вручную:
brew install knotint03e
25.10.2018 15:31Проблема с knot немного в другом, как оказывается:
brew install knotbrew 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
25.10.2018 18:51https://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.После этого всё ещё может не завестись. Пришлось сделать реинсталл, после стопнуть и запустить сервис заново (рестарт не помогал). Может быть реинсталл лишний.
FakieStyle
25.10.2018 15:57+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 Автор
25.10.2018 16:10Я нашел домен для гугла в сертификате: 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
morr
25.10.2018 19:03На 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
26.10.2018 01:58Если не сложно, то можете попробовать другой вариант.
Я для себя писал подобный прокси простенький на базе либы «miekg/dns», специально для DNS-over-TLS и DNS-over-HTTPS и максимально простым конфигом, локально у меня нормально работает. Вот исходники, он на Go, так что соберется и под Мак — github.com/Onlinehead/dns-to-dns-tls
Plst для автозапуска правда не делал, потому что у меня в контейнере живет на сервачке.
Правки приветствуются.
zhovner Автор
26.10.2018 02:04Во первых создайте репорт об этой проблеме в багтрекере 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>
CeyT
25.10.2018 19:50Ради минимальных приличий хоть напишите, что грязными лапами в список посещённых доменов после этого будут лезть Google и Cloudflare, и что это всё делается не ради помощи бедным пользователям и их безопасности, а для борьбы с конкурентами, получающими поведенческие данные в тех точках, куда указанным компаниям не дотянуться.
zhovner Автор
25.10.2018 20:08+1Гугл и cloudflare по крайней мере не были замечены в инъекциях рекламы в HTTP трафик и модификации моих сайтов. В отличии от мегафона и билайна.
Вообще я сомневаюсь что данные о резолвах открывают такое больше поле для аналитики. При обычном серфинге, вы, скорее всего, зарезолвите все те же ресурсы, что и при целевом посещении. Условно говоря, при поиске товаров для животных вы так или иначе зарезолвите vk.com, youtube.com, google.com и еще кучу доменов. Как из этого можно сделать поведенческий профиль? Резолв не дает так много информации, как например, трекеры на сайтах. Так что полагаю, что скорее всего, эти сервисы сделаны больше для того, чтобы доставлять свою рекламу в неизменном виде, чтобы по пути ее не резали блокировщиками и не подменяли на другую, а не столько для трекинга пользователей.CeyT
25.10.2018 22:49Никого ничему история не учит: вы сейчас доказываете, что Microsoft большой (больше всех!), и что предложение добавить в веб OLE с внешним исполнимым кодом взлетит, «потому что это Microsoft, а не какая-то местная конторка».
Вы сомневаетесь, а они не сомневаются. Это не благотворительные организации; то, что не приносит дохода, закрывается. Запросы к DNS дают не просто список доменов, а список доменов с точным временем перехода к ним — это и круглосуточный портрет пользователя, и статистика для всех сайтов (даже не имеющих ни одного трекера, даже при использовании блокировщика ни клиенте), и возможность легко объединить посещения конкретного пользователя со статистикой GA по нему. Cloudflare не сомневается, что халявный трафик через их сервера для любого желающего приносит прибыль, а не одни лишь убытки. Подрезали Google крылышки GDPR — встроенные карты тут же стали платными, потому что контент жирный, а сбор с него информации впрок теперь запрещён. Сравните старые и новые цены за доступ к технологии, чтобы прикинуть, во сколько это обходится.
Мы имеем то, что имеем, не в результате того, что кто-то пришёл с ружьём и всех заставил, а в результате множества таких вот компромиссов, но даже предложение признать проблему — не говоря уж об отказе от использования — встречается с недоумением. С таким вот диджитал резистанс все причастные могут спать спокойно.dollar
25.10.2018 23:36+1А вы не думали, что Google собирает данные просто для ранжирования сайтов в выдаче?
Это их основной продукт.
В любом случае, какой бы DNS вы ни использовали, данные будут кому-то утекать. Что ж, теперь, вообще Интернетом не пользоваться?CeyT
26.10.2018 02:06«В какой бы магазин вы ни пошли купить мяса, вам в итоге навалят обрезков, костей, грязных тряпок, и ещё под зад пнут ногой».
Не очень привычная логика, не находите?
ZaEzzz
25.10.2018 20:45Это отличная новость!
К примеру, ростелеком гарантированно меняет содержимое перенаправляя на рекламу своих пакетов. Техподдержка говорит, что РТ так доносит предложения, но на письмо на каком основании нет, они такой фигней не занимаются.dimonoid
25.10.2018 21:19+1Проверьтесь на
вирусы/используйте другой компьютер. Есть небольшой шанс что они не врут. AdwCleaner может помочь. У меня такая фигня както раз была, большинство антивирусов ничего не находят, тк реклама по их мнению не вирус, а нежелательное по.ZaEzzz
25.10.2018 21:43+2На мой запрос по какой причине производится замена результата пришел ответ с адреса no-reply@rt.ru:
Уважаемый абонент, Ваша претензия № 47511808 рассмотрена По фактам, указанным в Вашем обращении, проведена проверка. Редирект произведен с сайта store.steampowered.com. Это могло произойти как как на стороне сервера, так и на стороне клиента (в браузере). Средствами АСР Ростелеком редирект не производится.
Есть нюансы:
1 — Все, что происходит в системе я знаю, никаких сюрпризов нет и AdwCleaner у меня запустится только в виртуалке или под вайном. Ну не использую я винду и хорошо знаю что у меня в лялихе крутится.
2 — ТП в РТ сообщал о том, что это способ донести предложение. Цитирую: «Ростелеком старается предоставлять различным способами, включая показ при открытии сайтов. Очень жаль, если данный вариант Вас огорчил.» Но в письме с no-reply@rt.ru «Средствами АСР Ростелеком редирект не производится.»
3 — Редирект произошел после того, как я руками вбил в адресную строку store.steampowered.com (то есть не переход по ссылке) и открылась реклама тарифа РТ с каким-то аккаунтом танков и с доп танками.
В сухом остатке: видя, что я хочу перейти на игровой портал мне предлагают игровой тариф и говорят, что это не они устраивают MITM, а валв переводит трафик к своим конкурентам в надежде снизить посещаемость и продажи.
Простите, но это смешно.
nlykl
25.10.2018 21:13Ждём гайда по настройке этого в OpenWRT.
IGHOR
25.10.2018 23:44Что мешает провайдеру заблокировать все исходящие запросы на 853 порт?
Тем самым вынудить всех использовать стандартный, легко модифицируемый протокол по 53 порту.dollar
25.10.2018 23:54Теоретически ничто не мешает. Но это уже проблема сетевого нейтралитета. Если его у нас узаконят, то будет закон, который и будет мешать. С другой стороны, ничто не мешает ввести закон, запрещающий порт 853 в принципе, или любой другой бредовый закон. С фантазией в нашей стране проблем нет, так что законы всё «лучше» и «лучше».
zhovner Автор
26.10.2018 00:00Тогда будем использовать DNS over HTTPS. Его будет крайне сложно запретить не сломав при этом интернет целиком.
firehunt
26.10.2018 01:22DoH ломает концепцию, что DNS является «Control Plane» Интернет. Внезапно DNS оказывается на «Data Plane». Это не мои слова, это Paul Vixie.
Скорости работы ни от DoT ни от DoH ждать не приходится.
По скорости, среднем в РФ у провайдеров DNS сервера медленнее гуглового сервиса, иногда в разы.
За исключением Ростелекома Северо-Западного макро филиала, DNS сервера которого работают быстрее чем Google Public DNS уже несколько лет.
TrueBers
26.10.2018 02:44А что со скоростью резолва, собственно? Сколько раньше ни попробовал, меньше 500-700ms на холодную не получалось добиться. А это совсем не юзабельно. Может, не так что-то делал? Накручивал всякие fast open, keepalive, etc. Бестолку.
При том, что чистый днс ходит на гугл за 10-15мс.
time2rfc
Господа, что можно настроить под linux без долгой ругани, с возможностью часть доменной зоны(например работодатель.net) отдать на откуп вышестоящему dns работающему по-старинке.
zhovner Автор
Я так понимаю зона
работодатель.netсуществует только на одном резолвере и не существует в интернете? Это интересный вопрос. Полагаю, что можно на сервере развернуть knot и задать ему апстрим сервера которые знают об этой зоне. Ну а на клиенте уже настроить dns over tls до этого сервера.ValdikSS
В некоторых дистрибутивах NetworkManager интегрирован с dnsmasq. Если у вас такой дистрибутив (проверить можно наличием запущенного dnsmasq и записью
nameserver 127.0.0.2или аналогичной в/etc/resolv.conf), можно прописать определенным зонам определенный сервер DNS, в/etc/dnsmasq.conf.selivanov_pavel
Точнее, прописывать надо в
/etc/NetworkManager/dnsmasq.d/*.conf.Потому что NetworkManager запускает dnsmasq с опциями
--conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq.d.develop7
чуть менее, чем во всех. просто переключается ресолвер только из конфигов.
ValdikSS
Я встречал использование NetworkManager+dnsmasq по умолчанию только в Ubuntu-based.
Jouretz
Unbound, например.
Там весь конфиг можно в 20 строчек уложить. И локальные ресолверы на зоны настроить.
wiki.archlinux.org/index.php/unbound#Include_local_DNS_server
inkvizitor68sl
Unbound так умеет.
Там для форварда всех запросов делается так:
forward-zone:name: "."
....
Соответственно, отдельную зону форвардить можно в отдельные NS.