Как стать автором
Обновить

Встречаем сервис от Cloudflare на адресах 1.1.1.1 и 1.0.0.1, или «полку публичных DNS прибыло!»

Время на прочтение 7 мин
Количество просмотров 222K
Всего голосов 39: ↑39 и ↓0 +39
Комментарии 130

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

Ну не знаю…
ping 1.1.1.1

Обмен пакетами с 1.1.1.1 по с 32 байтами данных:
Ответ от 1.1.1.1: число байт=32 время=67мс TTL=57
Ответ от 1.1.1.1: число байт=32 время=67мс TTL=57
Ответ от 1.1.1.1: число байт=32 время=67мс TTL=57
Ответ от 1.1.1.1: число байт=32 время=67мс TTL=57

Статистика Ping для 1.1.1.1:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 67мсек, Максимальное = 67 мсек, Среднее = 67 мсек

ping 8.8.8.8

Обмен пакетами с 8.8.8.8 по с 32 байтами данных:
Ответ от 8.8.8.8: число байт=32 время=19мс TTL=53
Ответ от 8.8.8.8: число байт=32 время=19мс TTL=53
Ответ от 8.8.8.8: число байт=32 время=19мс TTL=53
Ответ от 8.8.8.8: число байт=32 время=19мс TTL=53

Статистика Ping для 8.8.8.8:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 19мсек, Максимальное = 19 мсек, Среднее = 19 мсек
Вопрос не в пинге, а в скорости работы DNS — а это зависит от точки клиента и ближайшего к нему сервера DNS. www.dnsperf.com, подозреваю, меряет не из России, так что график, конечно, не самый полезный.
Я лично пока надеюсь, что Cloudflare будет и дальше развивать проект. Несколькими мс я лично готов пожертвовать (тем более что после запроса данные лягут в мой локальный кеш), в обмен на большую приватность.
Скорость работы включает и время ответа, я так понимаю. Может кому-то важнее приватность,( и мне пригодится) я просто констатирую факт.
Специально для минусаторов, автор утверждает что это время ответа:
image
Насколько я знаю 8.8.8.8 очень много где разнесены географически на разных провайдерах, и попадаете вы на ближайший. Отсюда и низкая латенси.
Как минимум в Киеве знаю один 8.8.8.8 где находится (видел в живую), у WNET у них на площадке.
Думаю, не потребуется объяснять Cloudflare, что такое Anycast.
Думаю со временем будет.
С самого начала так и сделано было: Introducing DNS Resolver, 1.1.1.1 (not a joke):
DNS resolver, 1.1.1.1, is served by Cloudflare’s Global Anycast Network.

Сеть-то у них приличная:

Так что ждем покрытия России (не знаю только, как с РКН решат вопрос — надеюсь, что не путем соглашательства).
Не будет он работать быстрее в России. Их 24-часовая политика хранения прямо противоречит российскому закону Яровой.
Значит локальных серверов в РФ у них не появится.

у меня в Киеве 1.1.1.1 — 14мс, 8.8.8.8 — 35мс, наверное еще ближе разместили :D

Берите выше. Киев, Triolan:
Cloudflare 1-3 мс; google — 34.
Днепр, тот же трианал:
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 30.534/30.617/30.705/0.159 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 41.643/41.730/41.832/0.070 ms

А когда там Херсон переименуют, не слышно?
Очень смешно, в имени города и так петровск всегда опускали.
Киев, VipLan
Ответ от 1.1.1.1: число байт=32 время=1мс TTL=58
Ответ от 8.8.8.8: число байт=32 время=33мс TTL=47
Киев, UOS (uos.net.ua)
Ответ от 1.1.1.1: число байт=32 время<1мс TTL=60
Ответ от 8.8.8.8: число байт=32 время=31мс TTL=47
Ответ от 9.9.9.9: число байт=32 время=26мс TTL=58

Киев, фринет (о3)
— 1.1.1.1 ping statistics — 6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.922/0.940/0.973/0.018 ms


— 8.8.8.8 ping statistics — 3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 33.720/33.777/33.875/0.070 ms

Минск
1.1.1.1 — 48ms
8.8.8.8 — 35ms
77.88.8.8 — 17ms
У меня в Минске 14 мс до 1.1.1.1
То-то из Киева у других провайдеров пинг 32мс на 8.8.8.8…

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms in-010-005-001.lan [10.10.5.1]
2 <1 ms <1 ms <1 ms v1017-f-u-r1.nline.net.ua [193.41.219.9]
3 <1 ms <1 ms <1 ms xe0-776.EXT670.IEV.UA.29632.as [62.205.132.33]
4 <1 ms <1 ms <1 ms netassist.google.com [195.214.208.73]
5 1 ms <1 ms <1 ms 108.170.248.131
6 14 ms 14 ms 14 ms 209.85.248.105
7 32 ms 32 ms 32 ms 209.85.246.99
8 32 ms 32 ms 32 ms 216.239.40.244
9 * * * Request timed out.

