Кратко

  • В запросе RFC 9664 указана желаемая длительность; фактически выданные LEASE и KEY-LEASE находятся в успешном ответе авторитетного сервера.
  • Истечение аренды прекращает публикацию у авторитета, но не доказывает доступность сервиса, сходимость всей авторитетной группы или немедленное исчезновение ответа из кеша.

Рассмотрим условную регистрацию. Устройство просит публиковать его сервисные RR 30 минут. Аутентификация и предусловия DNS UPDATE проходят, сервер отвечает успешно, но выдаёт четыре часа. Через двадцать минут устройство выключается, не удалив записи и не отправив обновление.

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

Три решения внутри одной успешной операции

Update Lease переносится как опция EDNS(0) в обычном сообщении RFC 2136. Секции Zone, Prerequisite, Update и Additional Data сохраняются. Предусловия проверяются против текущего состояния зоны, а изменение принимается атомарно.

Так решается, имеет ли субъект право выполнить запись. Ответ Lease решает, как долго принятые RR будут публиковаться без продления. Работает ли адрес, порт и приложение, показывает только отдельная проверка сервиса.

TSIG или SIG(0) аутентифицируют транзакцию. Политика может ограничить ключ конкретными именами и типами. Но подпись не видит процесс приложения, сетевой путь и результат пользовательской операции. Аутентичная регистрация недоступного сервиса остаётся регистрацией недоступного сервиса.

Следует хранить все секции пакета, имя ключа TSIG или идентичность SIG(0), решение политики, длину опции, запрошенные значения, RCODE и возвращённые значения. Запись «lease успешно» не отвечает, кто и на сколько выдал время.

Четыре и восемь байтов разделяют сервис и имя

Четырёхбайтовый вариант содержит одно 32-битное LEASE для всех RR в Update, включая KEY. Восьмибайтовый добавляет KEY-LEASE: обычные RR используют первый срок, KEY — второй.

В Service Registration Protocol из RFC 9665 это позволяет убрать сервисные записи, но дольше сохранять KEY и резерв имени за тем же криптографическим владельцем. Сохраняется притязание на имя, а не живой сервис.

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

Явно удалённые RR удаляются постоянно. Lease не превращает удаление во временную паузу.

Операционные часы запускает ответ

Поддерживающий механизм сервер обязан вернуть опцию при успешной обработке запроса с ней. Клиент планирует Refresh на 80% выданного срока плюс случайные 0–5%. Разброс не даёт устройствам обновляться одновременно и оставляет 15–20% для повторов.

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

Если успешный ответ не содержит Update Lease, это признак отсутствия поддержки. RFC советует клиенту продолжать Refresh так, будто сервер вернул запрошенное значение. Такая совместимость не доказывает автоматическое истечение на сервере. Состояние следует отмечать как «клиент продлевает, серверная очистка не подтверждена».

Registration и Refresh тоже различаются. Registration добавляет предположительно отсутствующую информацию. Refresh продлевает существующее состояние без изменения. Если перезапуск уничтожил состояние сервера, Refresh может снова добавить RR. Тогда содержимое зоны меняется и serial должен увеличиться. Если содержимое не менялось, простое продление не должно менять serial.

У авторитета истекло, в кеше осталось

После истечения без продления сервер не должен возвращать RR. Он может удалить сохранённые данные, но не обязан. Состояние ответа и состояние хранения — разные факты.

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

Расследование разделяет выданный дедлайн, Refresh и повторы, распространение через журнал/подписывающий узел/вторичные серверы и наблюдаемый TTL. Если регистратор — hidden primary, его таблица не доказывает ответы публичных или anycast-узлов. Доступность устанавливается отдельным подключением к объявленному протоколу.

Границы задаёт локальная политика

Слишком долгая аренда почти равна бессрочной записи. Слишком короткая создаёт нагрузку и преждевременное исчезновение при задержке. RFC 9664 рекомендует максимумы по умолчанию 24 часа для LEASE и семь дней для KEY-LEASE, а минимум — не менее 30 секунд; обычно уместны гораздо большие значения, например час. Оператор может их изменить.

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

Источники