DNS-кеш и фантомный поддомен: охота на NXDOMAIN

Когда DNS кеш становится врагом: охота на фантомный поддомен

Работаю над проектом borisovai-admin — админ-панелью с собственной системой аутентификации. Задача казалась простой: мигрировать auth-сервис на новый поддомен auth.borisovai.tech и убедиться, что всё резолвится корректно. Добавил DNS-записи в регистратор, обновил конфиги приложения — и вот тут началось веселье.

Первый знак беды

Первая проверка через Google DNS (8.8.8.8) показала идеальный результат: auth.borisovai.tech резолвился на 144.91.108.139 без проблем. Казалось бы, всё готово. Но когда я переключился на AdGuard DNS (94.140.14.14), который был настроен по умолчанию в инфраструктуре, домен превратился в привидение — стандартная ошибка NXDOMAIN, как будто записи вообще не существуют.

А вот admin.borisovai.tech спокойно резолвился везде. Значит, проблема именно с auth.*. Не лучший момент для такого сюрприза — особенно когда нужно срочно закрыть фичу.

Расследование

Запустил диагностику: попросил оба DNS-резолвера вернуть записи для auth.borisovai.tech и auth.borisovai.ru. Результат совпадал: Google видел, AdGuard не видел. Явный паттерн.

Тут меня осенило — это же отрицательный кеш DNS! Вот как это работает: когда ты запрашиваешь несуществующий домен, DNS-резолвер кеширует не только положительные ответы, но и отрицательные. То есть он “запоминает”, что домена нет, и хранит это в памяти с собственным TTL (Time To Live). У AdGuard это может быть час или даже дольше.

Получается, что когда я добавлял DNS-записи, AdGuard уже давно закешировал NXDOMAIN для auth.borisovai.tech. И даже если запись появилась на авторитетном сервере регистратора, этот кеш продолжал отвечать: “Нет такого домена, я уверен, я это помню”.

Как я выбрался

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

Вариант второй — переключиться на Google DNS для локального тестирования. Работает мгновенно, но это временный костыль.

Вариант третий — очистить локальный кеш операционной системы. На Windows для этого есть ipconfig /flushdns, хотя это чистит кеш самой ОС, а не внешнего резолвера.

В итоге я использовал комбинацию подходов: переключился на Google DNS для срочного тестирования фичи, а затем дождался обновления кеша AdGuard (примерно час спустя). Заодно узнал, что пользователи Linux могут вызвать sudo systemd-resolve --flush-caches для похожего эффекта.

Интересный факт о DNS

Мало кто знает, что отрицательные ответы кешируются столько же, сколько и положительные. Оба имеют собственный TTL, обычно от 300 до 3600 секунд. Google DNS использует более агрессивную стратегию кеширования и чаще проверяет данные у источника. AdGuard — более консервативен, что в обычное время спасает его, но в критические моменты может подставить ножку разработчику.

Урок выучен

Теперь я знаю: при добавлении новых DNS-записей всегда проверяю через несколько независимых резолверов. Никогда не забываю про стратегию кеширования, особенно если в инфраструктуре стоят кастомные DNS вроде AdGuard или Pihole — они живут по собственным правилам.

И да, теперь я знаю точное место, где искать, если история повторится. А повторится ещё не раз.

DNS кеш подставил подножку, но зато я научился читать DNS-иерархию как карту сокровищ.

Что общего у AdGuard DNS и кота? 😄 Оба игнорируют инструкции и делают только то, что хотят.