Reply from 8.8.8.8: bytes=32 time=32ms TTL=48

Интересно, что польский Cloudflare получается, в итоге, поближе:

Tracing route to 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms in-010-005-001.lan [10.10.5.1]
2 <1 ms <1 ms <1 ms v1017-f-u-r1.nline.net.ua [193.41.219.9]
3 13 ms 13 ms 13 ms 40ge-776.LIM.WAW.PL.29632.as [62.205.132.153]
4 13 ms 13 ms 13 ms cloudflare.plix.pl [195.182.218.134]
5 13 ms 13 ms 13 ms 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]

Tracing route to 1dot1dot1dot1.cloudflare-dns.com [2606:4700:4700::1111]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 2a01:d0:5:4050::1
2 <1 ms <1 ms <1 ms 2a01:d0:5:ff04::1
3 1 ms <1 ms <1 ms 2a01:d0:0:1a::1
4 13 ms 13 ms 13 ms 2a01:d0:0:1c::153
5 13 ms 14 ms 13 ms cloudflare.ipv6.plix.pl [2001:7f8:42::a501:3335:1]
6 13 ms 13 ms 13 ms 1dot1dot1dot1.cloudflare-dns.com [2606:4700:4700::1111]
По ответам можно сделать только один вывод: каждый должен решать индивидуально, что работает быстрее. Наверное, очень зависит от удаленности к серверам и настройкам самого провайдера.

Ну или верить, что операторы днс работают над улучшением.

Зато когда google dns сбоит как сейчас 1.1.1.1 спасает.
пока в россии пинги неприемлемые-( 56 на еденицах и 58 на 1.0.0.1 (среднее значение).
это в нашей средней полосе (центральный регион.)
— сейчас приходится пользоваться провайдерскими днс (которые частенько падают!), а если нужно куда то залезть то спасает виртуалка внутри которой поднят крипт-днс.
А до серверов Яндекс-DNS, и до Quad9 (у них адрес сервера тоже из не особо сложных — 9.9.9.9) если не сложно, посмотрите от вас задержку? Просто любопытно.
PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data.
--- 9.9.9.9 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 67.163/67.231/67.369/0.245 ms

PING 77.88.8.8 (77.88.8.8) 56(84) bytes of data.

--- 77.88.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 22.370/23.815/25.069/1.192 ms

В Кёнигсберге Cloudflare ~ 14 ms, HE ~ 17 ms, Google ~ 25 ms, Yandex ~ 32 ms.
Вывод — ридна кёнигсбержщина це Эуропа :-)

Вы бы тогда по-немецки писали, что, раз уж вспомнили исторические корни города, у которого (точнее, не только у города, но и у всей Калининградской области) внешние каналы идут ну очень необычным образом.

У вас через чей канал наружу до CF и HE запрос пошел?

Jawohl! Retn und HE entsprechend.

Ну про HE тогда не удивлен, но я думал, у них ДЦ только на американщине… в смысле, in den USA. Это у вас туннель для ipv6? А RETN — молодцы, значит!

Nein. Ein solches Routing.

Спасибо, познавательно!
Тис есть на карте, а Линка нет к нему. Как они получают, интересно?

Beim Routing durch Vilnius

Как вы возбудились. Понимаете в чем дело, в Кенигсберге местное население называет город только настоящим названием. Временное название оккупационной администрации никто не использует. Город появился до того, как Московия стала государством и городу на названия оккупантов пофигу
Откуда вы такой, толстый и качественный? Прямо любо-дорого посмотреть!

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

Не кормите поцреотов — быстрее сдуются ;-)

Да мне смешно, когда мне советуют приехать в город, а я из окна вижу площадь Калинина и Южный вокзал. При этом к гадалке же не ходи он у нас не был ни разу.
Понимаете в чем дело, в Кенигсберге местное население называет город только настоящим названием. Город появился до того, как Московия стала государством

А хули не Твангсте тогда?
Че не Regiomontium? Królewiec? Karaliaučius?

городу на названия оккупантов пофигу

Ну да, живёте по законам оккупантов, армия оккупантская, полиция, суды и тюрьмы.
Но главное-то название! Назвались по немецки — и сразу как в родном Дойчлянде!

