Кэширование DNS сокращает время разрешения доменных имен с 50-200 мс до 1-5 мс. Это убирает задержки при каждом обращении к веб-сайтам, API или внутренним сервисам. Настройка кэша обязательна для инфраструктур с высокой нагрузкой, Kubernetes-кластеров и домашних лабораторий, где важна скорость отклика.
Даже на быстрых каналах, таких как FTTX, плохо настроенный DNS становится узким местом. Кэш работает как краткосрочная память сети, сохраняя ответы на запросы и избавляя от повторных обращений к внешним серверам. Это снижает нагрузку на upstream-резолверы и повышает отказоустойчивость: при временной недоступности внешнего DNS локальный кэш продолжит отдавать сохраненные записи.
В 2026 году важность низких задержек возросла с распространением распределенных систем и локального ИИ, как в системах на кристалле AMD Ryzen AI MAX, где каждая миллисекунда на сетевых операциях влияет на общую производительность.
Зачем нужно кэширование DNS и как оно ускоряет работу сети
Кэширование DNS решает проблему бутылочного горлышка в цепочке запросов. Без кэша каждый запрос, будь то обращение к сайту или внутреннему микросервису, проходит полный путь рекурсивного разрешения. Это создает избыточную нагрузку на сеть и увеличивает время отклика, что особенно заметно при массовых деплоях, работе с оркестраторами вроде Kubernetes или в сетях со сложной маршрутизацией.
Выгода проявляется на двух уровнях. Для конечных пользователей и приложений скорость разрешения имен вырастает в десятки раз. Для инфраструктуры снижается объем внешнего трафика и нагрузка на корневые и авторитативные DNS-серверы. В корпоративной сети это также позволяет контролировать и логировать DNS-запросы.
Как TTL (Time to Live) балансирует между скоростью и актуальностью данных
TTL - это срок годности DNS-записи в кэше, указанный в секундах. После его истечения запись считается устаревшей и при следующем запросе резолвер обращается к внешнему серверу за обновлением.
Практическое правило простое: высокий TTL (часы или дни) устанавливайте для стабильных сервисов, чьи IP-адреса редко меняются. Это дает максимальную скорость, так как записи долго хранятся в кэше. Низкий TTL (минуты) нужен для часто меняющихся записей, например, в системах балансировки нагрузки или при активных миграциях сервисов, чтобы обеспечить актуальность данных.
Риски связаны с неправильным выбором TTL. Слишком высокий TTL при смене IP-адреса ведет к простою: пользователи продолжают обращаться по старому адресу, пока запись не обновится в их кэше. Слишком низкий TTL создает лишнюю нагрузку на авторитативные серверы и увеличивает задержку, так как кэш часто признается невалидным.
Перед настройкой своего кэширующего резолвера проанализируйте TTL записей, которые часто запрашиваются в вашей сети. Используйте команды dig example.com или nslookup -type=soa example.com. Обратите внимание на TTL в ответе. Это поможет понять, с какими значениями вам придется работать, и решить, нужно ли их локально переопределять. Более глубокий анализ стратегий выбора TTL для разных сервисов можно найти в нашем отдельном руководстве.
Сравнение решений: клиентский кэш (nscd, systemd-resolved) vs серверные резолверы (Unbound, dnsmasq, BIND)
Выбор инструмента зависит от масштаба сети, требований к безопасности и контроля. Вот ключевые отличия:
| Решение | Производительность | Сложность настройки | Потребление памяти | Поддержка DNSSEC | Лучший сценарий |
|---|---|---|---|---|---|
| nscd / systemd-resolved | Низкая (один хост) | Минимальная | Минимальное | Ограниченная | Быстрая настройка на отдельном хосте, мало контроля. |
| dnsmasq | Средняя (до ~10k запр/сек) | Низкая | Низкое | Нет (в базовой сборке) | Домашние сети, маршрутизаторы, интеграция с DHCP и PXE. |
| Unbound | Высокая (десятки тыс. запр/сек) | Средняя | Среднее | Да, встроенная | Корпоративные сети, баланс безопасности и производительности. |
| BIND (named) | Очень высокая | Высокая | Высокое | Да | Крупные сети, авторитативные серверы, максимальный контроль. |
Для большинства практических задач по кэшированию выбирайте между Unbound и dnsmasq. Unbound - для корпоративных сетей, где критичны безопасность и современные стандарты. Dnsmasq - для домашней инфраструктуры, небольших офисов или виртуальных машин, где важна простота и связка с другими сервисами.
Когда выбрать Unbound: безопасность и производительность для корпоративной сети
Unbound - это современный рекурсивный резолвер с фокусом на безопасность. Его ключевое преимущество - встроенная поддержка DNSSEC из коробки. DNSSEC защищает от подмены DNS-ответов, что критично для корпоративных и финансовых сервисов.
Unbound эффективно работает с параллельными запросами и поддерживает агрессивное кэширование, включая негативный кэш (запоминание факта отсутствия домена). Функция prefetching позволяет автоматически подгружать популярные записи до истечения их TTL, поддерживая высокий хитрейт кэша.
На типичном сервере с 2-4 ядрами и 4 ГБ RAM Unbound легко справляется с нагрузкой в 20-30 тысяч запросов в секунду, что достаточно для сети на несколько сотен активных пользователей. Его конфигурация модульна и хорошо документирована.
Когда выбрать dnsmasq: простота и интеграция для домашней инфраструктуры и SMB
Dnsmasq - легковесное и многофункциональное решение. Его главный плюс - один конфигурационный файл для управления DNS, DHCP и даже TFTP (для PXE-загрузки). Статические записи можно прописывать прямо в файле /etc/hosts или в конфиге dnsmasq, что очень удобно для небольших сетей.
Он потребляет минимум ресурсов, идеально подходит для виртуальных машин, контейнеров или хостов TrueNAS в домашней лаборатории. Однако у dnsmasq есть ограничения: менее гибкое управление кэшем по сравнению с Unbound и однопоточная модель обработки запросов в старых версиях, что может стать узким местом при высокой нагрузке.
Пошаговая настройка кэширующего резолвера Unbound для максимальной производительности
Установите Unbound в зависимости от дистрибутива:
# Для Debian/Ubuntu
sudo apt update && sudo apt install unbound
# Для CentOS/RHEL 8+
sudo dnf install unbound
# Для CentOS/RHEL 7
sudo yum install epel-release
sudo yum install unboundОсновной конфигурационный файл находится в /etc/unbound/unbound.conf. Приведем базовую рабочую конфигурацию с комментариями:
server:
# Интерфейсы прослушивания. Для локального использования.
interface: 127.0.0.1
interface: ::1
# Для доступа из сети раскомментируйте и укажите свой IP.
# interface: 192.168.1.10
port: 53
# Безопасность: разрешаем запросы только с локального хоста и внутренней сети.
access-control: 127.0.0.0/8 allow
access-control: ::1 allow
# access-control: 192.168.1.0/24 allow
# Включение DNSSEC валидации
auto-trust-anchor-file: "/var/lib/unbound/root.key"
# Настройки кэша
# Минимальное время жизни записи в кэше (сек). Игнорирует слишком низкие TTL.
cache-min-ttl: 300
# Максимальное время жизни записи в кэше (сек).
cache-max-ttl: 86400
# Включение prefetch: подгрузка популярных записей до истечения TTL.
prefetch: yes
prefetch-key: yes
# Размер кэша для сообщений и наборов записей. Значения в байтах.
msg-cache-size: 100m
rrset-cache-size: 200m
# Отдавать "просроченный" кэш, если upstream не отвечает (для устойчивости).
serve-expired: yes
serve-expired-ttl: 3600
# Upstream-серверы. Можно указать несколько для отказоустойчивости.
forward-zone:
name: "."
forward-addr: 1.1.1.1@853 # Cloudflare DNS over TLS
forward-addr: 8.8.8.8@853 # Google DNS over TLS
forward-tls-upstream: yesПроверьте синтаксис конфигурации и перезапустите сервис:
sudo unbound-checkconf /etc/unbound/unbound.conf
sudo systemctl restart unbound
sudo systemctl enable unboundПротестируйте работу, сравнив время запроса до и после настройки. Укажите в запросе ваш новый сервер (например, 127.0.0.1):
time dig @127.0.0.1 admin-wiki.ruПервый запрос займет обычное время, последующие - единицы миллисекунд.
Оптимизация параметров кэша: размер, TTL и агрессивный prefetch
Для тонкой настройки под высокую нагрузку учитывайте следующие параметры:
- msg-cache-size и rrset-cache-size: Рассчитывайте, исходя из ожидаемого количества уникальных записей. Одна запись с несколькими RRset может занимать ~1-2 КБ. Для сети с 10 тыс. активных доменов установите размеры 50m и 100m соответственно. Мониторите статистику (
unbound-control stats) на предмет cache-misses. - cache-min-ttl и cache-max-ttl: Параметр
cache-min-ttl: 300(5 минут) защищает от слишком низких TTL, которые выставляют некоторые CDN (иногда 1-30 секунд). Это снижает нагрузку на upstream, но может задержать обновление записей.cache-max-ttl: 86400(сутки) предотвращает бесконечное хранение устаревших данных. - prefetch: Если включен, Unbound будет автоматически обновлять записи, к которым часто обращаются, когда их TTL подходит к концу (обычно за 10% времени до истечения). Это поддерживает хитрейт кэша выше 90%.
- serve-expired: Критически важная настройка для отказоустойчивости. Если все upstream-серверы недоступны, Unbound продолжит отдавать записи из кэша, даже если их TTL истек, в течение времени, заданного в
serve-expired-ttl.
Настройка для корпоративной сети: безопасность, ACL и мониторинг
В корпоративной среде настройте списки контроля доступа (ACL), чтобы резолвером могли пользоваться только доверенные подсети:
access-control: 10.0.0.0/8 allow
access-control: 172.16.0.0/12 allow
access-control: 192.168.0.0/16 allow
access-control: 0.0.0.0/0 refuse # Запрет всех остальныхВключите расширенное логирование для аудита и диагностики:
server:
verbosity: 2
logfile: "/var/log/unbound/unbound.log"
log-time-ascii: yesДля мониторинга производительности активируйте встроенный сервер статистики. Он отдает метрики в формате, совместимом с Prometheus:
server:
statistics-interval: 60 # Сбор статистики каждые 60 секунд
statistics-cumulative: no # Сбрасывать счетчики каждый интервал
remote-control:
control-enable: yes
control-interface: 127.0.0.1 # Ограничьте доступ!
control-port: 8953
server-key-file: "/etc/unbound/unbound_server.key"
server-cert-file: "/etc/unbound/unbound_server.pem"
control-key-file: "/etc/unbound/unbound_control.key"
control-cert-file: "/etc/unbound/unbound_control.pem"После этого вы сможете получать метрики, обращаясь к http://127.0.0.1:8953, и интегрировать их в Grafana. Ключевые метрики для наблюдения: общее число запросов (total.num.queries), хитрейт кэша (total.requestlist.avg), время отклика. Более сложные сценарии мониторинга производительности систем, включая Nginx и API, разобраны в нашем руководстве по TTL.
Настройка dnsmasq в качестве кэширующего DNS и DHCP сервера для домашней сети
Установите dnsmasq:
# Debian/Ubuntu
sudo apt install dnsmasq
# CentOS/RHEL
sudo yum install dnsmasqПеред редактированием создайте резервную копию оригинального конфига. Основной файл конфигурации - /etc/dnsmasq.conf. Минимальная конфигурация для кэширования:
# Слушаем на всех интерфейсах. Для ограничения укажите конкретный.
# listen-address=127.0.0.1,192.168.1.1
listen-address=127.0.0.1
# Порт
port=53
# Размер кэша (количество записей). 1000-10000 - типичные значения.
cache-size=1000
# Локальный TTL для записей, полученных от upstream. Не переопределяет исходный TTL.
local-ttl=300
# Upstream-серверы. Можно указать несколько.
server=1.1.1.1
server=8.8.8.8
# Не читать /etc/hosts. Если нужны локальные записи, оставьте закомментированным.
# no-hosts
# Если нужно добавить свои статические записи, используйте:
# address=/mylocal.host/192.168.1.10
# address=/nas.local/192.168.1.100Если dnsmasq будет работать на том же хосте, что и systemd-resolved, отключите или остановите последний, чтобы избежать конфликта на 53 порту:
sudo systemctl disable --now systemd-resolvedПерезапустите dnsmasq и проверьте его статус:
sudo systemctl restart dnsmasq
sudo systemctl enable dnsmasq
dig @127.0.0.1 google.comDnsmasq также позволяет легко блокировать рекламу и трекеры, указывая файлы со списками доменов для перенаправления в никуда:
# В конфиг dnsmasq.conf добавить:
addn-hosts=/etc/dnsmasq.d/blocklist.txt
# Или использовать специальный формат для перенаправления на локальный хост:
address=/doubleclick.net/127.0.0.1Для управления сложными правилами фильтрации и балансировки, например, на основе геолокации, ознакомьтесь с нашим руководством по геофильтрации DNS.
Мониторинг, диагностика и решение типичных проблем с DNS-кэшем
Основной инструмент диагностики - dig. С его помощью можно узнать время ответа, используемый TTL и сервер, который дал ответ.
Чтобы проверить, берется ли ответ из кэша, используйте флаг +stats и обратите внимание на время отклика (query time). При повторном запросе к тому же домену оно должно быть близко к 0 мсек:
dig @127.0.0.1 admin-wiki.ru +statsПроверьте, какой TTL возвращает запись. Если значение не уменьшается с каждым новым запросом, значит, работает переопределение TTL (например, через cache-min-ttl в Unbound).
Очистка кэша:
- Unbound:
sudo unbound-control flush(очистить все) илиsudo unbound-control flush_zone example.com. - Dnsmasq: Перезапуск сервиса (
sudo systemctl restart dnsmasq) или отправка сигнала SIGHUP:sudo killall -HUP dnsmasq. Это перечитает конфиг и hosts-файлы, но не очистит кэш полностью в некоторых версиях. Для полной очистки требуется перезапуск.
Типичные проблемы и их решение:
- «Кэш не работает, запросы медленные». Проверьте:
- Файрвол: открыт ли порт 53 на интерфейсе, где работает резолвер? (
sudo ss -tulpn | grep :53). - Доступность upstream-серверов: может ли резолвер выходить в интернет? Проверьте
dig @8.8.8.8 google.com. - Конфигурацию: нет ли ошибок в конфиг-файле? Используйте
unbound-checkconfилиdnsmasq --test.
- Файрвол: открыт ли порт 53 на интерфейсе, где работает резолвер? (
- «Устаревшие записи после смены IP». Очистите кэш на резолвере (см. выше). Проверьте TTL старой записи. Если TTL был высоким (например, 24 часа), клиенты будут видеть старый IP до его истечения. В будущем для критичных записей уменьшайте TTL заранее.
- «Медленные ответы сразу после очистки кэша». Это нормальное поведение, пока кэш прогревается. Для смягчения эффекта используйте prefetch в Unbound.
Мониторинг хитрейта кэша (hit rate) - ключевой показатель эффективности. В Unbound статистика доступна через unbound-control stats, ищите метрики total.num.cachehits и total.num.cachemiss. Хитрейт выше 80-90% считается хорошим. Низкий хитрейт указывает на слишком маленький размер кэша или очень низкие TTL у запрашиваемых доменов. Общие принципы диагностики проблем кэширования, применимые и к веб-серверам, подробно описаны в нашем руководстве по оптимизации DNS-кэширования.
Итоги и рекомендации: какое решение внедрить в вашем случае
Используйте эту шпаргалку для быстрого выбора:
- Домашняя сеть, хост TrueNAS, виртуальная машина: Выбирайте dnsmasq. Он прост в настройке, потребляет мало ресурсов и может совмещать роли DNS и DHCP-сервера.
- Офисная сеть (SMB), несколько десятков пользователей, требования к безопасности: Выбирайте Unbound. Его настройка займет немного больше времени, но вы получите встроенный DNSSEC, высокую производительность и гибкое управление кэшем.
- Корпоративная сеть, дата-центр, Kubernetes-кластер: Выбирайте Unbound в качестве рекурсивного кэширующего резолвера. Для авторитативных зон (если нужно размещать свои домены) рассмотрите BIND или PowerDNS, как описано в нашем расширенном руководстве.
- Быстрая проверка на отдельном сервере или ноутбуке: Используйте встроенный systemd-resolved или nscd. Настройка минимальна, но и контроль ограничен.
После внедрения наблюдайте за ключевой метрикой - средним временем разрешения запроса. Используйте мониторинг для отслеживания хитрейта кэша и нагрузки на резолвер. Периодически обновляйте ПО для получения исправлений уязвимостей и новых функций.
Для углубленного изучения всегда обращайтесь к официальной документации: Unbound, dnsmasq. Если ваша работа связана с интеграцией различных API, включая модели ИИ вроде Gemini, для автоматизации задач, вам может пригодиться агрегатор AiTunnel, который предоставляет единый доступ к множеству нейросетей.
Правильно настроенное кэширование DNS - это не разовая оптимизация, а базовая инфраструктурная практика. Оно обеспечивает предсказуемо низкие задержки, повышает отказоустойчивость сети и снижает зависимость от внешних сервисов.