Вы запускаете nslookup example.com, видите надпись «Не заслуживающий доверия ответ» и начинаете гуглить «как исправить DNS». Спойлер: исправлять нечего.
Это не ошибка. Это не вирус. Это не взлом.
Это плохой перевод Microsoft и непонимание того, как работает DNS-кэширование.
Эта шпаргалка для тех, кто:
- увидел «Non-authoritative answer» и запаниковал
- хочет получить авторитетный ответ напрямую от NS-сервера
- диагностирует реальные проблемы DNS, а не мифические
- устал читать теорию про SOA-записи вместо команд
Когда это использовать
Реальные кейсы:
Вы сменили A-запись домена, но сайт открывается по старому IP — нужно проверить, что NS-сервер отдаёт новую запись, а не кэш провайдера.
Клиент жалуется, что «DNS не работает», а вы видите нормальный ответ от 8.8.8.8 — нужно показать, что это кэш, а не авторитетный источник.
Роутер отдаёт внутренний IP (192.168.x.x) для публичного домена — нужно понять, что это DNS-интерсепт, а не «заслуживающий доверия» ответ.
Настраиваете новый домен и хотите убедиться, что делегирование работает корректно — нужен запрос к конкретному NS.
Типичные ошибки новичков:
- Считают, что «не заслуживающий доверия» = ошибка безопасности
- Пытаются «исправить» отключением кэша DNS (ipconfig /flushdns) — после чего снова видят ту же надпись
- Не понимают разницу между рекурсивным и авторитативным запросом
Быстрый старт
Шаг 1. Узнать NS-серверы домена:
nslookup -type=ns example.com
Шаг 2. Опросить конкретный NS-сервер напрямую:
nslookup example.com ns1.example.com
Шаг 3. Если нужен dig (Linux/macOS/WSL):
dig example.com @ns1.example.com
Шаг 4. Проверить флаг авторитетности в dig (смотрим «aa» в flags):
dig example.com @ns1.example.com | grep flags
Шаг 5. Если всё равно видите проблему — проверяйте делегирование через whois, а не nslookup.
Что вообще значит «Не заслуживающий доверия ответ»?
Короткий ответ: Это означает, что ответ пришёл НЕ от владельца DNS-зоны, а от промежуточного сервера (кэш).
Технический ответ:
DNS работает так:
- Авторитативный сервер (Authoritative) — это NS-сервер, который реально хранит записи домена. Например, ns1.yandex.ru для домена yandex.ru.
- Неавторитативный ответ (Non-authoritative) — это когда ответ взят из кэша: с вашего роутера, DNS провайдера, Google Public DNS (8.8.8.8) или Cloudflare (1.1.1.1).
Кэширование — это норма. Без него интернет работал бы в 100 раз медленнее.
Метафора для джунов:
Вы спрашиваете у Google Maps, где находится ближайшая пиццерия. Google показывает вам кэшированные данные (неавторитетный ответ). Если хотите узнать точно — звоните в саму пиццерию (авторитативный запрос к NS).
Почему в Windows пишут «Не заслуживающий доверия»?
Потому что в старых версиях Windows переводчики Microsoft перевели «Non-authoritative answer» как «Не заслуживающий доверия ответ».
Правильнее было бы:
- «Неавторитативный ответ»
- «Кэшированный ответ»
- «Ответ не от источника»
Но мы получили панику и тысячи форумных тредов «как исправить недоверие DNS».
Важно: Серверу, который выдал ответ, можно доверять. Он просто не является хозяином домена.
Основные команды: получение авторитетного ответа
Команда 1: Узнать NS-серверы домена
Смотрим, кто владеет зоной:
nslookup -type=ns yandex.ru
Вывод:
Сервер: router.local Address: 192.168.1.1 Не заслуживающий доверия ответ: yandex.ru nameserver = ns1.yandex.ru yandex.ru nameserver = ns2.yandex.ru
Теперь вы знаете: ns1.yandex.ru и ns2.yandex.ru — это авторитативные серверы.
Команда 2: Запрос к конкретному NS-серверу
Обращаемся напрямую к владельцу зоны:
nslookup yandex.ru ns1.yandex.ru
Вывод:
Сервер: ns1.yandex.ru
Address: 213.180.193.1
Имя: yandex.ru
Addresses: 77.88.55.60
5.255.255.60
Видите? Теперь нет надписи «Не заслуживающий доверия ответ». Потому что ответ пришёл от самого NS-сервера.
Команда 3: Dig для продвинутых (Linux/macOS/Windows WSL)
Проверяем флаг авторитетности:
dig yandex.ru @ns1.yandex.ru
Смотрим на строку flags:
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
Видите aa? Это Authoritative Answer — авторитетный ответ.
Если запросить через кэш:
dig yandex.ru @8.8.8.8
Флаг aa исчезнет. Останется только rd ra (рекурсия).
Команда 4: Проверка TTL записи
TTL показывает, сколько ещё секунд запись будет жить в кэше:
nslookup -debug example.com
Вывод покажет TTL:
example.com
internet address = 93.184.216.34
ttl = 3600
Если TTL = 0, это не ошибка. Это значит, что владелец домена настроил зону так, чтобы кэширования не было (используется для DNS-балансировки).
Команда 5: Проверка AAAA (IPv6)
Иногда задержки в DNS вызваны тем, что система ждёт ответ по IPv6:
nslookup -type=aaaa example.com
Если записи нет — это нормально. Но теперь вы знаете, что IPv6 не настроен.
Частые ошибки и подводные камни
Ошибка 1: Роутер выдаёт себя за DNS-сервер
Симптом: В nslookup видите адрес 192.168.1.1 как сервер, хотя в настройках указан 8.8.8.8.
Причина: Роутер работает как DNS-прокси. Он перехватывает все запросы (DNS-интерсепт) и отвечает от своего имени.
Как проверить:
nslookup example.com 8.8.8.8
Если и так показывает 192.168.1.1 — у вас включен NAT reflection или принудительный DNS на роутере.
Как исправить: Зайти в настройки роутера (обычно раздел «DNS», «LAN», «DHCP») и отключить опцию «Локальный DNS-сервер» или «DNS Relay».
Ошибка 2: Google DNS (8.8.8.8) не отвечает
Симптом: Команда зависает или выдаёт «Server failed».
Причина:
- Провайдер блокирует внешние DNS (редко, но бывает в корпоративных сетях)
- Проблемы на стороне Google (ещё реже)
- Фаервол блокирует UDP 53
Как исправить:
nslookup example.com 1.1.1.1
Если Cloudflare работает — проблема в маршруте к Google DNS.
Ошибка 3: Кэш показывает старую запись после смены DNS
Симптом: Сменили A-запись на NS-сервере, но браузер открывает старый IP.
Причина: TTL ещё не истёк. Кэш обновится только через время, указанное в TTL.
Как проверить, что NS отдаёт новую запись:
nslookup example.com ns1.example.com
Если здесь новый IP — значит, проблема в кэше (вашем, провайдера или CDN).
Временный фикс:
ipconfig /flushdns # Windows sudo dscacheutil -flushcache # macOS sudo systemd-resolve --flush-caches # Linux с systemd-resolved
Но это очистит только ваш локальный кэш. Кэш провайдера останется до истечения TTL.
Ошибка 4: Делегирование не работает
Симптом: Домен вообще не резолвится, хотя NS-записи прописаны.
Причина: Glue-записи не настроены у регистратора.
Как проверить:
whois example.com | grep "Name Server"
Если NS-серверы пусты или указывают на несуществующие адреса — обращайтесь к регистратору.
Полезные хаки
Хак 1: Быстрая проверка всех NS-серверов сразу
Проверяем, что все NS отдают одинаковые записи:
for ns in ns1.example.com ns2.example.com; do echo "=== $ns ===" nslookup example.com $ns | grep Address done
Если IP разные — у вас проблема синхронизации зон между NS.
Хак 2: Алиас для быстрой проверки авторитативности
Добавьте в .bashrc (Linux/macOS) или PowerShell Profile (Windows):
alias nscheck='dig +noall +answer +authority'
Теперь команда:
nscheck example.com @ns1.example.com
Покажет только нужные строки без мусора.
Хак 3: Проверка DNS через curl (если nslookup недоступен)
Используем DNS-over-HTTPS:
curl -H 'accept: application/dns-json' \ 'https://cloudflare-dns.com/dns-query?name=example.com&type=A'
Вернёт JSON с IP-адресами.
Хак 4: Мониторинг пропагации DNS
Проверяем, как быстро распространяется изменение DNS по миру:
# Онлайн-инструмент (без команд) # https://dnschecker.org # https://whatsmydns.net # Или через dig с разными резолверами: for dns in 8.8.8.8 1.1.1.1 208.67.222.222; do echo "=== $dns ===" dig +short example.com @$dns done
Проверка и диагностика
Чек-лист: Как понять, что DNS работает нормально
1. Проверить, что домен резолвится:
nslookup example.com
Должны быть IP-адреса в ответе.
2. Проверить NS-серверы:
nslookup -type=ns example.com
Должны быть 2+ NS-сервера.
3. Проверить авторитативный ответ:
nslookup example.com ns1.example.com
Ответ должен прийти без надписи «Не заслуживающий доверия ответ».
4. Проверить совпадение IP на всех NS:
nslookup example.com ns1.example.com nslookup example.com ns2.example.com
IP должны быть одинаковыми (если нет балансировки).
5. Проверить TTL:
dig example.com | grep "IN.*A"
Видите число перед типом записи — это TTL в секундах.
Где смотреть логи
Windows:
# Логи DNS Client Get-WinEvent -LogName "Microsoft-Windows-DNS-Client/Operational" -MaxEvents 20
Linux (systemd-resolved):
journalctl -u systemd-resolved -n 50
Linux (dnsmasq):
tail -f /var/log/dnsmasq.log
Роутер (MikroTik, Keenetic): Зависит от модели. Обычно в разделе «Логи» или через SSH.
Краткий чек-лист сисадмина
✅ Увидели «Не заслуживающий доверия ответ»
→ Успокоились. Это норма. Это не ошибка.
✅ Нужно проверить реальную запись
→ Идём на NS-сервер домена:
nslookup -type=ns example.com nslookup example.com ns1.example.com
✅ IP не совпадает с ожидаемым
→ Проблема не в надписи, а в кэше или NS-записях. Смотрим делегирование через whois.
✅ Все тесты проходят, но сайт не открывается
→ Ищем проблему в HTTP/HTTPS/TLS, а не в DNS.
✅ Роутер показывает 192.168.x.x как DNS-сервер
→ Отключаем DNS-прокси на роутере или явно указываем внешний DNS в команде.
✅ Сменили DNS-запись, но старая ещё в кэше
→ Ждём истечения TTL или чистим кэш (ipconfig /flushdns).
✅ Google DNS (8.8.8.8) не отвечает
→ Пробуем Cloudflare (1.1.1.1) или проверяем фаервол.
Таблица различий: Неавторитативный vs Авторитативный ответ
| Параметр | Неавторитативный (Non-authoritative) | Авторитативный (Authoritative) |
|---|---|---|
| Источник | Кэш роутера, провайдера, 8.8.8.8, 1.1.1.1 | NS-сервер владельца домена |
| Скорость | Высокая (данные из кэша) | Зависит от удалённости NS |
| Достоверность | Актуально, если TTL не истекло | 100% актуально на момент запроса |
| Когда использовать | Повседневный серфинг, быстрые проверки | Диагностика, смена DNS-записей, проверка делегирования |
| Флаг в dig | Без «aa» | Есть флаг «aa» (Authoritative Answer) |
| Надпись в nslookup | «Не заслуживающий доверия ответ» (Windows RU) | Надписи нет |
Мифы и факты
Миф 1: «Не заслуживающий доверия ответ» — это вирус или DNS-хайджекинг.
Факт: Нет. Это обычный перевод Microsoft. Английская версия nslookup пишет «Non-authoritative answer» — и никто не паникует.
Миф 2: Нужно сбросить кэш DNS (ipconfig /flushdns), чтобы убрать эту надпись.
Факт: Сброс кэша уберёт старую запись, но новый ответ всё равно будет неавторитативным, если вы не опрашиваете NS напрямую. Это не исправит «проблему», потому что проблемы нет.
Миф 3: Только nslookup показывает эту надпись — значит, с nslookup что-то не так.
Факт: Утилита ping, curl, браузеры работают с теми же кэшированными данными, но не показывают статус. Они просто молча используют неавторитативный ответ. nslookup честно сообщает источник.
Миф 4: Если TTL = 0, значит DNS сломан.
Факт: TTL = 0 — это настройка владельца домена. Используется для динамической балансировки нагрузки (например, CDN Cloudflare часто так делает).
Миф 5: Авторитативный ответ всегда точнее неавторитативного.
Факт: Точнее — да. Но для обычной работы кэш достаточен. Авторитативный запрос нужен только при диагностике или сразу после смены DNS.
FAQ: Быстрые ответы
В: Почему на скриншоте адрес сервера 192.168.1.1?
О: Это ваш роутер. Он работает как DNS-прокси. Ответ неавторитативный, потому что роутер не владеет зоной .ru или .com. Он просто пересылает запросы дальше и кэширует ответы.
В: Мне нужно, чтобы всегда был авторитативный ответ. Как настроить?
О: Никак. Если вы не владелец корневого DNS-сервера, вы всегда будете получать ответ через посредников. Единственный способ — каждый раз явно указывать NS-сервер в команде.
В: Dig показывает флаг «aa», а nslookup — «Non-authoritative». Кому верить?
О: Верить dig, если вы явно указали NS-сервер. Флаг «aa» = Authoritative Answer. nslookup просто по-другому формулирует тот же факт.
В: Что делать, если авторитативный и неавторитативный ответы показывают разные IP?
О: Это означает, что кэш устарел (TTL истёк, но кто-то ещё не обновился) или NS-серверы рассинхронизированы. Проверьте все NS-серверы домена — они должны отдавать одинаковые записи.
В: Можно ли отключить кэширование DNS в Windows?
О: Технически да (остановить службу DNS Client), но не делайте этого. Все DNS-запросы станут в 10 раз медленнее. Microsoft явно не рекомендует отключать эту службу.
В: Как понять, что DNS-сервер перехвачен (DNS hijacking)?
О: Реальный hijacking выглядит так:
- nslookup google.com показывает IP, который не принадлежит Google
- Whois показывает, что этот IP зарегистрирован на неизвестную компанию
- Браузер открывает фишинговый сайт вместо настоящего
Надпись «Не заслуживающий доверия ответ» к этому отношения не имеет.
Резюме
Вы увидели «Не заслуживающий доверия ответ» в nslookup.
Это нормально. Это не ошибка. Это не взлом. Это работа DNS-кэша.
Если нужно проверить реальное состояние записей — идите на авторитативный сервер:
nslookup -type=ns example.com nslookup example.com ns1.example.com
Если IP не совпадает с ожидаемым — проблема в делегировании или кэше, а не в этой надписи.
Если всё работает, но сайт не открывается — копайте в сторону HTTP, SSL, фаервола, а не DNS.
Сохраните эту шпаргалку. В следующий раз, когда коллега запаникует из-за «недоверия DNS», просто скиньте ссылку.
