Skip to main content
Resources

Обновление валидирующих резолверов DNS с установкой последней версии якоря доверия

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

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

Эта страница предназначена для администраторов резолверов DNS (которые иногда также называют «рекурсивными резолверами»). Информация на этой странице будет полезна, если:

  • операторы резолверов выясняют, что у них не установлен новый KSK
  • резолверы после обновления KSK выдают ошибку на все запросы DNS

Эти инструкции скорее всего предполагают переход к использованию последней версии якоря доверия для валидации DNSSEC.

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

Для проверки выполнения валидации 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. В разделе options должна отображаться строка dnssec-validation auto; или dnssec-validation yes;. Если dnssec-validation настроена в режим auto, то ручное обновление программного обеспечения или конфигурации не требуется. Необходимо просто перезапустить программное обеспечение, используя привычную вам команду завершения работы и запуска BIND; это обеспечит активацию новейшей версии якорей доверия в dnssec-validation auto.

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

Если у вас есть возможность обновления программного обеспечения:

  1. Выполните обновление до новейшей подверсии BIND 9.9, BIND 9.10 или BIND 9.11 тем же способом, который вы использовали для установки программного обеспечения. Если на вашем оборудовании используется программное обеспечение BIND 9.8, поддержка которого уже прекращена, его необходимо обновить до версии BIND 9.9 или более поздней. Следует использовать подверсию не ранее:
    • BIND 9.9.10
    • BIND 9.10.5
    • BIND 9.11.1
  2. Обязательно удостоверьтесь, что раздел options в файле конфигурации содержит строку dnssec-validation auto;.
  3. Прекратите работу старой версии BIND и запустите новую версию, используя привычную вам команду завершения работы и запуска BIND.

Если у вас нет возможности обновления программного обеспечения:

  1. Обновите файл bind.keys, чтобы включить в него новый якорь доверия. Файл bind.keys должен храниться в том же каталоге, где создаются другие файлы BIND. Как вариант, если файл named.conf содержит раздел managed-keys, где перечислены якоря доверия, можно обновить этот раздел. Отредактированный файл или раздел конфигурации должны содержать следующее:

    managed-keys { 
    	. initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF 
    		FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX 
    		bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD 
    		X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz 
    		W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS 
    		Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq 
    		QxA+Uk1ihz0="; 
    
    	. initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 
    		+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv 
    		ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 
    		0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e 
    		oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd 
    		RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN 
    		R1AkUTV74bU="; 
    };
    

Если конфигурация dnssec-validation настроена на auto, то содержимое файла bind.keys будет объединено с содержимым блока managed-keys в конфигурации. Узнать об этом подробнее можно по ссылке https://www.isc.org/downloads/bind/bind-keys/.

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


Unbound

Во всех версиях Unbound до 1.6.5, однако, действует ограничение, не позволяющее им принимать новый якорь доверия, если первый запуск версии выполнен за 30 дней или меньше до обновления ключа.

Если вы используете версию Unbound 1.6.5 или более позднюю:

  1. Удалите текущие якоря доверия, используя:

    rm root.key
  2. Получите новейшую версию якорей доверия, используя:

    unbound-anchor
  3. Перезапустите Unbound, чтобы выполнить повторную загрузку новой конфигурации, используя привычную вам команду запуска Unbound.

Если вы используете версию 1.6.4 или более раннюю, вы можете обновить программное обеспечение:

  1. Обновить Unbound до версии 1.6.5 или более поздней.

  2. Удалите текущие якоря доверия, используя:

    rm root.key
  3. Получите новейшую версию якорей доверия, используя:

    unbound-anchor
  4. Перезапустите новую версию Unbound, чтобы выполнить повторную загрузку новой конфигурации, используя привычную вам команду запуска Unbound.

Если вы используете Unbound версии 1.6.4 или более ранней, при этом один из ключей в файле root.key не указан как [ VALID ] и вы не можете обновить программное обеспечение:

  1. Способ получения нового файла root.key от NLnet Labs, в котором оба ключа настроены как [ VALID ] см. на странице https://www.unbound.net/root-11sep-11oct.html.
  2. Перезапустите Unbound, чтобы выполнить повторную загрузку новой конфигурации, используя привычную вам команду запуска Unbound.

Рекурсор PowerDNS

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

Если у вас есть возможность обновления программного обеспечения:

  1. Выполните обновление до новейшей подверсии рекурсора PowerDNS тем же способом, который вы использовали для установки программного обеспечения. Убедитесь, что получена версия 4.0.5 или более поздняя.
  2. Выполните выход из текущей версии PowerDNS и запустите новую версию, используя привычную вам команду завершения работы и запуска сервера.

Если у вас нет возможности обновления программного обеспечения:

  1. Если строка lua-config-file в главной конфигурации вашего PowerDNS отсутствует, вам необходимо добавить ее. Строка указывает на файл, который содержит дополнительную конфигурацию PowerDNS. Эта строка может выглядеть так:

    lua-config-file=/etc/pdns/luaconf.txt
  2. В файл, на который указывает строка lua-config-file, добавьте такие две строки:

    addDS('.', "19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5")
    addDS('.', "20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D")
    
  3. Перезапустите рекурсор PowerDNS, используя привычную вам команду завершения работы и запуска сервера.


Резолвер Knot

