Кратко

  • Первая ключевая пара DNSSEC для корневой зоны появилась не в тот момент, когда подписанная зона вышла в эксплуатацию. Церемония 16 июня в Калпепере сгенерировала KSK-2010; 12 июля в Эль-Сегундо её импортировали на западную площадку и выполнили следующий операционный этап.
  • IANA датирует первую производственную подписанную корневую зону 15 июля 2010 года. Сценарии, разделение ролей, внешние представители, видео, хеши и журналы сделали часть работы с ключом проверяемой. Они не доказывают, что все резолверы проверяли DNSSEC.

Три даты означают три разных действия

15 июля 2010 года IANA объявила, что корневая зона подписана. Речь шла об изменении публикуемых данных корня, а не о том, что каждый рекурсивный резолвер в мире включил проверку. Церемония не могла принять это решение за независимых операторов.

В архиве IANA этот результат отделён от двух церемоний. Первая состоялась 16 июня на восточной площадке управления ключами в Калпепере, штат Вирджиния. Вторая — 12 июля в Эль-Сегундо, штат Калифорния. Хронология запуска относит первую производственную подписанную зону к 15 июля. Генерация и контролируемое использование ключа, подготовка второй площадки и запуск производственного подписания были отдельными задачами.

Первая церемония началась в 17:00 UTC 16 июня и продолжалась после полуночи. В презентации ICANN того времени указано окончание в 00:25 UTC 17 июня. Позднейшие документы, называющие датой генерации 17 июня, могут фиксировать завершение той же сессии, а не другое событие.

Калпепер: ключ и его документальный след

Опубликованные цели первой церемонии были конкретны: ввести в работу восточную площадку управления ключами, создать KSK-2010 и подписать квартальные ключи подписи зоны (ZSK) на третий квартал 2010 года. KSK подписывает набор DNSKEY корня; отдельный ZSK подписывает записи корневой зоны. DNSSEC соединяет подписи по уровням, но это не значит, что KSK непосредственно подписывает каждую запись DNS.

В архиве IANA доступны сценарии, манифесты SHA-256, образ ISO, три видеозаписи и журнал генерации kskgen-20100616-211906.log. По ним можно сопоставить предусмотренные шаги с опубликованными артефактами. Удалённый читатель от этого не становится физическим свидетелем каждого действия; документы также не доказывают сами по себе, что вне кадра ничего не происходило. Их более узкая ценность — возможность независимой проверки оставленного документального следа.

Разделение ролей было частью защиты. В сообщении ICANN от 7 июня говорилось о 14 Trusted Community Representatives, не работавших в ICANN, VeriSign или Министерстве торговли США; каждому отводилась отдельная функция управления ключами. В презентации ICANN38 позднее насчитали 16 представителей в ролевых группах Crypto Officers, Recovery Key Share Holders и резервных участников. Это разные подсчёты: объявленные добровольцы и присутствующие с закреплёнными функциями. Их нельзя свести к одному точному числу. На площадке также были сотрудники, аудитор, представитель VeriSign и оператор камеры.

Эль-Сегундо: вторая площадка входит в рабочую цепочку

Вторая церемония прошла 12 июля на западной площадке в Эль-Сегундо. IANA указывает начало в 20:00 UTC. В число целей входили запуск площадки, импорт KSK-2010 и подписание ZSK на четвёртый квартал. Архив содержит сценарии, контрольные суммы, видео и журнал ksrsigner-20100712-224426.log.

Согласно обновлению IANA, материалы ключа доставили на запад, там импортировали или реплицировали ключ и продолжили квартальное подписание. VeriSign приняла подписанный ответ. Значит, вторая площадка участвовала в рабочей операции, а не служила декорацией. Источники не говорят, что на протяжении всего жизненного цикла существовала ровно одна копия ключа. Они описывают контролируемую схему с несколькими площадками.

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

Подписать корень — не значит включить проверку повсюду

После объявления 15 июля изменения корневой зоны ненадолго приостановили до 20 июля, чтобы наблюдать последствия и устранять проблемы. Эта пауза напоминает: создать подписи и безопасно эксплуатировать систему — разные задачи. Подписанные данные ещё нужно было распространить, а операторы резолверов сами решали, будут ли проверять ответы.

Отчёт NTIA от 28 мая описывал распределение обязанностей на тот момент: IANA/ICANN отвечала за KSK, VeriSign подписывала и распространяла всю зону с помощью ZSK, а NTIA разрешала изменения корня в рамках действовавшей договорённости. В отчёте до запуска также отмечалось, что в мае некоторые проверки авторизации ещё не завершились. Это источник о планах и незакрытых работах на ту дату, а не доказательство, что все проверки уже были пройдены. Июльские обновления IANA фиксируют завершение запуска.

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

Вывод следует ограничить тем, что подтверждают источники. Церемония не провозгласила доверие Интернета к организации. Она создала ключ по документированной процедуре; вторая площадка вошла в цепочку хранения и подписания; затем производственная система опубликовала подписанную зону. В логике Хэн Лу координационную процедуру нужно оценивать по операционному результату: оператор корневой зоны принял подписанный ответ, после чего данные можно было распространять. Это подтверждено лучше, чем заявление о всеобщем внедрении.

Ротации 2016–2018 годов и будущая смена KSK отвечают на другой вопрос: как заменить уже установленный ключ и проверить, что резолверы последовали за изменением. В 2010 году вопрос был предыдущим: как создать, хранить, передать и использовать первый криптографический ключ корня, оставив достаточно свидетельств для последующей проверки?

Источники

Дополнительный более поздний контекст, не свидетельство событий 2010 года