DNSSEC
Содержание:
- История
- Что такое DNSSEC
- Как это работает
- Механизм работы
- Цепочка доверия
- Оказываемые эффекты
- Ресурсные записи DNSSEC
- Интернациональные доменные имена
История
Изначально система доменных имен не имела никаких механизмов для защиты от подмены информации в ответе — и запрос, и ответ передаются чистым текстом. При этом резолвер судил о верности полученной информации только по идентификатору запроса, длина которого всего 2 байта. То есть чтобы отравить кэш нужно было просто перебрать $2^{16}$ значений.
Говорить об этом начали еще в 90-х. При этом принялись неспешно описывать первую редакцию DNSSEC. Она увидела свет в 1997, через два года появилась следующая. В 2005 появилась нынешняя редакция DNSSEC, с которой все и работают. Знаковое событие случилось в 2008 году, когда Дэн Камински показал миру, что отравить кэш можно за 10 секунд. Производители DNS софта ответили тем, что кроме идентификатора запроса стали рандомно выбирать исходящий порт. Попутно началась истерия по поводу внедрения DNSSEC.
Что такое DNSSEC
Domain Name System Security Extensions – набор расширений протокола DNS, позволяющих минимизировать атаки, связанные с подменой DNS-адреса при разрешении доменных имен.
DNSSEC является технологией, разработанной, помимо всего прочего, для защиты от атак с помощью цифрового “подписывания” данных, которое позволяет быть уверенным в их достоверности. Однако для устранения данной уязвимости Интернета необходимо использовать данную технологию на каждом этапе поиска, начиная с корневой зоны и заканчивая последним доменным именем. Подпись корня (использование технологии DNSSEC в корневой зоне) является необходимым действием во всем процессе. Важно отметить, что при этом данные не шифруются. Технология просто позволяет убедиться в достоверности адреса посещаемого сайта.
Как это работает
Принцип работы DNSSEC тот же, что и у цифровой подписи. То есть закрытым ключом подписываем, открытым сверяем.
Особенность состоит в том, что DNSSEC использует два типа ключей:
- ZSK, zone signing key - ключ подписания зоны
- KSK, key signing key - ключ подписания набора ключей
Сделано это из таких соображений: зона может быть достаточно большой, чтобы удалось подобрать закрытый ключ, поэтому его надо менять почаще, и сделать его можно покороче, чтобы зоны подписывались быстрее; KSK же используется для небольших объемов данных, поэтому его можно и подлиннее сделать и менять пореже. Тем более, что хэш от открытой части KSK требуется отправить в родительскую зону, что хотелось бы делать не слишком часто.
Механизм работы
Допустим, мы хотим узнать адрес test.bar.example.com
:
-
Запрашиваем доменное имя у резолвера
-
Резолвер выставляет бит DO и запрашивает
test.bar.example.com
у корневого сервера -
Резолвер знает, что корневая доменная зона подписана — у него указан ключ или хэш ключа для неё (trust-anchor), поэтому он запрашивает у корневого сервера DNSKEY записи для корневой зоны и сверяет полученное с имеющимся
-
Корневой сервер не знает такого доменного имени, он сообщает адреса серверов, ответственных за зону
com.
резолверу вместе с подписанной DS записью для зоны -
Резолвер валидирует DS запись полученным и проверенным ZSK ключом корневой зоны
-
Теперь резолвер знает, что зона
com.
подписана, далее он спрашивает у её DNS сервера DNSKEY и валидирует их, после чего спрашивает проbar.example.com.
Сервер зоны
com.
сообщает адреса ответственных серверовns.example.com
иns1.example.com
вместе с DS записью -
Так резолвер выстроил цепочку доверия до
example.com
, где он узнает серверы имен зоныbar.example.com
и ее DS -
Далее, резолвер итеративно узнает адреса DNS серверов, отвечающих за
bar.example.com
, у которых получает нужную информацию, валидирует её и отдает нам адресную запись, выставив в ответе бит AD.
При невозможности что-то провалидировать резолвер вернет servfail
.
Цепочка доверия
DNSSEC привязана к административной иерархии глобальной (общепринятой) системы доменных имён (DNS). То есть, для каждого домена должна быть построена “цепочка доверия”, ведущая от записей данного домена через различные криптографические ключи к корневому домену. Более детальное описание конкретного решения в случае nox.su
приведено ниже.
nox.su
- домен второго уровня, находится в зоне .su
, которая, в свою очередь, принадлежит к корневой зоне.
-
Корневой доменной зоне соответствует KSK с id=19036.
Запись DNSKEY содержит публичную часть данного KSK, которая позволяет проверить подписи, сделанные с его помощью. В нашем случае этим ключом подписаны две записи: публичная часть KSK (на схеме отражено при помощи “возвратной” стрелки) и публичная часть ZSK - ключа, используемого для подписывания всех остальных записей корневой зоны.
KSK служит исключительно для установления связки в цепочке доверия между вышестоящей зоной и внутренним, для данной зоны, ключом ZSK. Такой подход, кроме прочего, позволяет оптимизировать управление ключами.
В корневой зоне соответствующий ZSK (DNSKEY c id=51201) удостоверяет две DS-записи, относящиеся к ключам из расположенной ниже зоны
.su
. Это первое звено цепочки доверия в нашей схеме. DS-записи содержат хеши (SHA-1 и SHA-256) публичных частей ключей KSK, используемых в.su
(id=1509,id=19071, см. на след. слайде). Таких ключей два, что позволяет проводить ротацию ключей без нарушения работоспособности процедур валидации для данной зоны (один ключ заменяет другой, при этом оба заранее размещены в зоне).
-
Зона
.su
использует собственный ZSK (id=41948), при помощи которого подписана DS-запись, соответствующая KSK зоныnox.su
. То есть, использована та же процедура, что и для звенакорневая зона - .su
. Единственное отличие: указана только одна DS-запись. Это связано с тем, что вnox.su
- только один ключ KSK. Таким образом, для того, чтобы изменить этот ключ, потребуется внести в зону.su
новую DS-запись.Строго говоря, использование только одной DS-записи не является лучшей практикой, однако такое решение вполне допустимо. Например, если потребуется провести плановую ротацию ключей для
nox.su
, то вторую DS-запись можно разместить заранее. Проблема возникнет только при необходимости внезапной, незамедлительной смены ключа.
-
Как нетрудно узнать из 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 не используется, но размещён в зоне для обеспечения возможности быстрой ротации ключей.
Оказываемые эффекты
- Исходящий трафик авторитетного DNS сервера увеличивается примерно в 4 раза
- Размер файла зоны после подписи вырастает в 6-7 раз
- Увеличение длины ключа приводит к заметному снижению производительности резолвера, на авторитетный сервер влияет в меньшей степени
- Наоборот действует увеличение кол-ва итераций при использовании NSEC3
- DNSSEC приводит к значительному увеличению DNS ответа и, следовательно, необходимо чтобы все сетевое оборудование корректно работало с DNS пакетами более 512 байт.
Ресурсные записи DNSSEC
DS (Delegation Signer) – для идентификации ключа делегированной зоны. Содержит значение хеш-функции, открытого ключа, который должен находиться в одной из DNSKEY-записей делегируемой зоны. Размещается в делегирующей зоне, при условии наличия NS-записей для зоны делегируемой.
DNSKEY (DNS Key) – для публикации криптографических ключей в зоне. Содержит тип ключа, используемый алгоритм, сам ключ.
RRSIG (Signature RR) – для подписания других ресурсных записей. Содержит значения подписей, сгенерированных для наборов ресурсных записей зоны. Валидность той или иной подписи может быть проверена при помощи ключей, размещённых в соответствующих DNSKEY-записях.
Пример DNSKEY
su 345600 DNSKEY 256 3 7
AwEAAfWZHDRorjygm9vbdoAyMWttyXigyCwif0STSxjeaU
...wKbl1SwI8E06pqyPXiJRapdqNP; key tag = 30062
su 345600 DNSKEY 257 3 7
AwEAAakz9eb33Pqr8hVaCowuxLWNaZlEDKvF6t8nKyN77c
...VVKGOm+NZ5fD/dXi4LQtTXwS1y; key tag = 16101
Тип протокола - всегда 3 для DNSSEC
Код алгоритма - 5, соответствует RSA с использованием SHA1
Интернациональные доменные имена
IDN (Internationalized Domain Names) – доменные имена, которые содержат символы национальных алфавитов.
президент.рф
, مصر.
Для поддержки IDN достаточно, чтобы их понимал браузер.
Punycode – стандартизированный метод преобразования последовательностей Unicode-символов в ACE- последовательности (ASCII Compatible Encoding).
Преобразованные имена должны начинаться с префикса: xn--
http://xn--80acd.com
– IDN в Punycode-представлении, http://80acd.com
– обычное доменное имя.
Примеры Punycode преобразования
Последовательность символов | Кодировка |
---|---|
abcdef | abcdef |
abæcdöef | abcdef-qua4k |
schön | schn-7qa |
ยจฆฟคฏข | 22cdfh1b8fsa |
☺ | 74h |
правда | 80aafi6cg |