Расскажем, как проект стал одним из основных DNS-сервисов в мире. Статья написана на основе доклада технического директора AdGuard Андрея Мешкова и директора по инфраструктуре AdGuard Константина Замякина в рамках Профессиональной конференции разработчиков высоконагруженных систем Saint HighLoad++ (июнь-2025).

Что это за компания

Компания AdGuard появилась в далёком 2009 году в Москве, а с 2016 года она базируется на Кипре. В мире она по большей части известна благодаря блокировке рекламы, но ещё разрабатывает много сервисов для защиты приватности. AdGuard доверяют сотни миллионов пользователей по всему миру.

Сегодня расскажем о, наверное, самом популярном продукте компании — AdGuard DNS. 

Что такое AdGuard DNS

Это фильтрующий публичный DNS-сервис, который блокирует рекламу и трекинг. «Фильтрующий» — значит, что он преобразует ответы по заданным пользователем правилам, например, блокирует домены, перенаправляет их или меняет какие-то специфические DNS-записи. Существует очень много вариантов.

Показатели нагрузки достаточно большие:

• 100M пользователей,

• 5M запросов в секунду,

• 130 серверов,

• 20 точек присутствия,

• 10 ПБ трафика в месяц,

• 95% трафика — DNS-over-HTTPS/TLS.

В топе мировых DNS находятся Google DNS (неоспоримый № 1) — на него приходится 13% всех DNS-запросов в мире, Cloudflare DNS — ещё 2%. Дальше идут OpenDNS, AdGuard DNS и, может быть, ещё пара имён. AdGuard DNS делит с ними приблизительно третье место по количеству пользователей, но даже для этой позиции нагрузка приличная.

Начнём с основ — не ломайте DNS

Domain Name System, или DNS, — это система для получения информации о доменах. 

Современный DNS — это не только соответствие доменов IP-адресам, но и целое распределенное хранилище различных метаданных (SVCB-, HTTPS-записи, всевозможные верификации и публичные ключи). Теперь с помощью DNS вы получаете не только адрес домена, но и:

• рекомендуемый транспорт (H2/H3);

• запасные дороги (альтернативные хосты);

• инструкции по безопасности (TLS, ECH) и параметры шифрования;

• ссылки на другой навигатор (DDR) и даже ссылки на другой DNS-сервер.

Мало про какие поломки придумали мемы, но про DNS сразу несколько. Наверное, самый известный из них — это мем-хайку:

Важно понимать, что DNS — это по-настоящему распределенная система: в ней нет единой точки, которая отвечает за всё. Это одновременно и преимущество, и недостаток — зачастую очень сложно понять, где же и что сломалось. Усугубляет ситуацию то, что DNS — это базовая система интернета, если сломан DNS — сломано всё. Но ещё хуже, когда DNS сломан не полностью, а в каком-то узком месте, которое очень часто и найти-то сложно.

Есть вообще идеальный пример того, когда всё пошло не так из-за DNS, а мы получили свой первый миллион RPS (примерно трёхкратный рост нагрузки на тот момент).

Октябрь 2021 года. Инженеры одной экстремистской соцсети случайно удалили маршруты к своим DNS-серверам, которые обслуживают их зону, и домены всех их сервисов перестали быть доступны — они просто отвечали тайм-аутом. Это затронуло не только публичные, но и внутренние сервисы компании: чтобы всё починить, надо было перезагрузить сервера, но доступ в дата-центр пропал — система контроля доступа тоже была завязана на внутренние домены, которые стали недоступны. Как в итоге попали в дата-центр — доподлинно не известно, но устранение ошибки заняло 6 часов.

Зачем AdGuard его сделали

В 2016 году, во времена бурного развития Internet of things стало понятно, что традиционные методы блокировки рекламы и трекинга не работают — нельзя поставить программу на каждый умный холодильник или лампочку. Использовать DNS казалось логичным, ведь даже этой лампочке нужно обратиться к DNS-серверу, чтобы узнать, куда же слить ваши данные.

Команда AdGuard решила быстренько собрать свой фильтрующий DNS-сервер. Изначально задача казалась лёгкой: простой протокол, простой механизм блокировки, много возможностей реализации, есть на кого ориентироваться.

Конечно, в реальности всё оказалось иначе. В процессе команда разработчиков совершила много ошибок, которые всё же привели сервис к многомиллионной аудитории. Расскажем, какие трудности помогли отшлифовать AdGuard DNS до успешного продукта.

