achekalin Apr 2 2018 at 15:21

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

7 min

250K

DNS*Domain names administrating*System administration*

+39

130

Comments 130

Oopss Apr 2 2018 at 15:29

Ну не знаю…

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 мсек

achekalin Apr 2 2018 at 15:36

Вопрос не в пинге, а в скорости работы DNS — а это зависит от точки клиента и ближайшего к нему сервера DNS. www.dnsperf.com, подозреваю, меряет не из России, так что график, конечно, не самый полезный.
Я лично пока надеюсь, что Cloudflare будет и дальше развивать проект. Несколькими мс я лично готов пожертвовать (тем более что после запроса данные лягут в мой локальный кеш), в обмен на большую приватность.

Oopss Apr 3 2018 at 15:16

Скорость работы включает и время ответа, я так понимаю. Может кому-то важнее приватность,( и мне пригодится) я просто констатирую факт.
Специально для минусаторов, автор утверждает что это время ответа:

zCooler Apr 2 2018 at 15:40

Насколько я знаю 8.8.8.8 очень много где разнесены географически на разных провайдерах, и попадаете вы на ближайший. Отсюда и низкая латенси.
Как минимум в Киеве знаю один 8.8.8.8 где находится (видел в живую), у WNET у них на площадке.

achekalin Apr 2 2018 at 15:41

Думаю, не потребуется объяснять Cloudflare, что такое Anycast.

zCooler Apr 2 2018 at 15:43

Думаю со временем будет.

achekalin Apr 2 2018 at 15:50

С самого начала так и сделано было: Introducing DNS Resolver, 1.1.1.1 (not a joke):

DNS resolver, 1.1.1.1, is served by Cloudflare’s Global Anycast Network.

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

Так что ждем покрытия России (не знаю только, как с РКН решат вопрос — надеюсь, что не путем соглашательства).

erty Apr 3 2018 at 13:20

Не будет он работать быстрее в России. Их 24-часовая политика хранения прямо противоречит российскому закону Яровой.
Значит локальных серверов в РФ у них не появится.

Dreyk Apr 2 2018 at 17:00

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

Akdmeh Apr 2 2018 at 17:10

Берите выше. Киев, Triolan:
Cloudflare 1-3 мс; google — 34.

Softer Apr 2 2018 at 17:13

Днепр, тот же трианал:

--- 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

lehnh Apr 2 2018 at 18:48

А когда там Херсон переименуют, не слышно?

DaleMartinWatson Apr 3 2018 at 00:02

Очень смешно, в имени города и так петровск всегда опускали.

zCooler Apr 2 2018 at 17:11

volz isp Киев
8.8.8.8 ~33ms
1.1.1.1 ~14ms

Azan Apr 2 2018 at 18:18

Киев, VipLan
Ответ от 1.1.1.1: число байт=32 время=1мс TTL=58
Ответ от 8.8.8.8: число байт=32 время=33мс TTL=47

Azan Nov 17 2018 at 10:46

Киев, 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

wacky Apr 2 2018 at 23:01

Киев, фринет (о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

Schokn-Itrch Apr 3 2018 at 10:29

Минск
1.1.1.1 — 48ms
8.8.8.8 — 35ms
77.88.8.8 — 17ms

Daimos Apr 7 2018 at 18:17

У меня в Минске 14 мс до 1.1.1.1

Massacre Apr 3 2018 at 09:17

То-то из Киева у других провайдеров пинг 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]

Akdmeh Apr 2 2018 at 17:14

По ответам можно сделать только один вывод: каждый должен решать индивидуально, что работает быстрее. Наверное, очень зависит от удаленности к серверам и настройкам самого провайдера.

achekalin Apr 3 2018 at 07:29

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

uranik Jun 30 2018 at 20:04

Зато когда google dns сбоит как сейчас 1.1.1.1 спасает.

achekalin Apr 2 2018 at 15:36

del

AngelNet Apr 2 2018 at 16:29

пока в россии пинги неприемлемые-( 56 на еденицах и 58 на 1.0.0.1 (среднее значение).
это в нашей средней полосе (центральный регион.)
— сейчас приходится пользоваться провайдерскими днс (которые частенько падают!), а если нужно куда то залезть то спасает виртуалка внутри которой поднят крипт-днс.

achekalin Apr 2 2018 at 17:16

А до серверов Яндекс-DNS, и до Quad9 (у них адрес сервера тоже из не особо сложных — 9.9.9.9) если не сложно, посмотрите от вас задержку? Просто любопытно.

Oopss Apr 2 2018 at 17:54

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

mxms Apr 2 2018 at 17:31

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

achekalin Apr 2 2018 at 17:35

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

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

mxms Apr 2 2018 at 17:42

Jawohl! Retn und HE entsprechend.

achekalin Apr 2 2018 at 17:44

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

mxms Apr 2 2018 at 17:48

Nein. Ein solches Routing.

mxms Apr 2 2018 at 19:38

http://he.net/3d-map/

achekalin Apr 3 2018 at 07:28

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

mxms Apr 3 2018 at 11:32

Beim Routing durch Vilnius

Ernillgeek Apr 4 2018 at 11:57

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

achekalin Apr 4 2018 at 12:01

Откуда вы такой, толстый и качественный? Прямо любо-дорого посмотреть!

Приезжайте в Кгд, откуда вы там сами, поговорите с людьми — как с пожилыми, так и с молодежью.

Ernillgeek Apr 4 2018 at 14:12

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

mxms Apr 7 2018 at 22:09

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

Ernillgeek Apr 7 2018 at 22:13

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

BeppeGrillo Jul 18 2018 at 17:45

Понимаете в чем дело, в Кенигсберге местное население называет город только настоящим названием. Город появился до того, как Московия стала государством

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

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

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

Dreyk Apr 2 2018 at 17:01

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

mxms Apr 2 2018 at 17:05

Да, они пишут

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.

achekalin Apr 2 2018 at 17:12

Конечно, все, что в посте описано, уже работает. Другое дело, что клиентов готовых не очень много (я бы сказал, что и вовсе мало).

Мозилла, как в посте же указано, будет тестировать поддержку DNS over HTTPs в своих ночных сборках. Они, как раз, сервис на серверах CF и будут использовать.

lehnh Apr 2 2018 at 18:51

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

SilentBob Apr 2 2018 at 20:56

Я никак не могу найти: stubby может сам резолвить локальные адреса? Или он только редиректит и надо ставить второй локальный dns?

lehnh Apr 3 2018 at 09:04

Второе. Если есть что-то «свое», надоставить stubby как форвардера. Сам по себе он зоны обслуживать не может. Если же своей зоны нет, вполне можно забиндить его на внешний интерфейс (не локалхост в смысле) и обслуживать локалку.

vdasus Apr 5 2018 at 19:36

Вильнюс,
Reply from 1.1.1.1: bytes=32 time=1ms TTL=57
Reply from 8.8.8.8: bytes=32 time=12ms TTL=57

inkvizitor68sl Apr 2 2018 at 20:06

Да, у меня unbound уже туда форвардит, всё работает.

modjo Apr 2 2018 at 18:19

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

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

achekalin Apr 2 2018 at 18:22

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

achekalin Apr 2 2018 at 20:37

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

marsdenden Apr 3 2018 at 10:43

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

marsdenden Apr 3 2018 at 10:41

Нефтекамск, Уфанет

— 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

одинаково почти

Pongo Apr 2 2018 at 18:31

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

UFO just landed and posted this here

achekalin Apr 2 2018 at 19:45

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

UFO just landed and posted this here

achekalin Apr 2 2018 at 20:35

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

UFO just landed and posted this here

mxms Apr 2 2018 at 23:31

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

NeoCode Apr 2 2018 at 19:17

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

Token2 Apr 2 2018 at 19:25

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

achekalin Apr 2 2018 at 19:46

Почему?

Token2 Apr 2 2018 at 20:07

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

achekalin Apr 2 2018 at 20:27

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

Evgen52 Apr 2 2018 at 20:20

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

achekalin Apr 2 2018 at 20:22

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

sindzicat Apr 2 2018 at 20:23

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

achekalin Apr 2 2018 at 20:25

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

chersanya Apr 2 2018 at 21:48

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

sindzicat Apr 2 2018 at 21:55

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

nikitasius Apr 2 2018 at 20:30

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

Сейчас использую гуглднс через 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 в польше "отличились"

achekalin Apr 2 2018 at 20:35

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

nikitasius Apr 2 2018 at 20:38

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

achekalin Apr 2 2018 at 20:39

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

nikitasius Apr 2 2018 at 20:48

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

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

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

lehnh Apr 3 2018 at 15:26

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

nikitasius Apr 4 2018 at 11:13

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

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

lehnh Apr 4 2018 at 11:50

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

nikitasius Apr 4 2018 at 12:16

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

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

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

achekalin Apr 4 2018 at 11:57

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

nikitasius Apr 4 2018 at 12:26

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

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

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

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

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

darkdaskin Apr 2 2018 at 22:50

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

achekalin Apr 2 2018 at 23:25

Пережевывать весь https-трафик vs отвести на анализ только 53 порт — для некоторых провайдеров задачи разного масштаба, на это, видимо, и расчет.

Prototik Apr 3 2018 at 07:35

Да зачем весь, достаточно первый пакет из tcp сессии на 443 порту. С большим шансом там будет sni, который можно распарсить как и dns.

UFO just landed and posted this here

nikitasius Apr 2 2018 at 20:42

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

UFO just landed and posted this here

maxzhurkin Nov 14 2018 at 20:23

Почему половина?

UFO just landed and posted this here

achekalin Apr 2 2018 at 20:38

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

UFO just landed and posted this here

Revertis Apr 2 2018 at 23:33

Плюс, обычный DNSCrypt забыли. Серверов по всему миру много, выбирай любой.

UFO just landed and posted this here

kamtec1 Apr 2 2018 at 22:00

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

L0NGMAN Apr 2 2018 at 23:18

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

www0rm Apr 2 2018 at 23:23

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 мсек

вот как то так

achekalin Apr 2 2018 at 23:28

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

www0rm Apr 3 2018 at 13:09

это пинг из организации,
вот до 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 мсек

achekalin Apr 3 2018 at 13:15

Мы пингом проверяем то, что надо проверить трейроутом и nslookup-ом.

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

www0rm Apr 3 2018 at 14:05

да вы правы, так и есть. админов трогать не буду

зы админы читающие этот комент — вы хорошие

dimmount Apr 2 2018 at 23:23

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

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

achekalin Apr 3 2018 at 07:26

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

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

dimmount Apr 3 2018 at 10:23

Даже затрудняюсь ответить. Пытался выяснить, может такой порядок задан какой-то инструкцией? Так и сами госорганы не могут ответить. «Так сложилось издавна»

achekalin Apr 3 2018 at 10:28

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

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

Xenos_rus Apr 3 2018 at 07:40

Широка страна моя родная :)
Из Хабаровска передают.

