Кратко

  • RFC 10037 определяет необязательный элемент ttl0_data для объектов домена и сервера имен в RDAP.
  • Опубликованный TTL берется из настроек базы реестра, а не из остаточного времени, увиденного в DNS-запросе.

Одинаковое число отвечает на разные вопросы

RDAP уже показывал серверы имен, glue-адреса и записи DS, связанные с доменом. Значения TTL для этих RRset отсутствовали. Между тем TTL выражает эксплуатационное намерение: как долго резолвер может повторно использовать набор, прежде чем запросить его снова.

Объект ttl0_data содержит таблицу values, сопоставляющую обозначения типов DNS со значениями TTL, и может включать замечания RDAP. Публикация остается выбором сервера. Если расширение используется, ответ обязан объявить ttl0 в rdapConformance.

Главное ограничение касается происхождения числа. Это должно быть значение, настроенное в базе реестра, а не убывающий остаток из живого DNS-ответа. Число 3600 означает, что для RRset представлена настройка в один час. Оно не доказывает, что все авторитативные серверы уже отдают ее, все кэши получили изменение или в конкретном кэше осталось ровно 3600 секунд.

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

Раскрытие добровольно, смысл стандартизирован

Реестр сохраняет право решать, публиковать ли ttl0_data. После публикации действуют строгие правила. Обозначения типов должны быть зарегистрированы IANA и записаны прописными буквами. TTL относится ко всему RRset. Значение JSON должно быть целым числом без дробной части и экспоненты, от нуля до 2147483647.

Стандарт управляет словарем, форматом и признаком соответствия. Реестр управляет доступностью и представленным состоянием базы. Клиент выбирает способ использования. Обмен настройкой не дает ни одной стороне контроля над работающей DNS.

Регистраторы, владельцы доменов, DNS-провайдеры и аварийные команды получают общую справочную точку без привилегированного доступа. Но RFC 10037 не подтверждает актуальность базы, полномочия на изменение или совпадение с опубликованными данными DNS.

Расширяемость требует гибкости клиента

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

Публикация через RDAP также отделена от настройки через EPP по RFC 9803. Реестр может внедрить одно расширение без другого. Видимый TTL не сообщает, кто его выбрал, какая политика ограничила или кто вправе изменить. RFC 10037 прямо оставляет вопросы определения, назначения и изменения значений за рамками документа.

Доказательства, контрфактический сценарий и неизвестное

Без расширения RDAP по-прежнему показывал бы связанные DNS-записи, но не настроенные реестром TTL. Операторы зависели бы от работающей DNS или собственных каналов реестра без стандартизированной внешней точки сверки. Это контрфактический вывод из функций спецификаций, а не измеренный результат.

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

Источники