Первая версия

Силами одного Android-разработчика на Java за неделю сделали первую версию.

Команда вспоминает эту разработку с неловкостью: она не умеет делать рекурсию, а просто форвардит запрос в «восьмёрки», не имеет кэша — вообще ничего не имеет. Ещё не осознавая, насколько всё плохо, проект с меткой ��бета-версия» отправили в свободное пользовательское плавание.

Чтобы подчеркнуть качество этого продукта, команда поделилась историей про «любимый» фэйл с TCP. Дело в том, что DNS — это не только UDP. Бывают ситуации, когда сервер не может вместить весь DNS-ответ в один UDP-пакет. В таком случае он не присылает сами записи в ответе, а просто ставит флаг TC (truncated).

Это значит, что клиент вновь отправит тот же самый запрос, но уже по TCP-53. А вот TCP-53 разработчики забыли учесть и узнали о том, что они ломают людям интернет совершенно случайно. Один пользователь пожаловался, что ему сломали YouTube, который возвращал в А-записи как раз много IP-адресов — это разработчики не предусмотрели.

Как отмечает команда AdGuard, было очень стыдно. Какой вывод делает программист, когда сталкивается с такими ситуациями? Надо всё выкинуть и переписать. Так и сделали.

Первая серьёзная версия: CoreDNS, Anycast и все-все-все

Команда задалась вопросом, как переписать продукт:

• чтобы сервер умел работать под высокой нагрузкой;

• чтобы работал надёжно;

• чтобы были метрики. В прошлой версии их вообще не было, и разработчики не знали; что происходит внутри системы.

Писать с нуля не хотелось. Взяли за основу CoreDNS, который по результатам внутренних поисков выглядел наиболее перспективно:

• Популярный продукт.

• Поддерживает DOH/DoT «из коробки».

• Активно развивается, как тогда казалось.

• Главное — имеет систему плагинов.

Звучит идеально!

Команда написала свой плагин, который реализует необходимую дополнительную логику, кэширование, фильтрацию, обновление фильтров и тому подобное.

Наконец, в 2018 году AdGuard созрела до того, чтобы снять метку бета-версии. Теперь всё работает как часы, думали разработчики.

Но на практике оказалось, что CoreDNS не так уж и хорош.

Возникли проблемы с расширяемостью: новые протоколы так просто в CoreDNS не добавить, плагином уже не ограничиться, приходится форкать, и не только его, но и его зависимости. А то, что нафоркал, обратно в CoreDNS вернуть тяжеловато — они крайне нежелательно принимают контрибьюшны.

Расскажем одну историю, которая демонстрирует все эти проблемы сразу.

Пример: отсутствие pipelining

В CoreDNS (как тогда, так и сейчас) отсутствует поддержка механизма TCP-pipelining. Что это значит? Если DNS работает over TCP либо over TLS (в случае AdGuard DNS это гораздо более популярный протокол), то клиент может записать в соединение сразу много запросов, не дожидаясь ответа. Дальше сервер может записать ответы в любом порядке. Очень удобно,  но в CoreDNS это работает иначе.

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

Разработчикам пришлось пропатчить не сам CoreDNS, а его зависимости. Исправленную версию принесли в апстрим, но мейнтейнеры ответили, что сначала сделают рефакторинг и только потом внедрят патч. Спустя шесть лет ничего не изменилось, баг на месте, имейте в виду, предупреждает команда AdGuard.

Но даже с этой версией AdGuard DNS вырос в глобальный сервис. Участники команды даже помнят конкретный момент, когда это произошло. Им написали из самого крупного корейского провайдера: «Ваши сервера в Токио отвечают медленно, нам жалуются пользователи, поэтому мы перенаправляем их в Сингапур. Почините Токио, напишите нам письмо».

В AdGuard удивились: вот это да, мы уже так влияем на глобальный роутинг целой страны, что, нам уже пишут и ругают! Так они поняли, что стали достаточно крупным сервисом, и пришло время заниматься не только софтом, но и другими аспектами.

Глобальный сервис, или Как управлять BGP, не привлекая внимание NOC’ов

Глобальный сервис — это не просто много RPS. Это значит, что люди пользуются продуктом из разных точек мира, и им всем нужен низкий latency.

