RFC 8509 | Корневой ключ якоря доверия стоящего на страже для DNSSEC

Аннотация

Расширения безопасности DNS (DNSSEC) были разработаны для обеспечения аутентификации источника и защиты целостности данных DNS с использованием цифровых подписей. Эти цифровые подписи могут быть проверены путем создания цепочки доверия, начиная с привязки доверия и заканчивая определенным узлом в DNS. Этот документ определяет механизм, который позволит конечному пользователю и третьим сторонам определять состояние доверенного ключа для корневого ключа распознавателей, которые обрабатывают DNS-запросы этого пользователя. Обратите внимание, что этот метод применим только для определения того, какие ключи находятся в хранилище доверенных сертификатов для корневого ключа.

Скачать оригинальный документ на английском языке RFC 8509 PDF

 

Оглавление

1. Введение
1.1. Терминология
2. Часовой механизм в резольверах
2.1. Предпосылки
2.2. Специальная обработка
3. Sentinel Тесты для одного DNS резольвера
3.1. Транспортеры
4. Sentinel Тесты для нескольких резольверов
4.1. Сценарий и цель теста
4.2. Тестовые предположения
4.3. Тестовая процедура
5. Вопросы безопасности
6. Вопросы конфиденциальности
7. Соображения IANA
8. Ссылки
8.1. Нормативные ссылки
8.2. Информационные ссылки
Приложение А. Пример прохождения протокола
Благодарности
Адреса авторов

 

Статус этой заметки

Это документ по отслеживанию стандартов Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 7841.

Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу https://www.rfc-editor.org/info/rfc8509.

 

Уведомление об авторских правах

Copyright (c) 2018 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На данный документ распространяется действие BCP 78 и Правовые положения IETF Trust в отношении документов IETF (https://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать в себя текст упрощенной лицензии BSD, как описано в разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.

 

1. Введение

Расширения безопасности DNS (DNSSEC) [RFC4033], [RFC4034] и [RFC4035] были разработаны для обеспечения аутентификации источника и защиты целостности данных DNS с использованием цифровых подписей. DNSSEC использует ключевые теги для эффективного сопоставления подписей с ключами, из которых они сгенерированы. Ключевой тег — это 16-битное значение, вычисленное из RDATA записи ресурса DNSKEY (RR), как описано в Приложении B к [RFC4034]. RRSIG RR содержат поле Key Tag, значение которого равно Key Tag для DNSKEY RR, который использовался для генерации соответствующей подписи.

В этом документе указывается, как распознаватели DNS с поддержкой безопасности, которые выполняют проверку своих ответов, могут отвечать на определенные запросы таким образом, чтобы агент, выполняющий запросы, мог определить, был ли загружен определенный ключ для корня в хранилище доверенных ключей этого преобразователя. В этом документе также описывается процедура, в которой можно проверить набор распознавателей, чтобы определить, загрузил ли хотя бы один из этих преобразователей данный ключ в свое хранилище доверенных ключей. Эти тесты можно использовать для определения того, готов ли определенный ключ подписи ключа (KSK) корневой зоны в качестве доверенного ключа в контексте запланированной проверки KSK корневой зоны.

Есть два основных варианта использования этого механизма:

• Пользователи могут пожелать выяснить, готов ли распознаватель среды разрешения их DNS к предстоящему переключению корневого ключа KSK.
• Исследователи хотят провести общеинтернетные исследования о доле пользователей, на которых негативное влияние окажет предстоящий ролловер KSK.

Механизм, описанный в этом документе, удовлетворяет требованиям обоих этих вариантов использования. Этот механизм не является обязательным для реализации и использования. Если он реализован, этот механизм ДОЛЖЕН быть включен по умолчанию для облегчения измерений в Интернете. Могут быть предоставлены параметры конфигурации для отключения механизма по причинам локальной политики.

Описанные в этом документе дозорные тесты KSK используют тест, содержащий набор DNS-запросов к доменным именам, которые имеют специальные значения для самой левой метки. Тест опирается на рекурсивные распознаватели, поддерживающие механизм, который распознает этот специальный шаблон имени в запросах; при определенных определенных обстоятельствах он вернет код ответа DNS SERVFAIL (RCODE 2), имитируя код ответа, который возвращается распознавателями с защитой при сбое проверки DNSSEC.

Если браузер или операционная система настроена с несколькими распознавателями, и эти распознаватели имеют разные свойства (например, один выполняет проверку DNSSEC, а другой нет), описанный в этом документе дозорный тест все еще можно использовать. Дозорный тест делает ряд предположений о поведении разрешения DNS, которое может не обязательно выполняться во всех средах; если эти предположения не выполняются, то этот тест может дать неопределенные или противоречивые результаты. Это может произойти, например, если преобразователь заглушки должен запросить следующий рекурсивный преобразователь в локально настроенном наборе при получении кода ответа SERVFAIL. В некоторых случаях, когда эти предположения не выполняются, повторение одного и того же набора тестовых запросов может привести к разным результатам.

Обратите внимание, что измерения, осуществляемые с помощью механизма, описанного в этом документе, отличаются от измерений в [RFC8145]. RFC 8145 полагается на распознаватели, которые сообщают корневым серверам список локально кэшированных привязок доверия для корневой зоны. Эти отчеты могут использоваться для определения того, на сколько преобразователей может повлиять проверка KSK, но не на то, как будет влиять на пользователя проверка KSK.

 

1.1. Терминология

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119], [RFC8174]

