Комментарии 147
Господа, что можно настроить под linux без долгой ругани, с возможностью часть доменной зоны(например работодатель.net) отдать на откуп вышестоящему dns работающему по-старинке.
работодатель.net
существует только на одном резолвере и не существует в интернете? Это интересный вопрос. Полагаю, что можно на сервере развернуть knot и задать ему апстрим сервера которые знают об этой зоне. Ну а на клиенте уже настроить dns over tls до этого сервера.nameserver 127.0.0.2
или аналогичной в /etc/resolv.conf
), можно прописать определенным зонам определенный сервер DNS, в /etc/dnsmasq.conf
.Точнее, прописывать надо в /etc/NetworkManager/dnsmasq.d/*.conf
.
Потому что NetworkManager запускает dnsmasq с опциями --conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq.d
.
Там весь конфиг можно в 20 строчек уложить. И локальные ресолверы на зоны настроить.
wiki.archlinux.org/index.php/unbound#Include_local_DNS_server
Там для форварда всех запросов делается так:
forward-zone:
name: "."
....
Соответственно, отдельную зону форвардить можно в отдельные NS.
Что за провайдер, если не секрет? Потенциальные новые клиенты должны знать героев, которые бегут вперёд паровоза РКН и заворачивают ДНС.
Что за провайдер, если не секрет?Дом.ру, например.
героев, которые бегут вперёдФильтрация DNS — официально рекомендуемый РКН способ для провайдеровпаровозаРКН
Операторам связи, не использующим DPI и осуществляющим ограничение доступа к доменному имени при помощи иных программных, аппаратных или программно-аппаратных средств, рекомендуется ограничивать доступ к доменному имени посредством фильтрации запросов ко всем DNS-серверам.
Да, я согласен, что за такое в приличных домах бьют канделябром по морде ибо нарушение связности.
Кроме того, DNS over TLS/HTTPS не спасает от блокировки по SNI. Так что РКН, скорее всего, даже не будет смотреть в сторону блокировки 8.8.8.8. Кстати, вы статью вообще читали?
Я вижу это так: специальным образом сконфигурированный DNS over TLS/HTTPS резолвер выборочно обрабатывает заблокированные сайты, подменяя их реальные IP на свои DNAT прокси. При этом проксируя только TCP. А так как SNI зашифрован, DPI не увидит к какому сайту запрос. Однако это может сломать DNSSEC, если владелец заблокированного домена решит подписать зону.
Возможно я где-то ошибаюсь, призываю ValdikSS раскидать по понятиям.
Вангую, что в ближайшем будущем, любые веб-сайты будут открываться с любых 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:
А можно поподробнее? Что и как делать?
Пробуем найти случайный 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.
Разве не на VLAN? Куда одному серверу столько?
DO ведь не даёт по /64 на дроплет и в AWS такая сеть выделается на VPC (фактически VLAN), а не на каждый инстанс EC2.
У хостера 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 на сервер, что противоречит стандарту (он оперирует клиентами), потребует дополнительной настройки и будет гонять трафик между серверами в стойке через шлюз.
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 в браузерах.
https://dnsprivacy.org/wiki/display/DP/Windows+installer+for+Stubby
Советую закомментировать в конфиге дефолтные адреса и раскомментировать Cloudflare: они быстрее гугловских.
Чтобы дополнительно запутать предполагаемого противника?
Я всё пытаюсь понять, чем это обсуловлено. Я почти уверен, что на каждого клиента, попросившего белый IP, маршрутизацию пишут вручную — ибо это, прости господи, в 2018-м году потребовало приезда монтажника (!!!), который полчаса ковырялся в несчастном 3Com'е, и заняло в целом четыре дня. Таким образом, завернуть трафик на фильтрацию становится технически едва ли не проще.
Просто накосячили или поленились нормально настроить.
Нет, что вы, это контора куда скромнее.
Культура работы и общения с клиентами у них не слишком далеко ушла от районных сетей середины нулевых, но к стабильности докопаться не могу — все работает как часы. Даунтаймы бывают, но в основном, по вине третьих лиц вроде коммунальщиков или водятлов, сваливших столб с оптикой.
В итоге плюнул и перешёл на DNSCrypt.
- 1.1.1.1
- 1.0.0.1
- 2606:4700:4700::1111
- 2606:4700:4700::1001
— там вроде обещали без цензуры?
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'}
})))
В чем разница между DNS over TLS и over HTTPS.
По сути это почти одно и то же, с некоторыми нюансами.
DNS over TLS — TCP подключение происходит на порт 853, внутри тоннеля обычный DNS запрос. Провайдер видит что это DNS запрос но не может в него вмешаться.
DNS over HTTP — TCP подключение на порт 443, подобному обычному HTTPS. Внутри другой формат запроса, с HTTP заголовками. Однако для провайдера такой запрос будет виден как обычное HTTPS подключение. Полагаю, этот протокол был придуман на случай, когда DNS запросы к чужим серверам будут заблокированы, чтобы маскировать под обычный веб трафик. А так же, чтобы браузеры могли сами резолвить домены и не создавать при этом аномальный трафик.
При прочих равных, в DNS over TLS должно быть чуть меньше накладных расходов на каждый запрос.
DNScrypt (к слову, ужасная мешанина технологий и пример оверинжиниринга) не имеет отношения к DNS-over-TLS.
Последний удобен, быстр и просто в настройке.
Также прошу написать, яем всё это добро отличается от DNSSEC.
Мне кажется, материал очень выиграет, если эти страшные слова будут разъяснены в одном месте.
https://forum.mikrotik.com/viewtopic.php?t=132678#p693725
Кто может глянуть — возможно ли это сделать без рута?
Думаю, на уровне маршрутизатора внедрить это дело было бы удобнее, чем на каждом конечном устройстве отдельно.
Сам не пробовал.
Поэтому я предпочитаю резолвер держать на одноплатнике внутри сети, и просто на него перенаправлять запросы от dnsmasq, который их уже кеширует.
ЗЫ: кстати, еще одна проблема подобного конфига с OpenWRT будет заключаться в том, что у них покамест даже в 18.04 и снэпшотах, используется слегка устаревшая версия OpenSSL, функционала которой недостаточно для проверки сертификатов.
Таким образом, верифицировать подпись DNS-сервера на OpenWRT вам не удастся. Единственный рабочий вариант сейчас — форсить игнор проверки подписи, что СЛЕГКА нивелирует весь смысл затеи.
А вы уверены, что она работала?
Проверьте логи, у меня при попытке зафорсить ее включение, в логах были месседжи об ошибке проверки подписи.
Возможно, разница в том, что я ставил самый последний ipk с unbound, который был доступен — в unbound из основного репозитория такой фичи не было вообще. Но проблема точно не в openssl, он проверяет сертификаты нормально во всех приложениях и никаких особенностей в отношении unbound тут нет.
В firefox с его встроенным DNS over HTTPS используется keep-alive для TCP подключения, так что по сути резолв может работать подобно UDP: один пакет с запросом --> один ответ.
В libc по умолчанию таймаут в 5 секунд (man resolv.conf
), если явно в resolv.conf не исправить на что-то поменьше.
Persistent DNS Connections for Reliability and Performance
Я понимаю их аргументы, я понимаю, что там есть таймауты, но я точно знаю, что tcp за счёт гарантий доставки более капризный, чем udp. Он делает гарантированную доставку, но так долго, что лучше не.
Я могу дать простой пример: сеть с 75% потерь. Мне нужно в среднем около 6 попыток, чтобы получить UDP/DNS ответ в такой сети. 6*5 = 30 секунд. Теперь вопрос, а сколько мне нужно попыток, чтобы установить tcp соединение и передать через него запрос? Удвоение числа пакетов, нужных для успешной отправки резко ухудшает мои шансы.
Заметим, в случае в UDP-повторами мне всё равно какой из ответов я получу. Любой из прорвавшихся ответов меня устроит. В случае с TCP, даже если мне придёт запоздалый ответ, я в ответ пришлю rst, потому что это «не в ту сессию».
Короче, у меня скепсис насчёт tcp/dns.
сеть с 75% потерь
А каким транспортным протоколом можно пользоваться в такой сети для решения каких-либо прикладных задач? Я не говорю что такие ситуации нереальны, но в действительно же будет почти невозможно пользоваться ничем.
Кстати в таких сетях отлично работает mosh для ssh. Хозяйке на заметку.
С обычным 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
Была ли у вас такая ошибка?
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
ls -la /usr/local//lib/libknot.8.dylib
ls -la /usr/local//Cellar/knot-resolver/3.0.0/lib/kdns_modules/
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…
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.
После этого всё ещё может не завестись. Пришлось сделать реинсталл, после стопнуть и запустить сервис заново (рестарт не помогал). Может быть реинсталл лишний.
Судя по всему это домен у которого оба резолвера указаны в 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?
У него так же как и 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
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 для автозапуска правда не делал, потому что у меня в контейнере живет на сервачке.
Правки приветствуются.
Вот измененный конфиг launchd который будет перезапускать knot в случае падения
<?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 пофиксили ряд багов, связанных с подобного рода проблемами.
Вообще я сомневаюсь что данные о резолвах открывают такое больше поле для аналитики. При обычном серфинге, вы, скорее всего, зарезолвите все те же ресурсы, что и при целевом посещении. Условно говоря, при поиске товаров для животных вы так или иначе зарезолвите vk.com, youtube.com, google.com и еще кучу доменов. Как из этого можно сделать поведенческий профиль? Резолв не дает так много информации, как например, трекеры на сайтах. Так что полагаю, что скорее всего, эти сервисы сделаны больше для того, чтобы доставлять свою рекламу в неизменном виде, чтобы по пути ее не резали блокировщиками и не подменяли на другую, а не столько для трекинга пользователей.
Вы сомневаетесь, а они не сомневаются. Это не благотворительные организации; то, что не приносит дохода, закрывается. Запросы к DNS дают не просто список доменов, а список доменов с точным временем перехода к ним — это и круглосуточный портрет пользователя, и статистика для всех сайтов (даже не имеющих ни одного трекера, даже при использовании блокировщика ни клиенте), и возможность легко объединить посещения конкретного пользователя со статистикой GA по нему. Cloudflare не сомневается, что халявный трафик через их сервера для любого желающего приносит прибыль, а не одни лишь убытки. Подрезали Google крылышки GDPR — встроенные карты тут же стали платными, потому что контент жирный, а сбор с него информации впрок теперь запрещён. Сравните старые и новые цены за доступ к технологии, чтобы прикинуть, во сколько это обходится.
Мы имеем то, что имеем, не в результате того, что кто-то пришёл с ружьём и всех заставил, а в результате множества таких вот компромиссов, но даже предложение признать проблему — не говоря уж об отказе от использования — встречается с недоумением. С таким вот диджитал резистанс все причастные могут спать спокойно.
Это их основной продукт.
В любом случае, какой бы DNS вы ни использовали, данные будут кому-то утекать. Что ж, теперь, вообще Интернетом не пользоваться?
Не очень привычная логика, не находите?
Рутовые сервера пропускают через себя слишком обезличенный и огромный поток, и контролируются хотя бы не корпорацией напрямую.
Если кто боится, что это нагрузит рутовые сервера днс — смешно. Запас мощности там на несколько порядков.
К примеру, ростелеком гарантированно меняет содержимое перенаправляя на рекламу своих пакетов. Техподдержка говорит, что РТ так доносит предложения, но на письмо на каком основании нет, они такой фигней не занимаются.
Уважаемый абонент, Ваша претензия № 47511808 рассмотрена По фактам, указанным в Вашем обращении, проведена проверка. Редирект произведен с сайта store.steampowered.com. Это могло произойти как как на стороне сервера, так и на стороне клиента (в браузере). Средствами АСР Ростелеком редирект не производится.
Есть нюансы:
1 — Все, что происходит в системе я знаю, никаких сюрпризов нет и AdwCleaner у меня запустится только в виртуалке или под вайном. Ну не использую я винду и хорошо знаю что у меня в лялихе крутится.
2 — ТП в РТ сообщал о том, что это способ донести предложение. Цитирую: «Ростелеком старается предоставлять различным способами, включая показ при открытии сайтов. Очень жаль, если данный вариант Вас огорчил.» Но в письме с no-reply@rt.ru «Средствами АСР Ростелеком редирект не производится.»
3 — Редирект произошел после того, как я руками вбил в адресную строку store.steampowered.com (то есть не переход по ссылке) и открылась реклама тарифа РТ с каким-то аккаунтом танков и с доп танками.
В сухом остатке: видя, что я хочу перейти на игровой портал мне предлагают игровой тариф и говорят, что это не они устраивают MITM, а валв переводит трафик к своим конкурентам в надежде снизить посещаемость и продажи.
Простите, но это смешно.
Тем самым вынудить всех использовать стандартный, легко модифицируемый протокол по 53 порту.
Скорости работы ни от 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» и берет самый наименьший.
При использовании
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.
При том, что чистый днс ходит на гугл за 10-15мс.
Только в отличие от 1.1.1.1 у 8.8.8.8 нет сертификата на 8.8.8.8.
Вы ошибаетесь, сертификат у них есть на все IP, в том числе и ipv6. Это можно проверить так:
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 есть
Да, об этом написано в первой строчке поста.
Теперь DoH, который ну совсем никак ни про производительность, ни про задержки, а только слом концепции, что DNS это «Control Plane» Интернет.
Я тут вкратце, но объясняю проблемы DNSCurve. С DoT будет примерно так же. Плюс DNSSEC изначально незвисимая от SSL PKI тема, как независимая дублирующая в чем-то. У DNSSEC конечно тоже пачка своих проблем, но всё же.
изложены во множестве статей
Да уж давайте. Большинство этих статей или уже неактульны, или нытьё.
Нигде нет DNSSEC. Значит, так он важен для всех.
Плюс DNSSEC изначально незвисимая от SSL PKI тема, как независимая дублирующая в чем-то.
Подконтрольная одному государству. Ну и регистратор домена может заменить DS любого домена при случае. Не очевидно, почему эти люди, у которых даже бизнес особо не завязан на гарантии их подписи, заслуживают большего доверия, чем имеющиеся удостоверяющие центры.
Одна из статей, которую смог найти и она заслуживает внимания.
Из личных впечатлений — для того, чтобы иметь гарантии, которые DNSSEC должен предоставлять, я должен держать непосредственно на моём устройстве валидирующий dnssec резолвер. Я обхожусь на ноутбуке dnssec-trigger и unbound на ноутбуке, однако это дно и это нужно сжечь огнём. Проблема с NSEC и NSEC3 действительно актуальна, и пока кое-какое костыльное решение смогли предоставить только Cloudflare в своей реализации DNSSEC. И то, ценой того, что авторитативный сервер всё же имеет доступ к ключам для подписи.
Сегодня DNSSEC, как и IPv6 — игрушки для гиков, реальный бизнес от них не зависит.
Нигде нет DNSSEC. Значит, так он важен для всех.
У меня! У меня есть!
zhovner.com
Хотя согласен, особой пользы от него нет.
vm-0.com
. И мы с тобой оба гики. Это что же получается…Я только ради SMTP DANE сделал. Это всё-таки кое-где да поддерживается. Ну и SSHFP и OPENPGPKEY — приятности.
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 Public DNS тихо включили поддержку DNS over TLS