Skip to main content
Resources

Проверка действующих якорей доверия в валидирующих резолверах DNS

Страница также доступна на следующих языках:

Настоящий документ был переведен на несколько языков только для информационных целей. Оригинал и аутентичный текст документа (на английском языке) находится по адресу: https://www.icann.org/dns-resolvers-checking-current-trust-anchors

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

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

Приведенная здесь информация полезна только в том случае, если ваш DNS-резолвер валидирует DNSSEC. ICANN рекомендует валидировать DNSSEC во всех случаях, когда это уместно, но если вы еще не выполняли валидацию DNSSEC, приведенные здесь инструкции не пригодятся.

Чтобы проверить, выполняет ли ваш резолвер валидацию DNSSEC, можно воспользоваться специальным доменом «dnssec-failed.org», который работает как публичная служба Comcast. Данный специальный домен намеренно вызывает отказ валидирующих резолверов дать ответ. Задайте следующую команду в командной строке интерфейса:

dig @ADDRESS dnssec-failed.org a +dnssec

В данной команде замените строку ADDRESS на адрес IPv4 или IPv6 вашего резолвера.

Если ответ содержит следующее:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL

то резолвер выполняет валидацию DNSSEC. (Индикация состояния SERVFAIL указывает на то, что валидация не выполнена, а значит, валидация действительно выполняется.)

Однако если ответ содержит следующее:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR

то резолвер не выполняет валидацию DNSSEC.

Далее на странице перечислены различные релизы резолвера и инструкции по проверке их якорей доверия.


BIND

Релиз BIND версии 9.9, 9.10, и 9.11 поддерживает валидацию DNSSEC, используя автоматическое обновление RFC 5011. Последние обновления этих версий поставляются совместно с KSK2017 в составе якорей доверия.

Сначала убедитесь, что валидация DNSSEC включена в файл конфигурации. В разделе параметры должна отображаться строка со значением dnssec-validation auto; или dnssec-validation yes;. Если в вашей конфигурации отображается значение dnssec-validation yes;, вы должны поменять его на значение dnssec-validation auto; и перезагрузить сервер, прежде чем перейти к выполнению следующих шагов.

Чтобы сгенерировать файл, содержащий используемые якори доверия, задайте команду

rndc secroots

Эта команда создает файл с именем named.secroots в том же каталоге, где создаются другие файлы BIND. Этот файл должен содержать две строки, одна из которых имеет значение ./RSASHA256/20326 а другая — ./RSASHA256/19036. Если этих ключей нет, необходимо обновить якори доверия в соответствии с приведенной здесь инструкцией.

Разработчики BIND, компания ISC, разместили дополнительную информацию о якорях доверия DNSSEC для BIND по адресу https://kb.isc.org/article/AA-01529/169/KSK-2010-Rollover.html [kb.isc.org].


Unbound

Откройте файл root.key, расположенный в каталоге Unbound, обычно с адресом /etc/unbound. Он должен содержать записи DNSKEY с текстом id = 20326, а также другие, с текстом id = 19036; обе записи должны иметь значение ;;state=2 [ VALID ].

Если вы используете Unbound версии 1.6.2 или более поздней, вы также можете получить список доверенных ключей, запросив резолвер для имени trustanchor.unbound в классе CH для ресурсов с типом TXT, например, с помощью команды:

dig @address trustanchor.unbound -c CH -t TXT

Если файл не содержит этих ключей или если в одном из ключей отсутствует значение ;;state=2 [ VALID ], или если в запросе не указаны оба ключа, необходимо обновить якори доверия в соответствии с приведенной здесь инструкцией.


PowerDNS Recursor

PowerDNS Recursor версии 4 поддерживает валидацию DNSSEC, но еще не поддерживает валидацию DNSSEC с автоматическим обновлением RFC 5011. Это означает, что для PowerDNS Recursor вам необходимо получать новый набор якорей доверия при выходе любых изменений для якорей доверия. Версия 4.0.5 и более поздние версии PowerDNS Recursor поставляются с KSK2017 в составе установленных якорей доверия.

Задайте следующую команду в командной строке:

rec_control get-tas

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


Knot Resolver

Knot Resolver поддерживает проверку DNSSEC с автоматическим обновлением RFC 5011 во всех версиях.

Откройте файл root.keys в каталоге конфигурации Knot Resolver (в зависимости от сборки). В нем должно быть две строки, одна из которых содержит текст 0101030803010001A80020A95566BA42E886BB804CDA84E47EF56DB, а другая — 0101030803010001ACFFB409BCC939F831F7A1E5EC88F7A59255EC5. Если этих ключей нет, необходимо обновить якори доверия в соответствии с приведенной здесь инструкцией.