не совсем понял в результате: уже есть возможность использовать DNS over TLS?

Да, они пишут


The DNS resolver, 1.1.1.1, is also supporting privacy-enabled TLS queries on port 853 (DNS over TLS), so we can keep queries hidden from snooping networks.
Конечно, все, что в посте описано, уже работает. Другое дело, что клиентов готовых не очень много (я бы сказал, что и вовсе мало).

Мозилла, как в посте же указано, будет тестировать поддержку DNS over HTTPs в своих ночных сборках. Они, как раз, сервис на серверах CF и будут использовать.
stubby собирается за 5 минут и работает очень шустро. По dhcp стал дома раздавать в качестве днс адрес сервака, на котором он крутится, ну и на роутере 53 порт тоже на него занатил на всякий случай. Работает ОЧЕНЬ быстро.

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=2.23 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=2.50 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=2.48 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=2.38 ms

Я никак не могу найти: stubby может сам резолвить локальные адреса? Или он только редиректит и надо ставить второй локальный dns?
Второе. Если есть что-то «свое», надоставить stubby как форвардера. Сам по себе он зоны обслуживать не может. Если же своей зоны нет, вполне можно забиндить его на внешний интерфейс (не локалхост в смысле) и обслуживать локалку.
Вильнюс,
Reply from 1.1.1.1: bytes=32 time=1ms TTL=57
Reply from 8.8.8.8: bytes=32 time=12ms TTL=57
Да, у меня unbound уже туда форвардит, всё работает.
user@ubuntu:~$ ping 1.1.1.1    
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.     
From 1.0.0.1 icmp_seq=2 Destination Host Unreachable   
From 1.0.0.1 icmp_seq=3 Destination Host Unreachable   
From 1.0.0.1 icmp_seq=4 Destination Host Unreachable

Не заработало. Уфа, Россия.

Бывает. Интернет вообще ненадежная штука: не найду быстро, но когда-то встречал информацию, что в любой момент времени из любой точки интернета примерно из остальных 7% хостов недоступны из-за проблем связности или аварий хостов. Притом одни хосты делаются доступными, другие пропадают со связи, а величина эта как будто бы не меняется, примерно такой и остается. Похоже, вам «повезло».
Плюс все же это anycast, может, ваш провайдер не очень «подружился» с bgp, либо зафильтровал весь Cloudflare за «пособничество» «вредным» сайтам?

Кажется, сети 1.0.0.0/24 особо любимы криворукими админами. В смысле неверно настроить, я имею в виду. В общем, стоит провайдеру сдать проблему — это не приватные сетки, трафик должен ходить, пусть решают вопрос.

у него либо билайн, либо башинформ — что то, что это — криворукость просто зашкаливает, все, что сверх «откройте интернет и зайдите на mail.ru» — не работает почти никогда
Нефтекамск, Уфанет

— 1.1.1.1 ping statistics — 4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 25.344/25.589/25.842/0.226 ms

— 8.8.8.8 ping statistics — 4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 26.736/26.793/26.879/0.053 ms

одинаково почти
Еще скорость работы можно проверить гугловским namebench. Конкретно у меня 8.8.4.4 оказался самым быстрым.
НЛО прилетело и опубликовало эту надпись здесь

А он-то откуда берется ответы?

НЛО прилетело и опубликовало эту надпись здесь

Ну это вы "хороший" вариант предложили. Думаю, вы как раз можете выбрать в ответах либо 3, либо 4.

НЛО прилетело и опубликовало эту надпись здесь

По первому пункту вам всё равно без DNScrypt/DNS-over-TLS/… не обойтись. Так чта...

У меня 1.1.1.1 даже не пингуется. Хотя для 8.8.8.8 и пинг работает, и команда host отдает результаты.

Внимание! 1.1.1.1 не заработает у клиентов за Cisco WLC с дефолтным конфигом

Почему?

Почему-то этот адрес используется как внутренний приватный (в качестве гейтвея и captive portal)

О, цисках, они знают стандарты! Руки пообрывать таким законодателям мод, а заодно админам локалку и провайдеров, которые по ошибке кроме 10.0.0.0/8 ещё и 1.0.0.0/8 фильтруют.

Простите за, возможно, глупый вопрос, но не может ли получиться так, что низкие задержки сейчас просто из-за сильно меньшей популярности и, как следствие, нагрузки на сервис?

CF легко такое выдерживают — их основной бизнес и с большими нагрузками живёт. Так что, думаю, просто они очень хотели построить хорошую сеть, а потом хотели запилить сервис лучше, чем Гугл.

