Кратко

  • RFC 8767 не отменяет TTL: старые данные допустимы лишь как ограниченный резерв после того, как недавняя добросовестная попытка не получила пригодных авторитетных данных.
  • Исходный TTL, максимальный срок stale, ожидание клиента, выдаваемый TTL, период подписи DNSSEC, EDE и повторные запросы — разные часы и разные утверждения.
  • David C. Lawrence указан одним из трёх авторов RFC. Коллективное авторство не означает власть над зонами, резолверами, реализациями, внедрениями или решениями ICANN.

Запрос приходит в переходный момент. RRset только что перестал быть свежим, но всё ещё лежит в памяти. Авторитетный путь молчит или возвращает непригодный результат. Приложение ждёт, и резолвер должен выбрать между видимым отказом и прежним значением.

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

RFC 8767 была опубликована в марте 2020 года за авторством David C. Lawrence, Warren Kumari и Puneet Sood. Документ не объявляет просроченные данные свежими. Он создаёт проверяемое временное состояние, в котором непрерывность остаётся подчинена источнику.

Хранение не даёт права утверждать актуальность

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

Реализация может сохранить байты для диагностики, сравнения или аварийной выдачи. Но «есть в памяти» и «разрешено вернуть клиенту» — два разных состояния. RFC 8767 регулирует второе.

Запись, изначально полученная с TTL ноль, исключена. Источник прямо запретил повторное использование. Резолвер не вправе потом назначить ей собственный период stale.

Поэтому доказательство появляется при записи в кэш: имя, тип, класс, источник ответа, хэш содержания, полученный TTL, время вставки, обычное истечение и статус DNSSEC. Выражение «последний хороший ответ» ничего не доказывает без объекта, возраста и основания прежнего доверия.

Источник получает первую попытку

RFC 8767 требует недавнего добросовестного обновления. Резолвер обращается к авторитетному пути и ждёт в пределах клиентского бюджета. Только сбой или тайм-аут открывает доступ к старой копии. Если совсем недавний запрос уже установил проблему наверху, последующие запросы могут не повторять полное ожидание.

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

Добросовестность должна оставлять поля: целевые серверы, транспорт, начало, конец, ответ или класс ошибки, DNSSEC и использованная память недавнего сбоя. Тайм-аут, SERVFAIL, авторитетный NXDOMAIN и неверная подпись — не одно событие.

Выданный старый ответ не доказывает восстановление. RFC требует продолжать запросы. Исключение заканчивается только после получения, оценки и установки свежего пригодного авторитетного ответа.

У одной записи не один срок

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

Второй — максимальный локальный срок использования старой копии. Он должен настраиваться; документ предлагает исходный порядок от одного до трёх дней. После границы запись теряет право на выдачу, даже если продолжает храниться.

Третий — ожидание клиента, обычно в секундах. Короткое ожидание снижает задержку, но чаще заставляет просто медленный авторитетный ответ проигрывать.

Четвёртый — TTL, возвращаемый вместе со stale-ответом. Он должен быть положительным; рекомендуется 30 секунд. Это предел для следующего кэша, а не новый возраст исходной записи.

Пятый — собственный интервал подписи DNSSEC. RRset может истечь раньше RRSIG, а подпись — раньше локального stale-предела. Параметры кэша не продлевают криптографическое время.

Шестой — период повторов и задержка между ними. Слишком частые запросы нагружают повреждённый источник, слишком редкие превращают старый ответ в длительную практическую истину. Все сроки надо сохранять отдельно.

DNSSEC подтверждает прошлое происхождение, а не нынешнюю волю

RFC 4035 требует проверить цепочку и временной интервал подписи. Просроченный RRset может оставаться Secure, пока доказательство действует. Это говорит, что владелец подписал данные в определённое время, но не говорит, что сегодня он публикует то же значение.

RFC 8767 предупреждает: с возрастом ошибки проверки становятся вероятнее. Есть и риск без подделки подписи: если атакующий удерживает авторитетный сервис недоступным, старая корректно подписанная запись живёт дольше. Используется разница между прежней подлинностью и текущим намерением.

Допустимость зависит от действия. Временно открыть страницу и выпустить сертификат на основании DNS challenge — разные уровни необратимости. RFC советует центрам сертификации не использовать stale-резолвер для такой проверки.

Отрицание тоже стареет. Старый положительный ответ направляет трафик на снятый сервис; старый NXDOMAIN скрывает вновь созданное имя. RFC 8914 выделяет Stale NXDOMAIN Answer именно потому, что отсутствие требует свежего основания.

EDE сообщает об исключении, но не исправляет его

Lawrence также участвовал в RFC 8914 об Extended DNS Errors. Код 3 означает Stale Answer, код 19 — Stale NXDOMAIN Answer. Подготовленный клиент может узнать, что получил не обычные текущие данные.

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

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

Счётчик кода 3 имеет смысл только вместе с объектом кэша, обновлением, возрастом, выданным TTL, DNSSEC и последующим восстановлением.

Работающая программа показывает локальную политику

RFC 8767 упоминает ранний патч для BIND 9.7.0, производственное использование Akamai с 2011 года и последующую поддержку в BIND 9.12, Unbound и Knot Resolver. Механизм вырос из коллективного опыта эксплуатации.

Единых настроек это не создало. Текущая документация Unbound говорит, что поведение RFC 8767 стало стандартным с версии 1.23.0. Она описывает ожидание 1,8 секунды или замену SERVFAIL, предел в один день, TTL ответа 30 секунд и продолжение разрешения.

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

Доказательство даёт работающая система: продукт, версия, фактические параметры, переход состояния и сетевой ответ. Испытания должны охватывать здоровый источник, молчание, SERVFAIL, DNSSEC-ошибку, восстановление до и после границы, изменённое значение и TTL ноль. Документ описывает возможность, трасса — факт.

Запись о Lawrence очерчивает вклад

IETF Datatracker ведёт David C. Lawrence под именем «tale» и перечисляет RFC 3425, 7871, 8767 и 8914. В актуальной карточке он сопредседатель Adaptive DNS Discovery, представитель IETF при Совете ICANN и технический рецензент.

Нынешняя страница Совета ICANN указывает, что David Lawrence с 14 ноября 2024 года представляет IETF без права голоса. Биография называет RPI и Usenet, UUNET, переписывание BIND в ISC, Nominum, тринадцать лет в Akamai, выбор DNSSEC Root Key Trusted Community Representative в 2010 году, DNS-OARC и CVFiber.

Это подтверждает длительное участие в коде DNS, стандартах и институциональной связи. Но не подтверждает единоличное изобретение, контроль резолверов или власть в ICANN. У RFC три автора и более широкий опыт сообщества.

Граница личности повторяет границу кэша: вклад не переносит эксплуатационные полномочия, копия не переносит авторитет имени.

Журнал закрывается свежим авторитетным ответом

Сначала фиксируются RRset, происхождение, TTL, вставка, истечение, хэш и DNSSEC. Затем — цели обновления, транспорт, время, результат и использованная память сбоя.

Решение содержит максимальный срок, вычисленную границу, возраст, бюджет клиента, TTL ответа, EDE, исключение и следующую попытку. Ограничение для необратимых потребителей тоже должно быть явным.

В конце стоят первый пригодный свежий ответ, проверка, новый хэш, установка, выход из stale-состояния и эффект для приложения. Если значение изменилось, история старой выдачи не стирается.

Так защищается журнал, а временный посредник не становится источником. Резолвер сохраняет функцию, пока происхождение, возраст, предел и возврат к авторитету остаются доказуемыми.

Источники