Но с этим есть определённые проблемы. Нельзя взять, например, Cloudflare или Google Load Balancer, чтобы они решили все проблемы связности, как минимум потому, что адрес DNS сервера — это обычный IP-адрес, а не домен, и стандартные способы балансировки не работают здесь. Надо спускаться на уровень ниже и заниматься IP-балансировкой.

Чтобы понять, что это такое, придётся вспомнить, что такое интернет и как он работает.

Весь интернет — это не монолитная система, где есть чёткие взаимодействия. Это набор независимых участников, каждый из которых обменивается друг с другом определённой информацией, и на её основе уже принимается решение о том, как и по какому пути пойдёт трафик. Протокол общения этот называется BGP и ниже речь пойдёт о нем.

Чтобы попасть из одной подсети в другую через интернет, нужно пройти цепочку автономных систем, основываясь на той информации, что они публикуют в BGP.

Например, на схеме — ситуация, когда из одной точки в другую (от клиента к серверу) ведёт более чем одна возможная цепочка автономных систем. В приоритете будет кратчайший путь.

На основе этих знаний можно построить требуемую систему балансировки трафика между IP-адресами — Anycast. Такую схему балансировки выбрали многие участники этого рынка, в том числе и AdGuard. 

Как это работает: из разных точек мира, дата-центров AdGuard анонсирует одни и те же свои подсети, и клиентские провайдеры видят те, которые имеют кратчайший AS Path до серверов и направляют клиентский трафик к ближайшей локации. Важно понимать, что ближайшая она не географически, а в терминах BGP — имеет кратчайший AS-Path, что не всегда значит, что отправит вас на действительно ближайший сервер. Но если у вас много точек присутствия, скорее всего, ближайшая локация с обеих этих точек зрения плюс-минус будет совпадать.

Примерно так работает Google DNS — вы всегда вписываете четыре восьмёрки и попадаете, скорее всего, на ближайший сервер.

Трафик в локации получили, дальше снова нужно балансировать.

А если в локации больше одного сервера? Например, пользователя отправили в Сингапур, а в этой локации есть 20 серверов. Здесь тоже используется BGP, но уже для балансировки трафика внутри одной локации, и технология Equal-cost multi-path routing (ECMP).

В этом случае на роутере прописывают политику балансировки с инструкцией, что нужно использовать алгоритм 4-tuples: сначала нужно вычислить определённый хэш от адреса отправителя + порт отправителя + адрес получателя + порт получателя, а его, в свою очередь, разделить на количество серверов, и остаток отделения станет номером сервера, куда придёт трафик.

Это очень простой алгоритм. Но нужно обратить внимание, чтобы все машины в одной локации были примерно одной и той же конфигурации, потому что трафик распределится примерно одинаково: как правило, нет ручки, которая позволит сказать «этот сервер новый и мощный, на него можно направить 50% трафика, а остальное нужно распределить между остальными поровну».

Какие плюсы BGP Anycast увидела команда:

• Простая настройка. Это один конфигурационный файл, который может написать сетевой администратор среднего уровня.

• Высокая доступность. Можно строить схемы неограниченной сложности с многократным резервированием через разные магистрали, физические каналы — как угодно.

• Неограниченный потенциал роста. Команда AdGuard ещё продолжает их изучать.

• Отсутствие SPoF (единой точки отказа). Нет такого, что лёг Cloudflare, и все ваши сервисы недоступны.

• Независимость от провайдеров и хостеров. Это стандартизованная технология, которая не имеет никаких вендорлоков.

Но есть и минусы:

• Сложно найти хостинг, особенно виртуальный, который предоставляет BGP. Даже если предоставляет, там будет куча ограничений — например, ручная настройка ECMP.

• Это неуправляемое решение. Нельзя указать, что в Сингапуре должно быть 50% трафика, а остальные — в какой-то другой локации. То есть как Сеть решит, так наш трафик распределится.

Любимая история команды AdGuard про BGP Anycast: эффект домино

Раз в месяц у команды случается какая-нибудь история с Anycast.

Например, на одном из этапов разработчики хотели получить максимум пользы от BGP Anycast и от ECMP в частности. Рассудили так: пусть на каждом сервере будет некая readiness-проба, которая будет проверять, работает ли софт или сервер. Если не работает, то всё — нужно опустить анонс, другие сервера в этой локации справятся. В теории прекрасная задумка, но на практике оно только роняло полностью локацию, потому что сначала убивался один сервер. Остальные сервера не могли разгрести эту нагрузку, и по очереди умирали, не имея возможности подняться (ведь на них моментально начинал поступать трафик со всей локации), а потом умирала и локация. Команда разработчиков успевала вмешаться и всё исправить, но глобально проблема оставалась.