Подмосковье
1.1.1.1: Минимальное = 99мсек, Максимальное = 151 мсек, Среднее = 120 мсек
8.8.8.8: Минимальное = 72мсек, Максимальное = 116 мсек, Среднее = 92 мсек
Вроде разница несущественна...

Точно. Более интересно, что tls и https ещё добавят — но цель того может и стоит!

Это пинг? Где же так долго гуляет — тоже подмосковье, до 1.1.1.1 — 2 мс, до 8.8.8.8 — 3 мс.

Ответил в личке.

Хорошие новости:)


Сейчас использую гуглднс через dnsmasq на домашнем лаптопе и серверах с принудительным dnssec. Первый выигрывает (дома!) почти 3 раза пинга 12мс против 30.


В ДЦ же различий не вижу особых в широком смысле, разница минимальна.


OVH GRA
~# ping -c 5 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=4.75 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=4.80 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=4.78 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=4.78 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=56 time=4.81 ms

--- 1.1.1.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 4.754/4.789/4.811/0.065 ms

# ping -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=4.79 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=4.85 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=4.76 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=4.93 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=4.89 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 4.769/4.850/4.931/0.060 ms

OVH SDG
~# ping -c 5 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=6.39 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=6.54 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=6.53 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=6.48 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=56 time=6.55 ms

--- 1.1.1.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 6.394/6.502/6.558/0.078 ms

~# ping -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=6.75 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=6.74 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=6.75 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=6.76 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=6.67 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 6.671/6.738/6.766/0.062 ms

OVH PL
~# ping -c 5 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=55 time=0.617 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=55 time=0.630 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=55 time=0.583 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=55 time=0.606 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=55 time=0.592 ms

--- 1.1.1.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4087ms
rtt min/avg/max/mdev = 0.583/0.605/0.630/0.031 ms

~# ping -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=29.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=29.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=52 time=29.7 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=52 time=29.6 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=52 time=29.7 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 29.677/29.701/29.727/0.218 ms

ATMAN PL
~# ping -c 5 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.12 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=0.853 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=0.875 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=0.907 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=0.788 ms

--- 1.1.1.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4033ms
rtt min/avg/max/mdev = 0.788/0.909/1.124/0.117 ms

~# ping -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=1.04 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=0.849 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=0.658 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=58 time=0.751 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=58 time=0.641 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4056ms
rtt min/avg/max/mdev = 0.641/0.789/1.046/0.148 ms

LINODE DE
~# ping -c 5 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=61 time=0.639 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=61 time=0.705 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=61 time=0.630 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=61 time=0.708 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=61 time=0.692 ms

--- 1.1.1.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4054ms
rtt min/avg/max/mdev = 0.630/0.674/0.708/0.046 ms

~# ping -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=0.720 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=61 time=0.799 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=61 time=0.770 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=61 time=0.784 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=61 time=0.774 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4041ms
rtt min/avg/max/mdev = 0.720/0.769/0.799/0.036 ms

upd: только OVH в польше "отличились"

dnssec — конечно помогает, но приватности никак не способствует же, так что вск равно надо использовать 1.1.1.1 или 9.9.9.9 поверх защищённого транспорта.

На серверах и на домашнем лаптопе приватность DNS запросов (=шифрование) в 99% не нужно. Нужна лишь проверка подписи, что отдали правильные данные.
Если нужно анонимно лазить, то есть сервисы вида запустил-работай.

Как раз вопрос про подмену ответов и про приватность. Я не хочу, чтобы какой-то провайдер, похожий на РТ, таргетировал меня по списку посещённых сайтов, например.

"Подмена ответов" поломает dnssec. На счет "приватности" (=скрытия запросов) — такой цели на серверах и домашнем лаптопе (франция) нету.


Что до таргетинга по запрещенным сайтам:
достаточно поднять тунель до vps и поставить "remote dns resolve" в настройках sock5 прокси (в браузере). Тем самым и траффик и dns буду идти через ssh тунель.


Не понимаю, чем именно вам поможет простое скрытые dns, когда цель уже шифровать все. Далее частные случаи покупки vps за биткоины, следом смена mac, коннект из паблик точек, tails, и т.д. и т.п. :)

Легко — туннель поднят с роутера, нормальный ipsec, без всяких socks, а вся локалка ничего про него не знает. В него вообще роутятся только выборочные адреса. При этом провайдер перехватывает запросы к 8.8.8.8 и все ломает.

И шапочку до кучи, чтобы котики меньше с ютуба мяукали.
Подняли тунель с роутера, кешируем ДНС на роутере и резолвим там, до куда подняли.


