Кратко

  • RFC 10037 опубликован в августе 2026 года. Он разрешает добавить ttl0_data в RDAP-объекты домена и сервера имён и показать TTL, provisioned в базе реестра. Это не оставшееся время, которое видно в живом DNS-ответе.
  • Новое наблюдение не объединяет управление. Политика, принятая настройка, авторитативная публикация, состояние каждого рекурсивного кэша и конечный результат требуют отдельных свидетельств.

Команда готовит замену NS в полдень. Сначала TTL уменьшают с суток до 300 секунд. В 11:55 RDAP уже показывает 300, и административный план выглядит исполненным. Однако резолвер, получивший старый RRset в 11:54 со значением 86 400, не узнает о новой цифре. Его копия продолжает собственный отсчёт.

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

RFC 10037 — документ IETF Standards Track, вышедший в августе 2026 года. Поддерживающий сервер может включать ttl0_data в domain- и nameserver-объекты. Внутри values имена зарегистрированных IANA типов DNS пишутся прописными буквами и сопоставляются целым JSON-числам от нуля до 2^31−1. Ответ с расширением указывает ttl0 в rdapConformance.

Главная граница сформулирована прямо: значение отражает TTL, provisioned в базе реестра, а не остаток, наблюдаемый в запросе к работающему DNS. RDAP стал внешним свидетельством настройки. Он не получил доступ к таймеру чужого кэша.

Право увидеть не становится правом изменить

Поле необязательно. Сервер может его не выдавать, а старый клиент должен игнорировать неизвестный член по правилам RFC 9083. Клиент с поддержкой расширения обязан принимать все допустимые DNS-типы и обновлять сведения по мере изменения реестра параметров DNS IANA. Новый тип не является ошибкой только потому, что библиотека выпущена раньше.

Реестр расширений RDAP IANA закрепляет идентификатор ttl0. Регистрация подтверждает общий словарь, а не внедрение у конкретного оператора, долю поддержки или возможность клиента задавать значение.

Для записи существует отдельная спецификация. RFC 9803 описывает EPP-расширение для TTL делегации. Сервер может ограничить типы RR, задать минимум, значение по умолчанию и максимум, отклонить запрос, не применить его ради устойчивости, изменить TTL вне команды клиента или автоматически вернуть исходную политику.

RFC 10037 совместим с этим механизмом, но не требует его. Реестр вправе публиковать собственное решение в RDAP и не передавать право выбора регистратору.

У одного изменения пять независимых состояний

Политика определяет допустимые значения и субъект запроса. База реестра хранит принятую конфигурацию, которую показывает RDAP. Генератор зоны и авторитативные серверы публикуют реальный RRset. Рекурсивный резолвер хранит ранее полученную копию по локальным правилам. Приложение проверяет, привели ли новый адрес, делегация и DNSSEC к работающему сервису.

RFC 2181 относит TTL ко всему RRset и требует одинакового значения для его записей. RFC 1035 задаёт обычный интервал кэширования. RFC 9499 называет его максимумом: оператор может сократить время или удалить копию раньше. После удаления оставшегося таймера уже нет.

Истечение также не гарантирует синхронного исчезновения. RFC 8767 позволяет в ограниченных условиях отдавать старые данные, если добросовестное обновление не удалось. Это локальное решение о доступности, а не новая публикация реестра и не восстановление актуальности старого RRset.

Отсчёт начинается после доказанной публикации

RFC 9803 отмечает распространённую ошибку: снижать TTL одновременно с заменой данных или после неё. Кэши со старым значением не сокращаются задним числом. Меньшая величина должна быть опубликована как минимум за прежний TTL до содержательного изменения; к этому добавляется задержка между приёмом команды и реальным появлением в DNS.

Проверяемая последовательность начинается с прежнего значения и политики. Затем следует авторизованный запрос, подтверждение принятия, наблюдение короткого TTL на всех нужных авторитативных серверах и ожидание старого интервала от этого доказанного момента. Только затем меняют NS, DS, A, AAAA или другие данные. Наблюдения через разные рекурсивные сети, проверка DNSSEC и прикладные canary подтверждают результат. Нормальный TTL возвращают после стабилизации, пока старый путь ещё пригоден для rollback.

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

Короткий и длинный TTL переносят разные риски

Владелец домена хочет быстро менять и возвращать. Реестр и авторитативная инфраструктура получают больше запросов при малом TTL и учитывают fast flux. Большое значение снижает обычную нагрузку, но после компрометации аккаунта может дольше удерживать вредоносные NS или glue в кэшах.

Поэтому границы и override остаются у оператора реестра. Видимость решения не доказывает его разумность. RFC 7481 опирается на другие слои для аутентификации, авторизации, конфиденциальности и целостности RDAP. Защищённая передача поля не подтверждает согласование базы, зоны и приложения.

Общий журнал связывает часы, не смешивая их

Для изменения сохраняют исполнителя и полномочия, версию политики, прежний TTL, EPP-транзакцию или равнозначное подтверждение, RDAP-ответ со временем, версию зоны, ответы всех авторитативных серверов, рекурсивные наблюдения, DNSSEC, прикладной canary и решение о rollback. Всякая отметка должна называть RRset, источник и стадию.

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

RFC 10037 не синхронизировал Интернет. Он позволил реестру точно назвать часы, которые тот способен показать.