Россиянам посоветовали поменять важную настройку в Android
1000.jpg)
Малоизвестная настройка Android позволяет заметно повысить скорость загрузки сайтов, а также сделать веб-серфинг более безопасным для пользователя.
Лайфхаком поделилось издание Hi-tech Mail.ru. Речь идет о прописывании в системе стороннего DNS-сервера вместо установленного по умолчанию.
DNS-сервер — это «посредник», который превращает адрес сайта (доменное имя) в его IP-адрес. Когда пользователь вводит в строку браузера адрес, браузер сначала обращается к DNS-серверу, получает от него IP-адрес сайта и затем загружает страницу.
Использование стороннего DNS вместо сервера по умолчанию может уменьшить время отклика (то есть время между нажатием клавиши «Ввод» и началом загрузки сайта), а также повысить безопасность благодаря блокировке вредоносных доменных имен.
В качестве альтернативы DNS-серверу по умолчанию рекомендуется использовать серверы крупных компаний. Это Google (dns.google), Cloudflare (1dot1dot1dot1.cloudflare-dns.com), Quad 9 (dns.quad9.net), AdGuard DNS (dns.adguard.com).
Чтобы поменять DNS-сервер, нужно открыть «Настройки — Подключения — Другие настройки — Персональный DNS-сервер», после чего указать один из перечисленных выше адресов в графе «Имя хоста персонального DNS-сервера» и нажать кнопку «Сохранить». Вслед за этим понадобится включить и выключить режим полета, чтобы сбросить данные кеша.
Встречаем сервис от Cloudflare на адресах 1.1.1.1 и 1.0.0.1, или «полку публичных DNS прибыло!»
Компания 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Этот вариант, похоже, лучше подойдет для локальных 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-серверах компании, будет мгновенным) делают пользование описываемого в посте сервиса еще более интересным.
Мощный бесплатный DNS
Cloudflare DNS — это сервис авторитетного DNS корпоративного класса, обеспечивающий минимальное время отклика, беспрецедентную степень резервирования и высокий уровень безопасности благодаря встроенной защите от DDoS-атак и поддержке DNSSEC.
Неограниченная защита от DDoS-атак без тарификации трафика
Избавьте вашу организацию от затрат и стрессов, связанных с DDoS-атаками на DNS. С Cloudflare DNS вы получите неограниченную защиту от DDoS-атак на DNS без тарификации трафика. Пропускная способность нашей сети на 23x превышает мощность самой крупной DDoS-атаки за всю историю наблюдений.
DNSSEC в один клик
Управляемый DNS-сервис Cloudflare обеспечивает встроенную поддержку DNSSEC для защиты ваших пользователей от атак, в ходе которых DNS-записи могут быть подделаны или захвачены. DNSSEC добавляет дополнительный уровень безопасности на каждом этапе DNS-поиска. Главное удобство: DNSSEC можно активировать одним нажатием кнопки.
Расширенная аналитика
Получайте детализированную аналитику в режиме реального времени о состоянии вашего DNS-трафика. Все это легко и доступно на информационной панели Cloudflare. Создавайте детализированные отчеты по вашим DNS-запросам как в исходном, так и в визуальном формате — с фильтрацией по кодам ответов, типам записей, географии, доменам и т. д. Исходные файлы журналов также доступны через API и могут интегрироваться в SIEM/инструменты парсинга.
Быстрая настройка DNS-записей для обеспечения безопасности электронной почты
Обезопасьте себя с помощью нашего удобного Мастера настройки DNS для безопасности электронной почты (Email Security DNS Wizard), чтобы исключить возможность отправки злоумышленниками мошеннических писем от имени вашего домена. Настройте необходимые DNS-записи электронной почты всего несколькими щелчками мыши. Мы предупредим вас, если обнаружим на вашем домене отсутствующие или небезопасные настройки электронной почты.
Узнайте подробнее о SPF, DKIM и DMARC в нашем Учебном центре.
Handle Misdirected Queries with the AS112 Project
Cloudflare helps reduce the load on public DNS infrastructure by functioning as an operator of the AS112 project, assisting the community-operated, loosely-coordinated anycast deployment of DNS servers that primarily answer reverse DNS lookup queries that are misdirected and create significant, unwanted load on the Internet.
Learn more about Cloudflare’s impact on the AS112 project via Cloudflare Radar.
Публичные DNS от Cloudflare 1.1.1.1 и 1.0.0.1
Как пишут на сайте: https://1.1.1.1/ Мол они быстрее Гугла. Протестировал, но что-то не сходится с картинкой: Наверное не учитывают, что у Гугла свои сервера стоят в каждой стране.
✅ Трастовых площадок под размещение статей и ссылок. Опыт 15 лет! ( https://searchengines.guru/ru/forum/675690 ) ⭐ Купить вечные трастовые ссылки для сайта ( https://getmanylinks.ru/?srh ) ⭐ Новый аналог AllSubbmitter (заполнение форм) https://getmanylinks.ru/getmanysubmits.html (Бесплатное демо)
- Гонят траф на сайт.
- Fastpanel подддомены
- Будет ли сайт корректно работать на CloudFlare?
На сайте с 17.09.2016
2 апреля 2018, 16:27
Это скорей всего время ответа DNS сервера (НЕ считая задержки сети) поэтому местоположение не учитывается скорей всего
;; Query time: 17 msec
;; Query time: 16 msec
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 gw.*********** (*****) 0.227 ms 0.225 ms 0.272 ms
2 msk-dc-sw1-vlan1813.fiord.net (62.140.245.77) 0.386 ms 1.609 ms 1.580 ms
3 msk-m9-b3-ae7-vlan712.fiord.net (62.140.243.141) 0.388 ms 0.409 ms 0.433 ms
4 72.14.222.198 (72.14.222.198) 13.931 ms 13.923 ms 13.896 ms
5 108.170.250.33 (108.170.250.33) 0.927 ms 108.170.250.129 (108.170.250.129) 1.327 ms 108.170.250.33 (108.170.250.33) 1.059 ms
6 108.170.227.177 (108.170.227.177) 1.250 ms 108.170.226.163 (108.170.226.163) 0.917 ms 209.85.244.149 (209.85.244.149) 1.098 ms
7 google-public-dns-a.google.com (8.8.8.8) 1.500 ms 0.943 ms 1.270 ms
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 gw.******** (****) 0.651 ms 0.635 ms 0.614 ms
2 msk-dc-sw1-vlan1813.fiord.net (62.140.245.77) 1.438 ms 1.428 ms 1.417 ms
3 kiev-nt-b1-ae4-vlan3877.fiord.net (80.77.167.17) 16.492 ms 16.517 ms 16.508 ms
4 dtel-ix.cloudflare.com (193.25.181.201) 16.736 ms 16.670 ms 16.695 ms
5 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 16.561 ms 16.608 ms 16.523 ms
Да и вообще это всё критично для первого обращения (касательно обычного юзера)
Браузер единоразово резолвит запись, а потом берёт с кеша (касательно браузеров на хромиум)
Протухает кеш через минуту, если не ошибаюсь
На сайте с 27.09.2003
2 апреля 2018, 18:17
На сайте с 02.03.2011
2 апреля 2018, 20:27
Из Черногории если пинговать эти адреса, то примерно равны гугловским. А вот сами запросы - первый на порядок медленнее, второй запрос к прокешированному домену чуток медленнее гугловских.
Антибот, антиспам, веб файрвол, защита от накрутки поведенческих: https://antibot.cloud/ru.html + партнерка, до 40$ с продажи.
На сайте с 29.09.2008
3 апреля 2018, 21:53
Если сравнивать RTT сloudflare dns и google dns - то они не сильно отличаются.
Результаты моих тестов:
ping 1.1.1.1
[Hetzner_Germany-1] => <
"msg": "PING 1.1.1.1 rtt min/avg/max/mdev = 5.121/5.133/5.142/0.008 ms"
>
[WEBZILLA-US] => <
"msg": "PING 1.1.1.1 rtt min/avg/max/mdev = 0.287/0.318/0.350/0.024 ms"
>
[Irkutsk-RU] => <
"msg": "PING 1.1.1.1 rtt min/avg/max/mdev = 1.248/1.266/1.316/0.046 ms"
>
[Online-FR] => <
"msg": "PING 1.1.1.1 rtt min/avg/max/mdev = 10.064/10.443/11.138/0.424 ms"
>
[LEASEWEB-NL] => <
"msg": "PING 1.1.1.1 rtt min/avg/max/mdev = 0.833/1.009/1.089/0.092 ms"
>
[Ukrtelecom-UA] => <
"msg": "PING 1.1.1.1 rtt min/avg/max/mdev = 33.712/39.090/56.602/8.849 ms"
>
[INFERNO-NL-DE] => <
"msg": "PING 1.1.1.1 rtt min/avg/max/mdev = 2.346/2.552/2.748/0.139 ms"
>
[DIGITALOCEAN-AMS-3] => <
"msg": "PING 1.1.1.1 rtt min/avg/max/mdev = 0.853/0.949/1.071/0.078 ms"
>
[VELIANET-US] => <
"msg": "PING 1.1.1.1 rtt min/avg/max/mdev = 0.406/0.483/0.540/0.050 ms"
>
[DIGITALOCEAN-NY] => <
"msg": "PING 1.1.1.1 rtt min/avg/max/mdev = 1.293/1.432/1.868/0.221 ms"
>
[AWS-Tokyo] => <
"msg": "PING 1.1.1.1 rtt min/avg/max/mdev = 2.765/2.795/2.818/0.060 ms"
>
[AWS-eu-central-1] => <
"msg": "PING 1.1.1.1 rtt min/avg/max/mdev = 1.138/1.190/1.267/0.050 ms"
>
################################################################################
ping 8.8.8.8
[Hetzner_Germany-1] => <
"msg": "PING 8.8.8.8 rtt min/avg/max/mdev = 5.063/5.083/5.096/0.011 ms"
>
[WEBZILLA-US] => <
"msg": "PING 8.8.8.8 rtt min/avg/max/mdev = 0.610/0.663/0.736/0.060 ms"
>
[Irkutsk-RU] => <
"msg": "PING 8.8.8.8 rtt min/avg/max/mdev = 1.531/1.568/1.613/0.056 ms"
>
[Online-FR] => <
"msg": "PING 8.8.8.8 rtt min/avg/max/mdev = 1.156/1.424/1.664/0.206 ms"
>
[LEASEWEB-NL] => <
"msg": "PING 8.8.8.8 rtt min/avg/max/mdev = 0.857/1.733/3.257/0.804 ms"
>
[Ukrtelecom-UA] => <
"msg": "PING 8.8.8.8 rtt min/avg/max/mdev = 43.650/43.844/44.247/0.344 ms"
>
[INFERNO-NL-DE] => <
"msg": "PING 8.8.8.8 rtt min/avg/max/mdev = 2.195/2.244/2.301/0.070 ms"
>
[DIGITALOCEAN-AMS-3] => <
"msg": "PING 8.8.8.8 rtt min/avg/max/mdev = 0.329/0.347/0.382/0.027 ms"
>
[VELIANET-US] => <
"msg": "PING 8.8.8.8 rtt min/avg/max/mdev = 0.409/0.483/0.521/0.053 ms"
>
[DIGITALOCEAN-NY] => <
"msg": "PING 8.8.8.8 rtt min/avg/max/mdev = 1.214/1.306/1.595/0.145 ms"
>
[AWS-Tokyo] => <
"msg": "PING 8.8.8.8 rtt min/avg/max/mdev = 1.624/1.643/1.664/0.054 ms"
>
[AWS-eu-central-1] => <
"msg": "PING 8.8.8.8 rtt min/avg/max/mdev = 1.118/1.174/1.228/0.035 ms"
>
################################################################################
time dig google.com @8.8.8.8 | grep Query
[Hetzner_Germany-1] => <
"msg": ";; Query time: 14 msec"
>
[WEBZILLA-US] => <
"msg": ";; Query time: 9 msec"
>
[Irkutsk-RU] => <
"msg": ";; Query time: 18 msec"
>
[Online-FR] => <
"msg": ";; Query time: 8 msec"
>
[LEASEWEB-NL] => <
"msg": ";; Query time: 6 msec"
>
[Ukrtelecom-UA] => <
"msg": ";; Query time: 56 msec"
>
[INFERNO-NL-DE] => <
"msg": ";; Query time: 6 msec"
>
[DIGITALOCEAN-AMS-3] => <
"msg": ";; Query time: 6 msec"
>
[VELIANET-US] => <
"msg": ";; Query time: 13 msec"
>
[DIGITALOCEAN-NY] => <
"msg": ";; Query time: 17 msec"
>
[AWS-Tokyo] => <
"msg": ";; Query time: 35 msec"
>
[AWS-eu-central-1] => <
"msg": ";; Query time: 11 msec"
>
time dig google.com @8.8.8.8 | grep Query
[Hetzner_Germany-1] => <
"msg": [ "",
"real 0m0.019s",
"user 0m0.004s",
"sys 0m0.001s"
]
>
[WEBZILLA-US] => <
"msg": [ "",
"real 0m0.021s",
"user 0m0.006s",
"sys 0m0.006s"
]
>
[Irkutsk-RU] => <
"msg": [ "",
"real 0m0.031s",
"user 0m0.009s",
"sys 0m0.006s"
]
>
[Online-FR] => <
"msg": [ "",
"real 0m0.147s",
"user 0m0.004s",
"sys 0m0.000s"
]
>
[LEASEWEB-NL] => <
"msg": [ "",
"real 0m0.032s",
"user 0m0.006s",
"sys 0m0.006s"
]
>
[Ukrtelecom-UA] => <
"msg": [ "",
"real 0m0.194s",
"user 0m0.012s",
"sys 0m0.000s"
]
>
[INFERNO-NL-DE] => <
"msg": [ "",
"real 0m0.016s",
"user 0m0.005s",
"sys 0m0.005s"
]
>
[DIGITALOCEAN-AMS-3] => <
"msg": [ "",
"real 0m0.016s",
"user 0m0.004s",
"sys 0m0.005s"
]
>
[VELIANET-US] => <
"msg": [ "",
"real 0m0.020s",
"user 0m0.001s",
"sys 0m0.006s"
]
>
[DIGITALOCEAN-NY] => <
"msg": [ "",
"real 0m0.028s",
"user 0m0.008s",
"sys 0m0.000s"
]
>
[AWS-Tokyo] => <
"msg": [ "",
"real 0m0.039s",
"user 0m0.000s",
"sys 0m0.000s"
]
>
[AWS-eu-central-1] => <
"msg": [ "",
"real 0m0.020s",
"user 0m0.004s",
"sys 0m0.000s"
]
>
###################################################################
time dig google.com @1.1.1.1 | grep Query
[Hetzner_Germany-1] => <
"msg": ";; Query time: 5 msec"
>
[WEBZILLA-US] => <
"msg": ";; Query time: 0 msec"
>
[Irkutsk-RU] => <
"msg": ";; Query time: 1 msec"
>
[Online-FR] => <
"msg": ";; Query time: 10 msec"
>
[LEASEWEB-NL] => <
"msg": ";; Query time: 2 msec"
>
[Ukrtelecom-UA] => <
"msg": ";; Query time: 38 msec"
>
[INFERNO-NL-DE] => <
"msg": ";; Query time: 3 msec"
>
[DIGITALOCEAN-AMS-3] => <
"msg": ";; Query time: 1 msec"
>
[VELIANET-US] => <
"msg": ";; Query time: 0 msec"
>
[DIGITALOCEAN-NY] => <
"msg": ";; Query time: 2 msec"
>
[AWS-Tokyo] => <
"msg": ";; Query time: 2 msec"
>
[AWS-eu-central-1] => <
"msg": ";; Query time: 1 msec"
>
time dig google.com @1.1.1.1 | grep Query
[Hetzner_Germany-1] => <
"msg": [ "",
"real 0m0.009s",
"user 0m0.002s",
"sys 0m0.002s"
]
>
[WEBZILLA-US] => <
"msg": [ "",
"real 0m0.012s",
"user 0m0.008s",
"sys 0m0.004s"
]
>
[Irkutsk-RU] => <
"msg": [ "",
"real 0m0.015s",
"user 0m0.007s",
"sys 0m0.009s"
]
>
[Online-FR] => <
"msg": [ "",
"real 0m0.017s",
"user 0m0.004s",
"sys 0m0.000s"
]
>
[LEASEWEB-NL] => <
"msg": [ "",
"real 0m0.016s",
"user 0m0.007s",
"sys 0m0.006s"
]
>
[Ukrtelecom-UA] => <
"msg": [ "",
"real 0m0.050s",
"user 0m0.008s",
"sys 0m0.000s"
]
>
[INFERNO-NL-DE] => <
"msg": [ "",
"real 0m0.013s",
"user 0m0.005s",
"sys 0m0.005s"
]
>
[DIGITALOCEAN-AMS-3] => <
"msg": [ "",
"real 0m0.009s",
"user 0m0.006s",
"sys 0m0.002s"
]
>
[VELIANET-US] => <
"msg": [ "",
"real 0m0.007s",
"user 0m0.007s",
"sys 0m0.000s"
]
>
[DIGITALOCEAN-NY] => <
"msg": [ "",
"real 0m0.014s",
"user 0m0.000s",
"sys 0m0.008s"
]
>
[AWS-Tokyo] => <
"msg": [ "",
"real 0m0.006s",
"user 0m0.000s",
"sys 0m0.000s"
]
>
[AWS-eu-central-1] => <
"msg": [ "",
"real 0m0.010s",
"user 0m0.004s",
"sys 0m0.000s"
]
>
Судя по моим тестам cloudflare dns быстрее google dns в разы (по крайней мере на данный момент, вполне возможно, как пойдет нормальная нагрузка ситуация может кардинально измениться).
то что cloudflare днс отвечают быстрее google днс подтверждается и другими тестами