Вижу, что чукча не читатель, чукча — писатель. В моей ветке комментариев это как козе баян. В моей могу написать вот так.
В ветке вечной борьбы с РКН вас поддержут, не растраивайтесь. У меня же РКНа нету, как нет и проблемы.

Конечно-конечно, мы в Вас верим. Правда, когда провайдер подменяет ответы от dns при доступе к linkedin (конечно, ведь у Вас нет РКН и буржуйский сервис Вам не нужен), рутрекеру и прочим торрент-хостингам, порнухе и тд, то это же все шапочка из фольги! Мне совершенно безразличны политические сайты, но когда блокируют полезные мне ресурсы из-за идиотских законов, это совсем другое дело.

При подмене DNS похерится подпись, и этот ответ будет отвергнут локальным DNS (который принудительно использует dnssec). Левый сайт не получу, ничего не откроется.


Если у меня будут проекты, доступ к которым блочат на уровне ДНС в тех местех, где сервера и впски хостятся, я, конечно, буду шифровать dns запросы и расчехлю нужный мне костыль для этого.


Просто сам тред про "паблик днс", и как заметили ниже, каждому свое по и по текущим запросам (пусть и в упрек мне написали :) ).

А в чем проблема-то? Вы так выкрутились, кто-то хочет, чтобы лично его DNS запросы не собирались и не анализировались, и все. Каждому свое!

Проблемы нет, "каждому свое".


Топик про паблик ДНС комментами превратился в топик "надо шифровать ДНС и пофиг что вам это не нужно" :)


На серверах в цивилизованных странах, где нет глупых блокировок нет смысла шифровать ДНС запросы и тратить на это ресурсы и время (которое тоже ресурс). Если же проект подразумевает какую-то стимпанк или просто подпольную идею — флаг в руки, будет круто… на бумаге :)


В реальности получается хрен, а не анонимность. Cloudflare? Или google? Они же собирают статистику о вас. А первый — это око саурона NSA.


Делаем запрос к K-root, и далее по цепочке если автоматика сего не делает. Раз включать параною, то по полной!

Не вижу смысла прятать DNS от провайдера. Если вы используете VPN/proxy, то можно и имена хостов через них разрешать. А если не используете, то провайдер имена хостов всё равно может из SNI достать.

Пережевывать весь https-трафик vs отвести на анализ только 53 порт — для некоторых провайдеров задачи разного масштаба, на это, видимо, и расчет.
Да зачем весь, достаточно первый пакет из tcp сессии на 443 порту. С большим шансом там будет sni, который можно распарсить как и dns.
НЛО прилетело и опубликовало эту надпись здесь

Если CF и GOOGLE не пальцем деланные, я не думаю, что там будет такая уж большая разница в отдаче записей.

НЛО прилетело и опубликовало эту надпись здесь
Почему половина?
НЛО прилетело и опубликовало эту надпись здесь

Так опрос был скорее про публичные сервисы… Хотя да, надо добавить. Openvpn?

НЛО прилетело и опубликовало эту надпись здесь
Плюс, обычный DNSCrypt забыли. Серверов по всему миру много, выбирай любой.
НЛО прилетело и опубликовало эту надпись здесь

Супер! CF давно должны быле зделать такое по своему CDN…

Гугл мне кажется надежнее…
ping 1.1.1.1

Обмен пакетами с 1.1.1.1 по с 32 байтами данных:
Ответ от 1.1.1.1: число байт=32 время<1мс TTL=252
Ответ от 1.1.1.1: число байт=32 время<1мс TTL=252
Ответ от 1.1.1.1: число байт=32 время<1мс TTL=252
Ответ от 1.1.1.1: число байт=32 время<1мс TTL=252

Статистика Ping для 1.1.1.1:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек

вот как то так
Если брать вероятный вариант, что 1.1.1.1 оказался в вашей сети, то обрывать админам руки за то, что по какой-то странной логике они 1.0.0.0/8 посчитали приватным диапазоном, и используют его для своих нужд. Это reserved диапазон, но не private.
Правда, позвоните провайдеру, задайте вопрос.
это пинг из организации,
вот до 1.0.0.0

ping 1.0.0.0

Обмен пакетами с 1.0.0.0 по с 32 байтами данных:
Ответ от 1.0.0.0: число байт=32 время=47мс TTL=56
Ответ от 1.0.0.0: число байт=32 время=47мс TTL=56
Ответ от 1.0.0.0: число байт=32 время=47мс TTL=56
Ответ от 1.0.0.0: число байт=32 время=47мс TTL=56

