Кратко
- RESINFO даёт резолверу одну авторитетную запись для заявлений о минимизации QNAME, доступных Extended DNS Error и диагностической HTTPS-странице.
- Аутентифицированное соединение или локальная проверка DNSSEC защищает ответ от подмены, но не подтверждает исполнение каждого заявленного свойства.
- Репутация, политика выбора, согласованность экземпляров, наблюдение запроса и итог сервиса остаются разными квитанциями.
В реестре всё было зелёным, а измерения ещё не начинались
Система управления подключилась к шифрованному резолверу, проверила его имя и запросила RESINFO с выключенной рекурсией. Ответ имел AA, содержал ровно одну корректную запись, qnamemin, набор EDE и HTTPS-ссылку. Карточка возможностей стала зелёной.
Но ни один авторитетный сервер не показал, какие метки получил. Не было контролируемого запроса, способного вызвать фильтр. Неизвестно, какая anycast-инстанция ответит из другой сети. Зелёным можно считать только факт самоописания идентифицированного резолвера.
RFC 9606 прямо предупреждает: шифрованный резолвер может вернуть неточные сведения. Это фундаментальная граница между подлинностью автора и точностью сообщения. Без неё защищённый канал легко превратить в чужую печать истины.
Обнаружение сообщает адрес кандидата
DNR или DDR находит шифрованный DNS-резолвер и его Authentication Domain Name. Этот шаг связывает сервис с именем для аутентификации. Он не выбирает сервис и не проверяет его дополнительные функции.
Затем клиент запрашивает RESINFO по ADN. Если DDR использует resolver.arpa, запрос строится для специального имени. RD устанавливается в ноль, потому что информация принадлежит самому резолверу, а не рекурсивной цепочке. Ответ без AA отбрасывается. Поддерживающий сервер возвращает ровно одну запись; неверный формат игнорируется.
Для защиты от подделки нужен аутентифицированный безопасный канал к обнаруженному резолверу или локальная DNSSEC-валидация. Для resolver.arpa применим только канал. Неподдерживающий резолвер может передать запрос выше, после чего положительный ответ придёт от другого сервера или злоумышленника.
Так фиксируются адресат, авторитетная форма, синтаксис и целостность. Исполнение обещанной функции в этот набор не входит.
qnamemin не хранит путь делегаций
Присутствие qnamemin означает настройку минимизации приватных данных в запросах к авторитетным серверам по RFC 9156. Это булев атрибут. В нём нет тестового имени, состояния кэша, шагов делегации, исключений и fallback.
Проверка поведения требует контролируемой зоны и подготовленного кэша. На каждой авторитетной ступени сохраняют реально полученные запросы, экземпляр резолвера, время и раскрытые метки. После изменения версии или конфигурации опыт повторяют.
Одна правильная трасса относится к одному сценарию, зато точно описывает предел вывода. RESINFO свидетельствует о заявленной конфигурации; журналы авторитетных серверов — о конкретном исполнении. Ни один слой не должен занимать место другого.
exterr перечисляет возможные объяснения
exterr содержит EDE-коды, которые резолвер способен возвращать. Blocked, Censored и Filtered показывают возможность объяснить некоторые решения политики. Список не обещает объяснение каждого случая, законность политики, верность классификации или показ причины приложением.
Стандарт даёт полезный механизм обратной связи. Получив EDE, отсутствующий в списке, клиент заново читает RESINFO. Если расхождение сохраняется, он может признать карточку неточной и отбросить её. Наблюдаемая работа исправляет инвентарь.
Отсутствие заявленного кода не столь однозначно. Условие могло не возникнуть, обновление могло идти поэтапно, маршрут мог привести к другому экземпляру. Нужна связка контролируемого запроса, ответа, EDE, ожидаемой политики, времени и точки наблюдения.
infourl предназначен для диагностики
infourl указывает на общую справку и процедуру сообщения о проблемах. Допускается только HTTPS; неверные URL игнорируются. RFC адресует страницу техническим специалистам, а не конечному пользователю.
HTTPS защищает соединение с указанным информационным сервером. Он не подтверждает полноту, свежесть и исполнение текста. Описание фильтра не равно измерению, форма жалобы не равна исправлению. Ссылку полезно архивировать, но нельзя превращать в автоматическое согласие.
Anycast скрывает за одним именем несколько часов
Экземпляры с общим ADN или anycast-адресом должны публиковать согласованный RESINFO. Маршрутизация и поэтапное обновление всё же могут приводить к разным узлам. Чтение карточки и проверка поведения также способны попасть на разные экземпляры.
Каждая выборка хранит точку измерения, адрес, сессию, время, TTL и доступные признаки экземпляра. Разные ответы под одним ADN — самостоятельный факт. Усреднение уничтожает именно то различие, которое нужно расследовать.
Одинаковые записи также не гарантируют одинакового кода. Узлы могут копировать одно описание и работать на разных версиях. Историю деклараций и историю поведения ведут отдельно, связывая только по времени и маршруту.
Репутация задаётся вне RESINFO
Если свойство нельзя проверить при выборе, RFC 9606 советует учитывать его лишь при достаточной репутации резолвера по локальной политике. Источником может быть пользователь, администратор или встроенный список.
IANA координирует словарь. Резолвер утверждает. Канал связывает утверждение с автором. Клиент назначает вес и выбирает. Регистрация и аутентификация не создают всеобщего приоритета.
Принцип Lu Heng о первичности работающего кода сохраняет правильный масштаб стандарта. Минимальная общая форма делает обещания сравнимыми, а локальные наблюдения не позволяют символу заменить реальность. RESINFO открывает проверяемый вопрос, а не закрывает его.
Источники
- https://www.rfc-editor.org/rfc/rfc9606.html
- https://www.rfc-editor.org/info/rfc9606/
- https://www.rfc-editor.org/rfc/rfc9606.txt
- https://www.rfc-editor.org/rfc/rfc9606.xml
- https://datatracker.ietf.org/doc/rfc9606/
- https://datatracker.ietf.org/doc/rfc9606/history/
- https://www.rfc-editor.org/errata/rfc9606
- https://www.rfc-editor.org/rfc/rfc9462.html
- https://www.rfc-editor.org/rfc/rfc9463.html
- https://www.rfc-editor.org/rfc/rfc9156.html
- https://www.rfc-editor.org/rfc/rfc8914.html
- https://www.rfc-editor.org/rfc/rfc1035.html
- https://www.rfc-editor.org/rfc/rfc6763.html
- https://www.rfc-editor.org/rfc/rfc8126.html
- https://www.rfc-editor.org/rfc/rfc7070.html
- https://www.rfc-editor.org/rfc/rfc9499.html
- https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