Этот документ содержит ряд терминов, связанных с DNS. Текущие определения этих терминов можно найти в [RFC7719].

 

2. Часовой механизм в резольверах

DNSSEC-проверяющие распознаватели, которые реализуют этот механизм, ДОЛЖНЫ выполнять проверку ответов в соответствии со спецификацией проверки ответов DNSSEC [RFC4035].

Этот часовой механизм использует две специальные метки:

• root-key-sentinel-is-ta- <key-tag>
• root-key-sentinel-not-ta- <key-tag>

Эти метки запускают специальную обработку в проверяющем преобразователе DNS при получении ответов от авторитетных серверов. Метки, содержащие «root-key-sentinel-is-ta- <key-tag>», используются для ответа на вопрос: «Является ли этот тег тегом ключа, которому проверяющий DNS-распознаватель в настоящее время доверяет в качестве привязки доверия?»

Метки, содержащие «root-key-sentinel-not-ta- <key-tag>», используются для ответа на вопрос: «Является ли это ключевой тег ключа, который проверяющий DNS-распознаватель * не * в настоящее время доверяет в качестве доверенного якоря ?»

Определенные здесь специальные метки были выбраны после тщательной оценки IETF альтернативных моделей и подходов в свете желаемого поведения (разделы 2.1 и 2.2) в резольвере и применяемой методологии тестирования (раздел 4.3). В качестве одного примера, имена с префиксом подчеркивания были отклонены, потому что некоторые браузеры и операционные системы не могли их получить, потому что они являются доменными именами, но не действительными именами хостов (см. [RFC7719] для этих определений).

Были рассмотрены локальные коллизии и резервирование крайних левых меток доменного имени, а также влияние на операторов зоны, которые могут захотеть использовать аналогичное имя хоста для целей, отличных от задокументированных здесь. Поэтому важно отметить, что резервирование меток таким способом определенно не считается «наилучшей практикой».

 

2.1. Предпосылки

Все следующие условия должны быть выполнены, чтобы вызвать специальную обработку внутри кода решателя:

• Ответ DNS подтвержден DNSSEC.
• Результат проверки — «Secure — Безопасный».
• Механизм расширения для DNS (EDNS (0)) Бит проверки отключенного (CD) в запросе не установлен.
• QTYPE — A или AAAA (тип запроса 1 или 28).
• OPCODE — QUERY.
• Самая левая метка исходного QNAME (имя, отправленное в разделе вопросов в исходном запросе) — это либо «root-keysentinel-is-ta- <key-tag>», либо «root-key-sentinel-not-ta- <key-tag>».

Если какое-либо из предварительных условий не выполняется, распознаватель НЕ ДОЛЖЕН изменять ответ DNS на основе механизма, описанного в этом документе.
Обратите внимание, что <key-tag> указывается в метке DNS как десятичное целое число без знака (как описано в [RFC4034], раздел 5.3), но имеет нулевую добавку до пяти цифр (например, значение ключевого тега 42 будет представлено в метка как 00042). Точная спецификация специальных этикеток выше должна точно соблюдаться. Например, метка, которая не содержит ключевой тег, дополненный нулями до пяти цифр, не соответствует этой спецификации и не должна обрабатываться так, как если бы она была — другими словами, такие запросы должны обрабатываться как любая другая метка и не соответствовать к разделу 2.2.

 