Статистика Ping для 1.0.0.0:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 47мсек, Максимальное = 47 мсек, Среднее = 47 мсек
Мы пингом проверяем то, что надо проверить трейроутом и nslookup-ом.

Попробуйте сделать nslookup на сервере 1.1.1.1 и разресолвить хотя бы ya.ru — будет ли ответ? Попробуйте сделать трейс до 1.1.1.1 (уверен, путь будет внутри организации), и с этими знаниями подойдите к админу (если можете это позволить себе).
да вы правы, так и есть. админов трогать не буду

зы админы читающие этот комент — вы хорошие
Теперь можно повеселиться пользователям VipNET. С какого-то препугу они назначают своим внутренним сетям адреса начиная с 1.0.0.0

Да и у многих гос-органов видел внутреннюю адресацию с 1.0.0.0. Кривизна настроек фаервола позволяет выходить такому трафику вовне.

Криворукие дебилы. Они все reserved диапазоны считают доступными для себя?


С 5.0.0.0/8 такое раньше было, тут ещё залёт!

Даже затрудняюсь ответить. Пытался выяснить, может такой порядок задан какой-то инструкцией? Так и сами госорганы не могут ответить. «Так сложилось издавна»
Госорганы вообще мало что могут объяснить, а многое делают по традиции. По традиции, и еще по указанию начальства (ни то, ни то законной силы, конечно, не имеет). Задашь вопрос официально «почему» — получишь отписку «согласно закона А и нормы Б во избежание В и для улучшения качества обслуживания».

Но вот выше обсуждают, что некоторые хотспот-решения используют эту сеть как свою, «приватную», хотя она ни разу не такова. Уверен, что и у провайдеров на том же основании («она вроде приватная») «единичка» может быть зафильтрована.
Широка страна моя родная :)
Из Хабаровска передают.

>ping 1.1.1.1

Обмен пакетами с 1.1.1.1 по с 32 байтами данных:
Ответ от 1.1.1.1: число байт=32 время=163мс TTL=60
Ответ от 1.1.1.1: число байт=32 время=164мс TTL=60
Ответ от 1.1.1.1: число байт=32 время=163мс TTL=60
Ответ от 1.1.1.1: число байт=32 время=163мс TTL=60

Статистика Ping для 1.1.1.1:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 163мсек, Максимальное = 164 мсек, Среднее = 163 мсек

>ping 77.88.8.8

Обмен пакетами с 77.88.8.8 по с 32 байтами данных:
Ответ от 77.88.8.8: число байт=32 время=133мс TTL=55
Ответ от 77.88.8.8: число байт=32 время=132мс TTL=55
Ответ от 77.88.8.8: число байт=32 время=132мс TTL=55
Ответ от 77.88.8.8: число байт=32 время=133мс TTL=55

Статистика Ping для 77.88.8.8:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 132мсек, Максимальное = 133 мсек, Среднее = 132 мсек

>ping 8.8.8.8

Обмен пакетами с 8.8.8.8 по с 32 байтами данных:
Ответ от 8.8.8.8: число байт=32 время=122мс TTL=57
Ответ от 8.8.8.8: число байт=32 время=122мс TTL=57
Ответ от 8.8.8.8: число байт=32 время=128мс TTL=57
Ответ от 8.8.8.8: число байт=32 время=122мс TTL=57

Статистика Ping для 8.8.8.8:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 122мсек, Максимальное = 128 мсек, Среднее = 123 мсек
Минск
C:\>ping 1.1.1.1

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=12ms TTL=53
Reply from 1.1.1.1: bytes=32 time=10ms TTL=53
Reply from 1.1.1.1: bytes=32 time=11ms TTL=53
Reply from 1.1.1.1: bytes=32 time=12ms TTL=53
Владивосток
1.1.1.1 — 145 ms
8.8.8.8 — 105 ms
Сурово!
Проверять интернет стало еще проще
ping 1.1
PING 1.1 (1.0.0.1) 56(84) bytes of data.
64 bytes from 1.0.0.1: icmp_seq=1 ttl=59 time=62.2 ms


О, спасибо за подсказку. Это ж на 2 символа короче, чем ya.ru ;)
Пригород Киева

[root@MikroTik-hEX] > ping count=10 1.1.1.1
  SEQ HOST                                     SIZE TTL TIME  STATUS                                                                                                            
    0 1.1.1.1                                    56  61 1ms  
    1 1.1.1.1                                    56  61 3ms  
    2 1.1.1.1                                    56  61 0ms  
    3 1.1.1.1                                    56  61 0ms  
    4 1.1.1.1                                    56  61 0ms  
    5 1.1.1.1                                    56  61 2ms  
    6 1.1.1.1                                    56  61 1ms  
    7 1.1.1.1                                    56  61 3ms  
    8 1.1.1.1                                    56  61 0ms  
    9 1.1.1.1                                    56  61 0ms  
    sent=10 received=10 packet-loss=0% min-rtt=0ms avg-rtt=1ms max-rtt=3ms 