Исправить её помогало то, что у BGP есть ручка, которая позволяет немного поиграться с роутингом. В BGP есть интересная технология BGP Communities. Суть в том, что когда вы анонсируете префиксы, можете вместе с префиксом добавить строку каких-то метаданных.

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

У AdGuard был такой кейс. Есть крупный магистральный провайдер Core Backbone, у которого хорошая связность в разных частях мира. Однажды возникла проблема, что у американских пользователей AS Path до серверов AdGuard в Нью-Йорке и во Франкфурте оказался одинаковой длины, и во Франкфурте фиксировались рандомные американские пользователи. Конечно, такой высокий пинг — не здорово.

Решение было простое: выяснили у Core Backbone, какие у них есть комьюнити, и через них попросили не передавать информацию из Франкфурта в Америку. Это работает, но не идеально:

• Не все операторы поддерживают такое решение.

• Нет единого стандарта, и все участники работают по-своему.

• Не все дают документацию.

• Часто это вообще не публично, и нужно буквально написать письмо или позвонить сотруднику провайдера, чтобы узнать о BGP-комьюнити.

• Зачастую виноват не вышестоящий провайдер, а кто-то ещё, и отправить ему комьюнити нельзя.

Как балансировать трафик, кажется, разобрались — остаётся вопрос с хостингом.

Железо vs облако

Вопрос классический. Естественно, как и многие, AdGuard начинали с облака, потому что это удобно для маленького бизнеса с небольшим количеством серверов.

Но и тут возникли проблемы. Во-первых, сложно найти облако с BGP. А если его нашли, возможно, потребуется ручная настройка ECMP: чтобы установить новую виртуалку и получить на неё трафик, зачастую надо написать тикет на добавление её адреса в плечо балансировки ECMP. Ну и так как трафика всегда было много, использовать облако вышло практически в десять раз дороже, чем железо.

Но есть и плюсы: гибкость масштабирования. Можно спокойно пережить пик трафика, просто добавив сервера одной строчкой Terraform.

Но однажды системный администратор Илюха не совладал с выводом Terraform и случайно удалил весь  DNS. 

Во время плановых работ нужно было обновить конфигурацию серверов, и Terraform предложил удалить их и пересоздать. Недолго думая, админ согласился. Удалилось всё сразу, а вот пересоздание заняло по 10−15 минут на машину, а из-за лимитов хостера нельзя было сразу создать все нужные виртуалки. Но даже после этого проблемы не кончились — не работал ECMP, и нужно было писать тикеты в поддержку на его настройку… В общем, команда перешла на железо, где и остаётся сейчас. Какие от этого были плюсы:

• Появился широкий выбор конфигураций. Стало возможно иметь сервера с разным количеством памяти и разными процессорами. Стало больше и самих хостеров, и теперь можно выбирать лучшие условия.

• Полностью управляемый BGP. Но расширения инфраструктуры теперь придётся планировать, потому что нельзя быстро добавить серверов, чтобы пережить пик трафика.

К счастью, есть возможности для оптимизации.

Например, оказывается, в 2020 году можно было получить около 20% перформанса от процессора бесплатно, просто вписав на одну строчку и выключив патчи безопасности. Однако эксперименты команды показали, что чем новее процессор, тем меньше шанс, что отключение патчей безопасности поможет. На более старых это ещё может сработать.

Ещё на практике выяснили, что можно переключить scaling governor процессоров в «спорт-режим», что даже даст немалое ускорение, но результат тоже зависит от процессора. 

Так или иначе, команда AdGuard выбрала железо.

А что с софтом? Говорят, у самурая нет цели, только путь.

Переписали во второй раз

Теперь команда на опыте, теперь точно всё правильно — и по новым критериям:

• Нужно отказаться от CoreDNS, писать всё с нуля.

• Максимально сфокусироваться на производительности.

• Добавить новые функции для премиум-пользователей.

Что значит фокус на производительности

95% трафика в AdGuard DNS зашифрована, то есть это TLS. И именно TLS команда проекта оптимизирует — по двум основным векторам.

1. TLS session tickets.