2.2. Специальная обработка

Ответы, которые удовлетворяют всем предварительным условиям в разделе 2.1, требуют специальной обработки, в зависимости от самой левой метки в QNAME.

Во-первых, распознаватель определяет, равно ли числовое значение <key-tag> какому-либо из значений тега ключа активной корневой зоны KSK, которой в настоящее время доверяет локальный распознаватель и которая хранится в хранилище доверенных ключей. Активная корневая зона KSK — это та, которая в настоящее время может использоваться для проверки (то есть ключ, который не находится ни в состоянии AddPend, ни в Revoked, как описано в [RFC5011]).

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

Инструкция «return SERVFAIL» означает, что распознаватель ДОЛЖЕН установить RCODE = SERVFAIL (значение 2), а раздел ответа ответа DNS ДОЛЖЕН быть пустым, игнорируя все другие документы, в которых указано содержание раздела ответа.

Инструкция «вернуть исходный ответ» означает, что распознаватель ДОЛЖЕН обработать запрос без какой-либо дополнительной специальной обработки, то есть точно так, как если бы механизм, описанный в этом документе, не был реализован или был отключен. Ответ на запрос A или AAAA отправляется клиенту.

 

3. Sentinel Тесты для одного DNS резольвера

В этом разделе описывается использование механизма обнаружения сторожа для одного рекурсивного распознавателя DNS, чтобы определить, использует ли этот определитель конкретную привязку доверия для проверки ответов, подписанных DNSSEC.

Обратите внимание, что тест в этом разделе относится к одному преобразователю DNS. Тест, описанный в Разделе 4, применяется вместо этого к коллекции распознавателей DNS, что можно найти в конфигурации DNS среды конечного пользователя.

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

Процедура обнаружения стража может проверить распознаватель DNS с помощью трех запросов:

• Имя запроса, содержащее крайнюю левую метку «root-key-sentinel-ista- <key-tag>». Это соответствует правильно подписанному имени в родительской зоне, так что ответы, связанные с этим именем запроса, могут аутентифицироваться проверяющим устройством, проверяющим DNSSEC. Любая правильно подписанная DNS-зона может быть использована в качестве родительской зоны для этого теста.
• Имя запроса, содержащее крайнюю левую метку «root-key-sentinel-notta- <key-tag>». Это также соответствует правильно подписанному имени. Любая правильно подписанная DNS-зона может быть использована в качестве родительской зоны для этого теста.
• Имя запроса, подписанное с помощью подписи DNSSEC, которое не может быть проверено (описано как «фиктивный» RRset в Разделе 5 [RFC4033], когда, например, RRset связан с зоной, которая не подписана с действительным RRSIG запись).

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

Здесь существенное предположение заключается в том, что этот метод основан на распознавателях безопасности (проверяющих DNSSEC), отвечающих кодом ответа SERVFAIL на запросы, в которых запрашивается проверка DNSSEC и ответ не может быть проверен. Обратите внимание, что другие проблемы могут также привести к тому, что распознаватель возвращает ответы SERVFAIL, и поэтому обработка, выполняемая дозором, может иногда приводить к неверным или неопределенным выводам.

Чтобы описать этот процесс классификации, преобразователи DNS классифицируются по пяти различным типам поведения с использованием меток: «Vnew», «Vold», «Vind», «nonV» и «other». Эти метки соответствуют типам поведения резолвер-системы следующим образом:

Vnew: DNS-распознаватель, который настроен для реализации этого механизма и загрузил назначенный ключ в свои локальные хранилища доверенных ключей, ответит ответом R или R-набора AAAA для связанных запросов «root-key-sentinel-is-ta», SERVFAIL для запросов «root-keysentinel-not-ta» и SERVFAIL для подписанных запросов имен, которые возвращают «поддельный» статус проверки.

Vold: распознаватель DNS, который настроен для реализации этого механизма и не загружал назначенный ключ в свои локальные хранилища доверенных ключей, ответит SERVFAIL для связанных запросов «root-keysentinel-is-ta», A или AAAA RRset ответ для запросов «rootkey-sentinel-not-ta» и SERVFAIL для запросов на подписанные имена, которые возвращают «поддельный» статус проверки.

