Negative caching: почему опечатка в домене живёт дольше, чем сама опечатка

MAATRIX

Поддомен создан, A-запись прописана, dig с авторитативного сервера отдаёт правильный IP — а часть пользователей всё равно видит «сервер не найден». Самое неприятное в этой ситуации — она не про то, что запись «ещё не разошлась». Она про то, что чей-то резолвер когда-то давно получил ответ «такого домена не существует» и честно запомнил его на заданный срок. Разбираемся, как устроено отрицательное кеширование DNS и почему однажды введённая опечатка способна пережить создание настоящего поддомена.

Резолвер запоминает не только «да», но и «нет»

Когда резолвер получает от вас запрос на app.example.com и авторитативный сервер отвечает валидным IP, этот ответ кешируется на срок, заданный TTL самой записи — это привычная механика, с ней сталкивался каждый, кто хоть раз обновлял A-запись и ждал, пока изменение «дойдёт» до всех.

Но у DNS есть и обратная сторона: если авторитативный сервер отвечает «такого имени нет», резолвер тоже кеширует этот факт — просто по другим правилам. Это называется negative caching, отрицательное кеширование, и описано в RFC 2308. Смысл прост: если домен не существует, нет причин каждый раз заново идти к авторитативному серверу и спрашивать снова — достаточно один раз получить «нет» и какое-то время отвечать «нет» из собственной памяти.

DNS различает здесь два разных «нет»:

• NXDOMAIN — имени не существует вообще, ни как записи, ни как узла дерева имён. Именно этот случай интересует нас: dev.example.com не существует ни в каком виде.
• NODATA — имя существует (например, есть MX-запись), но записи именно того типа, который вы запросили (скажем, AAAA), для него нет. Технически это отдельный код ответа (NOERROR с пустым ANSWER), но кешируется он по тем же правилам, что и NXDOMAIN.

Для этой статьи важен именно NXDOMAIN: он возникает, когда кто-то обращается к поддомену, которого ещё не существует, — например, из-за опечатки или потому что поддомен анонсировали чуть раньше, чем реально создали.

Кто определяет, на сколько запомнить «домена нет»

TTL отрицательного ответа не связан с TTL записей зоны напрямую. Он берётся из SOA-записи домена — точнее, из последнего поля в ней, которое исторически называется MINIMUM:

example.com.  IN  SOA  ns1.example.com. hostmaster.example.com. (
                  2026082901 ; serial
                  7200       ; refresh
                  3600       ; retry
                  1209600    ; expire
                  1800 )     ; minimum <- TTL негативного кеша

До RFC 2308 поле MINIMUM трактовалось как TTL по умолчанию для всей зоны, но после этого RFC его смысл сузился: теперь это тот срок, на который резолверу разрешено запомнить отрицательный ответ по этой зоне. Формально TTL негативного кеша — это минимум из значения MINIMUM в SOA и TTL самой SOA-записи, но на практике администратору зоны важно в первую очередь поле MINIMUM.

Есть и вторая часть механизма — потолок на стороне самого резолвера. У рекурсивных резолверов (BIND, Unbound, PowerDNS Recursor, публичные резолверы провайдеров) обычно есть собственная настройка максимального времени хранения отрицательного ответа, которая может обрезать значение из SOA, даже если в зоне стоит больше. Конкретные значения по умолчанию отличаются между версиями и дистрибутивами, поэтому если точное число критично — сверяйтесь с документацией именно той версии резолвера, которая стоит в проде, а не полагайтесь на память. Важна сама конструкция: TTL негативного кеша — это компромисс между тем, что прописано в SOA, и тем, что позволяет резолвер на другом конце.

Сценарий: опечатка добралась до поддомена раньше вас

Разберём конкретную ситуацию, из-за которой обычно и всплывает эта тема. Команда планирует выкатить staging.example.com в среду. Кто-то из коллег в понедельник, ещё до того как DNS-запись реально создана, пробует зайти по этому адресу — то ли по памяти, то ли перепутав с похожим доменом, то ли просто проверяя раньше времени. Авторитативный сервер честно отвечает: такого имени в зоне нет, NXDOMAIN.

