Кратко

  • RFC 8767 позволяет рекурсивному резолверу использовать подходящие данные после истечения TTL, если авторитативное обновление не удалось; запись с исходным TTL, равным нулю, не может стать таким резервом.
  • Выигрыш в доступности временно меняет цепочку контроля: оператор зоны опубликовал TTL, однако оператор резолвера задаёт ожидание, классифицирует отказ и ограничивает продолжительность stale-состояния.
  • Коды EDE способны обозначить Stale Answer, но остаются диагностикой: они не аутентифицируют старые данные и не дают разрешения использовать их от имени клиента.

Анализ

Представим перенос сервиса на новый IP-адрес. Оператор зоны публикует новое значение и позволяет TTL прежней записи истечь. Большинство резолверов успевают получить изменение. Но один достигает конца TTL во время полной недоступности авторитативных серверов. Ошибка немедленно лишит клиента разрешения имени. Старый адрес может скрыть сбой, однако он же может направить трафик на отключённую, повторно выделенную или исключённую из доверенной границы систему.

TTL исторически задаёт временную границу этой неопределённости. RFC 1035 описывает его как интервал, в течение которого ресурсная запись может храниться в кэше до повторного обращения к источнику и удаления. RFC 2181 уточняет, что TTL — максимальное время жизни, а не обязанность держать запись до последней секунды. В обычном режиме зона публикует предел, а резолвер прекращает повторное использование после его окончания.

RFC 8767 создаёт исключение для невозможности обновить данные. Если TTL истёк, а получить актуальный авторитативный ответ не удаётся, рекурсивный резолвер может сохранить запись и использовать её как непросроченную. Это не разрешение постоянно отвечать старым кэшем, откладывая проверку на потом. Недавняя добросовестная попытка обновления должна завершиться неудачей, а поиск текущих данных должен продолжаться и после отправки stale-ответа вплоть до окончания общего таймера разрешения.

Нулевой TTL остаётся жёсткой границей. Такая запись допустима только в текущей транзакции и не может сохраняться как будущий stale-резерв. Когда резолвер действительно возвращает просроченные записи, он обязан указать для них в сообщении положительный TTL. RFC 8767 рекомендует 30 секунд. Это обходит известные проблемы некоторых реализаций с нулём и ограничивает немедленные повторные запросы со стороны нижестоящих кэшей.

Четыре таймера распределяют разные решения. Таймер ответа клиенту определяет, сколько пользователь ждёт свежих данных до рассмотрения stale-ответа; примерное рекомендуемое значение — около 1,8 секунды. Таймер разрешения ограничивает весь объём работы по получению текущего ответа. Таймер повторной проверки отказа регулирует частоту новых обращений к проблемным авторитативным путям. Максимальный stale-таймер определяет, как долго просроченная запись вообще остаётся кандидатом; документ предлагает практический диапазон от одного до трёх дней.

Эти значения не обязаны совпадать у разных операторов. RFC 8767 определяет serve-stale как локальную операцию рекурсивного резолвера и оставляет параметры реализации и эксплуатации. Поэтому два соответствующих стандарту резолвера во время одного сбоя могут по-разному ответить на одно имя. Один сохранит прежнее значение, другой вернёт ошибку. Это различие отражает выбор риска — перерыв или устаревание, — а не обязательно дефект протокола.

Смысл авторитативного ответа завершает исключение. Авторитативный NOERROR или NXDOMAIN с установленным битом AA обновляет состояние и заменяет прежние данные. Другие коды обычно ничего не утверждают о том, что сейчас существует под данным именем, поэтому считаются неудачным обновлением и оставляют старый кэш нетронутым. SERVFAIL не доказывает правильность прежнего адреса; он лишь показывает, что полезный текущий ответ не получен.

От этого следует отличать кэш ошибок разрешения из RFC 9520. Резолвер должен хранить результат неудачного разрешения не менее одной секунды и не более пяти минут, чтобы совпадающие клиентские запросы не создавали повторную нагрузку вверх, пока запись ошибки действует. Такой кэш хранит факт неудачи процесса. Serve-stale использует прежние данные ответа. Первый сдерживает шторм повторов, второе меняет сведения, которые получает клиент.

RFC 8914 даёт диагностический язык для наблюдения выбора. Extended DNS Error с кодом 3 означает Stale Answer, а код 19 — Stale NXDOMAIN Answer. Эти сведения полезны для телеметрии, но не создают дополнительного доверия. EDE не аутентифицирован, если сама DNS-транзакция не защищена, и не должен менять обработку протокола. Код объясняет путь ответа, но не подтверждает безопасность старого значения.

Цена зависит от типа записи. Старый A или AAAA может поддержать неизменившийся сервис либо вернуть трафик на выведенную систему. Старый CNAME способен восстановить уже удалённую зависимость. RFC 8767 также предупреждает, что подписи могут оказаться за пределами срока действия, stale-данные NSEC или NSEC3 могут задержать новые записи TLSA или DS, а атакующий, способный нарушить доступность авторитативных серверов, может попытаться продлить практическую жизнь старой информации.

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

Источники