Статья опубликована в январском номере журнала Системный Администратор ()
Практически 25 лет DNS запросы не считались безопасными, но после внедрения DNSSEC на корневых серверах эта проблема будет решена.
Не секрет, что практически все технологии современного Интернета получили свою жизнь еще в 70-80 годах. В то время разработчиков интересовала сама возможность, и ни кто особо не рассчитывал на том, что сеть станет общедоступной и разрастется до мировых масштабов. А подключаться к Интернет можно будет с любой точки планеты. В итоге практически во всех протоколах не была предусмотрена возможность защиты или повышения безопасности. Результат мы получили в виде спама, атак на ресурсы Сети путем подделки DNS адресов и многих других проблем. Сегодня изменить что-то глобально, не так то и просто, даже не возможно, слишком много сил и средств следует потратить. Поэтому и проблемы пытаются решить при помощи разного рода надстроек над протоколами, расширений использующих в качестве защиты стойкую криптографию. Для SMTP таким “спасительным кругом” является DKIM (DomainKeys Identified Mail, [1]), для DNS — протокол DNSSEC.
Зачем нужен DNSSEC?
Служба DNS в которой сопоставлены IP-адреса именам доменов, по сути, является фундаментом Интернета. К ее услугам обращаются практически все остальные популярные сервисы предназначенные для отправки почты, веб-серфинга, VoIP, ICQ и так далее. Соответственно если DNS выдает не правильную информацию, это сказывается на работе любого сервиса его запрашивающего. Хотя многие пользователи и не замечают его присутствия, да и вообще не знают о его существовании и вполне возможно не считают его заслуживающим уважения. Но именно DNS, как база Интернета, требует защиты не менее, даже более, чем другие сервисы. Известны две возможных атаки на DNS как на сервис разрешения имен:
- DDoS (Denial of Service) – атака на отказ в обслуживании, в результате которой сервер перестает отвечать на запросы клиентов (пример, мы видели в октябре 2002 года, когда перестали отвечать 10 из 13 коренных серверов);
- DNS Spoofing/DNS cache poisoning — атака, заключающаяся в подмене действительной записи о соответствии имени и IP-адреса в кэше DNS-сервера ложной записью, в результате пользователь, набравший это имя, направляется совсем по другому адресу.
Признаю, что есть и другие атаки на DNS вроде “man-in-the-middle” и так далее, перечисление их всех, не входит в задачу статьи. Но в итоге все сценарии сводятся к двум возможным последствиям – недоступность сервиса или выдача пользователю ложной информации. Универсального решения против DDOS атаки на любой сервис нет и DNS здесь не является исключением. Защита строится на тех же принципах – повышаем, увеличивает, фильтруем и блокируем. Хотя у DNS есть одно существенное преимущество — иерархическая структура, при которой информация не хранится в одном месте, а на многочисленных серверах и запрашивается по мере необходимости. Обращение к серверам верхнего уровня происходит только при отсутствии информации в текущем DNS сервере. Кэширование DNS данных приводит к уменьшению числа запросов. В итоге чтобы DDOS атака действительно была эффективной, необходимо чтобы она затронула максимальное количество серверов, в том числе 13 корневых, и действовала в течение продолжительного времени. А это далеко не так просто реализовать.
А вот с выдачей неправильных данных уже не все так безмятежно. Все реализации атак основываются на том, что протокол DNS (RFC 1034 и 1035) не предоставляет клиенту никакой возможности проверки подлинности полученной информации. И в итоге клиент вынужден “доверять” любому ответу, полученному от DNS сервера. При DNS запросах обычно используется протокол UDP, что упрощает подделку ответа сервера, так как при этом не устанавливается виртуальный канал. Кроме этого злоумышленнику не нужно атаковать все DNS сервера, достаточно взять на прицел только один. В итоге пользователь набравший адрес требуемого ресурса попадает на подставной сайт, где он может раскрыть свои пароли или другую информацию. Особо нужно отметить, что уязвимым в этом случае является именно протокол, а не программы его реализующие. Поэтому и проблему можно решить, только изменив подход к получению адреса клиентом.
Особенности DNSSEC
Расширение к протоколу DNS — DNSSEC (DNS Security Extensions)[2], разработанное одноименной группой, не может защитить от самой атаки направленной на подмену адреса, но дает возможность обнаружить такую попытку и отклонить неправильные данные, обезопасив тем самым клиента. Самое главное – DNSSEC не является заменой DNS. Задача разработчиков была создать такой протокол, внедрение которого не требовало бы менять существующую систему и обеспечивал совместимость клиентов поддерживающих и не поддерживающих расширение. Поэтому DNSSEC можно разворачивать постепенно, добавляя новые возможности к уже существующей службе DNS.
Работа по улучшению DNS велась давно и первые упоминания о датированы еще январем 1997 года в RFC 2065 (через 10 лет после принятия RFC 1034), в котором были предложены два дополнительных поля DNS Security (DNSSEC, так раньше расшифровывалась аббревиатура). Затем в последующих RFC [3] эта идея развивалась и уточнялась. Эксперименты по развертыванию DNSSEC по RFC 2535, показали, что имеется много нюансов, в основном в процедуре распространения ключевых данных, что в итоге привело к появлению доработок названных — RFC 2535bis или DNSSECbis. На текущий момент актуальными/базовыми являются вышедшие в марте 2005 года:
- RFC 4033 — DNS Security Introduction and Requirements – введение и общие условия;
- RFC 4034 — Resource Records for the DNS Security Extensions – описания расширений в ресурсных записях DNS;
- RFC 4035 — Protocol Modifications for the DNS Security Extensions – изменения в протоколе DNS.
Эти RFC заменили более ранние, в том числе и RFC 2535, которые считаются уже устаревшими. Сами разработчики называют для технологии DNSSEC переломным 2004 год, когда на новые расширения обратили внимание в группе по IESG (Internet Engineering Steering Group, выработка инженерного регламента Интернета), которая следит за процессом стандартизации в Интернете.
Основная идея DNSSEC проверка подлинности полученных данных при помощи цифровой подписи, для чего задействуется механизм шифрования с открытыми ключами.
Для этого администратор доменной зоны подписывает информацию о соответствии имен и IP-адресов, используя свой закрытый ключ. Клиент (Security-Aware Resolver) вместе с адресом получает подписанную адресную информацию, которую он может проверить, используя открытый ключ администратора. Соответственно, если данные в полученном сообщении не соответствуют подписи, они отбрасываются. Механизм подтверждения применяются только к данным по зоне и при подтверждении отсутствия DNS записей, но не предназначен для защиты таких операций, как перенос зон и динамические обновления.
В механизме с открытыми ключами есть слабое место – необходимо точно знать, что открытый ключ принадлежит именно тому субъекту, который нас интересует, то есть в нашем случае клиент получивший подписанный ответ должен доверять открытому ключу. И только тогда он может быть уверен, что полученная DNS запись принадлежит именно ответственному серверу. В DNSSEC эту проблему решают за счет построения цепочек доверия. При этом случае полностью задействует имеющуюся иерархическую структуру, когда администратор верхнего уровня выступает гарантом, удостоверяющим подпись доменов находящихся уровнем ниже. В результате клиент, получающий адрес, последовательно может проследить цепочку доверия к открытому ключу начиная от самого верхнего сервера root/TLD к серверу отвечающему за конкретную зону. Очевидно, что данный подход требует поддержки DNSSEC в корневых серверах или хотя бы в TLD (top-level domain). Ведь при использовании DNSSEC в root серверах клиенту потребуется знание единственного ключа, для подтверждения любых (в идеале) данных. Иначе потребуется импортировать ключ для каждой зоны или отдельного домена.
В отсутствии поддержки DNSSEC корневой зоны и TLD допускается участие в подтверждении ключа третьих сторон (look-aside). Это может быть необходимо при построении “островка безопасности” (в RFC — Island of Security), то есть автономно работающего DNS сервера поддерживающего DNSSEC и не завязанного на TLD (в котором не реализован DNSSEC) или другие сервера верхнего уровня. Чтобы упростить процедуру было принято решение развернуть отдельную инфраструктуру, обеспечивающую централизованное хранение публичных ключей зон и подтверждать любые зоны не являющиеся дочерними. Такая структура описана в RFC 4431 и 5074 и получила название DLV (DNSSEC Lookaside Validation). В настоящее время централизованная база поддерживается организацией ISC, хотя DLV может быть развернута на любом DNS сервере.
Кстати наличие открытых ключей в DNS записях позволяет использовать их и для других операций – SSH, электронная почта и т.п.
Особо хочу отметить, что DNSSEC не защищает данные, так как в этом нет смысла, они должны быть открыты, а затрудняет их подделку. Также не следует считать эту схему панацеей, ведь всегда есть вероятность того, что злоумышленнику удастся не только подделать адресную информацию, но и подменить подписи, выдав свой ключ за ключ администратора зоны. Хотя в случае DNSSEC подменить адрес на порядок сложнее.
DNSSEC предполагает подписывать не каждую отдельную запись, а все множество ресурсных записей (RRSet). Его внедрение потребовало некоторых изменений в DNS протокол в частности в ресурсные DNS записи:
- RRSIG (Resource Record Signature) — цифровая подпись и связанная с ней информация (интервал времени, алгоритм, тэг для определения связанного DNSKEY и т.д.);
- DNSKEY (DNS Public Key) – открытый ключ, который используется клиентом для проверки подписи;
- DS (Delegation Signer) – необязательное поле используется в тех случаях, когда необходимо разрешить проверку подлинности открытых ключей дочерних зон для организации цепочки доверия;
- DLV – похоже на предыдущий, но разрешает проверку подлинности для любых зон в ней описанных;
- NSEC (Next Secure) — перечисление типов ресурсных записей, существующих в данном домене;
Детально они рассмотрены в RFC 4034. Так поле DNSKEY содержит кроме самого ключа еще три записи – флаг (16 позиций, установленный в “1” 7ой бит означает, что запись содержит ключ DNS зоны), протокол (только значение 3) и алгоритм. Список поддерживаемых алгоритмов дан в Appendix A.1 RFC 4034 – RSA/MD5, Diffie-Hellman, DSA/SHA-1, Elliptic Curve DSA (ECDSA) и RSA/SHA-1. Два поля помечены как Private и позволяют при необходимости задействовать другие алгоритмы в отдельных решениях.
Кроме этого в настоящее время действителен RFC 5702 в котором добавлены алгоритмы RSA/SHA-256 и RSA/SHA-512. В результате DNSKEY может выглядеть так (цифра “5” на третьей позиции — RSA/SHA-1):
example.com. 7200 IN DNSKEY 256 3 5 (открытый ключ)
Запись RRSIG содержит большее количество полей:
host.example.com. 7200 IN RRSIG A 5 3 7200 20091110090150 (
20091103182315 13173 example.com.
raR/8vMh37yX…..6LOsE1TqzqPJ # сигнатура в Base64)
По порядку – владелец, TTL, цифра “5” указывает на алгоритм шифрования. Цифра 3 указывает на метку label (количество ресурсных записей, она используется для уточнения имени владельца). Так root имеет label = 0, домен верхнего уровня – 1 и так далее. Следующее число (7200) описывает Original TTL, который определяет значение время жизни для подписанных ресурсных записей. За ним две даты — Signature Expiration и Signature Inception (время истечения и начала действия ключа то есть период действия ключа 20091110090150, 20091103182315 13173). Далее следует тэг (определяет хэш DNSKEY), FQDN ресурсной записи DNSKEY, которая должна использоваться для проверки подписи и собственно сигнатура в Base64 кодировке.
Имеющиеся утилиты практически полностью автоматизируют создание DNSKEY и RRSIG записей, поэтому проблем здесь ни каких быть не должно.
Протокол DNSSEC потребовал новых полей в заголовке DNS сообщения: Checking Disabled (CD) и Authenticated Data (AD). Кроме этого задействуется механизмы расширений для DNS (EDNS0, RFC 2671), которые позволяют использовать UDP пакеты свыше 512 байт, как это изначально установлено в RFC 1035. Не следует увлекаться с большей длиной ключей. Кроме дополнительной нагрузки на сервер, это может привести к увеличению результирующего UDP пакета. Некоторые сетевые устройства могут не пропускать пакеты с большей длиной, чем 512 байт, учитывая возможные потери фрагментов разработчики не рекомендуют превышать этот “лимит”.
Как видно ключи должны периодически обновляться и зоны переподписываться. Чтобы упростить эти операции, рекомендовано (именно рекомендовано, но не обязательно) использовать два ключа – KSK (Key Signing Key) и ZSK (Zone Signing Key). Ключ KSK используется для подписывания ресурсных записей зоны (DNSKEY), в родительской зоне (запись DS) при аутентифицированном делегировании, открытая часть KSK передается клиенту. Ключ ZSK используется для подписывания всего множества ресурсных записей в зоне и подписывания DS. Такая схема рекомендована с целью ускорения процесса проверки подписей DNS, так как размер ZSK ключей выбирают меньшего размера, чем KSK. При создании KSK следует исходить из требований безопасности, производительность играет меньшую роль, поэтому здесь рекомендована большая длина ключа. Менять KSK следует раз в год, ZSK чаще вплоть то раз в месяц.
Здесь виден еще один минус DNSSEC – периодически ключи меняются, а администраторы подчиненных серверов должны отслеживать их смену, иначе в один прекрасный день DNS сервер не сможет разрешать адреса.
Сегодняшняя ситуация с DNSSEC
Не смотря на то, что спецификации DNSSEC насчитывают уже десяток лет, реальная работа по переходу начата относительно недавно. Причины называют разные, как технические, так и политические. Некоторые участники побаиваются, что используя DNSSEC очень легко “отключить” отдельные домены, группы доменов, а то и весь национальный Интернет, если по каким либо причинам они станут кому-то неугодны. Вероятно в будущем, когда технология приживется такой сценарий исключать полностью нельзя, но на данном этапе это невозможно технически. Очень долго велись споры, кто будет держателем “ключей к Интернету” – ключей которые будут использованы в корневых серверах. Сами разработчики не очень доверяют ICANN как основному регулировщику Интернет.
Действительный переход начат только в 2008 году, когда были переведены TLD домены обслуживающие зоны ORG и NET. Постепенно к этому списку начали добавляться и другие зоны — SE, PR, BG, CZ и так далее. О начале подготовки к переходу зоны EDU объявлено в сентябре 2009, РосНИИРОС заявил, что технически все готово к переводу на DNSSEC зоны RU. По сообщению Internetnews.com на октябрь 2009 года расширение DNSSEC активировано на 15 TLD. Полная поддержка технологии DNSSEC в корневой зоне системы DNS будет введена с 1 июля 2010 года (вначале был заявлен строк конец 2008 [4]). Закрытое тестирование начнется уже с 1 декабря 2009 года, и с января 2010 года начнется поэтапный переход к полному использованию. Пока этого нет, то необходимо вносить ключи для каждого домена верхнего уровня. По сообщению компании VeriSign к 2011 году все доменные зоны, администрированием которых она занимается (cc, tv, com, net), будут переведены на DNSSEC. Учитывая размеры зоны com, она планируется к переводу последней.
Просмотреть наличие соответствующих записей можно при помощи утилиты dig (или drill из состава ldns). Например, запрос к зоне SE сразу выводит наличие соответствующих записей:
$ dig +retry=1 +dnssec +multiline +trace se
Кроме этого о поддержке технологии говорит и установленный флаг “ad” в ответе полученном при помощи dig. Например. Получим ключ одного из серверов:
$ ssh-keygen -r Eagle.roysdon.net -f /etc/ssh/ssh_host_rsa_key
Eagle.roysdon.net IN SSHFP 1 1 37c2af30b0083602254fb0c5780a0de9e15231bf
Теперь смотрим ответ сервера:
$ dig +adflag SSHFP Eagle.roysdon.net. @atlt-dnssec-trial.s3woodstock.ga.atlanta.comcast.net.
; < <>> DiG 9.4.2 < <>> +adflag SSHFP Eagle.roysdon.net. @atlt-dnssec-trial.s3woodstock.ga.atlanta.comcast.net.
;; global options: printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 64778
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4
В зоне RU сервера поддержкой DNSSEC встречаются крайне редко.
С технической стороны также не все было готово. Использование DNSSEC требует поддержки нового расширения с обеих сторон: сервер (Security-Aware Name Server) и клиента (Security-Aware Resolver). Поддержка DNSSEC в самом популярном DNS сервере BIND включена еще в 2004 году в версии 9.3 (напомню, что BIND доступен как для Unix так и Windows). Новую версию BIND 9.7 разработчики называют не иначе как “DNSSEC Usability release”. Тогда же в 2004 году появилась экспериментальная поддержка нового расширения в NSD (Name Server Daemon) [5] (собирается с --enable-dnssec), заявлена поддержка в PowerDNS, Unbound и в некоторых других DNS серверах [6]. С клиентским ПО дело обстоит немного хуже, очевидно отсутствие DNSSEC на DNS серверах как таковой сказалось на том, что клиентское ПО в этом направлении практически не развивалось.
В ОС от Microsoft данная спецификация уже поддерживается. В Windows Server 2008 (RFC 2535), а в новых - Windows 7 и Windows Server 2008 R2 (RFC 4033, 4034, 4035) [7].
Более ранние версии Windows Server 2003 и Windows XP имели базовую поддержку RFC 2535, которая фактически выражалась тем, что они принимали подписанный пакет, но больше никаких действий с ним не производили. Сервер DNS на Windows Server 2003 может выступать как secondary DNS работающий совместно с DNSSEC совместимым сервером (с оговоркой выше).
Однозначного утверждения о том, что штатный DNS-клиент в Linux и других Unix системах поддерживает расширение DNSSEC и обрабатывает их, найти не удалось. Эксперименты с tcpdump показывают, что в некоторых случаях отправляются дополнительные DNS запросы, в других нет. Поэтому лучшей рекомендацией на данный момент является активация DNSSEC на DNS сервере организации/провайдера, а клиенты будут получать с него уже проверенную информацию. Провести атаку на подмену IP-адреса в отношении единичного компьютера достаточно проблематично, здесь проще пойти другим путем (подложное письмо, вирус и т.п.). Соответственно если бизнес «завязан» на Интернет, то планировать перевод своих серверов на DNSSEC или подпись DNS данных уже нужно сейчас.
Здесь хочется отметить проект DNSSEC-Tools [8], который предлагает специализированное расширение к веб-браузеру Firefox, почтовому клиенту Thunderbird, SMTP серверам Sendmail и Postfix, FTP серверам proftpd, ncftp, Jabber серверу jabberd, OpenSSH, позволяющее добавить поддержку DNSSEC в эти приложения, а также ряд вспомогательных утилит, патч к logwatch, библиотеки libsres и libval. Правда готовых сборок, в которых присутствует этот патч, не представлено, поэтому тот же Firefox необходимо перекомпилировать самостоятельно.
Чтобы было немного понятней, что собой представляет DNSSEC на фоне теории, разберем настройку сервера BIND9 в двух возможных режимах, поддерживающих это расширение.
Настройка BIND в режиме кэширующего/неавторитативного DNS сервера
Для начала заставим BIND проверять полученные с определенной зоны данные, в результате клиенты которые будут использовать этот DNS сервер, будут защищены от подмены. Примеры буду показывать на основе Ubuntu. Устанавливаем BIND.
$ sudo apt-get install bind9
При самостоятельной сборке BIND необходимо активировать флаг “—with-openssl”.
После установки в /etc/bind/named.conf (в Ubuntu секция options вынесена в named.conf.options) добавляем следующие параметры:
options {
dnssec-enable yes; # активируется поддержка DNSSEC
dnssec-validation yes; # включается только для неавторитативного сервера
};
Далее необходимо сконфигурировать доверенные якоря (trust anchor) для тех зон/доменов, которые будут проверяться. Узнать нужный публичный ключ можно разными способами. Самый простой получить при помощи dig из DNS (как это показано выше), но в этом случае нужно четко знать, что ключ принадлежит именно тому, кому нужно. Проверить затем полученный ключ можно зайдя на один из сайтов зоны. Сегодня также доступны специальные сервисы в которых администраторы размещают trust anchor своих доменов [9]. Далее заносим анкоры в файл в секцию trusted-keys файла named.conf:
zone "se." {
type forward;
forwarders { 212.247.7.228; };
};
trusted-keys {
# зона se
"se." 257 3 5
4w6RVY0ciZ/a8t1xy5FIxkg2U95ZV5VuLtwmx2rgtAbx
BACzTKrqYIpJ6LYSmjdQ3or+ZiO2tEMr53EwAjA6GKrf
qQ2S1y7Rblz2kaS6PK2Gh5MOCufhGozUhPQSGFTn/mV8
H9hlQptfcFCpFZrQQDAQqFAyxQginDgrwSripBk=
# Далее аналогично добавляются ключи и для других зон
# например для 4x4.org
"4x4.org" 256 3 5 "BEAAAAOxYIG/de/sEWGkMlMw/+WZHw72QMNAdCbneozk4BU4OCAbv9krBFnk52CZ67QPEfDMwV0k12Hr6sXkgZgeBpRV";
};
Принцип думаю понятен. DLV записи создаются аналогичным образом (в options требуется dnssec-lookaside).
options {
dnssec-lookaside . trust-anchor dlv.isc.org.;
};
Для удобства отслеживания запросов, можно создать отдельный канал для протоколирования запросов DNSSEC:
logging {
channel dnssec_log {
file "log/dnssec" size 20m;
print-time yes;
print-category yes;
print-severity yes;
severity debug 3;
};
category dnssec { dnssec_log; };
}
Переконфигурируем BIND:
$ sudo rndc reconfig
$ sudo rndc flush
И проверяем запрос:
> dig @127.0.0.1 4x4.org +retry=1 +dnssec +multiline
Флаг “ad” в полученном ответе должен быть установлен:
В журнале будет показан полный путь проверки имени, все том числе и проблемы с ключами и т.п:
Nov 5 21:41:35 ubuntu named[32464]: /etc/bind/named.conf:47: trusted key 'ru.' has a weak exponent
Nov 5 21:43:53 ubuntu named[32464]: not insecure resolving 'samag.ru/A/IN': 89.253.192.21#53
И так далее.
Настройка BIND в режиме мастер сервера
Чтобы настроить любой DNS сервер в качестве мастер сервера отвечающего за зону необходимо пройти несколько шагов:
- сгенерировать ZSC и KSK;
- прописать ключи в файл зоны;
- подписать зону
Для создания ключей и подписи зоны используются утилиты входящие в состав BIND, хотя доступны уже решения сторонних разработчиков, но о них в конце статьи. Ключевая парам генерируется при помощи dnssec-keygen. Общий формат вызова ее прост:
dnssec-keygen –a алгоритм –b длина –n тип имя_домена
Все параметры понятны, за исключением типа ключа. Их несколько в контексте статьи нас интересуют ZONE или HOST, с остальными можно познакомиться man странице.
Создаем ZSC:
$ dnssec-keygen –a RSASHA1 –b 1024 –n ZONE example.com
В некоторых дистрибутивах необходимо задать устройство, которое будет участвовать в выработке ключа “–r /dev/random”. В результате получим два файла вида:
Kdomain++.key - открытый ключ
Kdomain ++.private – закрытый ключ
В нашем примере это Kexample.com.+004+10141.key и Kexample.com.+004+10141.private
KSK ключ создается аналогично:
$ dnssec-keygen –r /dev/random -a RSASHA1 –b 1024 -n ZONE -f KSK example.com
Kexample.com.+004+34980.key
Kexample.com.+004+34980.private
Формат полученного файла содержащего публичный ключ, позволяет сразу его импортировать в зонный файл без дополнительных правок.
$ cat Kexample.com+004+10141.key
example.com. IN KEY 256 3 5 bzA2wu … U1asmQg==
$ cat Kexample.com +*.key >> /etc/bind/zones/db.example.com
Как вариант ключи можно подключить в файле зоны при помощи параметра $include.
Теперь необходимо подписать зону, то есть добавить RRSIG, NSEC и другие ассоциированные записи. Для этого вызывается утилита dnssec¬signzone:
dnssec¬signzone [¬o zonename] [¬N INCREMENT] [¬k KSK.key] zonefile [ZSK.key]
$ dnssec¬signzone ¬o example.com ¬k Kexample.com.+004+34980 \
/etc/bind/zones/db.example.com Kexample.com.+004+10141
В результате на выходе получим файл зоны — db.example.com.signed в котором ресурсные записи будут рассортированы по алфавиту, а записи содержать необходимые поля RRSIG, NSEC и DNSKEY.
Осталось добавить описание новой зоны в named.conf:
zone "example.com" {
type master;
file "/etc/bind/zones/db.example.com ";
};
Это все. Не забываем активировать параметр “dnssec-enable” в named.conf.
К слову в RedHat/Fedora доступны: командная “dnssec-configure” и графическая “system-config-dnssec” утилиты упрощающие настройку DNSSEC в BIND. Особых чудес, правда они не делают, просто добавляют нужные строки в секцию options файла named.conf.
Например, проверим статус DNSSEC:
# dnssec-configure -s -b
Bind DNSSEC:enabled
Bind DLV:disabled
Ряд проектов DNSSEC-tools, OpenDNSSEC [10] и Autotrust от от NLnet Labs [11], DICI Tools от RIPE NCC [12], DNSSEC-monitor [13] предлагают различные инструменты для более удобного управления зонами, наблюдения за DNSSEC зонами, обновления якорей и так далее. Например, утилита maketestzone входящая в состав DNSSEC-tools позволяет одной командой создать весь набор файлов, для тестовой зоны.
$ maketestzone example.com
***
Итак, процесс «выхода в массы» DNSSEC начался. Как мы видим во внедрении DNSSEC не все так однозначно, администраторам как минимум добавится работы, ведь теперь придется заботиться об актуальности ключевой информации. Это признают и сами разработчики. Будем надеяться, что к тому времени, когда поддержка этой технологии будет внедрена в корневых серверах и TLD, многие вопросы по управлению будут решены.
Ссылки:
1. С.Яремчук Технология борьбы со спамом DKIM. — //Системный администратор, №11, 2008г., — С. 34-39
2. Сайт DNSSEC — http://www.dnssec-deployment.org/, Российский — http://www.dnssec.ru/
3. Связанные RFC — http://www.dnssec.net/rfc
4. Заявление ICANN о переводе корневых серверов на DNSSEC — http://www.icann.org/en/announcements/announcement-24jul08-en.htm
5. Сайт проекта NSD — http://www.nlnetlabs.nl/projects/nsd/
6. Comparison of DNS server software — http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software
7. DNS Security Extensions (DNSSEC) в Windows 2008 R2 и Windows 7 — http://technet.microsoft.com/en-us/library/ee683904%28WS.10%29.aspx
8. Сайт проекта DNSSEC-tools — http://www.dnssec-tools.org/, http://dnssec-tools.sourceforge.net/
9. Доверенные анкоры сайтов — https://www.ripe.net/projects/disi/keys/, http://secspider.cs.ucla.edu/trust-anchors.conf, https://www.iks-jena.de/leistungen/dnssec.php, https//itar.iana.org/.DNSSEC-tools на Java — http://www.verisignlabs.com/dnssec-tools/
10. Сайт проект OpenDNSSEC — http://www.opendnssec.org/
11. Сайт Autotrust от NLnet Labs — http://www.nlnetlabs.nl/projects/autotrust/
12. DICI (Deployment of Internet Security Infrastructures) Tools от RIPE NCC — https://www.ripe.net/projects/disi/code.html
13. Сайт проекта DNSSEC-monitor — http://opensource.iis.se/trac/dnssec/wiki/DNSSEC-monitor
14. Сайт проекта java-dnssec-tools — http://www.verisignlabs.com/dnssec-tools/