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

Старый адрес живёт на трёх уровнях: (1) кеш ОС/браузера, (2) кеш резолвера 10.0.10.2, (3) авторитативная зона (AD DNS или внешняя). ipconfig /flushdns на одном ПК чинит только (1). Сравните nslookup name 10.0.10.2 и ответ с другого резолвера / с DC @. Сбрасывайте тот слой, где врёт. Не чистите зону _msdcs «от старых A».

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

  • TTL ещё не истёк после смены A;
  • один клиент уже видит новый IP, другой нет;
  • nslookup без сервера (клиентский кеш) ≠ nslookup … 10.0.10.2.

Отличия: ответы прыгают каждую секунду — нестабильный DNS. Внутренний и внешний IP разные по дизайну — split DNS. Браузер не открывает при верном IP — пинг vs сайт.

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

  1. Высокий TTL, смена записи «уже вчера».
  2. Negative cache: NXDOMAIN на ещё не созданное имя.
  3. hosts-файл.
  4. Кэш Windows DNS Client / systemd-resolved.
  5. Кэш на 10.0.10.2 (форвардинг).
  6. AD: запись не реплицировалась на второй DC.
  7. Браузерный DNS-кэш / DoH.
  8. CNAME цепочка на старый A.

Диагностика

1. Три запроса

Get-Content C:\Windows\System32\drivers\etc\hosts
Get-DnsClientCache | Where-Object Entry -Match 'app.contoso.example'
nslookup app.contoso.example
nslookup app.contoso.example 10.0.10.2
Resolve-DnsName app.contoso.example -Server 10.0.10.2
getent ahosts app.contoso.example
resolvectl query app.contoso.example
dig app.contoso.example @10.0.10.2 +ttlunits
dig app.contoso.example @10.0.10.2 +norecurse

+norecurse на резолвере: если он не авторитативен, увидите, кешировал ли. На DC с зоной — авторитативный ответ.

2. Авторитативный vs кэш

На DC:

Get-DnsServerResourceRecord -ZoneName 'contoso.example' -Name 'app' -RRType A

Если здесь уже новый IP, а @10.0.10.2 старый — 10.0.10.2 не этот DC или кэш форвардера. Если на DC старый — зона не обновлена/не реплицируется.

3. TTL

В dig поле TTL. Клиент не обязан спрашивать, пока TTL жив. Negative TTL (SOA minimum) держит NXDOMAIN.

4. Браузер

Приватное окно, другой браузер. Chrome свой кеш. DoH обходит 10.0.10.2 — тогда «кэш» вообще не ваш сервер.

Решение

Сценарий A. Только этот ПК

Clear-DnsClientCache
ipconfig /flushdns
Get-DnsClientCache
resolvectl flush-caches

Проверьте hosts. Не делайте это GPO на всю организацию как первый шаг.

Сценарий B. Кэш резолвера 10.0.10.2

Windows DNS:

Clear-DnsServerCache -ComputerName DC01

Сценарий C. Авторитативная зона

Исправьте A/CNAME, дождитесь репликации AD:

Get-DnsServerResourceRecord -ZoneName 'contoso.example' -Name 'app'
repadmin /replsummary

Не удаляйте «лишние» A DC. Смена IP сервера — обновите запись и scavenging-тайминги.

Сценарий D. Negative cache

Создали имя, клиенты уже спросили — NXDOMAIN в кеше. Flush на клиенте или ждите negative TTL. На резолвере — то же.

Сценарий E. Слишком большой TTL

Для записей, которые часто переезжают, снизьте TTL заранее (за сутки до переезда), не после.

6. Кто ещё кеширует кроме ОС

После Clear-DnsClientCache проверьте браузер и Get-DnsClientCache снова: некоторые приложения резолвят сами. DoH в Edge обходит 10.0.10.2 — вы будете бесконечно flush-ить. Сравните nslookup name 10.0.10.2 и ответ DC @ авторитативно. Если DC уже новый IP, а форвардер 10.0.10.2 старый — чистите кеш резолвера или ждите TTL, не зону _msdcs. Negative NXDOMAIN после создания имени — flush клиента и резолвера, не «пересоздать зону». CNAME на старый A держит «старый адрес» при живой новой A на имени, которое никто не спрашивает. Репликация AD: второй DC отдаёт старое — это не клиентский кеш. Не гоняйте GPO flushdns после каждой смены A: снизьте TTL заранее. Проверка: два ПК, два DC, браузер без DoH, Test-NetConnection на новый IP. Сохраните dig +ttlunits до/после. nscd на старых Ubuntu — отдельный кеш; на 22.04/24.04 чаще resolvectl flush-caches.

Планируйте переезд IP: TTL 300 за сутки до, смена A, контроль, TTL обратно. Иначе «кеш на 24 часа» будет вашей политикой, не багом Windows.

Практический чек-лист переезда app.contoso.example с 10.0.10.10 на 10.0.10.20: снизить TTL заранее; сменить A на обоих DC; dig @10.0.10.2 до истечения старого TTL может врать — это норма кеша резолвера; клиентский flush только тем, кому нельзя ждать; браузерный DoH выключить политикой заранее, не в день переезда. Не удаляйте старый A, пока не убедитесь, что никто не ходит по IP напрямую в конфигах приложений. Если приложение зашило IP — DNS-кеш ни при чём. Проверка с Get-NetNeighbor не заменяет nslookup: ARP старого IP может быть жив при уже новой A. Смешивать эти слои — типичная причина «мы сбросили DNS, не помогло». Для AD SRV не применяйте те же советы, что для www: не чистите SRV вручную. Эта статья про A/CNAME пользовательских имён и кэши, не про спасение леса.

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

Clear-DnsClientCache
nslookup app.contoso.example 10.0.10.2
ping -n 2 app.contoso.example
Test-NetConnection app.contoso.example -Port 443
resolvectl flush-caches
dig app.contoso.example @10.0.10.2

Одинаковый новый IP с клиента, с 10.0.10.2, с обоих DC. Браузер без DoH. Соседний ПК тоже.

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

  • CDN/GSLB отдаёт anycast — «старый» с вашей точки зрения может быть geo. Смотрите, какой IP должен быть для офиса.
  • Сайт только из одной сети — разные форвардеры.
  • Kerberos/SPN на старом имени — уже не DNS-кеш.
  • Многоуровневый CNAME.

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

  • План смены IP: снизить TTL заранее.
  • Мониторинг расхождения A на двух DC.
  • Не держать TTL 24ч на сервисах с частым переездом.
  • Запрет hosts на рабочих станциях политикой (кроме исключений).

FAQ

flushdns на всех ПК через GPO после каждой смены A?

Нет. Исправьте авторитатив и TTL. Массовый flush — ритуал, не инженерия.

Почему ping резолвит новое, браузер старое?

Кеш браузера/DoH/Happy Eyeballs IPv6. Смотрите DevTools, не только nslookup.

Нужно ли чистить кеш на 8.8.8.8?

Вы не можете. Не используйте публичный как единственный для внутренних имён. Для внешней зоны ждите TTL.

dnscmd /clearcache vs Clear-DnsServerCache?

Современный путь — PowerShell cmdlet. Не смешивайте со стиранием зоны.

Ubuntu nscd?

Если установлен nscd, у него свой кеш (nscd -i hosts). На 22.04/24.04 чаще resolved. Сначала resolvectl.