Данная публикация станет первой из серии публикуемых докладов о статусе проекта обновления ключа KSK. Мы намерены держать сообщество в курсе действий, предпринимаемых нами в рамках проекта обновления ключа.
27 сентября 2017 года корпорация ICANN объявила о переносе сроков обновления ключа KSK корневой зоны. Позже, 17 октября, мы опубликовали документ, озаглавленный Перенос обновления ключа KSK корневой зоны [PDF, 173 KB], в котором были приведены более подробные сведения о полученной нами в отношении конфигурации некоторых распознавателей информации, повлиявшей на наш анализ и аргументацию, которые легли в основу решения о переносе сроков.
Как описывалось в этом документе [PDF, 173 KB], в последних версиях рекурсивных распознавателей BIND и Unbound реализован протокол, определенный в стандарте RFC 8145 [TXT, 27 KB], Передача сигналов с информацией о якоре доверия в расширениях безопасности DNS (DNSSEC), который позволяет распознавателю сообщать конфигурацию своего якоря доверия. Поддерживающие эту возможность распознаватели передают свои настройки якорей доверия корневой зоны на серверы имен корневой зоны. Анализ таких передаваемых данных о якорях доверия, проведенный в недели, предшествующие ранее намеченной дате обновления ключа 11 октября 2017 года, вызвал опасения в отношении того, что количество распознавателей, не настроенных на использование ключа KSK-2017 (принятое у нас обозначение нового ключа для подписания ключей корневой зоны) в качестве якоря доверия, может оказать большим, чем ранее предполагалось. Такие распознаватели после обновления ключа окажутся неспособными выдавать ответы на запросы DNS.
Исследовательская группа в офисе технического директора (OCTO) проанализировала трафик, поступавший на корневые серверы B, D, F и L в течение всего сентября 2017 года, и обнаружила 11 982 уникальных IP-адреса (8908 адресов протокола IPv4 и 3078 адресов протокола IPv6), с которых отправлялась информация о конфигурации якоря доверия. Из них 620 адресов сообщали о конфигурации, поддерживающей только ключ KSK-2010 (сокращение, обозначающее текущий ключ для подписания ключей корневой зоны). После дальнейшего анализа нам удалось устранить некоторые ложные включения: IP-адреса, которые по тем или иным причинам не представляли рекурсивные распознаватели, выполняющие проверку DNSSEC. Мы уменьшили этот список до 500 адресов потенциально неправильно настроенных рекурсивных распознавателей, с операторами которых мы хотели бы связаться. У нас есть две основные причины, по которым мы хотим с ними связаться: чтобы понять, по какой причине их распознаватель сообщает о том, что в его конфигурации настроено использование только ключа KSK-2010, а также, если это возможно, помочь им исправить конфигурацию и обеспечить готовность к обновлению ключа.
Изначально мы планировали опубликовать такой список адресов, чтобы привлечь помощь со стороны сообщества. После дальнейшего размышления мы поняли, что такой список может быть ошибочно истолкован как намерение публично пристыдить операторов систем с неправильной конфигурацией, что вовсе не входило в наши намерения. Мы решили сначала попытаться самим связаться с администраторами. В зависимости от результатов нам может понадобиться опубликовать список адресов распознавателей, с администраторами которых у нас не получится связаться.
Согласно упомянутым выше данным за сентябрь, 4,1% IP-адресов сообщают об использовании только ключа KSK-2010. (Фактическая доля распознавателей в Интернете, использующих только ключ KSK-2010, может оказаться еще большей, поскольку только очень небольшое их количество в настоящее время сообщают свою конфигурацию использования якоря доверия.) Мы хотим разобраться в этом и внести необходимые корректировки, чтобы значительно уменьшить это количество. Поскольку мы не знаем, со сколькими администраторами нам удастся связаться, мы пока не хотим намечать целевое значение процентной доли.
Важно отметить, что это значение отражает долю распознавателей, а не конечных пользователей, а наиболее важным соображением являются как раз последствия для конечных пользователей. В критериях отмены обновления ключа, приведенных в опубликованном плане работ [PDF, 741 KB] на случай возникновения проблем, упоминаются последствия для конечных пользователей:
ICANN рассмотрит возможность отмены любого их этапов процедуры обновления ключа, если измерительная программа укажет на то, что значительное количество конечных пользователей Интернета столкнулось с отрицательными последствиями изменений в течение 72 часов после развертывания каждого из изменений в корневой зоне.
Эти критерии были сформулированы отчасти исходя из рекомендаций проектной группы по обновлению ключа для подписания ключей корневой зоны, которая была сформирована ICANN для помощи в планировании обновления ключа и отчет [PDF, 1.2 MB] которой содержит следующую рекомендацию, также посвященную конечным пользователям:
Рекомендация 16. Отмена любого их этапов процедуры обновления ключа должна быть инициирована в том случае, если измерительная программа укажет на то, что не менее 0,5% от оцениваемого количества конечных пользователей Интернета столкнулось с отрицательными последствиями изменений в течение 72 часов после развертывания каждого из изменений в корневой зоне.