Vind: DNS-распознаватель, который не настроен для реализации этого механизма, будет отвечать ответом RRset A или AAAA для «rootkey-sentinel-is-ta», ответом RRset A или AAAA для «root-keysentinel-not-ta», и SERVFAIL для имени, которое возвращает «поддельный» статус проверки. Этот набор ответов не дает никакой информации об элементах доверия, используемых этим распознавателем.

nonV: распознаватель DNS, не связанный с безопасностью, ответит ответом RRset A или AAAA для «root-key-sentinel-is-ta», ответом RRset A или AAAA для «root-key-sentinel-not-ta» и ответ A или AAAA RRset для имени, которое возвращает «поддельный» статус проверки.

other: Существует возможность допустить другие комбинации ответов на эти три запроса. Хотя это может показаться противоречивым, существуют случаи, когда такой результат возможен.

Например, в фермах распознавателя DNS то, что кажется единым преобразователем DNS, отвечающим на запросы, передаваемые на один IP-адрес, фактически создается как набор подчиненных распознавателей, и запрос передается одному из этих внутренних обработчиков распознавателя.

Если эти индивидуальные подчиненные распознаватели в ферме не ведут себя одинаково, то от этих трех запросов можно ожидать других наборов результатов. В таком случае невозможно определить возможности этой фермы преобразователя DNS.

 

Обратите внимание, что SERVFAIL может быть кэширован в соответствии с разделом 7 [RFC2308] на срок до 5 минут и положительным ответом для его TTL.

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

В этой таблице ответ «Y» обозначает ответ A или AAAA RRset (в зависимости от типа запроса записей A или AAAA), «SERVFAIL» обозначает код ответа DNS SERVFAIL (RCODE 2), а «*» обозначает любой ответ.

Vnew: назначенному ключу доверяет распознаватель.
Vold: назначенный ключ еще не является доверенным для распознавателя.
Vind: Нет информации о доверительных якорях распознавателя.
nonV: распознаватель не выполняет проверку DNSSEC.
другое: свойства распознавателя не могут быть проанализированы с помощью этого протокола.

 

3.1. Сервер пересылки

Некоторые распознаватели настроены не отвечать на запросы с использованием рекурсивного алгоритма, впервые описанного в [RFC1034], раздел 4.3.2, а вместо этого передают запросы одному или нескольким другим распознавателям. Стабилизаторы, настроенные таким образом, упоминаются в этом документе как «серверы пересылки».

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

Если проверяющий распознаватель имеет конфигурацию переадресации, и он устанавливает бит проверки отключения (CD) EDNS (0), как описано в разделе 3.2.2 [RFC4035], для всех переадресованных запросов, то этот распознаватель действует идентичным образом. в автономный распознаватель.

Более сложный случай, когда выполняются все следующие условия:

• И проверяющий распознаватель, и целевой распознаватель пересылки поддерживают этот механизм дозорного доверенного ключа.
• В запросах локального распознавателя не установлен бит CD EDNS (0).
• Состояние доверенного ключа различается между распознавателем пересылки и целевым распознавателем пересылки.

В таком случае, либо результат является неопределенным подтверждением («Vind»), либо во всех трех ответах присутствуют смешанные сигналы, такие как SERVFAIL («другой»), что аналогично является неопределенным ответом в отношении состояния доверенного ключа.

 

4. Sentinel Тесты для нескольких резольверов

В разделе 3 описывается тест привязки доверия, который можно использовать в простой ситуации, когда тестовые запросы передаются одному рекурсивному распознавателю, который напрямую запрашивает авторитетные серверы имен.

Однако в общем сценарии конечного пользователя среда локального разрешения DNS пользователя настроена на использование более одного рекурсивного распознавателя. Метод тестирования с одним распознавателем не будет надежно работать в таких случаях, поскольку ответ SERVFAIL от одного распознавателя может привести к тому, что локальный обработчик-заглушка будет повторять запрос к одному из других настроенных преобразователей, и результаты могут быть неубедительными.

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

 

4.1. Сценарий и цель теста

Этот тест не предназначен для определения того, какие привязки доверия используются каким-либо одним распознавателем DNS.

