Нестабильный DNS: найдите какой резолвер отвечает с таймаутом

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

Нестабильный DNS почти никогда не лечится ipconfig /flushdns «на всех ПК». Найдите, какой сервер отвечает в момент сбоя: 10.0.10.2, второй форвардер, публичный, или кэш. Снимите серию nslookup с указанием сервера, сравните RTT, код (NOERROR/NXDOMAIN/SERVFAIL) и IP. Флап — это разные ответы или чередование timeout, а не «медленный интернет».

Split-horizon (внутренняя и внешняя зона одного имени) даёт ту же жалобу, если клиенты прыгают между резолверами.

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

• Браузер: то страница, то «не удаётся найти»;
• nslookup contoso.example без сервера — разный сервер в заголовке «Server:»;
• доменный вход иногда 10+ секунд (SRV то находятся, то нет);
• на Ubuntu resolvectl query чередует 10.0.10.2 и 1.1.1.1.

Отличия от похожего:

• Всегда один и тот же старый IP — кэш, не флапающий uplink.
• Всегда разный мир «внутри/снаружи» — split DNS.
• Только ICMP жив — пинг vs сайт.
• Только одна сеть ломается — сайт из одной сети.

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

1. В NIC два DNS: живой 10.0.10.2 и мёртвый/медленный второй; клиент уходит на второй по timeout.
2. Форвардер на 10.0.10.2 сам флапает к провайдеру (UDP/53 loss).
3. Два контроллера с расходящимися зонами (репликация AD DNS).
4. TTL короткий + балансировка без общего состояния.
5. UDP режется, TCP/53 иногда проходит — «иногда».
6. Captive/фильтр периодически подменяет ответы.
7. systemd-resolved + DHCP option 006 + статический fallback одновременно.
8. EDNS/фрагментация: крупные ответы SRV теряются, маленькие A проходят.

Диагностика

1. Список резолверов, которые клиент реально использует

Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClientNrptPolicy
ipconfig /all

resolvectl status
nmcli device show | grep -i dns
cat /etc/resolv.conf

На Ubuntu 22.04/24.04 /etc/resolv.conf часто stub 127.0.0.53. Истина — resolvectl status (DNS Servers, DNS Domain).

2. Серия запросов на каждый сервер

1..10 | ForEach-Object {
  '{0} {1}' -f $_, (Measure-Command { nslookup example.com 10.0.10.2 }).TotalMilliseconds
}
nslookup example.com 10.0.10.2
nslookup example.com 8.8.8.8

for i in $(seq 1 10); do
  echo -n "$i "
  time nslookup example.com 10.0.10.2 >/dev/null
done
dig +norecurse example.com @10.0.10.2
dig example.com @10.0.10.2 +stats

Timeout только у второго адреса в NIC — уберите его или почините. Timeout у обоих — путь к резолверу (потеря пакетов).

3. Код ответа и split

Resolve-DnsName www.contoso.example -Server 10.0.10.2
Resolve-DnsName www.contoso.example -Server 8.8.8.8

Внутренний A = 10.0.10.10, внешний — публичный. Клиент, который иногда спрашивает публичный, «теряет» внутренний сайт. Это не баг браузера.

4. SRV и крупные ответы

Resolve-DnsName _ldap._tcp.dc._msdcs.contoso.example -Type SRV -Server 10.0.10.2

dig _ldap._tcp.dc._msdcs.contoso.example SRV @10.0.10.2 +bufsize=512
dig _ldap._tcp.dc._msdcs.contoso.example SRV @10.0.10.2 +tcp

UDP с +bufsize=512 падает, TCP жив — фрагментация/фильтр. Не увеличивайте MTU вслепую; сначала PMTUD.

5. Сетевой путь до 10.0.10.2

Test-NetConnection 10.0.10.2 -Port 53
ping -n 20 10.0.10.2
tracert -d 10.0.10.2

ping -c 20 10.0.10.2
traceroute -n -U -p 53 10.0.10.2

Потеря 5–20% до резолвера даёт «DNS иногда». Чините канал, не зону.

Решение

Сценарий A. Второй DNS в NIC мёртв

