Зачем вообще DoH/DoT в 2026
Обычный DNS по UDP/53 по-прежнему быстрый, но плохо совместим с требованиями к приватности: запросы видны провайдеру и любому, кто может наблюдать трафик. Поэтому DoH (DNS over HTTPS) и DoT (DNS over TLS) стали дефолтом во многих ОС, браузерах и корпоративных политиках.
Ключевой нюанс для админов и вебмастеров: DoH/DoT не делает вас «анонимными». Он шифрует транспорт между клиентом и резолвером, но сам резолвер видит домены, которые вы резолвите. Поэтому сравнение публичных резолверов — это в первую очередь про доверие, политику логов, доступные режимы фильтрации и про реальную задержку, а не только «красивые цифры» в тестах.
Если резолвер далеко, перегружен или вы неверно измеряете задержки, «приватный DNS» легко превращается в лишние десятки миллисекунд к TTFB и неприятные флаппинги из-за таймаутов.
DoH vs DoT: что быстрее и что проще эксплуатировать
Протоколы и их накладные расходы
DNS over TLS (DoT) — это DNS поверх TLS, чаще всего на порту 853. Плюсы: проще в трассировке, легче отделять DNS от веб-трафика, обычно понятнее для сетевых политик. Минусы: в некоторых сетях 853 могут резать, а TLS-сессии иногда чаще пересоздаются при агрессивных NAT/файрволах.
DNS over HTTPS (DoH) — DNS как HTTP-запросы (обычно HTTP/2 или HTTP/3) поверх 443. Плюсы: почти всегда проходит, часто выигрывает за счет современных транспортов и мультиплексирования. Минусы: сложнее отличать от обычного веба, а при «умных» прокси/инспекции возможны неожиданные эффекты.
В 2026 спор «DoH против DoT» чаще упирается не в «чистую скорость протокола», а в практику:
- качество PoP/Anycast рядом с пользователем;
- поддержку persistent соединений (TLS resumption, HTTP/2 keepalive);
- поведение клиента (ОС, браузер, локальный резолвер) и кэш;
- политику ретраев и таймаутов;
- наличие фильтрации (она иногда добавляет небольшую задержку).
Практический выбор «по умолчанию»
Если вы администрируете рабочие станции/ноутбуки в разнородных сетях (кафе, отели, мобильные провайдеры) — DoH часто дает меньше сюрпризов по доступности, потому что живет на 443.
Если у вас контролируемая сеть (офис, серверная, корпоративный VPN) и вы хотите проще дебажить и жестче отделять DNS от веба — DoT обычно удобнее.
Для серверов на виртуальном хостинге или на VDS DoH/DoT стоит рассматривать не как «обязательное улучшение», а как отдельную задачу. На сервере чаще важнее стабильность резолвинга, предсказуемые таймауты и локальный кэширующий резолвер, чем «приватность» клиента.
Как честно измерять DNS latency (и не обмануть себя)
Тема задержек в DNS коварная: один замер может показать «1–2 мс», а реальный пользователь ощущает тормоза. Причина обычно в том, что вы меряете не то (кэш-хит вместо кэш-мисса), не там (из другой сети) или не тем (сверху уже сидит кэш ОС/браузера).
Что именно измерять
Полезно разделять задержки на уровни:
- RTT до резолвера (сеть): близость Anycast/PoP и качество канала.
- Время ответа резолвера: кэш-хит обычно очень быстрый, кэш-мисс зависит от авторитативов.
- Цена установления/возобновления шифрованной сессии: особенно заметно, когда соединения часто рвутся.
- Эффект кэша на клиенте: ОС/браузер/локальный stub может кэшировать ответы и «рисовать» низкую задержку.
Минимальный набор инструментов
Для базового сравнения резолверов используйте несколько подходов:
digдля «обычного» DNS (UDP/TCP), чтобы иметь базовую линию;kdig(Knot DNS utils) удобен для DoT;- для DoH чаще всего удобнее тестировать через ваш локальный резолвер/клиент ОС и замерять итоговые времена, либо использовать специализированные тестеры.
Примеры команд (как ориентир):
dig @1.1.1.1 example.com A +tries=1 +time=1
dig @8.8.8.8 example.com A +tries=1 +time=1
kdig +tls @1.1.1.1 example.com A
kdig +tls @9.9.9.9 example.com A
kdig +tls @8.8.8.8 example.com A
Чтобы сравнение было ближе к продакшен-реальности:
- делайте серии по 20–50 запросов и смотрите медиану и 95-й перцентиль, а не «лучший результат»;
- тестируйте и кэш-хит (повтор одного домена), и кэш-мисс (случайные поддомены у домена, который вы контролируете, или домены с низким TTL);
- проверяйте в разное время суток;
- отдельно смотрите «первый запрос» после простоя — он часто самый дорогой для DoH/DoT.
Cloudflare DNS (1.1.1.1): сильные стороны и типичные ожидания
Cloudflare для многих — де-факто «быстрый публичный резолвер». В паре «Quad9 vs Cloudflare» Cloudflare нередко выигрывает по «сырой» задержке за счет широкой Anycast-сети и близости PoP к пользователям.
Про скорость
На практике Cloudflare часто дает низкую медиану в городах, где у Cloudflare плотная инфраструктура, и хороший хвост (95p) при нормальной сети. Но это не гарантия: если ваш провайдер маршрутизирует к далекому узлу, вы получите стабильные +10–30 мс просто из-за пути.
Про приватность и логи
С точки зрения приватности ключевой вопрос — доверие к провайдеру резолвера и формулировки его политики данных. Для админа важно заранее сверить ожидания с реальностью: что логируется, как долго, какие атрибуты запросов хранятся, и подходит ли это под ваш комплаенс и юрисдикции.
Про фильтрацию
Cloudflare предлагает готовые «семейные» и «анти-малварные» режимы через отдельные эндпоинты. Это удобно для базовой защиты, но это не «гибкий dns filtering под бизнес» с профилями, ролями и процессом изменений.
Google Public DNS: стабильность, масштаб и компромиссы
Google выбирают за масштаб и предсказуемую доступность. По скорости он часто сопоставим с Cloudflare, но итог зависит от региона и от того, куда именно Anycast приводит ваших пользователей.
Про latency
Частый сценарий: медиана хорошая, но у части клиентов хвосты заметнее из-за маршрутизации к не самому близкому узлу. Поэтому Google стоит тестировать именно «с ваших AS/регионов», а не по общим рейтингам.
Про приватность
С точки зрения доверенной модели данных Google воспринимается многими как более «тяжелый» вариант. Это не автоматически «плохо», но требует осознанного выбора в организациях, где важно минимизировать передачу метаданных внешним провайдерам.
Про фильтрацию
Google Public DNS — не про управляемую пользовательскую фильтрацию как сервис. Если вам нужны политики по группам, отчеты, allowlist/denylist и раздельные профили, это обычно решают другими классами решений.
Quad9: безопасность и политика блокировок
Quad9 часто выбирают, когда приоритет — безопасность и блокировка вредоносных доменов на уровне резолвера. В сравнении с Cloudflare он может проигрывать по абсолютной задержке в некоторых регионах, но выигрывать по снижению риска фишинга/малвари за счет репутационных фидов.
Где появляются лишние миллисекунды
Фильтрация и проверка репутации может добавить небольшой оверхед, но чаще задержка определяется географией и маршрутизацией. Если Quad9 для вас оказывается «далеко», это будет видно как повышенная медиана и особенно как рост хвостов в часы пик.
Важно для эксплуатации
Любая блокировка на резолвере — это потенциальные тикеты «не открывается сайт». В проде важно заранее понять модель отказа и подготовить процедуру обхода.
- Проверьте, что именно возвращается при блокировке:
NXDOMAIN,REFUSEDили иное поведение. - Заранее решите, как вы делаете исключения: локально, через альтернативный резолвер, через собственный резолвер с политиками.
- Оцените взаимодействие с корпоративным прокси/VPN и политиками конечных устройств.
NextDNS: гибкая фильтрация и «DNS как продукт»
NextDNS обычно выбирают, когда нужен управляемый dns filtering: политики, списки, профили, аналитика и иногда интеграции. Это ближе к SaaS-модели, где вы покупаете не только резолвинг, но и управление.
Latency: почему бывает по-разному
По задержкам NextDNS может быть очень быстрым в одних локациях и средним в других: итог зависит от привязки к узлу и от того, как настроен клиент (особенно если используются режимы идентификации профиля).
Практический момент: «самый быстрый NextDNS» — это не абстрактный выбор, а результат теста именно с вашей сети. Иногда достаточно сменить вариант подключения/эндпоинт, чтобы попасть на более близкий PoP.
Фильтрация: главный плюс и главный риск
Сильная сторона NextDNS — гибкость: allowlist/denylist, категории, защита от трекеров, отдельные профили для серверов, рабочих мест и мобильных.
Риск — усложнение. Чем больше правил, тем выше шанс сломать легитимные интеграции (особенно домены аналитики/капчи/платежей, которые внезапно оказываются критичными для авторизации и фронта). В продакшене это требует дисциплины: change management, тестового профиля и понятной диагностики.
Сравнение по сценариям: что выбрать админам и вебмастерам
Сценарий 1: «Нужна минимальная задержка без сюрпризов»
Обычно начинают с Cloudflare или Google и выбирают того, у кого лучше 95-й перцентиль в вашей сети. Если вы обслуживаете аудиторию по разным регионам, полезно тестировать с нескольких точек (офис, домашние провайдеры, мобильная сеть) и сравнивать хвосты, а не только медиану.
Сценарий 2: «Нужна защита от малвари на уровне DNS»
Quad9 часто логичен, если вы готовы к возможным false positive и у вас есть процедура обхода блокировок. Альтернатива — управляемая фильтрация (например, NextDNS), но это уже другой класс решения.
Сценарий 3: «Нужны политики, отчеты и управление»
NextDNS выигрывает продуктовой частью, но админский вопрос №1 — данные: кто владеет логами, где они хранятся, как долго, кто имеет доступ, и можно ли это выключить или сократить под вашу политику.
Сценарий 4: «Сервер/прод на хостинге»
Если речь про продакшен-сервер, часто лучшее решение для задержки и надежности — локальный кэширующий резолвер (или системный резолвер хоста) плюс здравые таймауты и fallback. DoH/DoT на сервере оправдан, когда вам нужно шифрование DNS на выходе по требованиям политики или при недоверии к транспортной сети.
Если вы часто работаете с доменами и продакшен-окружениями, полезно держать в голове и «вне-DNS» меры: например, защиту бренда домена и контроль жизненного цикла доменов (неочевидные падения резолвинга иногда начинаются с административных проблем, а не с протокола).
Частые ошибки при внедрении DoH/DoT
- Оценка по одному тесту: «сегодня 5 мс» не означает стабильность. Смотрите перцентили и повторяемость.
- Игнорирование кэша: вы измеряете кэш-хит и думаете, что «всё летает», пока не появляется кэш-мисс на новом домене.
- Слишком агрессивные таймауты: при редких сетевых всплесках получаете
SERVFAILи цепочку проблем выше (падение авторизации, timeouts в приложении). - Фильтрация без процесса изменений: включили категории — сломали прод, потому что заблокировали домен платежного провайдера или капчи.
- Смешивание целей: «приватность», «фильтрация», «самая низкая latency» — иногда это разные резолверы или разные профили.
Чек-лист выбора резолвера в 2026
Перед тем как фиксировать выбор, проверьте:
- поддерживаемые протоколы (DoH/DoT) и поведение при fallback;
- медиану и 95p задержек в ваших сетях и регионах;
- политику логирования и хранения данных под ваши требования;
- возможности фильтрации и управляемость (профили, исключения, отчеты);
- как выглядят ошибки для пользователя/сервиса при блокировке и при сбое;
- совместимость с вашей ОС/браузерами/локальным резолвером (особенно в корпоративных средах).
Когда DNS — часть пользовательской безопасности (порталы, личные кабинеты, оплаты), не забывайте и про транспорт: корректно настроенные SSL-сертификаты и понятный процесс их обновления снижают риск «странных» инцидентов, которые пользователи часто списывают на «интернет глючит».
Итог
В 2026 выбор между Cloudflare, Google, Quad9 и NextDNS — это баланс между доверенной моделью данных, удобством эксплуатации и реальными задержками. На вопрос «кто быстрее» корректно отвечать только после замеров с ваших точек и с учетом хвостов (95p), а не по единичному тесту.
Если нужна «просто быстрая и стабильная база» — обычно начинают с Cloudflare или Google и выбирают по замерам. Если важна безопасность через блокировку вредоносных доменов — смотрите Quad9. Если требуется управляемая фильтрация и политики — NextDNS часто оказывается самым практичным, но требует аккуратного change management.