Тестовый сценарий явно ограничен сценарием среды KSK, где текущий активный KSK (называемый «KSK-current») должен быть заменен новым KSK (называемым «KSK-new»). Тест предназначен для запуска между введением KSK-new в корневую зону и подписью корневой зоны с помощью KSK-new.

Цель теста — определить, будет ли на пользователя негативно влиять бросок KSK. «Негативное влияние» для пользователя определяется так, что все настроенные преобразователи являются распознавателями безопасности, которые выполняют проверку ответов, подписанных DNSSEC, и ни один из этих преобразователей не загрузил KSK-new в свой локальный набор привязки доверия. В этой ситуации ожидается, что после развертывания KSK весь набор распознавателей пользователя не сможет проверить содержимое корневой зоны, и пользователь может потерять службу DNS в результате этой неспособности выполнить успешную проверку DNSSEC.

 

4.2. Тестовые предположения

В этом тесте используется ряд предположений о среде DNS. Если эти предположения не выполняются, результаты теста будут неопределенными.

• Когда рекурсивный распознаватель возвращает SERVFAIL для распознавателя заглушки пользователя, преобразователь заглушки отправит тот же запрос следующему преобразователю в наборе локально настроенных преобразователей. Это будет продолжаться до тех пор, пока он не получит ответ не SERVFAIL или не исчерпает решающие устройства, чтобы попробовать.
• Когда обработчик заглушки пользователя передает запрос распознавателю в сконфигурированном наборе распознавателя, он получит согласованный ответ в течение периода времени запросов. Это предположение подразумевает, что если один и тот же запрос заглушки запрашивает один и тот же запрос несколько раз подряд одному и тому же рекурсивному распознавателю, ответ рекурсивного распознавателя будет одинаковым для каждого из этих запросов.
• Все проверяющие средства, проверяющие DNSSEC, имеют KSK-current в своем локальном кеше доверия.

В настоящее время нет опубликованных данных измерений, которые бы указывали, в какой степени действительны первые два предположения, перечисленные здесь, или на какое количество конечных пользователей могут повлиять эти предположения. В частности, первое предположение о том, что согласованный ответ SERVFAIL приведет к тому, что среда разрешения локальных заглушек DNS будет запрашивать все свои сконфигурированные рекурсивные преобразователи, прежде чем прийти к заключению, что имя не может быть разрешено, является критическим предположением для этого теста.

Обратите внимание, что дополнительная точность / детерминизм могут быть достигнуты путем обхода нормального поведения ОС и явного тестирования с использованием каждого сконфигурированного рекурсивного преобразователя (например, с использованием «копания»).

 

4.3. Тестовая процедура

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

• Имя запроса, подписанное подписью DNSSEC, которое не может быть проверено (описывается как «фиктивный» RRset в Разделе 5 [RFC4033], когда, например, RRset не подписан с действительной записью RRSIG).
• Имя запроса, содержащее крайнюю левую метку «root-key-sentinel-notta- <key-tag-of-KSK-current>». Это имя ДОЛЖНО быть действительным подписанным именем. Любая правильно подписанная DNS-зона может быть использована для этого теста.
• Имя запроса, содержащее крайнюю левую метку «root-key-sentinel-ista- <key-tag-of-KSK-new>». Это имя ДОЛЖНО быть действительным подписанным именем. Любая правильно подписанная DNS-зона может быть использована для этого теста.

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

Ответы на эти запросы описаны в упрощенной записи. Каждый запрос будет приводить либо к ответу SERVFAIL (обозначен «S»), что указывает на то, что все распознаватели в наборе рекурсивных распознавателей вернули код ответа SERVFAIL, либо к ответу с требуемым значением RRset (обозначен «A»). Запросы упорядочены по «недопустимому» имени, метке «root-key-sentinel-not-ta», затем метке «root-key-sentinel-is-ta», а триплетная нотация обозначает конкретный ответ. Например, триплет «(SSA)» обозначает ответ SERVFAIL на недопустимый запрос, ответ SERVFAIL на запрос «root-key-sentinel-not-ta» и ответ RRset на «rootkey-sentinel-is-ta»запрос.

Набор всех возможных ответов на эти три запроса:

(A * *): Если какой-либо распознаватель возвращает ответ «A» для запроса недопустимого имени, тогда в наборе распознавателя содержится хотя бы один не проверяющий преобразователь DNS, и при проверке KSK на пользователя не повлияет.