[root@MikroTik-hEX] > ping count=10 8.8.8.8
  SEQ HOST                                     SIZE TTL TIME  STATUS                                                                                                            
    0 8.8.8.8                                    56  49 33ms 
    1 8.8.8.8                                    56  49 33ms 
    2 8.8.8.8                                    56  49 33ms 
    3 8.8.8.8                                    56  49 33ms 
    4 8.8.8.8                                    56  49 33ms 
    5 8.8.8.8                                    56  49 33ms 
    6 8.8.8.8                                    56  49 33ms 
    7 8.8.8.8                                    56  49 33ms 
    8 8.8.8.8                                    56  49 33ms 
    9 8.8.8.8                                    56  49 33ms 
    sent=10 received=10 packet-loss=0% min-rtt=33ms avg-rtt=33ms max-rtt=33ms 


[root@MikroTik-hEX] > /tool traceroute 1.1.1.1
 # ADDRESS                          LOSS SENT    LAST     AVG    BEST   WORST STD-DEV STATUS                                                                                    
 1 94.158.85.225                      0%   17   0.4ms     0.5     0.4     0.8     0.1                                                                                           
 2 91.196.151.1                       0%   17   0.6ms     0.9     0.5     2.1     0.5                                                                                           
 3 128.0.175.222                      0%   17   0.6ms     0.7     0.5     2.7     0.5                                                                                           
 4 217.20.162.221                     0%   17   0.7ms     1.2     0.6     8.9     1.9                                                                                           
 5 193.25.181.201                     0%   17   0.7ms     1.3     0.7     5.2     1.2                                                                                           
 6 1.1.1.1                            0%   17   0.7ms     0.7     0.6     1.2     0.1                                                                                           

[root@MikroTik-hEX] > /tool traceroute 8.8.8.8
 # ADDRESS                          LOSS SENT    LAST     AVG    BEST   WORST STD-DEV STATUS                                                                                    
 1 94.158.85.225                      0%    5   0.5ms     0.5     0.5     0.7     0.1                                                                                           
 2 91.196.151.1                       0%    5   1.3ms     0.7     0.5     1.3     0.3                                                                                           
 3 185.1.62.69                        0%    5   0.9ms     0.9     0.7     1.3     0.2                                                                                           
 4 108.170.248.147                    0%    5   1.1ms     3.3     0.9    12.9     4.8                                                                                           
 5 209.85.248.105                     0%    5  15.2ms    15.6    15.2      16     0.3 <MPLS:L=448474,E=4>                                                                       
 6 209.85.246.99                      0%    5  33.6ms    33.6    33.4    34.2     0.3                                                                                           
 7 216.239.40.246                     0%    5  33.6ms    33.8    33.5    34.4     0.3                                                                                           
 8                                  100%    5 timeout                                                                                                                           
 9                                  100%    5 timeout                                                                                                                           
10                                  100%    5 timeout                                                                                                                           
11                                  100%    4 timeout                                                                                                                           
12                                  100%    4 timeout                                                                                                                           
Спасибо за подробные логи.
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=55 time=23.0 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=55 time=20.2 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=55 time=21.0 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=55 time=24.3 ms

$ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_req=1 ttl=59 time=8.18 ms
64 bytes from 1.1.1.1: icmp_req=2 ttl=59 time=5.41 ms
64 bytes from 1.1.1.1: icmp_req=3 ttl=59 time=6.71 ms
64 bytes from 1.1.1.1: icmp_req=4 ttl=59 time=4.50 ms

Так что буду пользоваться.
Вы лучше померяйте скорость работы того и другого лично для вас, пинг не все решает в DNS. Мне вот интереснее даже не время RTT, а именно приватность: я лучше пару десятков мс потрачу лишних, но чуть меньше дам поводов Гуглу меня скоррелировать.
> time nslookup microsoft.com. 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name: microsoft.com
Address: 104.40.211.35
Name: microsoft.com
Address: 104.43.195.251
Name: microsoft.com
Address: 23.100.122.175
Name: microsoft.com
Address: 23.96.52.53
Name: microsoft.com
Address: 191.239.213.197

real 0.15s
user 0.00s
sys 0.011

> time nslookup microsoft.com. 1.1
Server: 1.1
Address: 1.0.0.1#53

