Диагностика проблем с DNS: методика и команды — SVES

«Не работает интернет» в половине случаев означает «не резолвится DNS». Отличить одно от другого — вопрос двух команд.

Что решает эта инструкция

Методика поиска места обрыва в цепочке DNS-резолвинга. Пройдём от локального кэша до авторитетного сервера домена и определим, какое звено отвечает неправильно.

Шаг 1: DNS или сеть

Первым делом отделите проблему DNS от проблемы связности:

ping -c 3 1.1.1.1
ping -c 3 cloudflare.com

Интерпретация:

Оба проходят — DNS работает, проблема в другом
По IP проходит, по имени нет — проблема в DNS
Оба не проходят — проблема со связностью, DNS ни при чём

Шаг 2: какой резолвер используется

На Linux с systemd-resolved:

resolvectl status

Смотрите строку DNS Servers для активного интерфейса. Файл /etc/resolv.conf в этой схеме указывает на 127.0.0.53 — это заглушка systemd-resolved, а не реальный сервер.

Без systemd-resolved:

cat /etc/resolv.conf

Windows:

Get-DnsClientServerAddress -AddressFamily IPv4 |
    Where-Object { $_.ServerAddresses } |
    Format-Table InterfaceAlias, ServerAddresses

Шаг 3: проверка через разные резолверы

Ключевой шаг диагностики — сравнить ответы от разных серверов:

dig +short example.com                 # системный резолвер
dig +short example.com @1.1.1.1        # Cloudflare
dig +short example.com @8.8.8.8        # Google
dig +short example.com @9.9.9.9        # Quad9

Что означают расхождения:

Ситуация	Вывод
Все отвечают одинаково	DNS здоров, ищите проблему дальше по стеку
Системный молчит, публичные отвечают	Проблема в вашем резолвере или пути к нему
Все молчат	Проблема на стороне домена или его NS-серверов
Разные адреса	Кэш с устаревшей записью либо подмена DNS

Шаг 4: полная цепочка резолвинга

Проследить весь путь от корневых серверов:

dig +trace example.com

Вывод покажет последовательность: корневые серверы → серверы зоны (.com, .ru) → авторитетные NS домена → финальный ответ. Обрыв цепочки виден сразу — на каком уровне перестали приходить ответы.

Шаг 5: авторитетные серверы домена

dig NS example.com +short

Спросить напрямую у каждого — минуя все кэши:

dig example.com @ns1.example.com +short

Если авторитетные серверы отвечают правильно, а публичные резолверы — нет, значит запись изменена недавно и ещё не разошлась по кэшам.

Шаг 6: TTL и время жизни кэша

dig example.com

В секции ANSWER первое число после имени — оставшийся TTL в секундах. Пока он не истечёт, резолверы будут отдавать старое значение.

Совет. Планируете смену IP — за сутки уменьшите TTL до 300 секунд, переключитесь, убедитесь что всё работает, верните обратно. Это превращает сутки ожидания в пять минут.

Типичные проблемы

NXDOMAIN — домена не существует

Проверьте, что домен не истёк:

whois example.com | grep -iE "expiry|expiration|paid-till"

SERVFAIL

Резолвер не смог получить ответ. Частая причина — сломанный DNSSEC. Проверьте, резолвится ли без валидации:

dig example.com @1.1.1.1 +cd

Если с ключом +cd работает, а без него нет — проблема в DNSSEC-подписи домена.

Резолвится, но не тот адрес

Проверьте файл hosts — он обходит DNS полностью:

grep -v "^#" /etc/hosts | grep -v "^$"

Windows: C:\Windows\System32\drivers\etc\hosts

Резолвинг медленный

Измерьте время ответа каждого резолвера:

for s in 1.1.1.1 8.8.8.8 9.9.9.9; do
  echo -n "$s: "
  dig example.com @$s | grep "Query time"
done

Нормальное время — до 50 мс для ближайшего резолвера.

Проверка результата

dig +short example.com
curl -sI https://example.com | head -1

Первая команда должна вернуть ожидаемый IP, вторая — HTTP-статус.

Итог

Порядок проверки: ping по IP против ping по имени → какой резолвер настроен → сравнение ответов от разных резолверов → dig +trace для полной цепочки → опрос авторитетных NS напрямую. На каком шаге ответы разошлись — там и проблема.