Skip to main content

Почему ICANN решила отложить обновление ключа KSK

Большинству уже известно, что ICANN объявила о своем решении отложить замену криптографического ключа, способствующего защите системы доменных имен (DNS). Первоначально планировалось осуществить эту замену или обновление 11 октября.

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

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

«Система передачи данных об известных якорях доверия в составе расширений безопасности DNS (DNSSEC)» (которая определена в документе RFC 8145) — это недавно разработанное расширение протокола, позволяющее валидатору передать DNS-серверам зоны данные о том, какие якори доверия у него настроены для этой зоны.

Работа над указанным протоколом завершилась только в апреле 2017 года, при этом он поддерживается только самыми последними версиями некоторого широко используемого программного обеспечения валидаторов (BIND 9.10.5b1 и 9.11.0b3 и более поздние версии, Unbound 1.6.4 и более поздние версии). Первоначально не ожидалось, что этот протокол будет внедрен достаточно широко, чтобы дать полезную информацию для первого обновления ключа KSK корневой зоны.

Однако во время исследований на самом начальном этапе (выполненных Verisign и впоследствии ICANN) был выявлен рост количества валидаторов, передающих корневым серверам данные о настройках якорей доверия. Полученные по адресам шести корневых серверов данные свидетельствуют о том, что в сентябре 2017 года примерно с 12 000 уникальных IP-адресов источников были переданы отчеты о настройках якорей доверия. Число таких отчетов растет и сейчас приближается к 1 400 уникальных адресов в день.

Поступающие отчеты указывают на то, что приблизительно в 5% от общего количества валидаторов и примерно в 6%–8% отчетов за любой конкретный день используется KSK-2010, то есть KSK корневой зоны, который применяется для подписания DNSKEY RRset корневой зоны в настоящее время. Важно отметить, что эти валидаторы не смогли бы правильно выполнять преобразование после планируемого обновления ключа KSK корневой зоны.

На основании этой новой информации мы решили отложить обновление ключа KSK корневой зоны по крайней мере на один квартал.

В течение всего проекта мы подчеркивали, что обновление ключа KSK корневой зоны происходит в нормальных рабочих условиях, и действовали осмотрительно и без спешки. Решение отложить обновление принято в соответствии с этим принципом осмотрительности, так как отсутствует оперативная необходимость продвигаться вперед, учтивая сохранение уверенности в том, что используемый сейчас ключ — KSK-2010 — обеспечивает безопасность.

Валидатор может сообщать об использовании только KSK-2010 по ряду причин: старая конфигурация со статичной настройкой якоря доверия (например, инструкция «trusted-key» в BIND) или невозможность автоматического обновления якоря доверия с использованием протокола автоматизированного обновления RFC 5011 из-за ошибки в программного обеспечении, ошибка оператора или другая причина.

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

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

Comments

    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."