Резолвер Knot поддерживает валидацию DNSSEC путем автоматического обновления RFC 5011 во всех версиях. Для получения новейшей версии якорей доверия можно удалить текущую версию файла с ключами и повторно запустить резолвер Knot. Соответственно, обновлять версию резолвера Knot не требуется; необходимо просто получить новейшие якоря доверия и перезапустить резолвер Knot.

  1. Удостоверьтесь, что файл конфигурации содержит такую строку:

    trust_anchors.file = 'root.keys'
  2. Если этот файл не содержит строку со значениями 19036 и 20326, прекратите работу сервера, используя привычный способ, удалите файл root.keys и снова запустите сервер. Это заставит резолвер Knot повторно создать файл с новейшими якорями доверия от IANA.


Windows Server 2012R2 и 2016

Windows Server версий 2012R2 и 2016 поддерживает валидацию DNSSEC путем автоматического обновления RFC 5011. Для получения новейшей версии якорей доверия можно обновить текущую версию файла и повторно запустить Windows Server. Указанные команды вводятся через Windows PowerShell.

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

Get-DnsServerTrustPoint

Будет показано:

TrustPointName   TrustPointState   LastActiveRefreshTime   NextActiveRefreshTime
--------------   ---------------   ---------------------   ---------------------
.                Active            9/11/2017 7:45:03 PM    9/12/2017 7:45:03 PM

Время указано в формате UTC. Если надлежащего обновления якоря доверия не происходит, его можно заменить при помощи:

Add-DnsServerTrustAnchor -Root

Добавив якорь доверия, вы должны увидеть обновленное значение LastActiveRefreshTime в графе результатов команды Get-DnsServerTrustPoint.

Примечание: Если использование Add-DnsServerTrustAnchor -Root неэффективно, убедитесь, что на сервере включены DNSSEC. Используйте три команды:

$a = Get-DnsServerSetting -All $a.EnableDnsSec = 1 $a | Set-DnsServerSetting

Вы можете удостовериться, что RootTrustAnchorsURL указывает на https://data.iana.org/root-anchors/root-anchors.xml при помощи команды:

(Get-DnsServerSetting -All).RootTrustAnchorsURL

Если команда Add-DnsServerTrustAnchor -Root по-прежнему не срабатывает, возможно, передача блокируется брандмауэром. Такое может случаться в некоторых средах с высокой степенью защиты. Чтобы вручную добавить якорь доверия DS, необходимо знать выборку, алгоритм и метку ключа. Чтобы добавить якорь доверия DNSKEY, понадобится открытый DNSKEY (Base64Data). Как вариант, если у вас есть доступ к файлу набора ключей (для якоря DNSKEY) или DSSET (для якоря DS), можно импортировать якорь доверия. Выборку, алгоритм (тип выборки) и метку ключа для корневого якоря доверия можно просмотреть по ссылке https://data.iana.org/root-anchors/root-anchors.xml .

С помощью указанных далее команд можно вручную добавить якорь доверия DS в корневую зону.

Add-DnsServerTrustAnchor -Name "." -CryptoAlgorithm RSASHA256 -Digest 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 -DigestType SHA256 -KeyTag 19036 -ComputerName localhost -PassThru

Add-DnsServerTrustAnchor -Name "." -CryptoAlgorithm RSASHA256 -Digest E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D -DigestType SHA256 -KeyTag 20326 -ComputerName localhost -PassThru

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

Clear-DnsServerCache -Force

С более подробной информацией от Microsoft можно ознакомиться по ссылке https://technet.microsoft.com/en-us/itpro/powershell/windows/dnsserver/add-dnsservertrustanchor.


Akamai DNSi Cacheserve

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

Если у вас есть возможность обновления программного обеспечения:

  1. Самым простым способом получения новейшего корневого ключа DNSSEC  будет использование управляемых ключей и обновление версии Akamai DNSi Cacheserve:

    • 7.1.2.3
    • 7.2.0.3
    • 7.2.1.2

    или более поздней версии на соответствующих линиях оборудования, где уже встроен новый работающий корневой ключ.

Если у вас нет возможности обновления программного обеспечения:

  1. См. информацию по ссылке https://support.nominum.com/view-article/965 или обратитесь в Akamai по ссылке https://support.nominum.com/.

Infoblox NIOS

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

Добавление нового ключа для подписания ключей корневой зоны в качестве якоря доверия в NIOS происходит следующим образом:

  1. Войдите в графический интерфейс пользователя NIOS
  2. Перейдите в Data Management → DNS
  3. Нажмите на «Grid DNS Properties» на панели инструментов
  4. Включите режим «Advanced Mode»
  5. Выберите вкладку «DNSSEC»
  6. Прокрутите до «Trust Anchors»
  7. Нажмите кнопку «Add» и введите данные ключа. В качестве зоны укажите «.», а в качестве алгоритма «RSA/SHA-256(8)».
  8. Вставьте скопированный ключ в столбец «Public Key». Открытый ключ:
    AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 
    +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv 
    ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 
    0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e 
    oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd 
    RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN 
    R1AkUTV74bU=
    

В случае добавления на уровне отдельного члена:

  1. Войдите в графический интерфейс пользователя NIOS
  2. Перейдите в Data Management → DNS → Members/Servers
  3. Выберите сервер DNS
  4. Нажмите «Edit»
  5. Включите режим «Advanced Mode»
  6. Выберите «DNSSEC»
  7. Прокрутите до «Trust Anchors»
  8. Нажмите кнопку «Add» и введите данные ключа. В качестве зоны укажите «.», а в качестве алгоритма «RSA/SHA-256(8)».
  9. Вставьте скопированный ключ в столбец «Public Key». Открытый ключ:
    AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 
    +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv 
    ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 
    0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e 
    oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd 
    RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN 
    R1AkUTV74bU=
    
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."