(SA *): Если какой-либо из распознавателей возвращает ответ «A» для запроса «root-key-sentinel-not-ta», то по крайней мере один из распознавателей не распознает механизм дозорного и поведение коллекция резольверов во время крена KSK не может быть надежно определена.

(S S A): Этот случай подразумевает, что все распознаватели в наборе выполняют проверку DNSSEC, все распознаватели осведомлены о механизме стража, и по крайней мере один распознаватель загрузил KSK-new как локальную привязку доверия. Ролл KSK не повлияет на пользователя.

(S S S): Этот случай подразумевает, что все распознаватели в наборе выполняют проверку DNSSEC, все распознаватели осведомлены о механизме стража, и ни один из распознавателей не загрузил KSK-new в качестве локальной привязки доверия. Ролл KSK негативно отразится на пользователе.

 

5. Вопросы безопасности

В этом документе описан механизм, позволяющий пользователям определять состояние привязки доверия ключей подписи ключей корневой зоны в используемой ими системе разрешения DNS. Если пользователь выполняет сторонний код, то эта информация также может быть доступна третьей стороне.

Механизм не требует, чтобы распознаватели устанавливали иначе аутентифицированные ответы, помеченные как аутентифицированные, и не изменяет свойства безопасности DNSSEC в отношении интерпретации аутентичности ответов, которые помечены таким образом.

Механизм не требует какой-либо дальнейшей значительной обработки ответов DNS, а запросы в форме, описанной в этом документе, не создают никакой дополнительной нагрузки, которая может быть использована при атаке по сравнению с обычной нагрузкой обработки проверки DNSSEC.

 

6. Вопросы конфиденциальности

Механизм в этом документе позволяет третьим сторонам (с добрыми или плохими намерениями) узнать что-то о конфигурации безопасности рекурсивных преобразователей DNS. То есть тот, кто может заставить пользователя Интернета делать конкретные запросы DNS (например, посредством рекламы на веб-сайте или JavaScript на веб-страницах), может при определенных конкретных обстоятельствах, которые включают в себя дополнительные знания о средствах разрешения, которые вызываются пользователем, определить, какое доверие якоря настроены в этих резольверах. Без этих дополнительных знаний третья сторона может определить совокупные возможности среды разрешения DNS пользователя, но не может обязательно определить конфигурацию доверия любого рекурсивного сервера имен.

7. Соображения IANA

В этом документе нет действий IANA.

8. Ссылки

8.1. Нормативные ссылки

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC2308] Andrews, M., «Negative Caching of DNS Queries (DNS NCACHE)», RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/info/rfc2308>.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Resource Records for the DNS Security Extensions», RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Protocol Modifications for the DNS Security Extensions», RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.

[RFC5011] StJohns, M., «Automated Updates of DNS Security (DNSSEC) Trust Anchors», STD 74, RFC 5011, DOI 10.17487/RFC5011,
September 2007, <https://www.rfc-editor.org/info/rfc5011>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2. Информационные ссылки

[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, «DNS Terminology», RFC 7719, DOI 10.17487/RFC7719, December
2015, <https://www.rfc-editor.org/info/rfc7719>.

[RFC8145] Wessels, D., Kumari, W., and P. Hoffman, «Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)», RFC 8145, DOI 10.17487/RFC8145, April 2017,
<https://www.rfc-editor.org/info/rfc8145>.

Приложение А. Пример прохождения протокола

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

Алиса отвечает за корневой DNS-ключ KSK (Key Signing Key) и хотела бы свернуть / заменить ключ новым. Она публикует новый KSK, но хотела бы иметь возможность предсказать / измерить, как это повлияет, до удаления / отзыва старого ключа. Текущий KSK имеет ключевую метку 11112; новый KSK имеет ключевую метку 02323. Пользователи хотят убедиться, что их распознаватель не сломается после того, как Алиса свернет корневой KSK (то есть начинает подписывать только с KSK, ключевая метка которого 02323).

