Тест производительности DNS: dnsperf/resperf и выбор TTL

Зачем вообще тестировать DNS

DNS часто воспринимают как «всегда работающую» часть инфраструктуры. Пока не начнутся всплески трафика, миграции или неожиданные таймауты на резолверах пользователей. Правильный тест производительности помогает понять реальную пропускную способность (QPS), задержки (latency), устойчивость к пикам и эффект настроек кэширования (TTL) на трафик к авторитативным серверам.

В этой статье разберёмся, как использовать dnsperf и resperf для измерений, как готовить репрезентативные наборы запросов, чем отличаются сценарии для authoritative и resolver, и какие TTL выбирать для разных типов записей, чтобы не перегружать инфраструктуру и не ухудшать UX пользователей.

Что именно измеряем

Для DNS нас интересуют несколько метрик:

• Задержка ответа: среднее и перцентили (p50/p95/p99).
• Пропускная способность: устойчивый QPS без деградации задержки и ростов потерь.
• Потери/таймауты: доля запросов, не получивших ответ вовремя.
• UDP vs TCP: доля переходов на TCP (например, из-за фрагментации или TC=1), влияние DNSSEC и EDNS.

Главный признак насыщения — перцентили задержек расползаются вверх раньше, чем достигаете «желаемого» QPS. Потери и таймауты — уже постфактум.

dnsperf и resperf: в чём разница

Оба инструмента из одного набора. В общих чертах:

• dnsperf — генерирует трафик с фиксированной или ограниченной нагрузкой, меряет задержки и успешность. Хорош для стабильных прогонов, профилирования и A/B-сравнений конфигураций.
• resperf — «рампит» нагрузку, постепенно повышая предлагаемый QPS, чтобы увидеть, где сервер насыщается и как меняются задержки и потери по мере роста нагрузки.

Оба работают с файлом запросов, где каждая строка — домен и тип: например, www.example.org A или _25._tcp.mx.example.org TLSA. Это позволяет повторяемо воспроизводить реальные профили нагрузки.

Авторитативный vs резолвер: разные цели

Авторитативный сервер

Цель — понять, сколько запросов в секунду обрабатывает сервер зоны, с какими задержками и как на это влияет состав ответов (размеры, DNSSEC, наличие CNAME, доля NXDOMAIN). Резолверов между тестирующим хостом и авторитативом лучше не иметь: направляйте трафик напрямую на IP авторитативного сервера, чтобы исключить кэширование по пути.

Кэширующий резолвер

Цель — замерить латентность для кэш-хитов и кэш-миссов, устойчивый QPS и поведение под ростом нагрузки. Здесь важно уметь прогревать кэш или, наоборот, намеренно бить по «холодным» именам, чтобы видеть разницу.

Подготовка стенда: чтобы не тестировать случайности

• Синхронизируйте время (NTP/chrony) — перцентили и таймауты чувствительны к расхождениям.
• Отключите защитные лимиты на период теста: response rate limiting (RRL), лимиты в межсетевом экране, профили IPS/IDS. Верните обратно после.
• Зафиксируйте частоты CPU (performance governor) и отключите энергосбережение, чтобы исключить «дрожание» латентности из‑за турбобустов.
• Проверьте сетевой маршрут и MTU, чтобы фрагментация не искажала картину. Для DNS по UDP разумно придерживаться EDNS-окна в районе 1232 байт, чтобы не ловить фрагменты на магистралях.
• Файрвол: минимизируйте conntrack для UDP: при больших QPS таблицы состояния могут стать бутылочным горлышком. На время теста можно обойтись простыми stateless-правилами для порта 53.

Если нет подходящей машины для генерации нагрузки и сбора метрик, оперативно поднимите отдельный генератор на VDS рядом с тестируемым сервером, чтобы контролировать маршрут и задержки.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Готовим набор запросов

Для авторитативного сервера

• Сгенерируйте запросы по вашим зонам: A/AAAA, MX, NS, TXT, CNAME, PTR для обратных, а также долю запросов, дающих NODATA и NXDOMAIN (жизненно важно для реальной картины).
• Добавьте записи, где ответы крупнее: DNSSEC-подписанные RRset, длинные TXT (например, SPF/DMARC/DKIM), чтобы увидеть переходы на TCP.
• Распределение типов можно взять из логов производственной нагрузки за неделю — получится максимально честно.