В TLS установка соединения может пойти по двум путям. Первый — обычный, медленный, а второй — Session Resumption, когда не нужно договариваться о параметрах шифрования заново, он значительно проще и быстрее. Но для того, чтобы использовался второй путь, нужно где-то сохранить прошлые параметры сессии, чтобы заново их не высчитывать (в этом и смысл этой оптимизации).

Но что делать, если к вам попал трафик локации, где много серверов, с одним вы договорились о параметрах шифрования, но следующий ваш запрос отбалансировали на другой сервер — нужно заново договариваться? Вот какое решение нашли AdGuard.

Параметры сессии хранит клиент в зашифрованном виде. Сервер шифрует всё определёнными ключами, которые может использовать и для расшифровки. Если внутри локации все сервера используют одинаковый набор ключей, можно выиграть по CPU 10−20%. В AdGuard DNS используют коротко живущие TLS-соединения, поэтому в протоколах много handshakes, также немного выигрывают по трафику, потому что при Session Resumption клиенту не отправляется цельный большой сертификат.

2. Правильный выбор сертификатов сервера — ECDSA vs RSA.

Это специфично для Go. Если вы используете на сервере RSA-сертификат, то у вас handshake будет в 6−7 раз медленнее, чем если вы используете ECDSA-сертификат. 

Здесь тоже не обошлось без фэйла, который дал команде новый опыт. Однажды админ продлевал сертификаты и по ошибке выбрал дефолтный тип сертификата RSA, что привело к повышенной нагрузке на CPU. Это не сразу заметили, и через несколько часов сервера в одной из локаций перестали выдерживать нагрузку. Зато теперь у AdGuard DNS есть мониторинг типа сертификата, который сигнализирует, если выбран RSA.

(Сверх)пиковая нагрузка: что с ней делать

Вернёмся к BGP. Так как распределение нагрузки контролируется не на 100%, можно столкнуться с ситуацией, когда полученный трафик превышает возможности локации.

Можно что-то перероутить, перенастроить комьюнити, но на это требуется время. Индийские провайдеры (это достаточно большая доля трафика AdGuard DNS) часто создают проблемы, потому что:

• Они полностью закрыты для внешнего мира, у них нет комьюнити, они не отвечают на письма.

• Они могут рандомно отправить трафик в одну из нескольких точек мира.

Команда сервиса научилась распределять этот трафик, но на перегон нужно время, и эти пики надо как-то переживать.

В AdGuard придумали инновацию, которую они назвали Connlimiter. Идея в том, что после определённого лимита сервера не принимают новые соединения, но продолжают полноценно обслуживать старые. То есть ядро принимает новые соединения, но не обрабатывает их, накапливая таким образом очередь в ядре и приступая к её обработке сразу, как у сервера появятся на это ресурсы. Обычно же серверный софт всегда accept-ит как можно больше соединений, не задумываясь о том, способен ли он их сейчас обработать.

Нагрузка может стать пиковой не только из-за BGP. Есть ещё один более предсказуемый, но и более страшный «зверь» — это Android, на котором у AdGuard DNS очень много пользователей.

У Android есть одна особенность: если вы настроили у себя на девайсе Private DNS (так на Android называется DNS-over-TLS) и устройство в какой-то момент не смогло отправить DNS-запрос, оно это запоминает и продолжает повторять этот путь, пытаясь открыть соединение. И чем больше девайсов узнают о том, что у DNS-сервера проблемы, тем больше они хотят напомнить ему, что ему надо проснуться, и лезут устанавливать соединения.

Соответственно, даже если у вас рестарт, будет небольшой гарантированный пик. Если рестарт длинный, пик будет ещё выше — вплоть до падения сервера. Не идеально, но Connlimiter эту проблему решает.

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

Выводы: чему научилась команда AdGuard DNS

Вот основные выводы, которые сделала команда:

1. Большие сервисы без боли и ошибок не делаются.

2. Учиться на своих ошибках — это нормально.

3. Но лучше учиться на чужих — и AdGuard DNS щедро делятся своим опытом в open source на GitHub:

• AdguardTeam/AdGuardDNS

• AdguardTeam/AdGuardHome

• AdguardTeam/dnsproxy

• ameshkov/dnslookup

• ameshkov/godnsbench

Скрытый текст

Следующая конференция HighLoad состоится в 2026 году. Будет очень много докладов и мастер-классов, которые будут полезны всем, кто работает с высоконагруженными системами. Присоединяйтесь!