DNS и кэш: охота на запись, которая вроде есть, но не видна

Охота на привидения в DNS: как потерянная запись чуть не сломала аутентификацию

Проект borisovai-admin — это админ-панель с полноценной системой аутентификации. Задача казалась простой: настроить поддомены для разных частей приложения. admin.borisovai.tech уже работал безупречно, а вот auth.borisovai.tech и auth.borisovai.ru упорно отказывались резолвиться. Казалось, что может быть проще — добавить записи и забыть? Не так всё оказалось.

Первым делом я начал с базовой диагностики. Проверил nslookup и dig — и вот тут началось веселье. auth.borisovai.tech не резолвился с локального DNS, а вот Google DNS (8.8.8.8) прекрасно возвращал 144.91.108.139. Это был явный признак того, что проблема не в глобальной DNS-иерархии, а где-то рядом.

Полез в DNS API — может, записи просто не создались? Нашёл в базе пусто: records: []. Автоматического создания не было. Но вот странный момент — admin.borisovai.tech работал без проблем. Почему одна запись есть в DNS API, а другая нет? Начал разбираться в истории создания записей.

Выяснилось, что admin.borisovai.tech был добавлен напрямую у регистратора, минуя DNS API. А вот auth.* я стал добавлять через API, и тут столкнулся с интересным поведением: локальный AdGuard DNS (94.140.14.14), который использовался как основной рекурсивный резолвер, кэшировал старые данные или просто не видел новые записи из-за задержки распространения.

Это была классическая ловушка DNS-администраторов: разные пути создания записей приводят к рассинхронизации. Когда у тебя есть несколько источников истины (регистратор, API, локальный кэш), они начинают рассказывать разные истории. Сервис аутентификации попадал на несуществующий адрес, и всё падало в момент, когда требовалась верификация токена.

Интересный факт: DNS работает на принципе давности — записи имеют TTL (Time To Live), и если кэширующий резолвер уверен, что всё верно, он будет возвращать старые данные до истечения TTL, даже если на авторитативном сервере уже всё изменилось. В нашем случае TTL был достаточно высоким, поэтому AdGuard упорно держался за мысль, что auth.borisovai.tech не существует.

Решение: я привёл все записи в единую систему — создал их через DNS API, настроил правильные TTL (600 секунд вместо 3600) и добавил явное перенаправление с auth.borisovai.ru на основной домен. Проблема испарилась.

Главный урок: в распределённых системах всегда проверяй, откуда берётся каждый кусок информации. DNS выглядит просто, пока не начнёшь складывать вместе мнения разных серверов. И да, не забывай очищать кэш после изменений — Google DNS обновляется быстрее, чем AdGuard, и это сейчас спасало жизнь.

😄 А знаешь, почему DNS никогда не ходит к психологу? Потому что у него всё равно проблемы с разрешением.