Для резолвера

• Соберите «популярные» имена из ваших клиентских журналов (валидируя приватные данные), либо используйте публичные рейтинги доменов для моделирования.
• Подготовьте два файла: для прогрева кэша (hot) и для «холодного» теста (cold). В hot-файле домены должны повторяться; в cold — можно слегка рандомизировать поддомены, чтобы гарантировать кэш-мисс.
• Смешайте типы запросов в «реальных» пропорциях: A/AAAA обычно доминируют, затем NS/MX/TXT. Добавьте долю NXDOMAIN.

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

Примеры запуска

Базовый прогон dnsperf с ограничением QPS

# 60 секунд, максимум 5000 qps, 128 одновременных запросов
# замените 192.0.2.53 на целевой IP (authoritative или resolver)
dnsperf -s 192.0.2.53 -d queries.txt -l 60 -Q 5000 -c 128

На выходе смотрим среднюю задержку, p95/p99, потери и число успешных ответов. Меняя -Q и -c, строим зависимость «задержка от нагрузки».

Рамп-тест resperf

# постепенное повышение нагрузки в течение 180 секунд
resperf -s 192.0.2.53 -d queries.txt -m 180

По результату видно, на каком уровне предложенной нагрузки задержка и потери начинают резко расти. Это практический предел перед насыщением для вашего профиля запросов.

У разных сборок инструментария набор ключей может незначительно отличаться. Проверяйте -h для вашей версии, но базовые параметры неизменны: адрес сервера, файл запросов, длительность и лимиты нагрузки.

Как читать результаты

• Ищите «колено» на графике: пиковый устойчивый QPS — там, где p95 ещё стабилен, а потерь нет или они статистически пренебрежимо малы.
• Рост доли TCP указывает на слишком большие ответы (DNSSEC, много записей, длинные TXT). Это нормальная часть картины, но учитывайте нагрузку по TCP на сервере и firewall.
• Если p50 стабилен, а p95/p99 ползут вверх — вероятна конкуренция за CPU или блокировки внутри сервера имен. Проверьте количество рабочих потоков и распределение по ядрам.

Настройки ОС и сервера: что влияет

• Размеры буферов UDP/TCP и очередей сокетов. Следите за отсутствием дропа в netstat/ss и статистике интерфейсов.
• Ядра сервера: фиксируйте affinity воркеров DNS к разным ядрам. Для autoritative-софта используйте параметры, управляющие числом потоков/процессов и reuseport.
• Отключите RRL на время теста и верните после. Иначе получите искусственные потери при высокой повторяемости имен.
• Для DNSSEC сократите размер RRset (по возможности) и выставьте реалистичный EDNS-лимит (в районе 1232 байт), чтобы снизить фрагментацию.

TTL и производительность: как связаны

TTL (time to live) определяет, сколько резолвер хранит кэш для RRset. Чем больше TTL, тем меньше «попаданий» на ваши авторитативные серверы — нагрузка на них падает. Но оперативные изменения записей будут дольше «прокатываться». Баланс выбирается под профиль: стабильные записи — большой TTL, часто меняющиеся — малый.

Простая модель для популярного имени: если запросы приходят как пуассоновский процесс с интенсивностью λ, то вероятность кэш-хита у резолвера примерно H ≈ 1 − e^(−λ·TTL). С ростом TTL доля хитов быстро растёт при фиксированном λ, что резко снижает обратный трафик к авторитативу.

Практические ориентиры TTL

• A/AAAA для веб-сайтов: 300–900 секунд, если ожидаются миграции/балансировка; 3600–14400 секунд для стабильной инфраструктуры и CDN, где фронты не «скачут» по IP каждый час.
• MX: 3600–86400 секунд. Почта любит стабильность, а изменения MX редки; при миграциях TTL заранее снижают.
• NS: 86400 секунд и выше. Делегирование меняется редко; контролируйте актуальность NS через регистрацию доменов.
• TXT (SPF/DMARC/DKIM): 3600–86400 секунд. Оперировать безопасно, но не слишком часто; про практику смотрите руководство по SPF, DKIM и DMARC.
• CNAME: как для A/AAAA целевого имени, но помните: длинные цепочки CNAME увеличивают задержку резолва.
• SRV/TLSA: зависит от критичности сервиса; часто 1800–7200 секунд.

