Сайт открывается медленно, но причина еще не установлена. Проверьте сеть по известному IP, затем DNS-запрос с проблемного клиента. Ping домена не исключает сбой: имя разрешается до отправки ICMP. Если DNS быстр, проверяйте TCP/TLS, прокси, IPv6 и приложение. Диагностика DNS-сервера сравнивает ответы конкретного узла, системного резолвера и приложения. Разберем dig, nslookup, захват, журналы и коды ответа.
Пять типичных симптомов проблем с DNS-сервером
Одна жалоба может иметь несколько причин. Эти симптомы помогают выбрать первый тест, но сами по себе не доказывают неисправность DNS.
- «Интернет тормозит». Отдельно измерьте разрешение имени и установление соединения. Быстрый ICMP до известного IP не проверяет DNS и не исключает задержку TLS или приложения.
- «Сервер не найден». Приложения выдают ошибку подключения, хотя сервис физически доступен: клиент не может превратить имя в IP-адрес.
- «Внутренние ресурсы недоступны». Если подключение по IP работает, сравните DNS-ответ для server-1c.corp.example с системным разрешением. Причиной могут быть запись, DNS-view, hosts или клиентский кеш.
- «Периодически недоступен». Запишите время сбоя и сопоставьте запросы с нагрузкой, журналами и таймаутами апстрима. Самопроизвольное восстановление не доказывает перегрузку.
- «После обновления не разрешает имена». Проверьте фактическую конфигурацию, загрузку зон, ACL и журнал службы. Временное совпадение с обновлением помогает поиску, но не устанавливает причину.
Зафиксируйте имя, тип, сервер и время запроса.
Инструменты диагностики: dig, nslookup, tcpdump и логи
dig и nslookup: базовые команды
dig — стандартная утилита диагностики DNS в Linux, входит в пакет bind-utils или dnsutils. Синтаксис: dig @DNS-сервер имя запись-тип.
dig @10.0.1.10 server-1c.corp.example A проверяет конкретный DNS. Запишите status, флаги, ANSWER, TTL и Query time. Сравните первый и повторный запросы: рекурсия и кеш могут дать разные задержки.
dig @10.0.1.10 example.com A проверяет корпоративный DNS. dig example.com +trace прослеживает публичную делегацию с клиента: нужен прямой доступ к внешним DNS по UDP/TCP 53. @server влияет лишь на начальный запрос корневых NS, а не трассирует форвардер.
Обратный резолвинг: dig @10.0.1.10 -x 10.0.1.15 показывает имя хоста по IP-адресу, полезно при разборе логов.
Запросите NS и SOA внутренней зоны напрямую: dig @10.0.1.10 corp.example NS +norecurse. Проверьте aa и serial у авторитетных серверов. NS-ответ рекурсора может быть кешированным. Здесь используется corp.example: .local зарезервирован для mDNS.
В nslookup задайте server 10.0.1.10, затем set type=a и имя server-1c.corp.example. Команды выполняют по очереди в интерактивном режиме. Утилита проверяет DNS-ответ, но не весь путь разрешения имени приложением.
tcpdump и логи Bind9 и Windows DNS
sudo tcpdump -i ИНТЕРФЕЙС -n port 53 показывает обычный DNS UDP/TCP. Подставьте имя интерфейса и обеспечьте права. DoH и DoT фильтр 53 не видит. Если dig работает, сравните системный резолвер, hosts, кеш и приложение: оно может использовать другой сервер. Затем проверяйте путь пакетов.
Проверьте journalctl -u bind9 или фактическую службу named. Путь логов зависит от journald, rsyslog и BIND. Отдельный named.log требует канала, прав и ротации. Ищите ошибки загрузки, ACL, передачи и валидации по времени и имени. Сообщения зависят от версии.
В Event Viewer откройте Applications and Services Logs → Microsoft → Windows → DNS-Server. Audit отражает изменения, Analytical подробные DNS-события. Последний включают отдельно с Show Analytic and Debug Logs. Общий DNS Server log и Debug Logging отдельны. Debug Logging ограничьте временем, фильтрами и размером файла.
Начните с ответа конкретного DNS. Если причина не видна, подключите журналы, захват и проверку клиента. Срок диагностики зависит от причины и доступных данных.
Разбор частых проблем DNS и решений
Медленное разрешение. Сравните первый и повторные запросы с учетом TTL и кеша, задержки клиента и DNS-узла. Проверьте CPU, память, потери и апстрим. max-cache-size увеличивайте при подтвержденной нехватке: это расходует память, не гарантируя ускорения. Порог задают по целям сервиса.
SERVFAIL не доказывает одну причину. Сравните dig @10.0.1.10 example.com A +dnssec и запрос с +cdflag. +dnssec запрашивает данные, не валидируя цепочку. Ответ только с CD требует проверки через delv и журнал. Сверьте время, UDP/TCP и путь форвардера или рекурсии. rndc reload перечитывает файлы, не скачивая root hints. DNSSEC глобально не отключайте.
NXDOMAIN означает отсутствие имени. Проверьте FQDN, view, авторитетный ответ, SOA и отрицательный TTL. NOERROR без записи нужного типа отличается от NXDOMAIN. Ошибка загрузки чаще дает SERVFAIL: проверьте журнал и named-checkzone corp.example /etc/bind/zones/db.corp.example. Serial исправляют по причине, не автоматически.
REFUSED означает отказ по политике. Проверьте клиента, view, allow-query, allow-query-cache и allow-recursion. Сравните свою зону с +norecurse и внешнее имя. Исправляйте подтвержденный ACL, не открывая лишнюю рекурсию.
Secondary не синхронизирован. Сравните SOA serial, проверьте TCP 53, primaries, allow-transfer и TSIG: ключи и время. Изучите журнал, NOTIFY и refresh. Добавление IP в ACL не исправит неверный serial.
Мониторинг и превентивная диагностика DNS
Как не допускать DNS-проблем
Профилактика обходится дешевле, чем разбор инцидента после жалоб пользователей, и держится на пяти практиках.
- Для BIND нужны statistics-channel и совместимый bind_exporter с ограниченным доступом. Prometheus сам не создает счетчики. Метрики запросов и ошибок дополняют клиентской пробой. Cache hit ratio считают как hits / (hits + misses) за один период по согласованной категории версии BIND.
- Разделяйте кешированные и рекурсивные пробы, наблюдайте p95/p99, SERVFAIL, таймауты и оба DNS. Пороги задают по базовой линии, интервал по допустимому незамеченному сбою.
- Централизованные логи в Elasticsearch или Loki: при инциденте виден полный контекст за нужный период, а не разрозненные строки в локальном файле.
- В согласованном окне проверьте отказ primary: доступность резерва и актуальность зон. Частоту задает регламент. Наличие secondary не доказывает его готовность.
- Следите за security advisory своей ветки BIND. Критичные исправления устанавливайте по оценке риска и срочному регламенту, не ожидая квартального окна.
Оптимизация корпоративной сети помогает устранить подтвержденные потери и задержки DNS-пакетов. Сначала локализуйте причину: сбой зоны или ACL не лечится заменой коммутатора.
Типичные ошибки диагностики DNS
При диагностике разделяйте прямой DNS-запрос, системное разрешение и обращение приложения. Это помогает избежать следующих ошибок.
- Тестируют DNS-сервер с него самого, а не с клиентской машины, где реально возникает проблема.
- Не сравнивают DNS с системным разрешением. dig и nslookup не проверяют hosts. В Linux сопоставьте getent hosts server-1c.corp.example, ответ приложения и DNS.
- Сбрасывают кеш до сохранения RCODE и TTL. ipconfig /flushdns очищает кеш Windows, resolvectl flush-caches относится к systemd-resolved. Серверный и браузерный кеши проверяют отдельно.
- Диагностируют только primary DNS, а secondary остается рассинхронизирован, хотя должен подхватывать нагрузку.
- Не проверяют TTL записей: заниженный TTL создает лишнюю нагрузку на сервер, завышенный надолго консервирует устаревшие данные.
- Экономят на мониторинге и узнают о сбое DNS от пользователей, а не от системы наблюдения.
- Держат единственный DNS-сервер без secondary, и сбой этой точки останавливает резолвинг для всей сети.
- Не определяют точку DNSSEC-валидации. Обычно проверяет доверенный рекурсивный DNS, а не каждый stub-клиент. Нужны правильный резолвер и доверенный путь к его ответу.
- Правят только /etc/resolv.conf, хотя он может быть сгенерирован или указывать stub. Проверьте DNS и доменные маршруты в NetworkManager либо systemd-resolved, меняйте управляющий сервис.
- Не настраивают split-horizon там, где внутренние и внешние клиенты должны получать разные ответы на один домен.
Заключение
Начните с имени, типа записи и конкретного DNS. Код ответа выбирает тест, но редко доказывает причину. Сравните системный резолвер, приложение, журналы и сеть. До исправления сохраните данные, после повторите запрос и проверьте оба DNS.
Профилактика включает клиентские пробы, актуальность зон, резерв и исправления безопасности. Пороги и проверки задают по целям сервиса.
Если проверка выявила проблему каналов, коммутаторов или резервирования, Serverzilla поможет подобрать сетевое оборудование под доступность DNS. Передайте результаты замеров и требования к отказному режиму.