После миграции запросы идут на старый хост. Поставьте диагноз по выводу DNS.
Сервис вчера переехал на новый IP, но клиенты всё ещё подключаются к старому, выведенному из эксплуатации хосту. Поставьте диагноз по запросам ниже; назовите причину и как чините сейчас и предотвращаете в будущем.
$ curl https://api.internal # подключается к СТАРОМУ хосту, падает
$ dig api.internal
;; ANSWER SECTION:
api.internal. 3456 IN A 10.20.4.9 # старый, выведенный из эксплуатации хост
$ dig api.internal @ns1.internal +short
10.20.4.11 # авторитетный: НОВЫЙ хостВ чём причина и что вы делаете?
Рекурсивный resolver возвращает старую запись 10.20.4.9 с большим остатком TTL, тогда как авторитетный сервер уже отвечает 10.20.4.11 — значит это устаревший кэш, а не маршрутизация или приложение. Чиним сейчас: сбросить кэш resolver или переждать TTL; на будущее — снижать TTL записи перед миграцией.
- ✗Винить авторитетный сервер, когда он уже возвращает верную запись
- ✗Игнорировать большой TTL, из-за которого устаревший ответ живёт в resolver
- ✗Хвататься за маршрутизацию или конфиг приложения раньше сравнения resolver и авторитетного
- →Почему прямой запрос к авторитетному серверу обходит устаревший ответ?
- →Как снижение TTL перед изменением сокращает окно распространения?
The two dig runs disagree, and that gap is the diagnosis. The recursive resolver (the default path) still hands back 10.20.4.9 — the old host — with a large remaining TTL of 3456 seconds. Querying the authoritative server directly (@ns1.internal) returns 10.20.4.11, the new host. When the authoritative record is already correct but the resolver's is not, you are looking at a stale cache, not routing and not the application.
The TTL is why it persists: the record was published with a long TTL, so the resolver is entitled to keep serving the old answer until it expires.
Fix it now, and stop it recurring:
# Confirm the resolver, not the zone, is stale — authoritative is already correct.
$ dig api.internal @ns1.internal +short
10.20.4.11
# Flush the caching resolver (systemd-resolved shown; use the resolver you run).
$ sudo resolvectl flush-caches
$ dig +short api.internal
10.20.4.11 # now matches authoritative
# Prevent it: publish a short TTL BEFORE the next migration.
$ dig api.internal | grep -E '^api'
api.internal. 60 IN A 10.20.4.11If you cannot flush every downstream resolver, the only guaranteed cure is waiting out the TTL. Lowering the TTL (e.g. to 60 s) a day before a planned move shrinks that propagation window to a minute.
