ICANN опубликовала подробное руководство о том, чего следует ожидать во время обновления KSK в корневой зоне

https://www.icann.org/en/system/files/files/ksk-rollover-expect-22aug18-en.pdf
  • Перевод


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

Ссылка на текст новости от ICANN.

Смена ключей, процесс, известный под названием «обновление ключа для подписания ключей (KSK)», назначена на 11 октября 2018 года.

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

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

Полный текст руководства доступен здесь.

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

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

Хотя корпорация ICANN предполагает, что последствия смены KSK в корневой зоне для пользователей будут минимальные, ожидается, что небольшой процент интернет-пользователей испытает сложности при разрешении доменных имен, что на не техническом языке значит, что у них возникнут проблемы с достижением онлайн-пункта назначения.

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

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

Краткая сводка:

На ком обновление не отразится:

  • На пользователях, которые зависят от резолвера с последним KSK
  • На пользователях, которые зависят от резолвера, в котором не включена DNSSEC-валидация

На ком обновление отразится и каким образом:
Если в конфигурации якоря доверия резолвера не указан новый KSK, то в течение 48 часов после завершения обновления ключа пользователи начнут получать сообщения о невозможности разрешить имя (обычно в форме ошибок типа «server failure» или SERVFAIL).

ПРИМЕЧАНИЕ: Нет возможности предсказать, когда операторы резолверов, на которых отразится обновление заметят, что у них прекратилась валидация.

Результаты анализа позволяют заключить, что более 99% пользователей, чьи резолверы выполняют валидацию, от обновления KSK не пострадают.

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

И, наконец, хотя сейчас обновление ключа запланировано на 11 октября 2018 года, эта дата еще подлежит ратификации Правлением ICANN.

Информация обо всем, что связано с обновлением ключа доступна здесь.
  • +17
  • 5,9k
  • 2
Поделиться публикацией

Похожие публикации

Комментарии 2
    0

    О, только сегодня статью опубликовал с прицелом на практику.

      +2

      Если кратко и без воды — если у вас есть рекурсивный dns сервер и на нём включена валидация dnssec — добавьте второй ключ в доверенные. Вот, например, для dnsmasq оба ключа:


      prok@wendy:~$ cat /usr/share/dnsmasq-base/trust-anchors.conf
      # The root DNSSEC trust anchor, valid as at 10/02/2017
      
      # Note that this is a DS record (ie a hash of the root Zone Signing Key) 
      # If was downloaded from https://data.iana.org/root-anchors/root-anchors.xml
      
      trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
      trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

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

      Самое читаемое