Оставьте клиентам только рабочие внутренние: 10.0.10.2 и второй живой DC. Не ставьте 8.8.8.8 вторым «для надёжности» на доменных ПК — при timeout Windows может спросить публичный и получить NXDOMAIN на _msdcs.

DHCP option 006: только внутренние. См. также DHCP выдаёт неверный шлюз — тот же option-слой.

Сценарий B. 10.0.10.2 жив, форвардер флапает

На самом резолвере проверьте форвардеры, корневые подсказки, CPU. Не очищайте кэш DNS-сервера пакетом в рабочее время — спровоцируете шторм. Сначала уберите мёртвый форвардер.

Сценарий C. Split без политики

Клиенты внутренней сети должны всегда видеть внутреннюю зону. Условные форвардеры и recursion — по схеме. Не публикуйте внутренние A во внешнюю зону «чтобы совпало».

Сценарий D. resolved + DHCP + статическое дополнение

Ubuntu: один источник истины. Либо DHCP, либо netplan nameservers, не оба с разными списками.

resolvectl dns eth0 10.0.10.2
sudo nmcli connection modify 'Wired connection 1' ipv4.dns '10.0.10.2'
sudo nmcli connection up 'Wired connection 1'

6. Журнал и параллельный захват

Нестабильность часто видна только в серии, а не в одном nslookup. На Windows включите запрос с Measure-Command и одновременно Test-NetConnection 10.0.10.2 -Port 53. Если TCP/53 стабилен, а UDP-запросы теряются, это фильтр размера или rate-limit, не «зона AD умерла». На Ubuntu смотрите journalctl -u systemd-resolved -b --no-pager | tail -n 80 в момент жалобы: Transaction failed и Timed out указывают на конкретный IP резолвера.

Сравните два клиента в одном VLAN 10.0.10.0/24. Если у одного NIC содержит 10.0.10.2 и публичный, а у второго только 10.0.10.2, картина «у половины офиса DNS прыгает» объясняется списком серверов, а не WAN. Не меняйте TTL зоны, пока не доказали, какой сервер отвечает в провале.

Сохраните десять ответов с временными метками в каталог заявки. Без этого «сейчас уже работает» уничтожит возможность доказать флапающий форвардер.

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

Серия из 20 запросов к 10.0.10.2 без timeout, одинаковый IP для внутренних имён, SRV стабильны. Сравните два клиента. Браузер: 10 обновлений внутренней страницы без NXDOMAIN.

Clear-DnsClientCache
1..20 | ForEach-Object { Resolve-DnsName www.contoso.example -Server 10.0.10.2 | Select-Object -Expand IPAddress }

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

• Только IPv6-резолвер флапает — смотрите AAAA и RA DNS (RDNSS), не только IPv4.
• Проблемы только в прайм-тайм — rate-limit на DNS, не «зона».
• Корпоративный DoH в браузере параллельно с 10.0.10.2.
• AD-репликация зоны: один DC отдаёт старое. Это уже каталог, не клиентский flush.

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

• Два внутренних DNS, оба отвечают на тестовые A и SRV.
• Мониторинг: timeout rate, SERVFAIL, latency 10.0.10.2:53.
• Запрет публичных DNS на клиентах домена GPO.
• TTL внутренний разумный (не 5 секунд без нужды).
• Не смешивать guest и corp резолверы в одном DHCP.

FAQ

flushdns на всех — нормальный первый шаг?

Нет. Сначала докажите, что отвечает неверный сервер или кэш. Flush скрывает улики.

Почему второй DNS «для резерва» вреден, если он 8.8.8.8?

Клиент не использует второй только при полном отказе первого: при медленном первом он может уйти и получить ответ без внутренних зон.

SERVFAIL vs NXDOMAIN?

SERVFAIL — сервер не смог (форвардер, DNSSEC, битая зона). NXDOMAIN — имени нет в той зоне, которую спросили. Для split это часто «спросили внешнюю».

Стоит ли включать DNS over TLS на клиенте сразу?

Не как лечение флап. DoT к публичному снова обходит внутренние зоны. Сначала стабильный 10.0.10.2.

Как понять, что это потеря UDP, не DNS-логика?

Сравните dig +tcp и UDP, плюс ping/loss до 10.0.10.2. Потеря только UDP/53 при живом ICMP — ACL, не зона.