Non-authoritative answer:
Name: microsoft.com
Address: 23.96.52.53
Name: microsoft.com
Address: 23.100.122.175
Name: microsoft.com
Address: 104.40.211.35
Name: microsoft.com
Address: 104.43.195.251
Name: microsoft.com
Address: 191.239.213.197

real 0.02s
user 0.00s
sys 0.010

Приватность — согласен.
DNS-over-TLS и DNS-over-HTTPS

Зачем еще велосипеды? dnscrypt уже не торт?
Вероятно, вам стоит написать в Cloudflare, только «торт» как-то замените, по английски «why, dnscrypt isn't a cake anymore?» могут и не осознать.
Зачем еще велосипеды? dnscrypt уже не торт?

Он сложен во внедрении. Если вы почитаете его спецификацию, то на стороне сервера надо много чего делать и поддерживать (похоже на DNSSEC), в то время как DNS-over-TLS прекрасно ложится на уже готовую и везде присутствующую инфраструктуру.

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

DNS-over-HTTPS пока в экспериментальной стадии и нераспространён, в то время как DNS-over-TLS стандартизирован и давно в строю. Если речь и идёт о взимодействии DNS-DNS (а Интернет это далеко не только web), то следуя бритве Оккама приплетать сюда ещё и HTTP никакой потребности нет.
Рекомендую краткое сравнение
https://dnscrypt.info/faq

Астана
dig habrahabr.ru @8.8.8.8 #Google.DNS
Query time: 65 msec

dig habrahabr.ru @1.1.1.1 #CloudFlare.DNS
Query time: 89 msec

dig habrahabr.ru @84.200.69.80 #dns.watch
Query time: 85 msec

dig habrahabr.ru @77.88.8.8 #Yandex.DNS
Query time: 55 msec


dig stackoverflow.com @8.8.8.8 #Google.DNS
Query time: 53 msec

dig stackoverflow.com @1.1.1.1 #CloudFlare.DNS
Query time: 94 msec

dig stackoverflow.com @84.200.69.80 #dns.watch
Query time: 89 msec

dig stackoverflow.com @77.88.8.8 #Yandex.DNS
uery time: 52 msec
Настроил зачем-то этот DNS over TLS на Ubiquiti ER-X. Днс-трафик стал шифроваться. Выглядит примерно так:
08:17:20.646189 IP 5.139.172.87.41462 > 1dot1dot1dot1.cloudflare-dns.com.853: Flags [P.], seq 618:649, ack 2852, win 807, length 31
	0x0000:  4500 0047 c7fd 4000 4006 becf 058b ac57  E..G..@.@......W
	0x0010:  0101 0101 a1f6 0355 9c8e 9906 dde5 2f4f  .......U....../O
	0x0020:  5018 0327 0e89 0000 1503 0300 1a99 756f  P..'..........uo
	0x0030:  efcc f1cb 4395 bc18 85fc dfd7 c4da 4624  ....C.........F$
	0x0040:  aae8 b82b 5ec9 46                        ...+^.F

Пинг до CF 60мс. По ощущениям новые сайты первый раз открываются медленнее чем раньше. Ростелекомовские блокировки, к сожалению, не вылечило (надеялся на чудо). Вопрос: что это мне дало?
Вероятно, с блокировками нужно поглубже бороться: от VPN-туннеля в страну назначения трактора (где бы она ни была, по вашему мнению), и до, хотя бы, разбирательства с пакетами, которыми в вашем случае провайдер может вам малину портить (я просто не знаю, как именно у вас именно РТ решил выполнять закон).
Дало же вам использование лишь то, что статистику ни РТ, ни Гугл (если вы до этого 8.8.8.8 использовали) про вас уже не соберут.
Попользовался пару часов и отключил tls, слишком уж медленно. Оставил просто 1.1.1.1 без шифрования до лучших времен. Может ускорят еще. А может и роутер замедляет, хотя вряд ли.

Tbilisi


dig habrahabr.ru @8.8.8.8 #Google.DNS
Query time: 66 msec

dig habrahabr.ru @1.1.1.1 #CloudFlare.DNS
Query time: 68 msec

dig habrahabr.ru @84.200.69.80 #dns.watch
Query time: 91 msec

dig stackoverflow.com @8.8.8.8 #Google.DNS
Query time: 78 msec

dig stackoverflow.com @1.1.1.1 #CloudFlare.DNS
Query time: 82 msec

dig stackoverflow.com @84.200.69.80 #dns.watch
Query time: 75 msec
В данный момент 1.1.1.1 не доступен… 1.0.0.1 работает
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории