Компания Cloudflare представила публичные ДНС на адресах:
- 1.1.1.1
- 1.0.0.1
- 2606:4700:4700::1111
- 2606:4700:4700::1001
Утверждается, что используется политика "Privacy first", так что пользователи могут быть спокойны за содержание своих запросов.
Сервис интересен тем, что кроме обычного DNS предоставляет возможность использовать технологий DNS-over-TLS и DNS-over-HTTPS, что здорово помешает провайдерам по пути запросов подслушивать ваши запросы — и собирать статистику, следить, управлять рекламой. Cloudflare утверждает, что дата анонса (1 апреля 2018, или 04/01 в американской нотации) была выбрана не случайно: в какой еще день года представить "четыре единицы"?
Поскольку аудитория Хабра технически подкована, традиционный раздел "зачем нужен DNS?" я помещу под конец поста, а здесь изложу более практически полезные вещи:
Как использовать новый сервис?
Самое простое — в своем DNS-клиенте (или в качестве upstream в настройках используемого вами локального DNS-сервера) указываем приведенные выше адреса DNS-cерверов. Имеет ли смысл заменить привычные значения гугловских DNS (8.8.8.8 и т.д.), либо чуть менее распространенных яндексовских публичных серверов DNS (77.88.8.8 и иже с ними) на сервера от Cloudflare — решат вам, но за новичка говорит график скорости ответов, согласно которому Cloudflare работает быстрее всех конкурентов (уточню: замеры сделаны стронним сервисом, и скорость до конкретного клиента, конечно, может отличаться).
Гораздо интереснее работа с новыми режимами, в которых запрос улетает на сервер по шифрованному соединению (собственно, ответ возвращается по нему же), упомянутыми DNS-over-TLS и DNS-over-HTTPS. К сожалению, "из коробки" они не поддерживаются (авторы верят, что это "пока"), но организовать в своем ПО (либо даже на своей железке) их работу несложно:
DNS over HTTPs (DoH)
Как и следует из названия, общение идет поверх HTTPS-канала, что предполагает
- наличие точки приземления (endpoint) — он находится по адресу https://cloudflare-dns.com/dns-query, и
- клиента, который умеет отправлять запросы, и получать ответы.
Запросы могут быть либо в формате DNS Wireformat, определенном в RFC1035 (отправляться HTTP-методами POST и GET), либо в формате JSON (используется HTTP-метод GET). Лично для меня идея делать DNS-запросы через HTTP-запросы показалась неожиданной, однако рациональное зерно в ней есть: такой запрос пройдет многие системы фильтрации трафика, парсить ответы достаточно просто, а формировать запросы — ещё проще. За безопасность ответчают привычные библиотеки и протоколы.
Примеры запросов, прямо из документации:
GET-запрос в формате DNS Wireformat
$ curl -v "https://cloudflare-dns.com/dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" | hexdump
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f968700a400)
GET /dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Host: cloudflare-dns.com
User-Agent: curl/7.54.0
Accept: */*
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
HTTP/2 200
date: Fri, 23 Mar 2018 05:14:02 GMT
content-type: application/dns-udpwireformat
content-length: 49
cache-control: max-age=0
set-cookie: \__cfduid=dd1fb65f0185fadf50bbb6cd14ecbc5b01521782042; expires=Sat, 23-Mar-19 05:14:02 GMT; path=/; domain=.cloudflare.com; HttpOnly
server: cloudflare-nginx
cf-ray: 3ffe69838a418c4c-SFO-DOG
{ [49 bytes data]
100 49 100 49 0 0 493 0 --:--:-- --:--:-- --:--:-- 494
* Connection #0 to host cloudflare-dns.com left intact
0000000 ab cd 81 80 00 01 00 01 00 00 00 00 03 77 77 77
0000010 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
0000020 01 c0 0c 00 01 00 01 00 00 0a 8b 00 04 5d b8 d8
0000030 22
0000031POST-запрос в формате DNS Wireformat
$ echo -n 'q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB' | base64 -D | curl -H 'Content-Type: application/dns-udpwireformat' --data-binary @- https://cloudflare-dns.com/dns-query -o - | hexdump
{ [49 bytes data]
100 49 100 49 0 0 493 0 --:--:-- --:--:-- --:--:-- 494
* Connection #0 to host cloudflare-dns.com left intact
0000000 ab cd 81 80 00 01 00 01 00 00 00 00 03 77 77 77
0000010 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
0000020 01 c0 0c 00 01 00 01 00 00 0a 8b 00 04 5d b8 d8
0000030 22
0000031
То же, но с использованием JSON
$ curl 'https://cloudflare-dns.com/dns-query?ct=application/dns-json&name=example.com&type=AAAA'
{
"Status": 0,
"TC": false,
"RD": true,
"RA": true,
"AD": true,
"CD": false,
"Question": [
{
"name": "example.com.",
"type": 1
}
],
"Answer": [
{
"name": "example.com.",
"type": 1,
"TTL": 1069,
"data": "93.184.216.34"
}
]
}Очевидно, что редкий (если вообще хоть один) домашний роутер умеет так работать с DNS, но это не означает, что поддержка не появится завтра — причем, что интересно, здесь мы вполне можем реализовать работу с DNS в своем приложении (как уже собирается сделать Mozilla, как раз на серверах Cloudflare).
DNS over TLS
По умолчанию, DNS запросы передаются без шифрованния. DNS over TLS — это способ отправлять их по защищенному соединению. Cloudflare поддерживает DNS over TLS на стандартном порту 853, как предписывается RFC7858. При этом используется сертификат, выписанный для хоста cloudflare-dns.com, поддерживаются TLS 1.2 и TLS 1.3.
Установление связи и работа по протоколу происходит примерно так:
- До установления соединения с DNS клиент сохраняет закодированный в base64 SHA256-хеш TLS-сертификата cloudflare-dns.com’s (называемый SPKI)
- DNS клиент устанавливает TCP соединение с cloudflare-dns.com:853
- DNS клиент инициирует процедуру TLS handshake
- В процессе TLS handshake, хост cloudflare-dns.com предъявляет свой TLS сертификат.
- Как только TLS соединение установлено, DNS клиент может отправлять DNS запросы поверх защищенного канала, что предотвращает подслушивание и подделку запросов и ответов.
- Все DNS запросы, отправляемые через TLS-соединение, должны соответствовать спецификации по отправке DNS поверх TCP.
Пример запроса через DNS over TLS:
$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com
;; DEBUG: Querying for owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 170 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG: #1, C=US,ST=CA,L=San Francisco,O=Cloudflare\, Inc.,CN=\*.cloudflare-dns.com
;; DEBUG: SHA-256 PIN: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
;; DEBUG: #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA
;; DEBUG: SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted.
;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 58548
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1536 B; ext-rcode: NOERROR
;; PADDING: 408 B
;; QUESTION SECTION:
;; example.com. IN A
;; ANSWER SECTION:
example.com. 2347 IN A 93.184.216.34
;; Received 468 B
;; Time 2018-03-31 15:20:57 PDT
;; From 1.1.1.1@853(TCP) in 12.6 msЭтот вариант, похоже, лучше подойдет для локальных DNS-серверов, обслуживающих нужды локальной сети либо одного пользователя. Правда, с поддержкой стандарта не очень хорошо, но — будем надеяться!
Два слова пояснений, о чём разговор
Аббревиатура DNS расшифровывается как Domain Name Service (так что говорить "сервис DNS" — несколько избыточно, в аббревиатуре уже есть слово "сервис"), и используется для решения простой задачи — понять, какой IP-адрес у конкретного имени хоста. Каждый раз, когда человек щёлкает по ссылке, либо вводит в адресной строке браузера адрес (скажем, что-то вроде "https://habrahabr.ru/post/346430/"), компьютер человека пытается понять, к какому серверу следует направить запрос на получение содержимого страницы. В случае habrahabr.ru ответ от DNS будет будет содержать указание на IP-адрес веб-сервера: 178.248.237.68, и далее браузер уже попробует связаться с сервером с указанным IP-адресом.
В свою очередь, сервер DNS, получив запрос "какой IP-адрес у хоста с именем habrahabr.ru?", определяет, знает ли он что-либо об указанном хосте. Если нет, он делает запрос к другим серверам DNS в мире, и, шаг за шагом, пробует выяснить ответ на заданный вопрос. В итоге, по нахождению итогового ответа, найденные данные отправляются всё ещё ждучему их клиенту, плюс сохраняются в кеше самого DNS-сервера, что позволит в следующий раз ответить на подобный вопрос гораздо быстрее.
Обычная проблема состоит в том, что, во-первых, данные DNS-запросов передаются в открытом виде (что дает всем, кто имеет доступ к потоку трафика, вычленить DNS-запросы и получаемые ответы, а затем проанализировать их для своих целей; это дает возможность таргетирования рекламы с точностью для клиента DNS, а это совсем немало!). Во-вторых, некоторые интернет-провайдеры (не будем показывать пальцем, но не самые маленькие) имеют тенденцию показа рекламы вместо той или иной запрошенной страницы (что реализуется весьма просто: вместо указанного IP-адреса для запроса по имени хоста habranabr.ru человеку случайным образом возвращается адрес веб-сервера провайдера, где отдается страница, содержащая рекламу). В-третьих, существуют провайдеры интернет-доступа, реализующие механизм выполнения требований о блокировке отдельных сайтов, через подмену правильных DNS-ответов про IP-адресов блокируемых веб-ресурсов на IP-адрес своего сервера, содержащего страницы-заглушки (в результате доступ к таким сайтам заметно усложняется), либо на адрес своего прокси-сервера, осуществляющего фильтрацию.
Здесь, вероятно, нужно поместить картинку с сайта http://1.1.1.1/, служащего для описания подключения к сервису. Авторы, как видно, совершенно уверены в качестве работы своего DNS (впрочем, от Cloudflare трудно ждать другого):
Можно вполне понять компанию Cloudflare, создателя сервиса: они зарабатывают свой хлеб, поддерживая и развивая одну из самых популярных CDN-сетей в мире (среди функций которой — не только раздача контента, но и хостинг DNS-зон), и, в силу желания тех, кто не очень разбирается, учить тех, кого они не знают, тому, куда ходить в глобальной сети, достаточно часто страдает от блокировок адресов своих серверов со стороны не будем говорить кого — так что наличие DNS, не подверженного влиянию "окриков, свистков и писулек", для компании означает меньший вред их бизнесу. А технические плюсы (мелочь, а приятно: в частности, для клиентов бесплатного DNS Cloudflare обновление DNS-записей ресуров, размещенных на DNS-серверах компании, будет мгновенным) делают пользование описываемого в посте сервиса еще более интересным.
Комментарии (121)
AngelNet
02.04.2018 16:29пока в россии пинги неприемлемые-( 56 на еденицах и 58 на 1.0.0.1 (среднее значение).
это в нашей средней полосе (центральный регион.)
— сейчас приходится пользоваться провайдерскими днс (которые частенько падают!), а если нужно куда то залезть то спасает виртуалка внутри которой поднят крипт-днс.
achekalin Автор
02.04.2018 17:16А до серверов Яндекс-DNS, и до Quad9 (у них адрес сервера тоже из не особо сложных — 9.9.9.9) если не сложно, посмотрите от вас задержку? Просто любопытно.
Oopss
02.04.2018 17:54PING 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
02.04.2018 17:31+1В Кёнигсберге Cloudflare ~ 14 ms, HE ~ 17 ms, Google ~ 25 ms, Yandex ~ 32 ms.
Вывод — ридна кёнигсбержщина це Эуропа :-)achekalin Автор
02.04.2018 17:35+2Вы бы тогда по-немецки писали, что, раз уж вспомнили исторические корни города, у которого (точнее, не только у города, но и у всей Калининградской области) внешние каналы идут ну очень необычным образом.
У вас через чей канал наружу до CF и HE запрос пошел?Ernillgeek
04.04.2018 11:57Как вы возбудились. Понимаете в чем дело, в Кенигсберге местное население называет город только настоящим названием. Временное название оккупационной администрации никто не использует. Город появился до того, как Московия стала государством и городу на названия оккупантов пофигу
achekalin Автор
04.04.2018 12:01Откуда вы такой, толстый и качественный? Прямо любо-дорого посмотреть!
Приезжайте в Кгд, откуда вы там сами, поговорите с людьми — как с пожилыми, так и с молодежью.Ernillgeek
04.04.2018 14:12Что бы приехать в Кенигсберг мне сначала нужно из него уехать, вот сижу так, что если повернусь, то в окно вижу Южный вокзал и думаю чего это у тебя, никогда здесь не бывавшего, так полыхает от того, как население назыаает свой город?
Dreyk
02.04.2018 17:01не совсем понял в результате: уже есть возможность использовать DNS over TLS?
mxms
02.04.2018 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 Автор
02.04.2018 17:12Конечно, все, что в посте описано, уже работает. Другое дело, что клиентов готовых не очень много (я бы сказал, что и вовсе мало).
Мозилла, как в посте же указано, будет тестировать поддержку DNS over HTTPs в своих ночных сборках. Они, как раз, сервис на серверах CF и будут использовать.lehnh
02.04.2018 18:51+1stubby собирается за 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 msSilentBob
02.04.2018 20:56Я никак не могу найти: stubby может сам резолвить локальные адреса? Или он только редиректит и надо ставить второй локальный dns?
lehnh
03.04.2018 09:04Второе. Если есть что-то «свое», надоставить stubby как форвардера. Сам по себе он зоны обслуживать не может. Если же своей зоны нет, вполне можно забиндить его на внешний интерфейс (не локалхост в смысле) и обслуживать локалку.
modjo
02.04.2018 18:19user@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 Автор
02.04.2018 18:22Бывает. Интернет вообще ненадежная штука: не найду быстро, но когда-то встречал информацию, что в любой момент времени из любой точки интернета примерно из остальных 7% хостов недоступны из-за проблем связности или аварий хостов. Притом одни хосты делаются доступными, другие пропадают со связи, а величина эта как будто бы не меняется, примерно такой и остается. Похоже, вам «повезло».
Плюс все же это anycast, может, ваш провайдер не очень «подружился» с bgp, либо зафильтровал весь Cloudflare за «пособничество» «вредным» сайтам?
achekalin Автор
02.04.2018 20:37Кажется, сети 1.0.0.0/24 особо любимы криворукими админами. В смысле неверно настроить, я имею в виду. В общем, стоит провайдеру сдать проблему — это не приватные сетки, трафик должен ходить, пусть решают вопрос.
marsdenden
03.04.2018 10:43у него либо билайн, либо башинформ — что то, что это — криворукость просто зашкаливает, все, что сверх «откройте интернет и зайдите на mail.ru» — не работает почти никогда
marsdenden
03.04.2018 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
одинаково почти
krion
02.04.2018 19:17+1В вариантах ответа на вопросы нет пункта — 5) Лучший резолвер этот тот, который 127.0.0.1
achekalin Автор
02.04.2018 19:45А он-то откуда берется ответы?
krion
02.04.2018 19:47Из кэша и a.root-servers.net
achekalin Автор
02.04.2018 20:35Ну это вы "хороший" вариант предложили. Думаю, вы как раз можете выбрать в ответах либо 3, либо 4.
krion
02.04.2018 20:46Хороший без кавычек тем
— я бы не хотел чтобы кто-то видел мои queries
— я сам хочу делать валидацию DNSSEC если мне это надо или не делать, когда мне это не надо
— если вы хотите понимать DNS, поднимайте свой auth/resolvermxms
02.04.2018 23:31По первому пункту вам всё равно без DNScrypt/DNS-over-TLS/… не обойтись. Так чта...
NeoCode
02.04.2018 19:17У меня 1.1.1.1 даже не пингуется. Хотя для 8.8.8.8 и пинг работает, и команда host отдает результаты.
Token2
02.04.2018 19:25+3Внимание! 1.1.1.1 не заработает у клиентов за Cisco WLC с дефолтным конфигом
achekalin Автор
02.04.2018 19:46Почему?
Token2
02.04.2018 20:07+2Почему-то этот адрес используется как внутренний приватный (в качестве гейтвея и captive portal)
achekalin Автор
02.04.2018 20:27О, цисках, они знают стандарты! Руки пообрывать таким законодателям мод, а заодно админам локалку и провайдеров, которые по ошибке кроме 10.0.0.0/8 ещё и 1.0.0.0/8 фильтруют.
Evgen52
02.04.2018 20:20Простите за, возможно, глупый вопрос, но не может ли получиться так, что низкие задержки сейчас просто из-за сильно меньшей популярности и, как следствие, нагрузки на сервис?
achekalin Автор
02.04.2018 20:22CF легко такое выдерживают — их основной бизнес и с большими нагрузками живёт. Так что, думаю, просто они очень хотели построить хорошую сеть, а потом хотели запилить сервис лучше, чем Гугл.
sindzicat
02.04.2018 20:23Подмосковье
1.1.1.1: Минимальное = 99мсек, Максимальное = 151 мсек, Среднее = 120 мсек
8.8.8.8: Минимальное = 72мсек, Максимальное = 116 мсек, Среднее = 92 мсек
Вроде разница несущественна...achekalin Автор
02.04.2018 20:25+1Точно. Более интересно, что tls и https ещё добавят — но цель того может и стоит!
nikitasius
02.04.2018 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 msachekalin Автор
02.04.2018 20:35dnssec — конечно помогает, но приватности никак не способствует же, так что вск равно надо использовать 1.1.1.1 или 9.9.9.9 поверх защищённого транспорта.
nikitasius
02.04.2018 20:38На серверах и на домашнем лаптопе приватность DNS запросов (=шифрование) в 99% не нужно. Нужна лишь проверка подписи, что отдали правильные данные.
Если нужно анонимно лазить, то есть сервисы вида запустил-работай.achekalin Автор
02.04.2018 20:39Как раз вопрос про подмену ответов и про приватность. Я не хочу, чтобы какой-то провайдер, похожий на РТ, таргетировал меня по списку посещённых сайтов, например.
nikitasius
02.04.2018 20:48"Подмена ответов" поломает dnssec. На счет "приватности" (=скрытия запросов) — такой цели на серверах и домашнем лаптопе (франция) нету.
Что до таргетинга по запрещенным сайтам:
достаточно поднять тунель до vps и поставить "remote dns resolve" в настройках sock5 прокси (в браузере). Тем самым и траффик и dns буду идти через ssh тунель.
Не понимаю, чем именно вам поможет простое скрытые dns, когда цель уже шифровать все. Далее частные случаи покупки vps за биткоины, следом смена mac, коннект из паблик точек, tails, и т.д. и т.п. :)
lehnh
03.04.2018 15:26Легко — туннель поднят с роутера, нормальный ipsec, без всяких socks, а вся локалка ничего про него не знает. В него вообще роутятся только выборочные адреса. При этом провайдер перехватывает запросы к 8.8.8.8 и все ломает.
nikitasius
04.04.2018 11:13-1И шапочку до кучи, чтобы котики меньше с ютуба мяукали.
Подняли тунель с роутера, кешируем ДНС на роутере и резолвим там, до куда подняли.
Вижу, что чукча не читатель, чукча — писатель. В моей ветке комментариев это как козе баян. В моей могу написать вот так.
В ветке вечной борьбы с РКН вас поддержут, не растраивайтесь. У меня же РКНа нету, как нет и проблемы.lehnh
04.04.2018 11:50Конечно-конечно, мы в Вас верим. Правда, когда провайдер подменяет ответы от dns при доступе к linkedin (конечно, ведь у Вас нет РКН и буржуйский сервис Вам не нужен), рутрекеру и прочим торрент-хостингам, порнухе и тд, то это же все шапочка из фольги! Мне совершенно безразличны политические сайты, но когда блокируют полезные мне ресурсы из-за идиотских законов, это совсем другое дело.
nikitasius
04.04.2018 12:16При подмене DNS похерится подпись, и этот ответ будет отвергнут локальным DNS (который принудительно использует dnssec). Левый сайт не получу, ничего не откроется.
Если у меня будут проекты, доступ к которым блочат на уровне ДНС в тех местех, где сервера и впски хостятся, я, конечно, буду шифровать dns запросы и расчехлю нужный мне костыль для этого.
Просто сам тред про "паблик днс", и как заметили ниже, каждому свое по и по текущим запросам (пусть и в упрек мне написали :) ).
achekalin Автор
04.04.2018 11:57А в чем проблема-то? Вы так выкрутились, кто-то хочет, чтобы лично его DNS запросы не собирались и не анализировались, и все. Каждому свое!
nikitasius
04.04.2018 12:26Проблемы нет, "каждому свое".
Топик про паблик ДНС комментами превратился в топик "надо шифровать ДНС и пофиг что вам это не нужно" :)
На серверах в цивилизованных странах, где нет глупых блокировок нет смысла шифровать ДНС запросы и тратить на это ресурсы и время (которое тоже ресурс). Если же проект подразумевает какую-то стимпанк или просто подпольную идею — флаг в руки, будет круто… на бумаге :)
В реальности получается хрен, а не анонимность. Cloudflare? Или google? Они же собирают статистику о вас. А первый — это око
сауронаNSA.
Делаем запрос к K-root, и далее по цепочке если автоматика сего не делает. Раз включать параною, то по полной!
darkdaskin
02.04.2018 22:50Не вижу смысла прятать DNS от провайдера. Если вы используете VPN/proxy, то можно и имена хостов через них разрешать. А если не используете, то провайдер имена хостов всё равно может из SNI достать.
achekalin Автор
02.04.2018 23:25Пережевывать весь https-трафик vs отвести на анализ только 53 порт — для некоторых провайдеров задачи разного масштаба, на это, видимо, и расчет.
Prototik
03.04.2018 07:35Да зачем весь, достаточно первый пакет из tcp сессии на 443 порту. С большим шансом там будет sni, который можно распарсить как и dns.
krion
02.04.2018 20:32Непонятно почему все стали меряться пингами, которые никакого отношения ни к времени response, ни к cache-hit, ни к cache miss, ни к прямой валидации DNSSEC не имеют
nikitasius
02.04.2018 20:42Если CF и GOOGLE не пальцем деланные, я не думаю, что там будет такая уж большая разница в отдаче записей.
g0dlike
02.04.2018 20:37Пятый вариант голосовалки:
Использую свои рекурсивные DNS с SSL туннелем до них из дому/из телефона.е
www0rm
02.04.2018 23:23ping 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 Автор
02.04.2018 23:28Если брать вероятный вариант, что 1.1.1.1 оказался в вашей сети, то обрывать админам руки за то, что по какой-то странной логике они 1.0.0.0/8 посчитали приватным диапазоном, и используют его для своих нужд. Это reserved диапазон, но не private.
Правда, позвоните провайдеру, задайте вопрос.www0rm
03.04.2018 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 Автор
03.04.2018 13:15Мы пингом проверяем то, что надо проверить трейроутом и nslookup-ом.
Попробуйте сделать nslookup на сервере 1.1.1.1 и разресолвить хотя бы ya.ru — будет ли ответ? Попробуйте сделать трейс до 1.1.1.1 (уверен, путь будет внутри организации), и с этими знаниями подойдите к админу (если можете это позволить себе).www0rm
03.04.2018 14:05да вы правы, так и есть. админов трогать не буду
зы админы читающие этот комент — вы хорошие
dimmount
02.04.2018 23:23Теперь можно повеселиться пользователям VipNET. С какого-то препугу они назначают своим внутренним сетям адреса начиная с 1.0.0.0
Да и у многих гос-органов видел внутреннюю адресацию с 1.0.0.0. Кривизна настроек фаервола позволяет выходить такому трафику вовне.achekalin Автор
03.04.2018 07:26Криворукие дебилы. Они все reserved диапазоны считают доступными для себя?
С 5.0.0.0/8 такое раньше было, тут ещё залёт!
dimmount
03.04.2018 10:23Даже затрудняюсь ответить. Пытался выяснить, может такой порядок задан какой-то инструкцией? Так и сами госорганы не могут ответить. «Так сложилось издавна»
achekalin Автор
03.04.2018 10:28Госорганы вообще мало что могут объяснить, а многое делают по традиции. По традиции, и еще по указанию начальства (ни то, ни то законной силы, конечно, не имеет). Задашь вопрос официально «почему» — получишь отписку «согласно закона А и нормы Б во избежание В и для улучшения качества обслуживания».
Но вот выше обсуждают, что некоторые хотспот-решения используют эту сеть как свою, «приватную», хотя она ни разу не такова. Уверен, что и у провайдеров на том же основании («она вроде приватная») «единичка» может быть зафильтрована.
Xenos_rus
03.04.2018 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
03.04.2018 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
exhalace
03.04.2018 09:53+4Проверять интернет стало еще проще
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
baragoon
03.04.2018 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
vscrub
03.04.2018 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 Автор
03.04.2018 12:01Вы лучше померяйте скорость работы того и другого лично для вас, пинг не все решает в DNS. Мне вот интереснее даже не время RTT, а именно приватность: я лучше пару десятков мс потрачу лишних, но чуть меньше дам поводов Гуглу меня скоррелировать.
vscrub
03.04.2018 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
03.04.2018 12:14Пользователи wifi Московского метрополитена Будут счастливы :( по адресу 1.1.1.1 откликается Cisco раздающая интернет в метро
ton1
03.04.2018 12:14DNS-over-TLS и DNS-over-HTTPS
Зачем еще велосипеды? dnscrypt уже не торт?achekalin Автор
03.04.2018 12:16+1Вероятно, вам стоит написать в Cloudflare, только «торт» как-то замените, по английски «why, dnscrypt isn't a cake anymore?» могут и не осознать.
mxms
03.04.2018 14:40Зачем еще велосипеды? dnscrypt уже не торт?
Он сложен во внедрении. Если вы почитаете его спецификацию, то на стороне сервера надо много чего делать и поддерживать (похоже на DNSSEC), в то время как DNS-over-TLS прекрасно ложится на уже готовую и везде присутствующую инфраструктуру.
achekalin Автор
03.04.2018 14:41Можно ещё добавить, что dns over https чрезвычайно понятно реализуется любым разработчиком, который уже работает в своей программе с вебом. Скажем, в браузере.
mxms
03.04.2018 14:45DNS-over-HTTPS пока в экспериментальной стадии и нераспространён, в то время как DNS-over-TLS стандартизирован и давно в строю. Если речь и идёт о взимодействии DNS-DNS (а Интернет это далеко не только web), то следуя бритве Оккама приплетать сюда ещё и HTTP никакой потребности нет.
Рекомендую краткое сравнение
https://dnscrypt.info/faq
capslocky
03.04.2018 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
03.04.2018 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 Автор
03.04.2018 12:34Вероятно, с блокировками нужно поглубже бороться: от VPN-туннеля в страну назначения трактора (где бы она ни была, по вашему мнению), и до, хотя бы, разбирательства с пакетами, которыми в вашем случае провайдер может вам малину портить (я просто не знаю, как именно у вас именно РТ решил выполнять закон).
Дало же вам использование лишь то, что статистику ни РТ, ни Гугл (если вы до этого 8.8.8.8 использовали) про вас уже не соберут.dmitry_dvm
03.04.2018 14:30Попользовался пару часов и отключил tls, слишком уж медленно. Оставил просто 1.1.1.1 без шифрования до лучших времен. Может ускорят еще. А может и роутер замедляет, хотя вряд ли.
L0NGMAN
03.04.2018 12:31Tbilisi
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
03.04.2018 12:56Нагуглил на гитхабе public dns list
https://gist.github.com/kometchtech/8c1b91ec427b264fbe97
Там есть и другие красивые, запоминающиеся айпишники: 1.2.4.8; 80.80.80.80;
Oopss
Ну не знаю…
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 Автор
Вопрос не в пинге, а в скорости работы DNS — а это зависит от точки клиента и ближайшего к нему сервера DNS. www.dnsperf.com, подозреваю, меряет не из России, так что график, конечно, не самый полезный.
Я лично пока надеюсь, что Cloudflare будет и дальше развивать проект. Несколькими мс я лично готов пожертвовать (тем более что после запроса данные лягут в мой локальный кеш), в обмен на большую приватность.
Oopss
Скорость работы включает и время ответа, я так понимаю. Может кому-то важнее приватность,( и мне пригодится) я просто констатирую факт.
Специально для минусаторов, автор утверждает что это время ответа:
zCooler
Насколько я знаю 8.8.8.8 очень много где разнесены географически на разных провайдерах, и попадаете вы на ближайший. Отсюда и низкая латенси.
Как минимум в Киеве знаю один 8.8.8.8 где находится (видел в живую), у WNET у них на площадке.
achekalin Автор
Думаю, не потребуется объяснять Cloudflare, что такое Anycast.
zCooler
Думаю со временем будет.
achekalin Автор
С самого начала так и сделано было: Introducing DNS Resolver, 1.1.1.1 (not a joke):
Сеть-то у них приличная:
Так что ждем покрытия России (не знаю только, как с РКН решат вопрос — надеюсь, что не путем соглашательства).
erty
Не будет он работать быстрее в России. Их 24-часовая политика хранения прямо противоречит российскому закону Яровой.
Значит локальных серверов в РФ у них не появится.
Dreyk
у меня в Киеве 1.1.1.1 — 14мс, 8.8.8.8 — 35мс, наверное еще ближе разместили :D
Akdmeh
Берите выше. Киев, Triolan:
Cloudflare 1-3 мс; google — 34.
Softer
Днепр, тот же трианал:
--- 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
А когда там Херсон переименуют, не слышно?
DaleMartinWatson
Очень смешно, в имени города и так петровск всегда опускали.
zCooler
volz isp Киев
8.8.8.8 ~33ms
1.1.1.1 ~14ms
Azan
Киев, VipLan
Ответ от 1.1.1.1: число байт=32 время=1мс TTL=58
Ответ от 8.8.8.8: число байт=32 время=33мс TTL=47
wacky
Киев, фринет (о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
Минск
1.1.1.1 — 48ms
8.8.8.8 — 35ms
77.88.8.8 — 17ms
Massacre
То-то из Киева у других провайдеров пинг 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
По ответам можно сделать только один вывод: каждый должен решать индивидуально, что работает быстрее. Наверное, очень зависит от удаленности к серверам и настройкам самого провайдера.
achekalin Автор
Ну или верить, что операторы днс работают над улучшением.