>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 мсек

Daimos Apr 3 2018 at 10:18

Минск
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

undro Apr 3 2018 at 09:53

Владивосток
1.1.1.1 — 145 ms
8.8.8.8 — 105 ms

achekalin Apr 3 2018 at 09:53

Сурово!

exhalace Apr 3 2018 at 09:53

Проверять интернет стало еще проще

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

alexanster Apr 3 2018 at 11:31

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

baragoon Apr 3 2018 at 10:08

Пригород Киева

[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

achekalin Apr 3 2018 at 12:02

Спасибо за подробные логи.

vscrub Apr 3 2018 at 11:42

$ 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

Так что буду пользоваться.

achekalin Apr 3 2018 at 12:01

Вы лучше померяйте скорость работы того и другого лично для вас, пинг не все решает в DNS. Мне вот интереснее даже не время RTT, а именно приватность: я лучше пару десятков мс потрачу лишних, но чуть меньше дам поводов Гуглу меня скоррелировать.

vscrub Apr 3 2018 at 12:18

> 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

Приватность — согласен.

SlaNT Apr 3 2018 at 12:14

Пользователи wifi Московского метрополитена Будут счастливы :( по адресу 1.1.1.1 откликается Cisco раздающая интернет в метро

ton1 Apr 3 2018 at 12:14

DNS-over-TLS и DNS-over-HTTPS

Зачем еще велосипеды? dnscrypt уже не торт?

achekalin Apr 3 2018 at 12:16

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

mxms Apr 3 2018 at 14:40

Зачем еще велосипеды? dnscrypt уже не торт?

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

achekalin Apr 3 2018 at 14:41

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

mxms Apr 3 2018 at 14:45

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

capslocky Apr 3 2018 at 12:23

Астана

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

dmitry_dvm Apr 3 2018 at 12:29

Настроил зачем-то этот 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мс. По ощущениям новые сайты первый раз открываются медленнее чем раньше. Ростелекомовские блокировки, к сожалению, не вылечило (надеялся на чудо). Вопрос: что это мне дало?

achekalin Apr 3 2018 at 12:34

Вероятно, с блокировками нужно поглубже бороться: от VPN-туннеля в страну назначения трактора (где бы она ни была, по вашему мнению), и до, хотя бы, разбирательства с пакетами, которыми в вашем случае провайдер может вам малину портить (я просто не знаю, как именно у вас именно РТ решил выполнять закон).
Дало же вам использование лишь то, что статистику ни РТ, ни Гугл (если вы до этого 8.8.8.8 использовали) про вас уже не соберут.

dmitry_dvm Apr 3 2018 at 14:30

Попользовался пару часов и отключил tls, слишком уж медленно. Оставил просто 1.1.1.1 без шифрования до лучших времен. Может ускорят еще. А может и роутер замедляет, хотя вряд ли.

L0NGMAN Apr 3 2018 at 12:31

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

capslocky Apr 3 2018 at 12:56

Нагуглил на гитхабе public dns list
https://gist.github.com/kometchtech/8c1b91ec427b264fbe97
Там есть и другие красивые, запоминающиеся айпишники: 1.2.4.8; 80.80.80.80;

darkprof Apr 10 2018 at 06:22

В данный момент 1.1.1.1 не доступен… 1.0.0.1 работает