Резолвер, через который шёл этот запрос — свой корпоративный, резолвер интернет-провайдера или публичный DNS, — получает этот ответ и кеширует его на TTL негативного кеша из SOA-записи example.com. Если это значение выставлено на несколько часов (а тем более если стоит дефолт, доставшийся зоне «по наследству»), ответ «домена нет» задержится в кеше этого резолвера надолго.

В среду поддомен действительно создают: прописывают A-запись, проверяют через dig напрямую к авторитативному серверу — всё отдаётся правильно. Но резолвер, который в понедельник получил и закешировал NXDOMAIN, ничего не знает о том, что запись появилась. Он не обращается повторно к авторитативному серверу, пока не истечёт TTL его собственной записи в кеше, — он просто продолжает отвечать из памяти: «такого домена нет». И отвечает так на любой последующий запрос к этому имени, даже если спрашивает уже не тот человек, что ошибся в понедельник, а кто-то другой, чей запрос попал на тот же резолвер.

Получается парадоксальная картина: домен реально создан и рабочий, dig с авторитативного сервера это подтверждает, а часть аудитории по-прежнему получает «сервер не найден» — именно та часть, чьи запросы обслуживает резолвер, успевший закешировать более раннюю опечатку или преждевременную проверку.

Почему «домен вроде есть», а резолвится не у всех

Эта картина обманчива именно своей неравномерностью. Резолверы у разных пользователей разные: у кого-то это резолвер интернет-провайдера, у кого-то — публичный DNS вроде 8.8.8.8 или 1.1.1.1, у кого-то — корпоративный DNS-сервер в офисе. Каждый из них кеширует независимо от остальных. Если преждевременный запрос к dev.example.com прошёл именно через резолвер вашего интернет-провайдера, то NXDOMAIN закеширован только у него — у пользователей с другими резолверами всё заработает сразу после создания записи.

Отсюда и типичная жалоба: «у меня не открывается, а у коллеги за соседним столом всё нормально» — хотя оба выходят в интернет через разные DNS. Это легко перепутать с мифом «DNS ещё не распространился, подождите 24–48 часов». На деле проблема почти никогда не в скорости распространения новой записи — современные TTL для A-записей обычно небольшие, и после создания записи она видна почти сразу тем, кто спрашивает впервые. Дело именно в той узкой прослойке резолверов, которые уже успели получить и запомнить отрицательный ответ до того, как запись появилась.

Отдельный нюанс — RFC 8020 (агрессивное использование отрицательных ответов, актуально прежде всего при DNSSEC): часть резолверов трактует NXDOMAIN не как «этого имени нет», а как «во всём этом поддереве ничего нет» — получив NXDOMAIN на typo.example.com, такой резолвер может решить, что и anything-else.example.com тоже не существует, не делая по нему отдельного запроса. Работает это не везде одинаково и зависит от реализации резолвера, но объясняет и более широкие случаи «не резолвится», когда проблема как будто расползается на соседние поддомены, которые никто и не запрашивал с опечаткой.

Как отличить закешированный NXDOMAIN от реальной проблемы

Прежде чем чинить то, что не сломано, стоит убедиться, что дело именно в отрицательном кеше, а не в реальной ошибке конфигурации. Сравните ответ авторитативного сервера напрямую с ответом через резолвер, на который жалуется пользователь:

# запрос напрямую к авторитативному серверу зоны
dig @ns1.example.com dev.example.com A +short
# 203.0.113.20  <- запись реально есть и отдаётся

# запрос через резолвер, на который жалуется пользователь
dig @8.8.8.8 dev.example.com A
;; ->>HEADER<<- status: NXDOMAIN
;; AUTHORITY SECTION:
example.com.  1712  IN  SOA  ns1.example.com. hostmaster.example.com. 2026082901 7200 3600 1209600 1800