Если выпускаете wildcard-сертификаты по DNS-01 и автоматизируете создание TXT, обратите внимание на автоматизацию DNS-01 для wildcard.

Негативное кэширование (NXDOMAIN/NODATA)

TTL для негативного ответа задаётся полем MINIMUM в SOA (RFC 2308). Пример фрагмента зоны:

$TTL 3600
@ IN SOA ns1.example.com. admin.example.com. (
  2025010101 ; serial
  3600       ; refresh
  600        ; retry
  1209600    ; expire
  300        ; minimum (negative caching TTL)
)

Значение 300 означает, что резолверы будут кэшировать NXDOMAIN/NODATA до 5 минут. Это заметно снижает повторяющиеся запросы к несуществующим именам, что полезно при бурстах «шумных» клиентов и сканеров.

Не путайте TTL и «пропагацию DNS». Никакой отдельной «пропагации» нет: есть только кэширование резолверами в рамках TTL, и оно может дополнительно ограничиваться политиками резолверов.

Ограничения TTL у резолверов

Многие публичные резолверы применяют политики: ограничивают максимальный TTL (во избежание «вечных» кэшей) и иногда — минимальный TTL (защита от слишком частого обновления). Конкретные числа варьируются. Это значит, что TTL в зоне — не всегда окончательная истина; закладывайте запас и тестируйте реальную обратную нагрузку на авторитатив.

Как выбирать TTL на данных: методика

1. Соберите статистику базовой нагрузки на авторитатив: доля A/AAAA, NXDOMAIN, средние размеры ответов, текущие TTL.
2. Смоделируйте ожидаемое снижение QPS при увеличении TTL ключевых имен (формула хита кэша выше подходит как ориентир).
3. Проведите серии тестов dnsperf: сначала с текущими TTL (реальный фон), затем с понижением/повышением TTL у нескольких горячих имен (контролируемый эксперимент).
4. Оцените компромисс UX и операций: если планируются частые переключения IP, держите для этих имен TTL 60–300 секунд; остальному поднимайте TTL до часов.
5. Внедряйте поэтапно: снизить TTL за 24–48 часов до перемен, выполнить изменения, после — вернуть более высокий TTL.

Типичные ловушки в тестах

• RRL/ACL в авторитативе режет повторяющиеся запросы из тестового генератора — получаете ложные потери.
• Фрагментация UDP: слишком большой EDNS-буфер ведёт к потерям на пути и росту доли TCP. Проверьте MTU и примите 1232 как разумный предел.
• Firewall/conntrack упирается раньше сервера имён. Сравните локальный прогон на лупбэке и через сеть; смотрите счётчики дропов.
• Любые внешние резолверы между вами и авторитативом искажают картину. Для авторитативного теста бейте напрямую в IP NS.
• Набор запросов «нереалистичен»: либо одни A/AAAA без NXDOMAIN, либо только «тяжёлые» DNSSEC-ответы. Балансируйте профиль.

Чек‑лист перед прогоном

• Время синхронизировано, CPU в performance, сетевой путь стабилен.
• Отключены RRL и агрессивные лимиты на время теста.
• Набор запросов отражает реальный профиль (включая NXDOMAIN и большие ответы).
• Для резолвера сделаны отдельные прогоны: cold и hot cache.
• Собираете не только среднее, но и p95/p99, долю TCP и таймаутов.

Резюме

dnsperf и resperf позволяют быстро получить честную картину производительности DNS: как реагирует авторитативный сервер и кэширующий резолвер на рост нагрузки, где «колено» задержки, когда начинаются потери и как на всё это влияет размер ответов и кэширование. Корректный выбор TTL — ключ к снижению фоновой нагрузки и повышению устойчивости: стабильным RRset — часы и сутки, динамичным — минуты. Тестируйте с несколькими профилями запросов, проверяйте перцентили и следите за долей TCP — это поможет избежать сюрпризов в пиковые моменты.