DNSSEC - это технология, позволяющая строго устанавливать подлинность адресной информации в DNS при помощи криптографических алгоритмов. Зона .nox.su иллюстрирует внедрение DNSSEC для конкретного домена.
(Дополнение от 26.05.13: зона nox.su развивается и изменяется; в настоящей статье примерами служат старые файлы зоны, которые отличаются от того, что опубликовано в DNS сейчас; эти изменения не влияют на смысловое содержание данной статьи, поэтому, за исключением нескольких оговорок, здесь не отражаются.)
(Пояснение от 04.06.18: ранее в домене nox.su также был доступен демонстратор DANE для https - dane.nox.su, но сейчас демонстратор отключен, так как за прошедшие с момента его запуска (27.06.2012) шесть лет - технология DANE в вебе распространения не получила.)
Как всё это работает? DNSSEC привязана к административной иерархии глобальной (общепринятой) системы доменных имён (DNS). То есть, для каждого домена должна быть построена "цепочка доверия", ведущая от записей данного домена через различные криптографические ключи к корневому домену. Более детальное описание конкретного решения в случае nox.su приведено ниже.
(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 - задаёт директорию, в которой находятся ключи (обратите внимание на права доступа в соответствующей директории!).
Ресурсная запись | Описание |
---|---|
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 для данной зоны. |
Данное описание постепенно пополняется (см. "планы" в самом конце страницы). Вы прочитали версию 1.5, от 20.07.2013.
Автор: А. Венедюхин. Вопросы, пожелания - крайне приветствуются на адрес e-mail, указанный на сайте автора (см. предыдущую ссылку).
Проект io7.nl.
Источник схемы: dnsviz.net.
О том, что такое DNSSEC, в популярном изложении можно прочитать на dxdt.ru.
Проверка поддержки DNSSEC из браузера - страница, позволяющая проверить используемый резолвер и определить, поддерживается ли DNSSEC в вашей системе.
Специально "сломанные" имена в зонах .nox.su и .su: broken.nox.su, dotsu.su - это невалидные записи, помогающие проверить настройку резолвера.
Статистика внедрения DNSSEC в домене .ru - небольшое исследование, проведённое 20.05.13 (статья удалена в связи с реорганизацией RU-CENTER).
DNSSEC: DNS Security Extensions - справочная информация, презентации, статьи, ссылки на RFC и так далее.
DNSSEC debugger, VeriSign labs - браузерный инструмент, в деталях показывающий, как ваша зона выглядит снаружи.
Планы: