Кратко

  • RFC 5074, автором которого был Sam Weiler, описал DNSSEC Lookaside Validation (DLV) для проверки подписанных зон, когда родительская зона не публиковала обычную запись DS.
  • DLV не отменял доверие: резолверу требовался заранее настроенный якорь для отдельного домена DLV; только после этого его аутентифицированные записи можно было использовать вместо DS для целевой зоны.
  • ISC удалила записи реестра в 2017 году, сохранив подписанную пустую зону для старых конфигураций. В 2020 году RFC 8749 перевёл DLV в статус Historic: обычная цепочка DNSSEC стала значительно полнее, а дополнительный код валидации оставался издержкой.

Когда цепочка проверки обрывалась у родителя

Зона может подписывать свои данные, но резолвер всё равно не сможет проверить их от известной точки доверия. В стандартной схеме родительская зона публикует Delegation Signer (DS), связывающий DNSKEY дочерней зоны с подписанными данными родителя. Если один из предков не подписан или регистратор не принимает DS дочерней зоны, в цепочке остаётся разрыв. На раннем этапе внедрения DNSSEC это было практической проблемой: корневая зона и многие домены верхнего уровня ещё не имели подписи.

DLV предложил дополнительный вход. Согласно RFC 5074, отдельно подписанный домен DLV может публиковать аутентифицированные записи для зон ниже заданной точки, даже если те не являются его непосредственными поддоменами. Проверив набор DLV-записей, резолвер может обращаться с ним как с DS и продолжать проверку DNSKEY и подписей целевой зоны. RFC 4431 определяет тип ресурсной записи DLV — 32769; эту спецификацию совместно написали Mark Andrews и Sam Weiler. Weiler написал RFC 5074, посвящённый механизму и поведению валидатора.

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

Завершение механизма зависело от старых настроек

По данным ISC, её реестр DLV начал работу в 2006 году как временная помощь внедрению DNSSEC. По мере подписания корня и делегаций доменов верхнего уровня необходимость в отдельном пути уменьшалась. RFC 8749, написанный W. Mekking и Dan Mahoney, указывает, что корень был подписан в июле 2010 года, а к маю 2019 года 1 389 из 1 531 домена верхнего уровня имели защищённую делегацию от корня. В 2020 году документ перевёл RFC 4431 и RFC 5074 в категорию Historic.

Но новая отметка в реестре стандартов не меняет настройки на старых серверах. ISC удалила записи DLV 30 сентября 2017 года, но оставила dlv.isc.org в виде подписанной пустой зоны. По сообщению ISC, полное удаление зоны могло привести к тому, что некоторые старые резолверы BIND, всё ещё настроенные на DLV, отвечали бы SERVFAIL на множество запросов клиентов. Пустая зона позволила старым настройкам перестать получать действительные DLV-записи, не вызывая резкого сбоя в тех унаследованных конфигурациях, которые проверяла ISC. Это её сообщение о конкретном тестировавшемся случае, а не универсальное свойство всех резолверов.

RFC 8749 описывает обе стороны решения. DLV снижал давление на родительские зоны с целью добиться подписи и на регистраторов, которых просили принимать DS; одновременно он усложнял код валидации. Авторы указывают на реализации в BIND 9 и Unbound и пишут, что им не известны применения в частных компаниях. Это границы их осведомлённости на момент публикации, а не перепись конфигураций в 2026 году. Источники позволяют сделать более узкий вывод: DLV закрывал пробел, пока обычная цепочка расширялась, а при его выводе пришлось учитывать настройки, пережившие исходную причину появления механизма.

Записка Heng Lu №64 служит здесь лишь редакционной оптикой: она предлагает спросить, ограничен ли общий механизм необходимым минимумом и оцениваются ли изменения по фактическому внедрению. Это не источник сведений о Weiler или DNSSEC.

Источники