Боб, Чарли, Дейв и Эд — все пользователи. Они используют рекурсивные преобразователи DNS, предоставляемые их провайдерами. Они хотели бы подтвердить, что их интернет-провайдеры подобрали новый KSK. Интернет-провайдер Боба не выполняет проверку. Интернет-провайдер Чарли проверяет, но преобразователи еще не были обновлены для поддержки этого механизма. Резольверы Дейва и Эда были обновлены для поддержки этого механизма; У резольвера Дейва новый KSK, но резольверу Эда пока не удалось установить KSK 02323 в хранилище доверенных сертификатов.

Джефф — исследователь. Он хотел бы предоставить Бобу, Чарли, Дейву и Эду средства для выполнения тестов, а также самому провести измерения в Интернете, чтобы выяснить, как это повлияет (и сообщить об этом Алисе).

Джефф устанавливает официальный DNS-сервер для example.com, а также веб-сервер (www.example.com). Он добавляет три адресные записи на example.com:

bogus.example.com. IN AAAA 2001:db8::1
root-key-sentinel-is-ta-02323.example.com. IN AAAA 2001:db8::1
root-key-sentinel-not-ta-11112.example.com. IN AAAA 2001:db8::1

Обратите внимание, что использование имен «example.com» и адресов здесь являются примерами, и «фиктивный» преднамеренно имеет недопустимые подписи DNSSEC. В реальном развертывании доменные имена должны находиться под контролем исследователя, а адреса должны быть реальными, достижимыми адресами.

