Коротко: мы опросили 26 публичных DNS-резолверов с сервера в Москве — 11 доменов, три прогона, 858 запросов. Отвечают не все: четыре резолвера не ответили ни разу, ещё три отвечают через раз. Самый быстрый — не Google и не Cloudflare, а Ростелеком с медианой 19 мс; Cloudflare рядом (20–21 мс), Яндекс 28 мс, Google 36 мс. Заодно этот замер вскрыл ошибку в нашем собственном инструменте проверки DNS-пропагации, которую мы в тот же день исправили, — про неё в конце честно и подробно.
Что именно замерили
26 публичных резолверов — тот же список, по которому работает наша проверка распространения DNS. По каждому: 11 доменов разного профиля (yandex.ru, vk.com, gosuslugi.ru, sber.ru, ozon.ru, mail.ru, google.com, cloudflare.com, github.com, wikipedia.org, enterno.io), три независимых прогона, запрос A-записи через dig с таймаутом 2 секунды и без повторов. Итого 33 попытки на каждый резолвер и 858 замеров всего.
Точка замера — наш сервер в Москве, Selectel, AS50340. Это важнее, чем кажется, и об этом стоит сказать прямо.
Чего эти цифры не значат. Это замер из одного дата-центра, а не «скорость DNS в России». У домашнего провайдера другой транзит, другие пиринговые точки и часто другой маршрут до того же адреса — ваши 19 мс до Ростелекома могут оказаться 45, а до Google, наоборот, 12. Правильный вывод из таблицы ниже — не «ставьте себе вот этот адрес», а «вот кто вообще жив, а дальше замерьте из своей сети». Как замерить — в конце.
Результаты
Медиана и 90-й перцентиль — по всем успешным ответам резолвера. Столбец «ответов» — сколько из 33 попыток вернули адрес.
| Резолвер | Адрес | Ответов | Медиана | p90 |
|---|---|---|---|---|
| Ростелеком | 193.58.251.251 | 33/33 | 19 мс | 20 мс |
| Cloudflare (вторичный) | 1.0.0.1 | 33/33 | 20 мс | 22 мс |
| AliDNS | 223.5.5.5 | 33/33 | 20 мс | 22 мс |
| Cloudflare | 1.1.1.1 | 33/33 | 21 мс | 25 мс |
| Яндекс | 77.88.8.8 | 33/33 | 28 мс | 37 мс |
| Яндекс (вторичный) | 77.88.8.1 | 33/33 | 28 мс | 38 мс |
| Google (вторичный) | 8.8.4.4 | 33/33 | 35 мс | 45 мс |
8.8.8.8 | 33/33 | 36 мс | 40 мс | |
| SafeDNS | 195.46.39.39 | 33/33 | 38 мс | 40 мс |
| Quad9 EU | 149.112.112.112 | 33/33 | 39 мс | 42 мс |
| Quad9 | 9.9.9.9 | 33/33 | 40 мс | 44 мс |
| DNS.Watch (вторичный) | 84.200.70.40 | 33/33 | 59 мс | 64 мс |
| CleanBrowsing | 185.228.168.9 | 33/33 | 59 мс | 63 мс |
| 114DNS | 114.114.114.114 | 33/33 | 59 мс | 65 мс |
| AdGuard | 94.140.14.14 | 33/33 | 60 мс | 63 мс |
| OpenDNS | 208.67.222.222 | 33/33 | 64 мс | 106 мс |
| Dyn DNS | 216.146.35.35 | 33/33 | 65 мс | 110 мс |
| DNS.SB | 45.11.45.11 | 33/33 | 72 мс | 74 мс |
| Baidu DNS | 180.76.76.76 | 33/33 | 314 мс | 506 мс |
| CNNIC | 1.2.4.8 | 31/33 | 194 мс | 390 мс |
| DNS.Watch | 84.200.69.80 | 25/33 | 72 мс | 150 мс |
| DNSPod | 101.226.4.6 | 25/33 | 256 мс | 447 мс |
| CIRA | 195.7.7.7 | 0/33 | — | — |
| Level3 Бразилия | 177.93.205.18 | 0/33 | — | — |
| BTCL | 203.112.2.4 | 0/33 | — | — |
| Telstra | 203.2.96.1 | 0/33 | — | — |
Четыре резолвера, которых больше нет
CIRA (Канада), Level3 в Бразилии, BTCL (Бангладеш) и Telstra (Австралия) не ответили ни разу за 33 попытки каждый. Три прогона в разное время дали один и тот же ноль — это не сетевая неудача и не блокировка, а простое устаревание списка: адреса, которые когда-то были открытыми резолверами, перестали ими быть.
Так происходит регулярно. Открытый рекурсивный резолвер — это, помимо прочего, инструмент усиления DDoS-атак, и операторы связи планомерно закрывают их для внешних запросов, оставляя доступ только своим абонентам. Публичные списки «DNS-серверов мира», которые кочуют по статьям и репозиториям годами, этого не отслеживают.
Практический вывод для любого, кто пишет мониторинг: список резолверов — это не константа, а данные, которые протухают. Их нужно перепроверять, иначе однажды окажется, что четверть вашей проверки давно ничего не проверяет.
Что в этих цифрах неожиданно
Ростелеком быстрее Google почти вдвое. 19 мс против 36 мс — и это при том, что 193.58.251.251 редко попадает в обзоры «лучших DNS». Причина прозаична: узел физически ближе, а Google и Cloudflare отвечают из ближайшей точки присутствия, которой в этой сети может и не быть.
Китайский AliDNS отвечает из Москвы за 20 мс — наравне с Cloudflare и быстрее Яндекса. Это не значит, что его стоит ставить: у резолвера в другой юрисдикции свои правила логирования, свои фильтры и своя география ответов, а разница в 8 мс не окупает вопросов, которые к нему возникают. Но как факт — китайская сеть по этому маршруту работает отлично, а вот Baidu и DNSPod из той же страны показывают 314 и 256 мс.
AdGuard — 60 мс, вдвое медленнее Яндекса. Его выбирают не за скорость, а за фильтрацию рекламы, и это честный размен; просто стоит понимать, что размен есть. Подробнее — в разборе AdGuard DNS.
Разброс внутри одного бренда. У DNS.Watch первичный адрес ответил 25 раз из 33, вторичный — все 33. Один и тот же оператор, два адреса, принципиально разная надёжность. Если вы прописываете пару серверов, проверять надо оба: второй адрес обычно вписывают «для галочки», а работать он будет ровно тогда, когда упадёт первый.
Три нестабильных
CNNIC (31/33), DNS.Watch (25/33) и DNSPod (25/33) отвечают через раз. Для мониторинга это худший случай — хуже, чем честный отказ: инструмент, который опрашивает такой резолвер, будет периодически получать пустоту и, если он устроен наивно, объявит это проблемой проверяемого домена.
Именно на этом мы и поймали себя.
Что этот замер нашёл в нашем собственном инструменте
Наша проверка распространения DNS опрашивает домен по всему списку резолверов и показывает результат вида «21 из 26 распространили». Замер выше означает, что четыре резолвера из этих 26 не ответят никогда — а они всё это время оставались в знаменателе.
Мы посмотрели в собственную историю проверок, и она подтвердила худшее:
| Результат | Сколько раз |
|---|---|
| 20 из 26 | 240 |
| 21 из 26 | 192 |
| 19 из 26 | 129 |
| 22 из 26 | 72 |
| 18 из 26 | 40 |
За 827 проверок лучший результат за всю историю — 23 из 26. Ни один домен ни разу не показал полного распространения, потому что показать его было физически невозможно. Человек с идеально настроенным DNS видел «20 из 26», решал, что распространение ещё идёт, и ждал. Или, хуже, шёл искать проблему в своей зоне.
Та же арифметика ломала и уведомление. В инструменте есть опция «сообщить письмом, когда распространение дойдёт до 100 %» — а порог в 100 % был недостижим, потому что в списке фонового обходчика тоже сидел мёртвый адрес. Письмо не могло уйти ни при каких данных. Подписчиков на него пока не было, так что реально никто не пострадал, но обещание было неисполнимым.
Что исправлено. Мёртвые адреса убраны из обоих списков — заодно проверка стала заметно быстрее, потому что каждый такой резолвер стоил около шести секунд ожидания таймаута. И, что важнее, изменился сам счёт: процент теперь считается от резолверов, которые ответили. Резолвер, до которого не достучались, ничего не сообщает о распространении записи — превращать «мы не смогли спросить» в «ещё не распространилось» неправильно. При этом NXDOMAIN и пустой ответ по-прежнему считаются: это ответы, и они означают, что записи действительно нет. Молчащие резолверы теперь показываются отдельной пометкой, а не растворяются в проценте.
Рассказываем об этом не из любви к самобичеванию, а потому что ошибка поучительная: инструмент может выдавать неверное суждение при полностью верных данных. Все 26 запросов отрабатывали корректно, все ответы были настоящими — врал знаменатель. Такие дефекты не ловятся тестами на «работает ли запрос»; они ловятся только когда кто-то смотрит на распределение результатов и спрашивает, почему у идеального случая никогда не бывает идеального значения.
Как замерить из своей сети
Таблица выше — это Москва и один дата-центр. Ваша сеть даст другие числа, и получить их — минутное дело.
- Linux и macOS: команда
dig @1.1.1.1 example.com +statsпокажет строкуQuery time: N msec. Повторите с разными адресами из таблицы. - Windows:
nslookup example.com 1.1.1.1ответа по времени не даёт; ставьтеdigиз пакета BIND либо измеряйте черезMeasure-Commandв PowerShell. - Замеряйте несколько раз. Первый запрос почти всегда медленнее: резолвер идёт за ответом к авторитетным серверам. Показателен второй и последующие — они из кэша.
- Берите свои домены. Скорость на
google.comмало что говорит про домены, которыми вы реально пользуетесь: у популярных имён ответ уже лежит в кэше любого резолвера. - Проверьте оба адреса пары. Как показал DNS.Watch, вторичный может вести себя совсем иначе, чем первичный.
Какой резолвер выбрать по совокупности — скорость, приватность, фильтрация — разбираем отдельно в обзоре лучших публичных DNS-серверов. Эта статья отвечает на более узкий вопрос: кто из них вообще отвечает, если спрашивать из России.
Посмотреть, как ваша DNS-запись расходится по резолверам прямо сейчас, можно бесплатно и без регистрации — уже с исправленным счётом.