NOX.SU - первый домен .su, подписанный в рамках DNSSEC

1.
Nox.su - домен второго уровня, находится в зоне .su, которая, в свою очередь, принадлежит к корневой зоне (".") DNS. Корневой доменной зоне соответствует KSK (Key Signing Key) с id=19036. Запись DNSKEY содержит публичную часть данного KSK, которая позволяет проверить подписи, сделанные с его помощью. В нашем случае этим ключом подписаны две записи: публичная часть KSK (на схеме отражено при помощи "возвратной" стрелки) и публичная часть ZSK (Zone Signing Key) - ключа, используемого для подписывания всех остальных записей корневой зоны.

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

В корневой зоне соответствующий ZSK (DNSKEY c id=51201) удостоверяет две 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. Сейчас, 26.05.13, в DNS имена серверов изменены, но, как было указано выше, для настоящей статьи это не важно. Именно эти два сервера и содержат информацию об адресации внутри упомянутой зоны. Техническое решение практически стандартное: 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 - уже говорилось выше.

Файлы зон. Исходный файл зоны выглядит так:

$ORIGIN .
$TTL 900
nox.su.            IN SOA ns1.8191.ru postmaster.nox.su (
                                2012012721 ; serial
                                7200	   ; refresh (2 hours)
                                3600	   ; retry (1 hour)
                                86400	   ; expire (1 day)
                                900        ; minimum TTL
                                )
                        NS	ns1.8191.ru.
                        NS	ns2.8191.ru.
                        A	50.16.193.159
                        MX	10	mx.yandex.ru
                        TXT     "2357111317192329"
                        SPF     "v=spf1 redirect=_spf.yandex.ru"

Зона небольшая и простая. Для примера в ней присутствуют записи 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. Простое и, мягко говоря, не самое безопасное решение. Обсуждение практики хранения ключей - ниже, а пока посмотрим на результат работы утилиты:

$ dnssec-signzone -S -N increment -K keys/ -e +3mo nox.su
Fetching ZSK 23208/RSASHA1 from key repository.
Fetching KSK 47341/RSASHA1 from key repository.
Fetching ZSK 17166/RSASHA1 from key repository.
Verifying the zone using the following algorithms: RSASHA1.
Zone signing complete:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
                    ZSKs: 1 active, 1 stand-by, 0 revoked
nox.su.signed

- и мы получили файл зоны 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 работает крайне медленно; обратите внимание: использование источника urandom вместо random обычно означает, что программа получает меньше энтропии, то есть, псевдослучайные данные могут иметь "низкое качество", поэтому, несмотря на допустимость urandom, для генерации критически важных ключей этот источник может не подходить); -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 и .su, используется DS-запись, содержащая отпечаток KSK. Сгенерировать значение этой записи несложно:

$ dnssec-dsfromkey keys/Knox.su.+005+47341.key > ds-records.txt

Результатом выполнения команды оказывается файл ds-records.txt, содержащий нужное значение. Собственно, в файле будет пара строк, одна содержит запись с отпечатком SHA-1, вторая - SHA-256. Выбирайте тот вариант, который поддерживает интерфейс размещения записей в зоне первого уровня. Для nox.su я использовал SHA-1:

nox.su. IN DS 47341 5 1 3516AE4FCA981CDA9481A359D2258F85CB0C326D

Отличить типы хеш-функций можно по значению поля, обозначающего тип алгоритма (шестое поле слева, в примере выше): 1 - SHA-1.

Динамика жизненного цикла безопасной зоны. Криптографический подписи в зоне нужно периодически обновлять. Самый распространённый дефект, наблюдающийся в зонах, подписанных DNSSEC, - просроченные подписи (RRSIG). Если срок валидности подписи закончился, то валидирующий резолвер будет генерировать ошибку, а адреса в зоне окажутся недоступны для навигации пользователей.

Одним из решений является использовани функций автоматического сопровождения зоны, которые доступны в современных версиях BIND. Режим автоматического сопровождения включается в конфигурационном файле (обычно - named.conf), в разделе, описывающем ваши зоны. Например так (для зоны nox.su):

zone "nox.su" IN {
	       type master;
               file "d-zones/nox.su";
               key-directory "/var/pkcsobjects/keys";
               auto-dnssec maintain;
               update-policy local;
	       allow-transfer { key TSFKEY; };
		};

Настройка достаточно очевидна. Отметим лишь пару моментов: auto-dnssec maintain - включает автоматическую работу с DNSSEC, key-directory - задаёт директорию, в которой находятся ключи (обратите внимание на права доступа в соответствующей директории!).

Ресурсные записи DNSSEC

Ресурсная запись	Описание
DS	(Delegation Signer) Запись служит для идентификации ключа делегированной зоны. Размещается в делегирующей зоне, при условии наличия NS-записей для зоны делегируемой. DS-запись содержит значение хеш-функции (отпечаток), указывающей на открытый ключ, который должен находиться в одной из DNSKEY-записей делегируемой зоны.
DNSKEY	(DNS Key) Данный тип записи используется для публикации криптографических ключей в зоне. Содержит указания на тип ключа, используемый алгоритм, а также сам ключ.
RRSIG	(Signature RR) Такие записи содержат значения подписей, сгенерированных для наборов ресурсных записей зоны. Валидность той или иной подписи может быть проверена при помощи ключей, размещённых в соответствующих DNSKEY-записях.
NSEC	(Next SECure) Служит для подтверждения отсутствия запрошенной записи в зоне ("доказательство" несуществования). Содержит имя "следующей" (ближайшей) существующей записи. Смысл данной записи в том, что соответствующая ей подпись (RRSIG) позволяет валидировать отрицательный ответ авторитативного сервера на тот или иной запрос резолвера.
NSEC3	(Next SECure 3) Защищённая от перебора ("индексации зоны") версия NSEC. Использует вычислительно затратный, для клиента, пытающегося "индексировать зону", алгоритм генерации значений. Причиной появления NSEC3 стала особенность NSEC, позволяющая легко получить список всех записей, существующих в подписанной DNSSEC зоне.
NSEC3PARAM	(NSEC3 PARAMeter) Данная запись содержит параметр, используемый в работе алгоритма NSEC3 для данной зоны.