Комментарии 147
Господа, что можно настроить под linux без долгой ругани, с возможностью часть доменной зоны(например работодатель.net) отдать на откуп вышестоящему dns работающему по-старинке.
Я так понимаю зона
работодатель.net существует только на одном резолвере и не существует в интернете? Это интересный вопрос. Полагаю, что можно на сервере развернуть knot и задать ему апстрим сервера которые знают об этой зоне. Ну а на клиенте уже настроить dns over tls до этого сервера.
В некоторых дистрибутивах NetworkManager интегрирован с dnsmasq. Если у вас такой дистрибутив (проверить можно наличием запущенного dnsmasq и записью
nameserver 127.0.0.2 или аналогичной в /etc/resolv.conf), можно прописать определенным зонам определенный сервер DNS, в /etc/dnsmasq.conf.
Unbound, например.
Там весь конфиг можно в 20 строчек уложить. И локальные ресолверы на зоны настроить.
wiki.archlinux.org/index.php/unbound#Include_local_DNS_server
Там весь конфиг можно в 20 строчек уложить. И локальные ресолверы на зоны настроить.
wiki.archlinux.org/index.php/unbound#Include_local_DNS_server
Unbound так умеет.
Там для форварда всех запросов делается так:
Соответственно, отдельную зону форвардить можно в отдельные NS.
Там для форварда всех запросов делается так:
forward-zone:
name: "."
....Соответственно, отдельную зону форвардить можно в отдельные NS.
Теперь DNS 8.8.8.8 излечивает от Роскомнадзора? И если да, сколько недель пройдёт до блокировки этого адреса Ростелекомом?
Нет, не излечит. Но от определенных блокировок поможет. Например мой провайдер при DNS запросах к запрещенным сайтам возвращает IP своей заглушки. А весь трафик ДНС заворачивает на себя. От таких блокировок поможет.
Что за провайдер, если не секрет? Потенциальные новые клиенты должны знать героев, которые бегут вперёд паровоза РКН и заворачивают ДНС.
Да таких десятки по стране. Как минимум, лично сталкивался с дюжиной. Всех перечислять что ли? Часто это мелкие локальные провайдеры, которые ресейлят всяких Ростелекомов.
Что за провайдер, если не секрет?Дом.ру, например.
героев, которые бегут вперёдФильтрация DNS — официально рекомендуемый РКН способ для провайдеровпаровозаРКН
Операторам связи, не использующим DPI и осуществляющим ограничение доступа к доменному имени при помощи иных программных, аппаратных или программно-аппаратных средств, рекомендуется ограничивать доступ к доменному имени посредством фильтрации запросов ко всем DNS-серверам.
Да, я согласен, что за такое в приличных домах бьют канделябром по морде ибо нарушение связности.
Пока что речи о нативной поддержке не идёт. В статье говорится, что это возможно только для Android 9. А с помощью стороннего софта и раньше можно было «излечиваться» от РКН (то есть избегать перенаправления DNS запросов).
Кроме того, DNS over TLS/HTTPS не спасает от блокировки по SNI. Так что РКН, скорее всего, даже не будет смотреть в сторону блокировки 8.8.8.8. Кстати, вы статью вообще читали?
Кроме того, DNS over TLS/HTTPS не спасает от блокировки по SNI. Так что РКН, скорее всего, даже не будет смотреть в сторону блокировки 8.8.8.8. Кстати, вы статью вообще читали?
Если все заблокированные сайты включат поддержку шифрования SNI, тогда обойти блокировку можно будет простой сменой резолвера на специальный, вроде сервиса Antizapret. В таком случае на стороне клиента не потребуется устанавливать VPN или прокси, или какой-либо сторонний софт.
Я вижу это так: специальным образом сконфигурированный DNS over TLS/HTTPS резолвер выборочно обрабатывает заблокированные сайты, подменяя их реальные IP на свои DNAT прокси. При этом проксируя только TCP. А так как SNI зашифрован, DPI не увидит к какому сайту запрос. Однако это может сломать DNSSEC, если владелец заблокированного домена решит подписать зону.
Возможно я где-то ошибаюсь, призываю ValdikSS раскидать по понятиям.
Я вижу это так: специальным образом сконфигурированный DNS over TLS/HTTPS резолвер выборочно обрабатывает заблокированные сайты, подменяя их реальные IP на свои DNAT прокси. При этом проксируя только TCP. А так как SNI зашифрован, DPI не увидит к какому сайту запрос. Однако это может сломать DNSSEC, если владелец заблокированного домена решит подписать зону.
Возможно я где-то ошибаюсь, призываю ValdikSS раскидать по понятиям.
Надеюсь, все движется к тому, что блокировки сайтов станут невозможными. Этому должно помочь распространение ESNI, шифрованного DNS и IPv6.
Вангую, что в ближайшем будущем, любые веб-сайты будут открываться с любых IP. Как это сейчас сделано с веб-фронтендом гугла: вы можете открыть любой сайт (youtube, gmail, google drive) обратившись к любому IP адресу google указав нужный заголовок Host:.
Конечно, всегда остается тупая блокировка по IP, но с приходом IPv6 обычному владельцу сайта станут доступны миллиарды адресов почти бесплатно. Поэтому на каждый DNS запрос можно будет резолвить разный адрес, даже из разных сетей. Наверняка у сервисов вроде Cloudflare появится опция типа IP mixer, как раз для защиты сайтов от государственной цензуры. В такой системе блокировать сайты можно будет только заблокировав большую часть интернета.
Соудтрек этого комментария: youtube.com/watch?v=H8xwrF4sKsg
Вангую, что в ближайшем будущем, любые веб-сайты будут открываться с любых IP. Как это сейчас сделано с веб-фронтендом гугла: вы можете открыть любой сайт (youtube, gmail, google drive) обратившись к любому IP адресу google указав нужный заголовок Host:.
Конечно, всегда остается тупая блокировка по IP, но с приходом IPv6 обычному владельцу сайта станут доступны миллиарды адресов почти бесплатно. Поэтому на каждый DNS запрос можно будет резолвить разный адрес, даже из разных сетей. Наверняка у сервисов вроде Cloudflare появится опция типа IP mixer, как раз для защиты сайтов от государственной цензуры. В такой системе блокировать сайты можно будет только заблокировав большую часть интернета.
Соудтрек этого комментария: youtube.com/watch?v=H8xwrF4sKsg
вы можете открыть любой сайт (youtube, gmail, google drive) обратившись к любому IP адресу google указав нужный заголовок Host:
А можно поподробнее? Что и как делать?
Есть некоторые мобильные операторы, которые для корректной работы Android пропускают трафик к определенным служебным адресам google. Это позволяет смотреть youtube при отрицательном балансе :)
Пробуем найти случайный IP адрес google.com:
Пробуем запросить по этому адресу сайт Youtube.com. По заголовкам видим, что попали на youtube.
Иначе это можно было сделать добавив в файл hosts такую запись:
Пробуем найти случайный 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Боюсь с приходом IPv6 у облачных провайдеров будет возможность привязывать к клиенту (юр. или физ. лицу) статическую подсеть вместо плавающего публичного IP из общего пула, что лишь поможет РКН точнее блокировать сайты даже без DPI.
Ну вообще-то и сейчас, по-хорошему клиенту должна выдаваться сеть /64 на каждый сервер. Но даже в этом случае IP адреса становятся сильно дешевле и их можно закупать у разных хостеров и обновлять хоть каждую минуту.
Разве не на VLAN? Куда одному серверу столько?
Например, чтобы виртуалки на этом сервере могли получать IPv6-адрес, используя нативный механизм назначения адресов, без DHCP. В IPv6 принято иерархическое деление адресного пространства, и клиент получает куски, которые удобно дальше делить под свои нужды самостоятельно.
Так ничего не мешает выпускать ВМ или контейнеры через бридж.
Ну как раз и хорошо, если они подключены через бридж в основную сеть. Только всё равно нужен префикс /64 на машину, чтобы они могли нативно адреса получать.
Адресов из /64 хватит, чтобы выдать миллиарды адресов на каждый сервер в ЦОДе. Не будет сегментации между клиентами, но это дополнительная фича и решается через distributed firewall в SDN.
Отлично! А зачем, если можно раздать на каждую машину /64 и каждое сетевое устройство сможет использовать IPv6 SLAAC?
Устройства (ВМ с контейнерами на них) и будут получать адреса через SLAAC из одной большой сети.
DO ведь не даёт по /64 на дроплет и в AWS такая сеть выделается на VPC (фактически VLAN), а не на каждый инстанс EC2.
DO ведь не даёт по /64 на дроплет и в AWS такая сеть выделается на VPC (фактически VLAN), а не на каждый инстанс EC2.
У меня как раз есть виртуалка на DO, и мне доступно 16 IPv6-адресов из строго выделенного диапазона. Для того, чтобы назначать IPv6-адреса VPN-клиентам, мне нужно на каждый адрес поднимать neighbor proxy на отдельный адрес при подключении или вообще постоянно. Я не рад такому положению вещей и для меня это недостаток.
У хостера online.net каждый клиент получает префикс /48 и сам нарезает его для разных DUID на блоки размерами по /56 и /64. Серверы запрашивают делегацию префикса по DHCPv6, используя заданный DUID, и дальше распоряжаются адресами на своём уровне иерархии совершенно свободно.
Такой принцип распределения соответствует целям стандарта и на голову выше колхоза, который предлагают хостеры со своими фиксированными мелкими диапазонами. Впрочем, на DO в этом смысле особо равняться не стоит — они и failover IP навешивают через костыль в виде серого адреса — это всё продиктовано удобством реализации для них.
У хостера online.net каждый клиент получает префикс /48 и сам нарезает его для разных DUID на блоки размерами по /56 и /64. Серверы запрашивают делегацию префикса по DHCPv6, используя заданный DUID, и дальше распоряжаются адресами на своём уровне иерархии совершенно свободно.
Такой принцип распределения соответствует целям стандарта и на голову выше колхоза, который предлагают хостеры со своими фиксированными мелкими диапазонами. Впрочем, на DO в этом смысле особо равняться не стоит — они и failover IP навешивают через костыль в виде серого адреса — это всё продиктовано удобством реализации для них.
Для того, чтобы назначать IPv6-адреса VPN-клиентам, мне нужно на каждый адрес поднимать neighbor proxy
Согласен, неудобно. Впрочем, если бы на каждый сервер выдавалась сеть /64, это бы тоже не позволило выдавать VPN-клиентам адреса без костылей. Мне нравится как делает Linode и Veesp: на сервер выдается 1 ipv6 адрес и на него отдельная /64 или /48 сеть, маршрутизируемая через первый адрес. Это позволяет мне выдавать VPN клиентам ipv6 адреса ВООБЩЕ без настройки. Достаточно включить форвардинг ipv6 в sysctl.
Такой принцип распределения соответствует целям стандарта и на голову выше колхоза, который предлагают хостеры со своими фиксированными мелкими диапазонами.
Согласен, круто иметь VPC в базе.
Только ветка началась с моего удивления требованию выделять /64 на сервер, что противоречит стандарту (он оперирует клиентами), потребует дополнительной настройки и будет гонять трафик между серверами в стойке через шлюз.
Я вижу два возможных сценария блокировки соединения при распространении ESNI:
1. DNS-серверы провайдера будут блокировать запросы на поддомен
2. Системы DPI провайдера будут блокировать соединения с использованием ESNI. Для шифрованного SNI используется отдельное поле в пакете TLS ClientHello, и для DPI это выглядит так, будто TLS-сессия устанавливается без использования SNI. Некоторые DPI разрывают такие соединения, если они устанавливаются к IP-адресу, на котором расположен заблокированный домен с этим IP-адресом, из-за того, что нельзя понять, к какому домену происходит обращение.
Чтобы системы с подставными перенаправляющими DNS-ответами работали корректно, нужно отключать DNSSEC и DNS over HTTPS в браузерах.
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 в браузерах.
Как настроить Windows?
Первая ссылка в гугле
https://dnsprivacy.org/wiki/display/DP/Windows+installer+for+Stubby
Советую закомментировать в конфиге дефолтные адреса и раскомментировать Cloudflare: они быстрее гугловских.
> {'8.8.8.8', hostname='1.1.1.1'},
Чтобы дополнительно запутать предполагаемого противника?
Чтобы дополнительно запутать предполагаемого противника?
Немного оффтопик, но раз уж мы говорим за блокировки: с удивлением для себя обнаружил, что мой провайдер отдаёт нефильтрованный трафик в том случае, если клиент заказал себе белый IP. Из технических нюансов — адрес выдаётся из другой автономки, нежели та, из которой берутся адреса для NAT, плюс перестали, наконец, спуфить DNS.
Я всё пытаюсь понять, чем это обсуловлено. Я почти уверен, что на каждого клиента, попросившего белый IP, маршрутизацию пишут вручную — ибо это, прости господи, в 2018-м году потребовало приезда монтажника (!!!), который полчаса ковырялся в несчастном 3Com'е, и заняло в целом четыре дня. Таким образом, завернуть трафик на фильтрацию становится технически едва ли не проще.
Я всё пытаюсь понять, чем это обсуловлено. Я почти уверен, что на каждого клиента, попросившего белый IP, маршрутизацию пишут вручную — ибо это, прости господи, в 2018-м году потребовало приезда монтажника (!!!), который полчаса ковырялся в несчастном 3Com'е, и заняло в целом четыре дня. Таким образом, завернуть трафик на фильтрацию становится технически едва ли не проще.
Просто накосячили или поленились нормально настроить.
Как называется ваш провайдер?
Это случаем не ТТК? Я заказывал у них подключение со статическим IP. Приехали, долго тыкались в существующем подключении, сказали надо менять порт. Нашли ключи, порт поменяли, заработало. Но статического IP нет, говорят позже будет. Жду вечера, день, два… звоню в ТП, мол где мой статический IP. Пожали плечами, мол заявку оформляю. Жду день, два, три… Звоню снова в ТП. Говорят перезвоним. На следующий день звонок, мол вам нужно приехать в офис (а он один на весь Новосибирск), написать письменное заявление на статический IP адрес, потому что «в вшаем доме не прописан нужный VLAN»!!! Подключил другого провайдера и послал их лесом. Правда в офис всё-таки пришлось ехать договор расторгать.
Нет, что вы, это контора куда скромнее.
Культура работы и общения с клиентами у них не слишком далеко ушла от районных сетей середины нулевых, но к стабильности докопаться не могу — все работает как часы. Даунтаймы бывают, но в основном, по вине третьих лиц вроде коммунальщиков или водятлов, сваливших столб с оптикой.
Не знаю как сейчас, а раньше замечал 8.8.8.8 в небольшой фильтрации. Некоторые ресурсы, которые по мнению Google считаются пиратскими, не резолвились.
В итоге плюнул и перешёл на DNSCrypt.
В итоге плюнул и перешёл на DNSCrypt.
А если использовать
— там вроде обещали без цензуры?
- 1.1.1.1
- 1.0.0.1
- 2606:4700:4700::1111
- 2606:4700:4700::1001
— там вроде обещали без цензуры?
Вот вам альтернативные конфигурации knot-resolver на всякий случай:
Cloudflare (обещает вообще без фильтрации):
Quad9 (вариант с валидацией DNSSEC, фильтрация вредоносных доменов):
Quad9 (вариант без валидации DNSSEC, без фильтрации доменов):
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'}
})))
Как настроить в Ubuntu?
НЛО прилетело и опубликовало эту надпись здесь
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 должно быть чуть меньше накладных расходов на каждый запрос.
В чем разница между DNS over TLS и over HTTPS.
По сути это почти одно и то же, с некоторыми нюансами.
DNS over TLS — TCP подключение происходит на порт 853, внутри тоннеля обычный DNS запрос. Провайдер видит что это DNS запрос но не может в него вмешаться.
DNS over HTTP — TCP подключение на порт 443, подобному обычному HTTPS. Внутри другой формат запроса, с HTTP заголовками. Однако для провайдера такой запрос будет виден как обычное HTTPS подключение. Полагаю, этот протокол был придуман на случай, когда DNS запросы к чужим серверам будут заблокированы, чтобы маскировать под обычный веб трафик. А так же, чтобы браузеры могли сами резолвить домены и не создавать при этом аномальный трафик.
При прочих равных, в DNS over TLS должно быть чуть меньше накладных расходов на каждый запрос.
НЛО прилетело и опубликовало эту надпись здесь
Пожалуйста, дополните ваш UPD. Интересно, чем всё-таки является DNSCrypt с технической точки зрения.
Также прошу написать, яем всё это добро отличается от DNSSEC.
Мне кажется, материал очень выиграет, если эти страшные слова будут разъяснены в одном месте.
Также прошу написать, яем всё это добро отличается от DNSSEC.
Мне кажется, материал очень выиграет, если эти страшные слова будут разъяснены в одном месте.
Тут один товарищ прикрутил DNS over TLS к рутованному микротику:
https://forum.mikrotik.com/viewtopic.php?t=132678#p693725
Кто может глянуть — возможно ли это сделать без рута?
Думаю, на уровне маршрутизатора внедрить это дело было бы удобнее, чем на каждом конечном устройстве отдельно.
https://forum.mikrotik.com/viewtopic.php?t=132678#p693725
Кто может глянуть — возможно ли это сделать без рута?
Думаю, на уровне маршрутизатора внедрить это дело было бы удобнее, чем на каждом конечном устройстве отдельно.
Есть инструкция по настройке на OpenWRT (LEDE) от cloudflare blog.cloudflare.com/dns-over-tls-for-openwrt
Сам не пробовал.
Сам не пробовал.
попробовал, пашет, но сломал unbound'ом dhcp в локалке, как починить не знаю
Это распространённая проблема.
Поэтому я предпочитаю резолвер держать на одноплатнике внутри сети, и просто на него перенаправлять запросы от dnsmasq, который их уже кеширует.
ЗЫ: кстати, еще одна проблема подобного конфига с OpenWRT будет заключаться в том, что у них покамест даже в 18.04 и снэпшотах, используется слегка устаревшая версия OpenSSL, функционала которой недостаточно для проверки сертификатов.
Таким образом, верифицировать подпись DNS-сервера на OpenWRT вам не удастся. Единственный рабочий вариант сейчас — форсить игнор проверки подписи, что СЛЕГКА нивелирует весь смысл затеи.
Поэтому я предпочитаю резолвер держать на одноплатнике внутри сети, и просто на него перенаправлять запросы от dnsmasq, который их уже кеширует.
ЗЫ: кстати, еще одна проблема подобного конфига с OpenWRT будет заключаться в том, что у них покамест даже в 18.04 и снэпшотах, используется слегка устаревшая версия OpenSSL, функционала которой недостаточно для проверки сертификатов.
Таким образом, верифицировать подпись DNS-сервера на OpenWRT вам не удастся. Единственный рабочий вариант сейчас — форсить игнор проверки подписи, что СЛЕГКА нивелирует весь смысл затеи.
А поподробнее можно про верификацию можно? У меня был unbound на openwrt 18.04 с верификацией сертов.
А вы уверены, что она работала?
Проверьте логи, у меня при попытке зафорсить ее включение, в логах были месседжи об ошибке проверки подписи.
Да, иначе у меня резолвинг бы не работал. И когда я указывал проверяемый хостнейм неправильно, то он и действительно не работал. В данный момент я перешёл на stubby из-за меньшего объёма потребляемой памяти — она мне нужна для других важных фич.
Возможно, разница в том, что я ставил самый последний ipk с unbound, который был доступен — в unbound из основного репозитория такой фичи не было вообще. Но проблема точно не в openssl, он проверяет сертификаты нормально во всех приложениях и никаких особенностей в отношении unbound тут нет.
Возможно, разница в том, что я ставил самый последний ipk с unbound, который был доступен — в unbound из основного репозитория такой фичи не было вообще. Но проблема точно не в openssl, он проверяет сертификаты нормально во всех приложениях и никаких особенностей в отношении unbound тут нет.
А почему они все хотят TCP? Почему не шифровать запросы в udp? Меня идея засунуть state в stateless-протокол напрягает.
А мне наоборот нравится TCP, потому что тогда можно выставлять рекурсивный резолвер в интернет и при этом не превращаться в часть DDoS ботнета которого используют для UDP амплификации. Ну и TLS по UDP, наверное, не так просто реализовать.
В firefox с его встроенным DNS over HTTPS используется keep-alive для TCP подключения, так что по сути резолв может работать подобно UDP: один пакет с запросом --> один ответ.
В firefox с его встроенным DNS over HTTPS используется keep-alive для TCP подключения, так что по сути резолв может работать подобно UDP: один пакет с запросом --> один ответ.
Вот именно это меня и напрягает. Если у нас пакеты шлются в существующий канал, то если этот канал ушёл в один из уголков TCP, то возвращаться он будет долго. Переупорядоченные пакеты, потерявшийся ack на dup, etc… Там же бездна.
В libc по умолчанию таймаут в 5 секунд (man resolv.conf), если явно в resolv.conf не исправить на что-то поменьше.
Persistent DNS Connections for Reliability and Performance
Прочитал. «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.
Я понимаю их аргументы, я понимаю, что там есть таймауты, но я точно знаю, что tcp за счёт гарантий доставки более капризный, чем udp. Он делает гарантированную доставку, но так долго, что лучше не.
Я могу дать простой пример: сеть с 75% потерь. Мне нужно в среднем около 6 попыток, чтобы получить UDP/DNS ответ в такой сети. 6*5 = 30 секунд. Теперь вопрос, а сколько мне нужно попыток, чтобы установить tcp соединение и передать через него запрос? Удвоение числа пакетов, нужных для успешной отправки резко ухудшает мои шансы.
Заметим, в случае в UDP-повторами мне всё равно какой из ответов я получу. Любой из прорвавшихся ответов меня устроит. В случае с TCP, даже если мне придёт запоздалый ответ, я в ответ пришлю rst, потому что это «не в ту сессию».
Короче, у меня скепсис насчёт tcp/dns.
сеть с 75% потерь
А каким транспортным протоколом можно пользоваться в такой сети для решения каких-либо прикладных задач? Я не говорю что такие ситуации нереальны, но в действительно же будет почти невозможно пользоваться ничем.
Кстати в таких сетях отлично работает mosh для ssh. Хозяйке на заметку.
Иногда просто нет выбора. И тогда очень обидно, что всё ломается ещё на этапе dns.
Вы едете в поезде по степям Украины всего в 5км от ближайшего города с 4Г, ага.
С обычным dns — у вас будет шанс загрузить чегото сильно больше(особенно учитывая, что каждая страничка отправляет до полусотни днс запросиков).
С обычным dns — у вас будет шанс загрузить чегото сильно больше(особенно учитывая, что каждая страничка отправляет до полусотни днс запросиков).
Вспоминаю как я пытался на Кипре залить на сервер в Питере 100 гигов и отказался от этой затеи как раз из-за сети с кучей потерь, там это почти норма.
но в действительно же будет почти невозможно пользоваться ничем.Некоторые шутеры могут и не заметить (не уверен про 75%, но до 50% держат по крайней мере два). Потому что их разработчики уже наматюкались на TCP уже при 1% потерь пакетов.
Тут как раз трюк в том что соединения не прибиваются, аля мы "экономим" на хендшейке. Cкепсис правильный, работая с серверами я забыл что потери бывают разные.
Мобильные телефоны как раз регулярно имеют дело с потерями пакетов и у них, как я понял, stub резолвер умный и уже приспособлен к описанной ситуации.
Есть экспериментальный 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
Можно пользоваться DNSCrypt, протокол у него отличный, просто, по какой-то причине, они не заморочились с его публикацией в качестве RFC. dnscrypt-proxy поддерживает и DNSCrypt, и DNS over HTTPS.
В TLS достаточно тяжеловесное установление сессии с использованием ассиметричной криптографии. Когда сессия установлена, данные быстро шифруются симметричным ключём, полученным при установлении сессии.
Кто-то пробовал ставить по этой инструкции 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У меня Mojave, работает без проблем. Покажите конфиг knot-resolver и еще это:
ls -la /usr/local//lib/libknot.8.dylib
ls -la /usr/local//Cellar/knot-resolver/3.0.0/lib/kdns_modules/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…
Листинг лучше спрятать под спойлер. У вас наверное не установлен knot, хотя он должен был подтянуться в зависимостях. Установите его вручную:
brew install knot Проблема с 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.Теперь понятно куда копать, спасибо.
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.
После этого всё ещё может не завестись. Пришлось сделать реинсталл, после стопнуть и запустить сервис заново (рестарт не помогал). Может быть реинсталл лишний.
для настройки DoH в Android 9 нужно указать один домен через которых произойдет автоконфигурация. В случае с cloudflare это домен 1dot1dot1dot1.cloudflare-dns.com.
Судя по всему это домен у которого оба резолвера указаны в A и AAAA записях соответственно:
А есть ли такой же домен для гугл dns?
Судя по всему это домен у которого оба резолвера указаны в 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?
Я нашел домен для гугла в сертификате: dns.google
У него так же как и cloudflare сделано:
У него так же как и 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
На OSX mojave спустя разные интервалы времени 1-4 часа сервис падает с сообщением в логе
После падения соответственно DNS перестаёт работать до перезапуска вручную
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. Можно ли как-то настроить автоматический моментальный перезапуск при падении?Если не сложно, то можете попробовать другой вариант.
Я для себя писал подобный прокси простенький на базе либы «miekg/dns», специально для DNS-over-TLS и DNS-over-HTTPS и максимально простым конфигом, локально у меня нормально работает. Вот исходники, он на Go, так что соберется и под Мак — github.com/Onlinehead/dns-to-dns-tls
Plst для автозапуска правда не делал, потому что у меня в контейнере живет на сервачке.
Правки приветствуются.
Я для себя писал подобный прокси простенький на базе либы «miekg/dns», специально для DNS-over-TLS и DNS-over-HTTPS и максимально простым конфигом, локально у меня нормально работает. Вот исходники, он на Go, так что соберется и под Мак — github.com/Onlinehead/dns-to-dns-tls
Plst для автозапуска правда не делал, потому что у меня в контейнере живет на сервачке.
Правки приветствуются.
Во первых создайте репорт об этой проблеме в багтрекере gitlab.labs.nic.cz/knot/knot-resolver/issues (можно войти с аккаунтом github)
Вот измененный конфиг launchd который будет перезапускать knot в случае падения
Вот измененный конфиг 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>
Столкнулся с аналогичной проблемой, периодически после выхода мака из сна сервис падал с сообщением в логе:
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 пофиксили ряд багов, связанных с подобного рода проблемами.
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 пофиксили ряд багов, связанных с подобного рода проблемами.
Ради минимальных приличий хоть напишите, что грязными лапами в список посещённых доменов после этого будут лезть Google и Cloudflare, и что это всё делается не ради помощи бедным пользователям и их безопасности, а для борьбы с конкурентами, получающими поведенческие данные в тех точках, куда указанным компаниям не дотянуться.
Гугл и cloudflare по крайней мере не были замечены в инъекциях рекламы в HTTP трафик и модификации моих сайтов. В отличии от мегафона и билайна.
Вообще я сомневаюсь что данные о резолвах открывают такое больше поле для аналитики. При обычном серфинге, вы, скорее всего, зарезолвите все те же ресурсы, что и при целевом посещении. Условно говоря, при поиске товаров для животных вы так или иначе зарезолвите vk.com, youtube.com, google.com и еще кучу доменов. Как из этого можно сделать поведенческий профиль? Резолв не дает так много информации, как например, трекеры на сайтах. Так что полагаю, что скорее всего, эти сервисы сделаны больше для того, чтобы доставлять свою рекламу в неизменном виде, чтобы по пути ее не резали блокировщиками и не подменяли на другую, а не столько для трекинга пользователей.
Вообще я сомневаюсь что данные о резолвах открывают такое больше поле для аналитики. При обычном серфинге, вы, скорее всего, зарезолвите все те же ресурсы, что и при целевом посещении. Условно говоря, при поиске товаров для животных вы так или иначе зарезолвите vk.com, youtube.com, google.com и еще кучу доменов. Как из этого можно сделать поведенческий профиль? Резолв не дает так много информации, как например, трекеры на сайтах. Так что полагаю, что скорее всего, эти сервисы сделаны больше для того, чтобы доставлять свою рекламу в неизменном виде, чтобы по пути ее не резали блокировщиками и не подменяли на другую, а не столько для трекинга пользователей.
Никого ничему история не учит: вы сейчас доказываете, что Microsoft большой (больше всех!), и что предложение добавить в веб OLE с внешним исполнимым кодом взлетит, «потому что это Microsoft, а не какая-то местная конторка».
Вы сомневаетесь, а они не сомневаются. Это не благотворительные организации; то, что не приносит дохода, закрывается. Запросы к DNS дают не просто список доменов, а список доменов с точным временем перехода к ним — это и круглосуточный портрет пользователя, и статистика для всех сайтов (даже не имеющих ни одного трекера, даже при использовании блокировщика ни клиенте), и возможность легко объединить посещения конкретного пользователя со статистикой GA по нему. Cloudflare не сомневается, что халявный трафик через их сервера для любого желающего приносит прибыль, а не одни лишь убытки. Подрезали Google крылышки GDPR — встроенные карты тут же стали платными, потому что контент жирный, а сбор с него информации впрок теперь запрещён. Сравните старые и новые цены за доступ к технологии, чтобы прикинуть, во сколько это обходится.
Мы имеем то, что имеем, не в результате того, что кто-то пришёл с ружьём и всех заставил, а в результате множества таких вот компромиссов, но даже предложение признать проблему — не говоря уж об отказе от использования — встречается с недоумением. С таким вот диджитал резистанс все причастные могут спать спокойно.
Вы сомневаетесь, а они не сомневаются. Это не благотворительные организации; то, что не приносит дохода, закрывается. Запросы к DNS дают не просто список доменов, а список доменов с точным временем перехода к ним — это и круглосуточный портрет пользователя, и статистика для всех сайтов (даже не имеющих ни одного трекера, даже при использовании блокировщика ни клиенте), и возможность легко объединить посещения конкретного пользователя со статистикой GA по нему. Cloudflare не сомневается, что халявный трафик через их сервера для любого желающего приносит прибыль, а не одни лишь убытки. Подрезали Google крылышки GDPR — встроенные карты тут же стали платными, потому что контент жирный, а сбор с него информации впрок теперь запрещён. Сравните старые и новые цены за доступ к технологии, чтобы прикинуть, во сколько это обходится.
Мы имеем то, что имеем, не в результате того, что кто-то пришёл с ружьём и всех заставил, а в результате множества таких вот компромиссов, но даже предложение признать проблему — не говоря уж об отказе от использования — встречается с недоумением. С таким вот диджитал резистанс все причастные могут спать спокойно.
А вы не думали, что Google собирает данные просто для ранжирования сайтов в выдаче?
Это их основной продукт.
В любом случае, какой бы DNS вы ни использовали, данные будут кому-то утекать. Что ж, теперь, вообще Интернетом не пользоваться?
Это их основной продукт.
В любом случае, какой бы DNS вы ни использовали, данные будут кому-то утекать. Что ж, теперь, вообще Интернетом не пользоваться?
«В какой бы магазин вы ни пошли купить мяса, вам в итоге навалят обрезков, костей, грязных тряпок, и ещё под зад пнут ногой».
Не очень привычная логика, не находите?
Не очень привычная логика, не находите?
Я давно пропагандирую среди знакомых ставить локально или в приватной сети резолвер, который ходит прямо в рутовые сервера. unbound без форвардинга например, заодно и свою зону можно завести. Он даже биндовые файлы зон умеет.
Рутовые сервера пропускают через себя слишком обезличенный и огромный поток, и контролируются хотя бы не корпорацией напрямую.
Если кто боится, что это нагрузит рутовые сервера днс — смешно. Запас мощности там на несколько порядков.
Рутовые сервера пропускают через себя слишком обезличенный и огромный поток, и контролируются хотя бы не корпорацией напрямую.
Если кто боится, что это нагрузит рутовые сервера днс — смешно. Запас мощности там на несколько порядков.
Это отличная новость!
К примеру, ростелеком гарантированно меняет содержимое перенаправляя на рекламу своих пакетов. Техподдержка говорит, что РТ так доносит предложения, но на письмо на каком основании нет, они такой фигней не занимаются.
К примеру, ростелеком гарантированно меняет содержимое перенаправляя на рекламу своих пакетов. Техподдержка говорит, что РТ так доносит предложения, но на письмо на каком основании нет, они такой фигней не занимаются.
Проверьтесь на вирусы/используйте другой компьютер. Есть небольшой шанс что они не врут. AdwCleaner может помочь. У меня такая фигня както раз была, большинство антивирусов ничего не находят, тк реклама по их мнению не вирус, а нежелательное по.
На мой запрос по какой причине производится замена результата пришел ответ с адреса no-reply@rt.ru:
Есть нюансы:
1 — Все, что происходит в системе я знаю, никаких сюрпризов нет и AdwCleaner у меня запустится только в виртуалке или под вайном. Ну не использую я винду и хорошо знаю что у меня в лялихе крутится.
2 — ТП в РТ сообщал о том, что это способ донести предложение. Цитирую: «Ростелеком старается предоставлять различным способами, включая показ при открытии сайтов. Очень жаль, если данный вариант Вас огорчил.» Но в письме с no-reply@rt.ru «Средствами АСР Ростелеком редирект не производится.»
3 — Редирект произошел после того, как я руками вбил в адресную строку store.steampowered.com (то есть не переход по ссылке) и открылась реклама тарифа РТ с каким-то аккаунтом танков и с доп танками.
В сухом остатке: видя, что я хочу перейти на игровой портал мне предлагают игровой тариф и говорят, что это не они устраивают MITM, а валв переводит трафик к своим конкурентам в надежде снизить посещаемость и продажи.
Простите, но это смешно.
Уважаемый абонент, Ваша претензия № 47511808 рассмотрена По фактам, указанным в Вашем обращении, проведена проверка. Редирект произведен с сайта store.steampowered.com. Это могло произойти как как на стороне сервера, так и на стороне клиента (в браузере). Средствами АСР Ростелеком редирект не производится.
Есть нюансы:
1 — Все, что происходит в системе я знаю, никаких сюрпризов нет и AdwCleaner у меня запустится только в виртуалке или под вайном. Ну не использую я винду и хорошо знаю что у меня в лялихе крутится.
2 — ТП в РТ сообщал о том, что это способ донести предложение. Цитирую: «Ростелеком старается предоставлять различным способами, включая показ при открытии сайтов. Очень жаль, если данный вариант Вас огорчил.» Но в письме с no-reply@rt.ru «Средствами АСР Ростелеком редирект не производится.»
3 — Редирект произошел после того, как я руками вбил в адресную строку store.steampowered.com (то есть не переход по ссылке) и открылась реклама тарифа РТ с каким-то аккаунтом танков и с доп танками.
В сухом остатке: видя, что я хочу перейти на игровой портал мне предлагают игровой тариф и говорят, что это не они устраивают MITM, а валв переводит трафик к своим конкурентам в надежде снизить посещаемость и продажи.
Простите, но это смешно.
Ждём гайда по настройке этого в OpenWRT.
Это старое руководство для старой версии unbound (<1.6.1), которая не валидирует SAN сертификата. В таком виде DoT бесполезен. Вот статья, освещающая проблему и предоставляющая правильную конфигурацию.
А как теперь будут работать CDNы, локальные копии и тому подобное?
НЛО прилетело и опубликовало эту надпись здесь
Что мешает провайдеру заблокировать все исходящие запросы на 853 порт?
Тем самым вынудить всех использовать стандартный, легко модифицируемый протокол по 53 порту.
Тем самым вынудить всех использовать стандартный, легко модифицируемый протокол по 53 порту.
Теоретически ничто не мешает. Но это уже проблема сетевого нейтралитета. Если его у нас узаконят, то будет закон, который и будет мешать. С другой стороны, ничто не мешает ввести закон, запрещающий порт 853 в принципе, или любой другой бредовый закон. С фантазией в нашей стране проблем нет, так что законы всё «лучше» и «лучше».
Тогда будем использовать DNS over HTTPS. Его будет крайне сложно запретить не сломав при этом интернет целиком.
DoH ломает концепцию, что DNS является «Control Plane» Интернет. Внезапно DNS оказывается на «Data Plane». Это не мои слова, это Paul Vixie.
Скорости работы ни от DoT ни от DoH ждать не приходится.
По скорости, среднем в РФ у провайдеров DNS сервера медленнее гуглового сервиса, иногда в разы.
За исключением Ростелекома Северо-Западного макро филиала, DNS сервера которого работают быстрее чем Google Public DNS уже несколько лет.
Скорости работы ни от DoT ни от DoH ждать не приходится.
По скорости, среднем в РФ у провайдеров DNS сервера медленнее гуглового сервиса, иногда в разы.
За исключением Ростелекома Северо-Западного макро филиала, DNS сервера которого работают быстрее чем Google Public DNS уже несколько лет.
На счет медленнее гуглового.
1. Dnscrypt можно было запускать как два сервиса на разных портах и разный сервер, а при связке с Dnsmasq можно было давать команду «all-servers» и в «server» указывать данную пару. В итоге получалось что запрос от dnamasq уходил по двум направлениям Dnscrypt с разными серверами, который ответ быстрей приходил тот и активный в итоге.
2. Dnscrypt 2 уже использует алгоритм определения быстрого сервера из заданного списка «server_names». Определяет «Server with the lowest initial latency» и берет самый наименьший.
При использовании
Данный сервер «cloudflare» ни когда не попадает в «latency» меньше чем у трех серверов ...1,...2,...3 у которых значение по логу dnscrypt от «rtt:17-40ms».
Хоть и собран dnscrypt 2 на GO и в итоге
3. Быстродействие того или иного сервера DNS лучше оценить например такой старенькой программкой DNSBench.
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.
А что со скоростью резолва, собственно? Сколько раньше ни попробовал, меньше 500-700ms на холодную не получалось добиться. А это совсем не юзабельно. Может, не так что-то делал? Накручивал всякие fast open, keepalive, etc. Бестолку.
При том, что чистый днс ходит на гугл за 10-15мс.
При том, что чистый днс ходит на гугл за 10-15мс.
Здорово, спасибо. Грешным делом подумал, что это поможет заходить на заблокированные сайты, установил и вспомнил, что блокад по айпи) Кстати, после установки сломался xcodebuild, исправил с помощью sudo xcode-select -s /Applications/Xcode.app/Contents/Developer.
Только в отличие от 1.1.1.1 у 8.8.8.8 нет сертификата на 8.8.8.8. Но забавно. Судя по всему там и DoH есть
Всё там есть. И сертификат даже IPv6-адреса покрывает. DoH они уже давно запустили, вроде даже первыми.
Только в отличие от 1.1.1.1 у 8.8.8.8 нет сертификата на 8.8.8.8.
Вы ошибаетесь, сертификат у них есть на все IP, в том числе и ipv6. Это можно проверить так:
Раскрыть спойлер
Получить x509 сертификат подключившись к порту 853:
Берем сертификат
И смотрим SAN:
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 есть
Да, об этом написано в первой строчке поста.
Да, сертификат я на 443 смотрел. Там — нет. В первой строчке чушь написана. Это не про 8.8.8.8. И кстати по ссылке посмотрите, что у гугля написано. Я даже каментом ниже упомянул это.
И очень странный обзор технологий. DNSCrypt это адаптация DNSCurve, сделанная opendns для ресолверов. А DNSCurve это детище Даниэля Бернштейна, которому не нравился DNSSEC, но зато он разработал Ecliptic Curves. Т.е. это вообще ни разу не тестирование перед DoH. Кстати, DoH бывают два :) Один который DoH, а другой — JSON API Google. И да, Google поддерживает оба
Возможно это прозвучит странно, но есть серьезные сомнения в квалификации сотрудников Google, которые занимаются Google Public DNS. Яркий пример — они делали общий, разделяемый несколькими нодами кеш для разных инстансов сервиса. При том, что при их (большой) нагрузке это не могло привести к улучшению наполненности и актуальности кеша, если каждый инстанс обслуживает от 50,000 QPS и выше. Давление на кеш при такой нагрузке уже нормальное и он вполне себе наполнен актуальной информацией. Выигрыша от разделяемого кеша DNS между нодами в таком случае нет совсем или, даже если он и есть, то мизерный и смысла бороться за него серьезным увеличением сложности не стоило.
Теперь DoH, который ну совсем никак ни про производительность, ни про задержки, а только слом концепции, что DNS это «Control Plane» Интернет.
Теперь DoH, который ну совсем никак ни про производительность, ни про задержки, а только слом концепции, что DNS это «Control Plane» Интернет.
DoH это не гуглевская тема. Да, на сегодняшнем уровне развития и серверного оборудования, и каналов — проблема «Control Plane» Интернет стала более актуальной. Правда, у Google действительно странный подход к DNS. Они например придумали DANE и сами же его убили и лет пять потом не проявляли интереса вообще к DNSSEC
И правильно делают, этому протоколу суждено скончаться, не увидев массового внедрения. Все причины, почему ему не (стоит) жить, изложены во множестве статей — не буду приводить ссылки. Однако приведу одну другую, на блог APNIC, где можно найти интересное предложение как DoT может заменить DNSSEC, если будет использоваться ещё и между рекурсорами и авторитативными серверами. Как по мне, то у такой схемы гораздо больше шансов случиться.
www.slideshare.net/schors/a-popular-dns-security-overview-modern-theory-and-practice-116166410
Я тут вкратце, но объясняю проблемы DNSCurve. С DoT будет примерно так же. Плюс DNSSEC изначально незвисимая от SSL PKI тема, как независимая дублирующая в чем-то. У DNSSEC конечно тоже пачка своих проблем, но всё же.
Да уж давайте. Большинство этих статей или уже неактульны, или нытьё.
Я тут вкратце, но объясняю проблемы DNSCurve. С DoT будет примерно так же. Плюс DNSSEC изначально незвисимая от SSL PKI тема, как независимая дублирующая в чем-то. У DNSSEC конечно тоже пачка своих проблем, но всё же.
изложены во множестве статей
Да уж давайте. Большинство этих статей или уже неактульны, или нытьё.
В вашем случае далеко ходить не нужно:
Нигде нет DNSSEC. Значит, так он важен для всех.
Подконтрольная одному государству. Ну и регистратор домена может заменить DS любого домена при случае. Не очевидно, почему эти люди, у которых даже бизнес особо не завязан на гарантии их подписи, заслуживают большего доверия, чем имеющиеся удостоверяющие центры.
Одна из статей, которую смог найти и она заслуживает внимания.
Из личных впечатлений — для того, чтобы иметь гарантии, которые DNSSEC должен предоставлять, я должен держать непосредственно на моём устройстве валидирующий dnssec резолвер. Я обхожусь на ноутбуке dnssec-trigger и unbound на ноутбуке, однако это дно и это нужно сжечь огнём. Проблема с NSEC и NSEC3 действительно актуальна, и пока кое-какое костыльное решение смогли предоставить только Cloudflare в своей реализации DNSSEC. И то, ценой того, что авторитативный сервер всё же имеет доступ к ключам для подписи.
Сегодня DNSSEC, как и IPv6 — игрушки для гиков, реальный бизнес от них не зависит.
Нигде нет DNSSEC. Значит, так он важен для всех.
Плюс DNSSEC изначально незвисимая от SSL PKI тема, как независимая дублирующая в чем-то.
Подконтрольная одному государству. Ну и регистратор домена может заменить DS любого домена при случае. Не очевидно, почему эти люди, у которых даже бизнес особо не завязан на гарантии их подписи, заслуживают большего доверия, чем имеющиеся удостоверяющие центры.
Одна из статей, которую смог найти и она заслуживает внимания.
Из личных впечатлений — для того, чтобы иметь гарантии, которые DNSSEC должен предоставлять, я должен держать непосредственно на моём устройстве валидирующий dnssec резолвер. Я обхожусь на ноутбуке dnssec-trigger и unbound на ноутбуке, однако это дно и это нужно сжечь огнём. Проблема с NSEC и NSEC3 действительно актуальна, и пока кое-какое костыльное решение смогли предоставить только Cloudflare в своей реализации DNSSEC. И то, ценой того, что авторитативный сервер всё же имеет доступ к ключам для подписи.
Сегодня DNSSEC, как и IPv6 — игрушки для гиков, реальный бизнес от них не зависит.
Нигде нет DNSSEC. Значит, так он важен для всех.
У меня! У меня есть!
zhovner.comХотя согласен, особой пользы от него нет.
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 например.
Точно нет?
Да, на одном есть — проморгал.
Но напомните мне кейсы такого?Кейсы внедрения самого DNSSEC не так часты, а уж тем более завязывания сертификатов на него. Провинившийся PKI CA можно легко выкинуть из хранилища доверенных корневых сертов. Тут либо небольшое преимущество обычного PKI, либо паритет — понять пока трудно, цепь доверия DNSSEC в дикой природе используется не так давно, не так активно.
Набор неинженерного нытья и голословных утверждений на основании «очевидно».Навешивание ярлыков, которое применимо и к вашим высказываниям.
Тренд сейчас вообще проверять на софтине. Для пассивного использования достаточно комбинировать с удаленным ресолвером, который сам валидирует. Например, через DoT и DoHПро тренд — сильное утверждение, проверять я его конечно не буду. Про комбинацию с DoT, DoH — вот и получается, что технология сама даже со своей функцией не справляется. На этом фоне решение использовать DoT между резолвером и авторитативным сервером выглядит гораздо привлекательнее, DNSSEC опять лишний выходит. Как правильно замечено в той статье, DNSSEC не обязан случиться. Если бы в него кто-то верил, стандарт MTA-STS не появился бы. Его бросили все крупные компании и авторы стандартов, увы.
Хорошо, поговорите об этом с Cloudflare например. Сразу перед беседой EBITDA'у свою достаньте, чтобы ваш разговор так скажем был на одном уровне :)Демагогический приём «сперва добейся». Бизнес Cloudflare никак не поменяется от отсутствия DNSSEC. И IPv6 у них тоже постольку-поскольку всё должно быть. Вернёмся за примером к двум сайтам вначале моего предыдущего сообщения: у одного нет IPv6, у другого нет DNSSEC, и никакой пользы нет, если они появятся.
А вот с доступом к ключам тут сложно. Оверинжиниринг на мой взгляд. У сайтов к своим ключам тоже доступ есть. Да, это действительно немнго уменьшает секьюрность. Но всё-таки.
Я согласен. Я считаю, кто прям сильно хочет — пусть ключ свой на HSM выносит.
На самом деле интересно что будет дальше…
Предположим, что Google включил DoT и DoH у себя на серверах. Означает ли это, что в обозримом будущем все Андроид-устройства перейдут на DoT/DoH? Если Да, то какие сервера они для этого будут использовать? Если Google выберет для этого свои сервера, то им придется чуток их «расширить и углубить». DNS трафика от мобильных абонентов реально много и сейчас только несколько процентов из них идут не на резолверы оператора, а на те же 8.8.8.8/8.8.4.4. Или предполагается, что операторы будут поднимать на своих резолверах DoT/DoH?
Еще интересно что по этому поводу думает Apple и Microsoft?
Предположим, что Google включил DoT и DoH у себя на серверах. Означает ли это, что в обозримом будущем все Андроид-устройства перейдут на DoT/DoH? Если Да, то какие сервера они для этого будут использовать? Если Google выберет для этого свои сервера, то им придется чуток их «расширить и углубить». DNS трафика от мобильных абонентов реально много и сейчас только несколько процентов из них идут не на резолверы оператора, а на те же 8.8.8.8/8.8.4.4. Или предполагается, что операторы будут поднимать на своих резолверах DoT/DoH?
Еще интересно что по этому поводу думает Apple и Microsoft?
В 9-ом Андроиде уже
Что уже? Он уже ходит на сервера Google?
Он уже DoH из коробки
Вопрос не в том что у него «из коробки», а какие резолверы он использует и можно ли это поменять? Оператором это может облегчить жизнь как минимум тем, что не нужно будет расширять резолверы. А вот если адреса нельзя поменять, то Google может нарваться на иск от того же Yandex, что нельзя использовать «Семейный DNS».
НЛО прилетело и опубликовало эту надпись здесь
на всякий случай: www.securitylab.ru/vulnerability/495369.php
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Google Public DNS тихо включили поддержку DNS over TLS