Кратко

  • RFC 8767 позволяет рекурсивному резолверу вернуть просроченные данные, если добросовестная попытка получить свежее авторитетное состояние не удалась. Это решение оператора резолвера, а не продление гарантии издателя зоны.
  • Проверяемость требует раздельно хранить исходный TTL, возраст после истечения, максимальное stale-окно, TTL ответа, состояние DNSSEC, класс сбоя, когорту резолверов и факт восстановления.

Адрес уже удалён из зоны после инцидента безопасности. Его прежний TTL завершился. Тем не менее часть пользователей продолжает получать старое назначение. Это необязательно означает, что авторитетная реплика отстала. Их рекурсивный резолвер мог потерять доступ к авторитетным серверам и предпочесть сохранённую просроченную копию ошибке.

Сценарий условный: это не описание конкретного происшествия и не утверждение о настройках продукта. Он показывает долг непрерывности. Резолвер выигрывает доступность сейчас, но обязан объяснить, как долго и почему использует сведения, которые издатель больше не гарантирует как свежие.

RFC 8767 называет механизм Serve Stale. После окончания TTL источник обычно должен быть опрошен вновь. Если авторитетное обновление невозможно, сохранённые данные разрешено в ограниченных условиях использовать так, будто срок ещё не закончился. Такая формулировка не делает их новыми.

После TTL меняется источник полномочия

Пока TTL действует, повторное использование поддерживает срок, объявленный зоной. После истечения основанием становится локальная политика рекурсивного оператора. Байты те же, но решение уже принимает другая сторона.

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

Поэтому журнал должен содержать время помещения в кэш, исходный TTL, вычисленное истечение, текущий просроченный возраст, окончательную stale-границу и TTL в клиентском ответе. Видимые «30 секунд» могут относиться к выдаче старой копии, а не к подтверждению издателя тридцать секунд назад.

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

Четыре таймера не сводятся к одному флагу

RFC 8767 сознательно не задаёт единственный алгоритм. В примере четыре таймера ограничивают разные риски.

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

Индикатор «Serve Stale включён» не раскрывает компромисс. Короткое ожидание клиента ускоряет ответ, но может заменить лишь медленный авторитет старой копией. Долгая повторная проверка снижает нагрузку во время атаки, но позже замечает восстановление. Длинное хранение переносит крупный сбой, но удерживает заброшенные адреса и прежние состояния безопасности.

Перед выдачей нужна недавняя добросовестная попытка обновиться. Механизм не разрешает всегда отвечать прошлым, а спрашивать потом. Даже после stale-ответа разрешение следует продолжать до собственного предела. Исключение покупает время для восстановления, но не заменяет его.

Сбой обновления должен иметь точное имя

Авторитетные NOERROR и NXDOMAIN с AA обновляют состояние по RFC 8767. NXDOMAIN особенно важен: если издатель намеренно удалил имя, резолвер не вправе хранить старый положительный ответ лишь потому, что так доступнее. Универсально отличить сознательное удаление от ошибочного невозможно.

Тайм-аут, недоступная сеть, SERVFAIL, REFUSED, неправильное сообщение, ошибка DNSSEC и некорректная делегация также неравнозначны. У них разные владельцы восстановления. RFC 2308 ограничивает запоминание сбойного или недоступного сервера пятью минутами.

Цепочка доказательств включает каждый опрошенный авторитетный узел, адрес, транспорт, момент, RCODE, AA, проверку и сетевую ошибку. Нужны попытка обновить делегацию, контекст RD/CD/DO, ключ кэша и класс ответа: положительный, NODATA либо NXDOMAIN.

Два резолвера могут ответить по-разному из-за разных историй, маршрутов и политик. Общий показатель успешности скрывает, какая группа живёт на текущем состоянии, а какая — на исключении.

Короткий TTL ответа не омолаживает запись

При выдаче просроченных записей TTL в сообщении должен быть больше нуля; RFC 8767 рекомендует тридцать секунд. Нулевые значения вызывали проблемы совместимости, а слишком малые способны создать поток повторов во время отказа. Короткий срок ограничивает нижестоящий спрос.

Реальный возраст он не сбрасывает. Если форвардер сохранит ответ, следующий клиент увидит короткий TTL, но не момент окончания исходных данных. Необходимо связать ответ с резолвером, который предоставил исключение, временем его кэша и последней попыткой обновления.

RFC 8914 даёт дополнительные коды EDE. Код 3 — Stale Answer, 19 — Stale NXDOMAIN Answer, 22 — No Reachable Authority. Они могут присутствовать и при NOERROR.

EDE остаётся диагностическим контекстом. Он не меняет обработку RCODE, может быть удалён или создан посредником и без защищённой транзакции не аутентифицирован. Код 3 доказывает, как отправитель описал ответ, но не доказывает его внутренний возраст и историю запросов.

У DNSSEC собственные часы

RRset мог успешно пройти проверку при помещении в кэш и не проходить её позже. Начало и окончание RRSIG независимы от TTL и максимального stale-окна. Чем дольше хранение, тем выше вероятность выйти за криптографический срок.

Флаг AD должен отражать текущую проверку, а не память о прошлом успехе. Сохраняются времена RRSIG, момент валидации, состояние доверенных якорей и CD/DO. Даже всё ещё корректно подписанный старый адрес может указывать на инфраструктуру, которой издатель больше не управляет. Аутентичность данных не равна текущей безопасности назначения.

Отрицательные ответы несут отдельный риск. Старый NXDOMAIN скрывает новое имя. Устаревшие NSEC или NSEC3 могут задержать новые DS и TLSA. RFC 8198 синтезирует ответы из ещё допустимого проверенного отрицательного материала. Serve Stale задаёт дополнительный вопрос после обычного истечения и неудачного обновления.

Источники