Windows Server 2012R2 и 2016

Обе описываемые версии Windows Server поддерживают валидацию DNSSEC с помощью автоматического RFC 5011. Приведенные ниже команды вводятся в оболочку командной строки Windows PowerShell.

Чтобы проверить содержимое якорей доверия, введите:

Get-DnsServerTrustAnchor -Name .

Вы должны увидеть следующее:

TrustAnchorName TrustAnchorType TrustAnchorState TrustAnchorData
--------------- --------------- ---------------- ---------------
. 		DNSKEY 		Valid 		 [19036][DnsSec][RsaSha256][AwEAAagAIKlVZrpC6Ia7...
. 		DNSKEY 		Valid 		 [20326][DnsSec][RsaSha256][AwEAAaz/tAm8yTn4Mfeh...

Признаки ключа отображаются под TrustAnchorData. Для корневого якоря доверия вы увидите два признака ключа: 19036 и 20326. Оба якоря доверия должны должны находиться в состоянии, обозначенном как «Valid». Если этих ключей нет, необходимо обновить якори доверия в соответствии с приведенной здесь инструкцией.

Чтобы просмотреть все текущие активные на сервере точки доверия, используйте команду:

Get-DnsServerTrustPoint

Она отобразит следующее:

TrustPointName 	TrustPointState LastActiveRefreshTime 	NextActiveRefreshTime
-------------- 	--------------- --------------------- 	---------------------
.		Active		9/11/2017 8:37:02 PM	9/12/2017 8:37:02 PM

Akamai DNSi Cacheserve

Akamai DNSi Cacheserve (версии 7.1.2.3, 7.2.0.3, 7.2.1.2 или более поздние) поддерживает проверку DNSSEC с использованием управляемых ключей RFC5011. Эта возможность существует и в более старых версиях, однако ее нельзя было использовать, поскольку возникла проблема с кодом обновления ключа. Чтобы проверить, действительно ли Akamai DNSi Cacheerve выполняет проверку, задайте следующую команду:

nom-tell cacheserve resolver.mget fields='(trusted-keys managed-keys-state)'

Если поля появляются trusted-keys или managed-keys-state, значит Akamai DNSi Cacheserve действительно выполняет валидацию DNSSEC, в этом случае необходимо убедиться, что используются правильные ключи. В поле managed-keys-state для корня ('.') вы увидите keyid со значением 19036 и 20326, для обоих состояние state должно быть в значении valid, а в поле has-validated должно отображаться значение True. Для доверенных ключей необходимо сравнить информацию действительных ключей. Чтобы это сделать или чтобы исправить ключи, если они не соответствуют описанию, следуйте приведенным здесь указаниям.


Infoblox NIOS

Infobox NIOS поддерживает валидацию DNSSEC, но еще не поддерживает валидацию DNSSEC с помощью автоматического обновления RFC 5011. Это означает, что для Infoblox NIOS необходимо настраивать новый набор якорей доверия при выходе любых изменений для якорей доверия.

Проверка текущих якорей доверия для NIOS включает следующие шаги:

  1. Войдите в NIOS GUI
  2. Перейдите в Data Management → DNS
  3. Нажмите на «Grid DNS Properties» на панели инструментов
  4. Включите «Advanced Mode»
  5. Выберите вкладку «DNSSEC»
  6. Прокрутите вниз до «Trust Anchors»
  7. Все настроенные якори доверия отобразятся в таблице «Trust Anchors». Найдите запись с параметром "." в столбце «Zone» и в столбце «Secure Entry Point». (Если данный якорь доверия отсутствует, ключ для подписания ключей корневой зоны не настроен.) Наведите указатель мыши на значение в столбце «Public Key», чтобы увидеть полное значение.

Для проверки на уровне участника:

  1. Войдите в NIOS GUI
  2. Перейдите в Data Management → DNS → Members/Servers
  3. Выберите сервер DNS
  4. Нажмите «Edit»
  5. Включите «Advanced Mode»
  6. Выберите «DNSSEC»
  7. Прокрутите вниз до «Trust Anchors»
  8. Все настроенные якори доверия отобразятся в таблице «Trust Anchors». Найдите запись с параметром "." в столбце «Zone» и в столбце «Secure Entry Point». (Если данный якорь доверия отсутствует, ключ для подписания ключей корневой зоны не настроен.) Наведите указатель мыши на значение в столбце «Public Key», чтобы увидеть полное значение.

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

AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0Ezr
AcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf
5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMj
JPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmR
LKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=

Ключ для подписания ключей новой корневой зоны (текущий) будет выглядеть так:

AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOL
AJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3Eg
VLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWe
L3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555Kr
UB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."