Джефф затем DNSSEC подписывает зону example.com и намеренно делает запись bogus.example.com фиктивным статусом проверки (например, путем редактирования подписанной зоны и ввода мусора для подписи). Джефф также настраивает свой веб-сервер на прослушивание 2001: db8 :: 1 и обслуживание ресурса (например, 1×1 GIF, 1×1.gif) для всех этих имен. Веб-сервер также обслуживает веб-страницу (www.example.com), которая содержит ссылки на эти три ресурса (http://bogus.example.com/1×1.gif, http: // root-key-sentinel-is-ta -02323.example.com/1×1.gif и http://root-key-sentinel-not-ta-11112.example.com/1×1.gif).

Затем Джефф просит Боба, Чарли, Дейва и Эда зайти на сайт www.example.com. Используя методы, описанные в этом документе, пользователи могут выяснить, какой будет их судьба после удаления 11112 KSK.

Боб не использует проверяющий распознаватель. Это означает, что он сможет разрешить bogus.example.com (и получить GIF 1×1); это говорит ему, что бросок КСК не влияет на него, и поэтому он будет в порядке.

Решающие устройства Чарли проходят валидацию, но они не были обновлены для поддержки сторожевого механизма KSK. Чарли не сможет получить ресурс http://bogus.example.com/1×1.gif (запись bogus.example.com является фиктивной, и ни один из его преобразователей не разрешит ее). Он может получить оба других ресурса; Исходя из этого, он знает (см. логику в этом документе), что он использует проверяющие распознаватели, но по крайней мере один из этих распознавателей не настроен для выполнения дозорной обработки. Дозорный метод KSK не может дать ему однозначного ответа на вопрос, повлияет ли он на бросок KSK.

Резольверы Дейва реализуют дозорный метод и подобрали новый KSK. По той же причине, что и Чарли, он не может получить «фальшивый» ресурс. Его распознаватель разрешает имя root-key-sentinel-is-ta-02323.example.com в обычном режиме (он связывается с официальными серверами example.com и т. Д.); поскольку он поддерживает механизм дозорного, непосредственно перед тем, как рекурсивный распознаватель Дейва отправляет ответ заглушке Дейва, он выполняет проверку дозорного KSK. QNAME начинается с «root-keysentinel-is-ta-», и рекурсивный распознаватель действительно имеет ключ с тегом ключа 02323 в своем корневом хранилище доверия. Это означает, что эта часть контрольной проверки KSK проходит (верно, что ключевой тег 02323 находится в хранилище привязки доверия), и рекурсивный распознаватель отвечает нормально (с ответом, предоставленным уполномоченным сервером). Рекурсивный распознаватель Дейва затем разрешает имя root-keysentinel-not-ta-11112.example.com. Еще раз, он выполняет нормальный процесс разрешения, но, поскольку он реализует сторож KSK (а QNAME начинается с «root-key-sentinel-not-ta-»), непосредственно перед отправкой ответа он выполняет сторожевую проверку KSK. Поскольку у него есть ключ с меткой ключа 11112 в его хранилище привязки доверия, ответ «является ли это * не * привязкой доверия» ложен, и поэтому рекурсивный распознаватель не отвечает с ответом от авторитетного сервера. Вместо этого он отвечает с помощью SERVFAIL (обратите внимание, что ответ с помощью SERVFAIL вместо исходного ответа является единственным механизмом, который использует KSK Sentinel). Это означает, что Дейв не может получить «фальшивый», он может получить «root-key-sentinel-is-ta-02323», но он не может получить «root-keysentinel-not-ta-11112». Исходя из этого, Дейв знает, что он стоит за набором распознавателей, которые все проверяют, у всех есть ключ с тегом Key Key 11112, и по крайней мере один из этих распознавателей загрузил ключ с тегом Key 02323 в свой локальный кэш привязки доверия. Дейв не будет затронут броском KSK.

Так же, как Чарли и Дейв, Эд не может получить «фальшивую» запись. Это говорит ему, что его резольверы проверяются. Когда его (sentinelaware) распознаватели выполняют контрольную проверку KSK на наличие «root-keysentinel-is-ta-02323», ни один из них не загрузил новый ключ с тегом ключа 02323 в свое локальное хранилище доверенных привязок. Это означает, что проверка не пройдена, и рекурсивный распознаватель Эда преобразует (действительный) ответ в ответ об ошибке SERVFAIL. Он выполняет ту же проверку для root-keysentinel-not-ta-11112.example.com, и, поскольку все распознаватели Эда выполняют проверку DNSSEC и распознают метку стража, Эд не сможет извлечь «root-key-sentinel-». не-та-11112 «ресурс. Это говорит Эду, что его распознаватели не установили новый KSK, и он будет негативно затронут броском KSK.

Джефф хотел бы провести масштабное тестирование и предоставить информацию Алисе. Он использует какой-то механизм, например, заставляет пользователей переходить на веб-страницу, чтобы заставить большое количество пользователей пытаться разрешить три ресурса, а затем анализирует результаты тестов, чтобы определить, какой процент пользователей будет затронут KSK. событие опрокидывания.

Это описание является упрощенным примером. Не ожидается, что Боб, Чарли, Дейв и Эд действительно будут искать отсутствие или присутствие веб-ресурсов; вместо этого загружаемая веб-страница, скорее всего, будет содержать JavaScript (или аналогичный), который отображает результаты тестов, отправляет результаты Geoff или и то, и другое. Этот дозорный механизм не полагается на Интернет: его также можно использовать, пытаясь разрешить имена (например, с помощью общей команды «копать») и проверяя, какие имена приводят к SERVFAIL.

Благодарности

Этот документ широко заимствован из [RFC8145] для вводного текста, и авторы хотели бы поблагодарить авторов этого документа и поблагодарить их за некоторые текстовые выдержки и за более общее стимулирование мыслей о мониторинге хода КСК корневой зоны DNS.

Авторы хотели бы поблагодарить Джо Эбли, Мехмета Акцина, Марка Эндрюса, Ричарда Барнса, Рэя Беллиса, Стефана Борцмейера, Дэвида Конрада, Ральфа Долманса, Джона Дикинсона, Стейнара Хауга, Боба Гарольда, Уэса Хардакера, Пола Хоффмана, Мэтта Ларсона, Джинмея Татуя , Эдвард Льюис, Джордж Майклсон, Бенно Оверейндер, Мэтью Паунсетт, Уго Сальгадо-Эрнандес, Андреас Шульце, Мукунд Сивараман, Петр Спейсек, Джоб Снейдерс, Эндрю Салливан, Ондрей Сьюри, Пол Викси, Дуэйн Уэссельс и Пол Ваутерс за полезную обратную связь.

Авторы хотели бы особенно призвать Пола Хоффмана и Дуэйна Уэсселса за предоставление комментариев в форме запросов на извлечение. Джо Абли также услужливо предоставил обширный обзор и старый / новый текст.

Петр Спейсек написал несколько очень ранних реализаций и предоставил значительную обратную связь, в том числе указав, что тестовый стенд не соответствует документу!

Адреса авторов

Geoff Huston
Email: gih@apnic.net
URI: http://www.apnic.net

Joao Silva Damas
Email: joao@apnic.net
URI: http://www.apnic.net

Warren Kumari
Email: warren@kumari.net