Nox.su стал первым доменом в зоне .SU, подписанный в рамках программы внедрения протокола DNSSEC. DNSSEC – это технология, позволяющая строго устанавливать подлинность адресной информации в DNS при помощи криптографических алгоритмов. Зона .nox.su иллюстрирует внедрение DNSSEC для конкретного домена.
Как всё это работает? DNSSEC привязана к административной иерархии глобальной (общепринятой) системы доменных имён (DNS). То есть, для каждого домена должна быть построена “цепочка доверия”, ведущая от записей данного домена через различные криптографические ключи к корневому домену. Более детальное описание конкретного решения в случае nox.su приведено ниже.
Общее описание
1. Nox.su – домен второго уровня, находится в зоне .su, которая, в свою очередь, принадлежит к корневой зоне (“.”) DNS. Корневой доменной зоне соответствует KSK (Key Signing Key) с id=19036. Запись DNSKEY содержит публичную часть данного KSK, которая позволяет проверить подписи, сделанные с его помощью. В нашем случае этим ключом подписаны две записи: публичная часть KSK (на схеме отражено при помощи “возвратной” стрелки) и публичная часть ZSK (Zone Signing Key) – ключа, используемого для подписывания всех остальных записей корневой зоны.
(KSK служит исключительно для установления связки в цепочке доверия между вышестоящей зоной и внутренним, для данной зоны, ключом ZSK. Такой подход, кроме прочего, позволяет оптимизировать управление ключами.)
В корневой зоне соответствующий ZSK (DNSKEY c id=55231) удостоверяет две DS-записи, относящиеся к ключам из расположенной ниже зоны .su. Это первое звено цепочки доверия в нашей схеме. DS-записи содержат хеши (SHA-1 и SHA-256) публичных частей ключей KSK, используемых в .su (id=1509,id=19071 – см. следующий блок на схеме). Таких ключей два, что позволяет проводить ротацию ключей без нарушения работоспособности процедур валидации для данной зоны (один ключ заменяет другой, при этом оба заранее размещены в зоне).
2. Зона .su использует собственный ZSK (id=41948), при помощи которого подписана DS-запись, соответствующая KSK зоны nox.su. То есть, использована та же процедура, что и для звена “корневая зона – .su”. Единственное отличие: указана только одна DS-запись. Это связано с тем, что в nox.su – только один ключ KSK. Таким образом, для того, чтобы изменить этот ключ, потребуется внести в зону .su новую DS-запись. (Строго говоря, использование только одной DS-записи не является лучшей практикой, однако такое решение вполне допустимо. Например, если потребуется провести плановую ротацию ключей для nox.su, то вторую DS-запись можно разместить заранее. Проблема возникнет только при необходимости внезапной, незамедлительной смены ключа.)
3. Как нетрудно узнать из DNS, зону nox.su поддерживают минимум два NS-а: ns1.8191.ru и ns2.8191.ru. В реальности, именно эти два сервера и содержат информацию об адресации внутри упомянутой зоны. Техническое решение практически стандартное: Linux + BIND 9.7. (утилиты dnssec-signzone и др.).
При помощи KSK (id=47341 на схеме) подписаны два ZSK (id=23208, id=17166). ZSK 23208 – удостоверяет остальные записи в зоне (в том числе и сам этот ZSK, что, в общем, избыточно). Второй ZSK не используется, но размещён в зоне для обеспечения возможности быстрой ротации ключей. (В предыдущей версии зоны nox.su использовался только один ZSK. Сейчас пробуем два.)
Технические подробности
(некоторые подробности)
Итак, для поддержки зоны nox.su используются два сервера. Техническое решение тут весьма бюджетное: это два виртуальных сервера из Amazon EC2, один в европейском датацентре, другой – в азиатском (типа, повышение надёжности, да). Про то, что это Linux+BIND – уже говорилось выше.
Файлы зон.
Исходный файл зоны выглядит так:
Зона небольшая и простая. Для примера в ней присутствуют записи TXT и SPF.
Для того чтобы получить файл с подписями, требуется пропустить исходный файл через утилиту dnssec-signzone. Грубо говоря, главное предназначение этой утилиты – сгенерировать записи RRSIG, которые, собственно, содержат электронные подписи адресной информации в зоне. Всё остальное, что вычисляет эта замечательная программа – подчинено только что обозначенной цели: генерации RRSIG-ов.
В процессе использования dnssec-signzone нужно обратить внимание на верное указание промежутков времени, в течение которых размещённые в DNS подписи будут считаться валидными.
Команда выглядит примерно так:
$ dnssec-signzone -S -N increment -K keys/ -e +3mo nox.su
Данная утилита довольно умная, поэтому (если ей сказать “-S”) умеет сама выбирать нужные ключи из найденных и использовать их так, как предписано в файлах ключей. Ключ -N – означает, что нужно увеличить серийный номер в файле зоны; ключ -K – указывает на директорию, в которой находятся криптографические ключи (про хранение ключей – ниже); фраза “-e +3mo” означает, что сгенерированные RRSIG-и получат интервал валидности три месяца (считая с даты генерации); nox.su – имя файла зоны (совпадает с фактической иерархией для данного домена, это важно для синтаксиса dnssec-signzone).
В процессе подписывания зоны требуется доступ к секретным частям ключей. В нашем случае эти ключи были доступны в директории keys. Простое и, мягко говоря, не самое безопасное решение. Обсуждение практики хранения ключей – ниже, а пока посмотрим на результат работы утилиты:
– и мы получили файл зоны nox.su.signed (к имени автоматически добавляется .signed, а исходный файл остался нетронутым):
nox.su. 900 IN SOA ns1.8191.ru. postmaster.nox.su. ( 2012012919 ; serial 7200 ; refresh (2 hours) 3600 ; retry (1 hour) 86400 ; expire (1 day) 900 ; minimum (15 minutes) ) 900 RRSIG SOA 5 2 900 20120428135713 ( 20120129135713 23208 nox.su. IE9km+SRRF7RRIDeCUjMVIVMrYmLqkWZPwam fuPeGlRq1g0EhBtZF0vy+CMVlaTzLNI4VcSv HRaTFdkwQsVBO55oKxS7xK4SK8q77zzg1jCn NcicLCWskwHGl3vixVpHt64ZSkQodAQQoolc Yvxvxpt1VNVe48c+PhBudUHH1NA= ) 900 NS ns1.8191.ru. 900 NS ns2.8191.ru. 900 RRSIG NS 5 2 900 20120428135713 ( 20120129135713 23208 nox.su. hcq2wYlWWtanDHupo0AbpoiNt8YpSnSaEs1j IrobPYl60ULJ07Oxx0/NZYRSYoAZeFWWMKol IqHlqTHyDuhbZKfdQITiGPcDQWpEhUusnXGP mgrFfCO6rtJP2XjFoE5pDUjmDqp7CBoub4RY hpe37jVFYdr7Q3t4PBjJuKX7bvY= ) 900 A 50.16.193.159 900 RRSIG A 5 2 900 20120428135713 ( 20120129135713 23208 nox.su. UJj9OfQ3DxGfkyn+56LiK2Xq1VCMSk8r/wZ9 vOtDi1Z6h+clSk8W95udDdbSzKcC+82P3RHP fPMdJLU3sIVQpTif/MjcS/FaphvNDM0Yr+cr YqEj1Z6JYCnj0eaab33YzUX1XMNnVlD6SkYf xyl6eevbGq9uKe/0EBemg8m2cx0= ) 900 MX 10 mx.yandex.ru. 900 RRSIG MX 5 2 900 20120428135713 ( 20120129135713 23208 nox.su. IcQHaLERYou08scxNjNjJlXlNk9z6I3lKSRI S5WAEcNM5gPlljGCs+rgWmY2Ug8LvMC9BaaK AxSJD0W79o2wEqsQ5eNfJ4UHI1SNganlv9LK q2uPUx25VZVGG0tA8yyBmjH6qRZhfUtDkGDy xDEtF5vzWjo5kWOwchR5pXOVqp0= ) 900 TXT "2357111317192329" 900 RRSIG TXT 5 2 900 20120428135713 ( 20120129135713 23208 nox.su. W5oPQFcRiqyPuQF5CQ1YWxW1M6g7upNWWDjB HSmhcqjVXRucoCMoiexjRHbI4k0+tk92EkLI 74OGGBs96HL2jGf3T6xUgMi+vnRrxGmg6tMl iFQFGQvnWBDKonMOFn/R03barHWu09EazWCU JvPesHPwEu2Ql08O7jgzM4yo8N0= ) 900 NSEC nox.su. A NS SOA MX TXT RRSIG NSEC DNSKEY SPF 900 RRSIG NSEC 5 2 900 20120428135713 ( 20120129135713 23208 nox.su. gJs9wGXdBzKSJocp4n1UKfWJzP3EAqkUrqb8 gSF7YtuM0wfgzzlzqo/fNIj2Wylz/X0ux0dm E6WVj6bXbFy+wJ4n+IzLb/H1yemTfn87s3xa cYP/b2nUW0Uzdxe3abneSIMEATzWE67bqNhh Sy35XgRnw/vAOsSFAbPYsMuAij0= ) 900 DNSKEY 256 3 5 ( AwEAAZ/Yjdfx+JSOENA7FMbRTHmYBSROZJC4 DldQU6yxowVl05QhOQMCP6IvEwTIxYO8d7G3 r7Az1cVeaQGbETfVsAvlwCqZkrj4SjAtgXOt 1M/WdTpOI7JpF/lYzbm4WITYUmYnjDpf97uG 4zZoewufgL38L/RUdNYGRjyIsfyKVGs3 ) ; key id = 23208 900 DNSKEY 256 3 5 ( AwEAAeH40cGKe6ri45pxhneYbVNGtY0syq4q OrwSA7yKDJW+6YFh1mWKJA6NBZbqaw+18Q00 rkDBcYRsjCtVinuYyi8Vf5RndlmQjhWm/k+O 9MZ1M6Sq/H0wtWJV8xoVTL8q1UW3rg9Q5C/b U6Ra8hlJ4dPQk3rcbsiY2ZwRGiA2Wbzx ) ; key id = 17166 900 DNSKEY 257 3 5 ( AwEAAeGZzsfxLEsiEnURsNr0+EhX8bUCz5H+ 35Vx4VY6YxFSIDpMXgwgpZE/YcyaYQaPUc1e M/Gl1+N8NO6T5Ip3fyUi+WurqO/XEiOFqmo/ hnVp00oczmuG2R3rGnqLX/sDQlKKYml5oKpC UBxr89E1aV1h0Xi2J1vPYYpFOPUWfmeGlOuX XMKEzyFWlrAMbLU2n80wzDaSzAgTYu30xff6 BipCxqroIIXZv8uwiPLBK0Vx0uziWgOJvcQm u8XFD5WXZdQ9AGwHePLjbXQ8pjUzsdDeqkCG i44ybe3JEPhcBgB9dhSwVYzqhNQR+KcDdmFj OZETTsvbi8VOoBGXXE1pnuM= ) ; key id = 47341 900 RRSIG DNSKEY 5 2 900 20120428135713 ( 20120129135713 23208 nox.su. MMPD3Jbxnb8ddWOzaytv8jSis/EzVDi1+0P3 wfkAUq5T99Il5y/XQWKTsfmm6oijBMNcLVtX l5cRkFoJGqkJH4ql8gbJRfbGW5qVy/Qok/yK tB1Suk7r2ybC5PJm/0+IAt47IhzeMUQODSZq wi7Ca301YHdBqWI0Q/7sxYjnmXA= ) 900 RRSIG DNSKEY 5 2 900 20120428135713 ( 20120129135713 47341 nox.su. k6PVI1RyY4l65Mazbg9twFYoy9rDcZVlyiev 3WEkvC+JdTt6XlxFbh7mGU10iGiMqL3Mnbdr kEpdONWDMiiRvOzm61nUeL5DKBVVRyGYnQKr RBoKKLV9CkyKwubqEb2Vk5VzjRcBDYBb8kN8 6V8gzdaF/bwYpwnJCjdNxqivz08AoVuEuu6n kOI8sW/1fZM6XnD3tT1goVzB433XyGk1kqWX GkV5Tf9sqifKUdRtQRqs4HD7IxjKFDfVgve1 z3fOXhXtuVoV+xjDJ5txXlROwtWSlauqqp+j cMil8HPZj1EyjRfN3AN5Ul7PWjPz0E9V8MVb 7QJittCfIYU5DEmQcA== ) 900 SPF "v=spf1 redirect=_spf.yandex.ru" 900 RRSIG SPF 5 2 900 20120428135713 ( 20120129135713 23208 nox.su. Atsd69CXIhsbiimjcHJggLC/JdzANvIDAqvQ G2wrMg3t8NZtKck+/cVdk92BWr26yOEivAbg DBlqwprcO0oeCjnimn0nbKR/L7SpZ6DBiBrs x8f2eh+Lg0Iv2jEcXc3Y2EFZUkAiK8fEalva xJCHsAePkdheRrvjbZ1Me5Cnz7I= )
Что мы получили? Файл зоны, содержащий, в дополнение к исходным записям, записи RRSIG, DNSKEY, NSEC. Изучив приведённый выше файл зоны, несложно понять, что там чему соответствует. Так, всякая запись RRSIG (содержит подпись) соответствует записи (записям) определённого типа: SPF – RRSIG SPF и так далее. Параметры RRSIG-ов указывают, кроме прочего, заявленное “время жизни” (период валидности) данной подписи и идентификатор ключа, использованного для её генерации.
Генерация и жизнь криптографических ключей.
Прежде всего, ремарка: мы рассматриваем хоть и живую, но экспериментальную зону, с малым числом записей.
Естественно, если следовать строгим стандартам, то криптографические ключи должны храниться особым образом. Например, в самом правильном случае, секретные части ключей размещаются внутри специального криптосервера, который находится в режиме офлайн, а особое сетевое подключение к нему устанавливается только тогда, когда нужно подписать зону, и исключительно для осуществления этой транзакции.
К сожалению, это скорее сказка, чем быль. В интернетовской реальности даже большие и реально нуждающиеся в защите зоны DNS будут жить с DNSSEC-ом по совсем другим правилам. Но это другая история. Тем более, что для зоны, не содержащей множества записей, указывающих на критически важные ресурсы, вполне допустимо достаточно вольное обращение с криптоключами. В нашем случае принятая модель угроз такова, что ключи охраняются исключительно средствами разграничения прав доступа ОС, работающей на авторитативном сервере имён, где эти ключи и находятся.
Генерация ключей проводится с помощью утилиты dnssec-keygen. Сразу посмотрим на живой пример, из практики nox.su:
$ dnssec-keygen -r /dev/urandom -a RSASHA1 -P now -A +3mo -b 1024 -n ZONE nox.su
– генерирует ZSK (для подписывания записей в зоне). Ключ -r указывает источник случайных данных (/dev/urandom – исправляет ситуацию в том случае, если dnssec-keygen работает крайне медленно);
-a RSASHA1 – требуемые криптографические алгоритмы;
пара “-P и -A” задаёт временнЫе параметры для ключа: -P – время публикации, now – означает, что немедленно;
-A – время начала использования ключа, +3mo – через три мясяца;
-b 1024 – длина 1024 бита; -n ZONE – тип ZSK. В конце строки указано имя зоны.
Обратите внимание на то, что сведения о расписании использования ключей записываются dnssec-keygen в файлы, эти ключи содержащие, откуда данная информация извлекается другими утилитами. В только что рассмотренном примере мы генерируем ключ ZSK, который будет опубликован сразу, но пока не будет использоваться для подписывания записей (этот момент отложен на три месяца – -A +3mo). Кстати, если не указать “-P now”, то в качестве времени публикации будет использовано время начала действия ключа (-A +3mo). При помощи описанной команды мы сгенерировали “запасной” ZSK, который на иллюстрации со схемой работы зоны обозначен id 17166.
$ dnssec-keygen -r /dev/urandom -a RSASHA1 -b 1024 -n ZONE nox.su
– генерирует ZSK, предназначенный для использования сразу (по умолчанию, ключ начинает действовать в момент создания).
Такой командой сгенерирован основной ZSK (id=23208) в нашей зоне nox.su.
$ dnssec-keygen -r /dev/urandom -a RSASHA1 -b 2048 -f KSK -n ZONE nox.su
– генерирует KSK, используемый для подписания ZSK. Именно KSK устанавливает связь в цепочке доверия (делегирования), так как его хеш размещается в зоне уровнем выше, где удостоверяется соответствующим ключом.
Для поддержки зоны nox.su используется несколько ключей. После работы dnssec-keygen директория keys/ содержит следующие файлы:
Knox.su.+005+17166.key Knox.su.+005+17166.private Knox.su.+005+23208.key Knox.su.+005+23208.private Knox.su.+005+47341.key Knox.su.+005+47341.private
Можно без особых проблем догадаться по именам (а их dnssec-keygen генерирует по шаблону),
что за ключ (или какая часть ключа) содержится в каждом файле. Идентификаторы соответствуют использованным в файле зоны.
Данное описание постепенно пополняется (см. “планы” в самом конце страницы nox.su).
Это версия 1.2, от 27.01.2012.
Автор: А. Венедюхин.