Короткий ответ

Подозрительный DNS — это не «сайт не открылся». Смотрите кто спрашивает (WS-042), какой резолвер (DC vs 10.0.10.55 vs публичный), какие QTYPE (A vs TXT/NULL), NXDOMAIN vs уникальные случайные имена (DGA). Не ставьте на клиенте 8.8.8.8 «чтобы проверить интернет» — вы обойдёте журнал внутреннего DNS и политику. Не стройте DNS-туннель в лаборатории на проде.

Связка: исходящий трафик, процесс, спам WordPress если сайт резолвит кучу доменов.

Симптомы и как отличить

  • На DC/BIND: тысячи уникальных имён с WS-042, почти все NXDOMAIN.
  • Всплеск TXT к одному длинному имени.
  • ipconfig /all на ПК: DNS = 10.0.10.55, а должен быть DC.
  • Pi-hole/фильтр: hit на known C2 домены (если у вас есть список, не выдумывайте).
КартинаСкорее нормаСкорее инцидент
Prefetch браузера, десятки Aданет, если не DGA
SRV _ldap._tcpдоменнет
NXDOMAIN опечатки пользователямалошторм тысяч
Резолвер = DHCP корпоративныйдачужой IP резолвера

Возможные причины

  1. Malware с DGA (поиск C2).
  2. DNS-туннель (часто TXT/NULL, регулярный размер).
  3. Клиент указывает на скомпрометированный/чужой резолвер (10.0.10.55 — чужой хост в LAN или rogue DHCP).
  4. Резолвер организации форвардит всё на неизвестный upstream.
  5. Шум сканера/мониторинга без whitelist.
  6. Сломанный суффикс поиска (contoso.example приклеивается к опечаткам) — много NXDOMAIN, но шаблон виден.

Диагностика

1. Что видит клиент WS-042

Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClientCache | Select-Object -First 30 Entry, Type, Status
ipconfig /displaydns | Select-Object -First 80
Get-WinEvent -LogName 'Microsoft-Windows-DNS-Client/Operational' -MaxEvents 20 -ErrorAction SilentlyContinue

Ожидание: DNS = контроллеры/внутренние резолверы, не случайный 10.0.10.55, не только 8.8.8.8.

Linux:

resolvectl status
cat /etc/resolv.conf
sudo tcpdump -n -c 40 port 53

2. Что видит сервер DNS

Журнал AD-integrated / BIND / Unbound: клиент, имя, тип, код ответа. Экспорт топ queriers и топ NXDOMAIN.

Не включайте debug DNS на час на загруженном DC без места на диске — забьёте том. Лучше span на коллектор, если уже есть.

3. QTYPE и размер

Много TXT к одному имени + стабильный интервал — подозрение на туннель. Дальше изоляция хоста, не «блок TXT глобально» (сломаете SPF/DKIM проверки на почтовых серверах, если они тем же резолвером пользуются — думайте, какой view).

4. Кто процесс

Свяжите запросы с PID: на Windows без EDR сложно; Sysmon если уже стоит (не ставьте Sysmon в пике без GPO-проекта). Get-NetUDPEndpoint + процесс. На Linux: ss -up / tcpdump + ps.

Решение

Сценарий A. DGA / туннель с одного WS-042

Изолировать ПК, снять процесс, антивирус, считать компрометацией. Блок домена на резолвере — дополнение, не лечение. Клиенту вернуть DNS на DC.

Сценарий B. Резолвер клиента = 10.0.10.55

Это rogue DHCP или ручной DNS. Чините DHCP option 006, порт чужого DHCP — неизвестное устройство. На ПК:

Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ResetServerAddresses
# либо явно на DC, не 8.8.8.8

Сценарий C. Корпоративный форвардер глядит «не туда»

Верните forwarders на согласованные (обычно корневые подсказки или выбранный защищённый upstream по политике). Не оставляйте форвардер, который вынесли «временно» на чей-то домашний.

DoH, суффикс поиска и rogue DHCP

Если после возврата DNS на DC шторм жив, клиент ходит DoH (браузер/malware) — это уже исходящий 443, статья про трафик. На host.example как резолвере проверьте forwarders и listen-address: bind, открытый в users VLAN и ещё в WAN, станет усилителем. Не включайте recursion для мира.

Суффикс contoso.example превращает опечатки в NXDOMAIN вида gogle.contoso.example — шаблон виден, это не DGA. DGA: много уникальных меток, слабая повторяемость. Rogue DHCP, раздающий 10.0.10.55 как DNS, лечится snooping и карантином устройства, не ipconfig /flushdns на каждом WS-042. Учётка ivan.petrov ни при чём, если option 006 подменили всем VLAN — масштаб другой.

Если резолвер — ваш host.example, он должен быть в документации, а не «внезапно у всех в DHCP».

Как проверить, что проблема устранена

  • Клиентский DNS снова DC/штатный.
  • NXDOMAIN шторм с этого IP прекратился.
  • Нет TXT-пульса на странное имя.
  • Хост изолирован или переустановлен по решению.
  • Forwarders DNS-сервера соответствуют документации.

Не учите пользователей прописывать 8.8.8.8. Алерт топ-NXDOMAIN на host.example и DC сэкономят час на следующем DGA.

Если не помогло

  • Шторм с многих ПК — заражение массовое или сломан суффикс/мониторинг; не блокируйте DNS целиком.
  • После смены DNS на DC шторм жив — процесс всё ещё спрашивает свой резолвер в бинаре (DoH). Смотрите исходящий 443 и SNI, трафик.
  • SERVFAIL на всём — вы сломали форвардер, откатите изменение IR, это уже доступность.
  • Linux systemd-resolved stub 127.0.0.53 — норма, смотрите uplink DNS в resolvectl.

Профилактика

  • DHCP только свои option DNS.
  • Запрет внешних DNS с users VLAN (egress 53 только к своим резолверам; DoH — отдельная политика прокси).
  • Логи DNS на коллектор.
  • Алерт: топ NXDOMAIN per client.
  • Не учить пользователей «пропиши 8.8.8.8».

FAQ

Это точно туннель, если я вижу TXT?

Нет. SPF/DMARC тоже TXT. Смотрите клиент (почтовик vs WS-042 пользователя) и частоту.

Можно ли временно выключить DNS на ПК?

Он отвалится от домена. Изолируйте сеть целиком, DNS не «выключатель malware».

Нужно ли чистить кэш на DC?

Clear-DnsServerCache не лечит DGA и может ударить по всем. Не первый шаг.

DoH в браузере обходит наш журнал

Да. Политика браузера/прокси. Для инцидента: изоляция хоста важнее спора про DoH.

10.0.10.55 — это наш Linux bind

Тогда он должен быть в документации. Подозрение — если клиенты вдруг переехали на него без change, или bind стал форвардить в неизвестность.