Ключевой признак — статус NXDOMAIN в заголовке ответа и пустая секция ANSWER, при этом в секции AUTHORITY присутствует SOA-запись зоны с оставшимся TTL. Число в начале этой строки (в примере — 1712) — это сколько секунд осталось жить закешированному отрицательному ответу у данного резолвера. Если оно плавно уменьшается при повторных запросах — вы наблюдаете угасающий негативный кеш, а не постоянную поломку. Полезно сразу проверить несколько независимых резолверов (8.8.8.8, 1.1.1.1, 9.9.9.9), а не только тот, с которого жаловался пользователь: если авторитативный сервер отвечает корректно, а часть публичных резолверов — NXDOMAIN с SOA в AUTHORITY, вопрос закрыт, это негативный кеш, и единственное, что можно сделать в отношении резолверов, которые вам не подконтрольны, — подождать, пока истечёт TTL из вывода dig.

Как настраивать SOA MINIMUM, чтобы не наступать на эти грабли

Раз источник TTL негативного кеша — поле MINIMUM в SOA-записи вашей зоны, у вас есть прямой рычаг влияния на то, насколько долго живут подобные «случайные» NXDOMAIN:

• Не оставляйте дефолтное значение из шаблона зоны бездумно. Многие DNS-панели подставляют в MINIMUM значение «на всякий случай побольше», доставшееся ещё со времён до RFC 2308, когда это поле имело другой смысл. Стоит сознательно решить, какое значение подходит именно вашей зоне.
• Чем активнее у вас появляются новые поддомены, тем ниже должен быть MINIMUM. Если регулярно создаются стенды, временные окружения, поддомены под клиентов — риск, что кто-то обратится к ещё не созданному имени и закеширует NXDOMAIN, выше, чем в статичной зоне с парой записей, не менявшихся годами.
• Перед плановым созданием заранее анонсированного поддомена стоит на время снизить MINIMUM. Это не отменяет риск преждевременных запросов полностью, но сокращает время жизни возможного случайного NXDOMAIN.
• Слишком низкий MINIMUM на постоянной основе тоже не бесплатен. Каждый отрицательный ответ, TTL которого истёк, означает новый запрос к авторитативному серверу при следующем обращении к тому же несуществующему имени. Для доменов, к которым массово стучатся боты и сканеры по словарю поддоменов, слишком короткий негативный TTL заметно увеличивает нагрузку на авторитативные серверы.

Изменение вступает в силу не мгновенно: старые закешированные отрицательные ответы продолжат жить по прежнему TTL — снижение MINIMUM влияет только на то, как долго будут кешироваться новые NXDOMAIN, полученные после изменения.

Что делать, если резолвер, где застрял кеш, не ваш

Если у вас есть собственный рекурсивный резолвер (например, PowerDNS Recursor или Unbound перед вашей инфраструктурой), для него можно принудительно сбросить конкретную закешированную запись:

# PowerDNS Recursor
rec_control wipe-cache dev.example.com

# Unbound
unbound-control flush_negative dev.example.com

# BIND (в сборках с поддержкой rndc flushname)
rndc flushname dev.example.com

Но это работает только для инфраструктуры, которую вы администрируете. Если проблема у пользователя с резолвером его интернет-провайдера, корпоративным DNS его офиса или публичным резолвером вроде 8.8.8.8, повлиять на срок жизни его конкретного закешированного ответа нельзя — можно только посоветовать временно переключиться на другой резолвер (1.1.1.1, 9.9.9.9) для проверки, что домен действительно работает, либо подождать истечения TTL из вывода dig. Разумная тактика — заранее закладывать в процесс создания заметных, анонсированных поддоменов паузу и низкий MINIMUM, а не бороться с последствиями постфактум.

Если тема резолвинга DNS в целом интересна не только со стороны negative caching, полезно посмотреть на весь путь запроса — как DNS-запрос обходит полмира объясняет, через сколько серверов проходит обычный запрос. Смежная механика — обычный позитивный TTL и что происходит, когда его выставляют слишком большим при переезде на новый сервер, разобрана в статье про TTL 86400 и двухдневный переезд. Разбор похожего эффекта как случившегося инцидента, с атомарной заменой rrset и мониторингом расхождений между резолверами, — в статье про кеш отрицательных ответов, который держал сайт мёртвым ещё час. Для настройки своей DNS-инфраструктуры пригодится руководство по установке и настройке PowerDNS на VPS.

Частые вопросы