Настройка dns зоны c использованием dnssec cisco. Зачем нужна технология DNSSEC

Смотреть видеоурок

DNSSEC - это расширение протокола DNS, использующее цифровую подпись данных DNS для обеспечения безопасности процесса преобразования доменных имен. Общую информацию о DNSSEC и его использовании можно найти на и https://tools.ietf.org/html/rfc6781 .

Примечание . Поддержка DNSSEC доступна в Plesk для Linux. Провайдер хостинга должен установить расширение Plesk DNSSEC в Plesk.

Вы можете делать следующее для защиты данных DNS ваших доменов с помощью DNSSEC:

  • Подписывать зоны или удалить подпись в соответствии со спецификациями DNSSEC
  • (Необязательно) Указывать индивидуальные настройки для создания ключей
  • Получать уведомления
  • Просматривать и копировать записи ресурсов DS
  • Просматривать и копировать наборы записей ресурсов DNSKEY.
Подписание доменной зоны

Чтобы начать использовать защиту DNSSEC для своей зоны DNS, подпишите эту зону. Plesk подписывает зону автоматически создаваемыми подписями, используя две пары асимметричных ключей: для подписи ключа - Key Signing Key (KSK) и для подписи зоны - Zone Signing Key (ZSK).

Чтобы подписать доменную зону:

Обновление записей DS в родительской зоне

Если в родительской зоне содержатся устаревшие записи DS, доменное имя больше не преобразуется службой DNS.

Необходимо вручную добавить или обновить записи DS в родительской зоне во всех случаях, когда ключи DNSSEC были обновлены, а именно:

  • Вы подписали доменную зону с помощью вновь созданных ключей.
  • Произошло обновление KSK (Key Signing Key).

Plesk отправляет вам уведомления и дает некоторое время на обновление записей DS - этот период времени равен одному периоду обновления KSK. В течение этого периода предыдущие записи DS все еще действительны.

Если вы удалили подпись доменной зоны, необходимо вручную удалить записи DS из родительской доменной зоны.

Чтобы обновить записи DS в родительской зоне:

Для домена в Plesk, чья родительская зона находится вне Plesk, обновите записи DS у своего регистратора домена.

Для субдомена домена, размещенного в Plesk, чья зона DNS находится в Plesk:

  1. Перейдите на страницу настроек DNS родительского домена (Сайты и домены > родительский домен > Настройки DNS ).
  2. Добавьте новые записи типа DS (Добавить запись ) и вставьте показываемые Plesk значения в поле Записи ресурсов DS в настройках DNSSEC субдомена.
Удаление подписи доменной зоны

Удаление подписи доменной зоны отключает защиту DNSSEC для этой зоны. Вам может потребоваться удалить подпись зоны, если были скомпрометированы ключи, чтобы затем подписать зону снова новыми ключами.

Чтобы удалить подпись доменной зоны:

  1. Перейдите на страницу Сайты и домены > выберите домен > DNSSEC и нажмите Удалить подпись .
  2. Удалите записи ресурсов DS из родительской зоны. В противном случае имя домена не будет преобразовываться.

Примечание . При удалении подписи зоны ключи не удаляются из Plesk. Вы можете снова подписать зону с помощью тех же ключей.

Просмотр записей ресурсов DNSKEY

Вам может понадобиться получить записи ресурсов DNSKEY, содержащие открытые части ключей Key Signing Keys, которые используются для домена.

Для просмотра записей DNSKEY:

  1. Перейдите на страницу Сайты и домены > выберите домен > DNSSEC.
  2. Нажмите Просмотр записей DNSKEY .

Leave your feedback on this topic here

If you have questions or need support, please visit the Plesk forum or contact your hosting provider.
The comments below are for feedback on the documentation only. No timely answers or help will be provided.

Please enable JavaScript to view the comments.

Системы разрешения имен DNS, являющаяся одной из основ современной системе сетевых взаимодействий, разрабатывалась более 20 лет назад, когда о вопросах защиты информации почти не задумывались. Одним из основных недостатков системы DNS является возможность подделки ответа на DNS запрос.

Проблема в том, достоверность ответа DNS-сервера никак не проверяется, это означает, что в случае взлома DNS сервера (и перенаправления его на ложные DNS сервера), подделки DNS записи, отравлении кэша DNS (DNS cache poisoning), можно отправить пользователя на произвольный IP адрес, причем пользователь будет находится в полной уверенности, что он работает с легитимным сайтом или сервисом. Этими методиками широко используют злоумышленники, перенаправляя пользователей на сайты, содержащие вредоносные коды или собирая их личные данные (пароли, номера кредиток и т.п.) с помощью т.н. pharming атак.

Зачем нужна технология DNSSEC

DNS Security Extensions (DNSSEC) – технология, предназначена для повышения безопасности службы DNS за счет использования криптографических подписей, позволяющих однозначно удостоверится в подлинности информации, полученной от DNS сервера. Т.е. все запросы и ответы DNS сервера с поддержкой DNSSEC должны обладать цифровой подписью, верность которой может проверить клиент с помощью открытого ключа. Эти цифровые подписи создаются при подписывании зоны (применения к ней DNSSEC).

Упрощенно механизм проверки DNSSEC работает так: клиент отправляет запрос на DNS сервер, сервер возвращает DNS ответ с цифровой подписью. Т.к. клиент обладает открытым ключом центра сертификации, подписавшего записи DNS, он может расшифровать подпись (хэш-значение) и проверить ответ DNS. Для этого и клиент и сервер DNS должны быть настроены на использование одного якоря доверия (trust anchor). Trust anchor – предварительно настроенный открытый ключ, связанный с конкретной зоной DNS. Если DNS сервер поддерживает несколько зон, то может использоваться несколько якорей доверия.

Важно отметить, что основное предназначение DNSSEC – защита от подделки и модификации DNS-запросов и ответов. Но сами передаваемые по сети данные не шифруются (хотя конфиденциальность передаваемых DNS данных и может быть обеспечено с помощью шифрования, но это опционально и не является основной целью DNSSEC).

Основные компоненты DNSSEC определены в следующих стандартах RFC:

  • RFC 4033
  • RFC 4034
  • RFC 4035

DNSSEC в системах Windows

Поддержка технология DNSSEC появилась еще в Windows Server 2008 R2 и Windows 7. Однако из-за сложности и неочевидности настроек, широкого распространения она не получила. Свое дальнейшее развитие DNSSEC получила в Windows Server 2012, в котором функционал DNSSEC был существенно расширен, и предполагает возможность настройки через графический интерфейс.

В этой статье мы опишем базовую установку и настройку DNSSEC на базе DNS сервера с ОС Windows Server 2012, создадим подписанную зону и точки доверия.

Установка и настройка DNSSEC в Windows Server 2012

Создадим новую DNS зону dnssec.contoso.com и добавим в нее одну A запись сервера SRV12 с адресом 192.168.1.14.

Примечание . В Windows 8/2012 вместо утилиты nslookup для получения информации с DNS сервера лучше воспользоваться Powershell командлетом Resolve-DnsName.

Resolve-DnsName srv12.dnssec.contoso.com –Server SRV12-SUB-CA –DnssecOk

Т.к. зона не подписана, запрос не вернет записи RRSIG.

Подпишем цифровым сертификатом внутреннюю DNS зону dnssec.contoso.com. Для этого в консоли DNS щелкните правой кнопкой по зоне и выберите пункт DNSSEC->Sign the Zone .

В появившемся мастере Zone Signing Wizard оставьте все параметры по умолчанию (Use default settings to sign the zone) -> Next -> Next -> Finish.

После окончания работы мастера в подписанной зоне автоматически создадутся следующие новые ресурсные записи:

  • RRSIG (Resource Read Signature) — подпись ресурсной записи
  • DNSKEY (A Public Key) – хранит публичную часть ключа и его идентификаторы
  • DS (Delegation Signer) – содержит хэш доменного имени наследника и его ключа KSK
  • NSEC (Next Secure) и NSEC3 (Next Secure 3) – используется для надежной защиты от spoofing атак

После того, как зона подписана, открытый ключ будет сохранен в файле %windir%\system32\dns\keyset-dnssec.

Импортируем в DNS открытый ключ зоны (тот самый якорь доверия), перейдя в консоли DNS в раздел Trust Point, выбрав import -> DNSKEY, и указав путь к файлу keyset-dnssec.

Примечание . Данный ключ необходимо распространить на все DNS сервера, которым будут участвовать в процессе безопасного кэширования данных подписанной зоны.

В результате импорта ключа в разделе Trust Points -> dnssec появится два ключа типа DNSKEY (один ключ активный, другой — standby).

В Windows Server 2012 возможно автоматически реплицировать ключи якорей доверия (Trust Anchors) по всем контролерам домена в лесу, обслуживающем данную зону DNS. Для этого в свойствах нужной зоны (dnssec) на вкладке Trust Anchor включите опцию Enable the Distribution of Trust Anchors for this zone и сохраните изменения.

Попробуем еще раз опросить данную зону с клиента.

Как мы видим, в ответе DNS сервера есть информации об RRSIG записи и цифровой подписи.

Настройка клиентов WIndows на использование DNSSEC

Чтобы заставить клиентов на ОС Windows принудительно использовать только «безопасные» (DNSSEC) запросы, т.е. принимать DNS данные только в том случае, если их цифровая подпись верна, необходимо с помощью GPO задействует политику NRPT (Name Resolution Policy Table).

Для этого в разделе GPO Computer Configuration -> Polices -> Windows Settings -> Name Resolution Policy на вкладке DNSSEC включите опции:

  • Enable DNSSEC in this rule
  • Require DNS clients to check that name and address data has been validated by the DNS server

Осталось назначить политику на нужную OU. После применения политики убедимся, что клиент настроен на использование «безопасного» DNS:

Get-DnsClientNrptPolicy

Значение DNSSecValidationRequired=True , т.е. на клиенте требуется обязательная валидация ответов DNS.

В том случае, если полученный от DNS сервера ответ не будет подписан, или будет подписан неверным сертификатов, команда вернет ошибку Unsecured DNS packet .

DNSSEC для внешних зон

Чтобы DNS сервер требовал обязательной проверки DNSSEC для внешних зон, нужно в его свойствах на вкладке Advanced включить опцию Enable DNSSEC validation for remote responses .

Импортировать якоря доверия корневых зон можно вручную (описано выше), либо с помощью команды:

Dnscmd /RetrieveRootTrustAnchors

Совет . Для корректной работы DNSSEC необходимо внести ряд изменений в межсетевые экраны:

  1. Открыть в обе стороны порт 53 порт протоколов TCP и UDP
  2. Т.к. размер данных в пакете DNSSec превышают 512 байт, необходимо разрешить прохождение DNS пакетов более 512 байт по UDP и TCP
Как оказалось, не так много людей знают что такое DNSSec, для чего он нужен, для чего нет и стоит ли его внедрять у себя. Так как на русском языке информации на этот счет мало, я постараюсь пролить свет на эти вопросы.

Кроме того, NSEC3 запись имеет поле флагов, которого нет у NSEC. На данный момент определен только один флаг - OPT-OUT, благодаря которому существует возможность подписывать не всю зону (что при больших размерах может быть весьма длительным процессом), а только те доменные имена, для которых есть DS записи.
С одной стороны OPT-OUT позволяет сильно сократить время подписи, однако при его использовании, наличие у злоумышленника доступа к файлу зоны позволяет ему добавить незащищенную запись, которая в дальнейшем может доставить проблемы.

Механизм работы
Допустим мы хотим узнать адрес test.bar.example.com:
  1. Мы запрашиваем доменное имя у резолвера;
  2. Резолвер выставляет бит DO и запрашивает test.bar.example.com у корневого сервера;
  3. Резолвер знает, что корневая доменная зона подписана - у него указан ключ или хэш ключа для нее (так называемый trust-anchor), поэтому он запрашивает у корневого сервера DNSKEY записи для корневой зоны и сверяет полученное с имеющимся;
  4. Корневой сервер не знает такого доменного имени, да и вообще максимум что ему известно - на каких серверах располагается зона com, он и сообщает адреса этих серверов нашему резолверу вместе с подписанной DS записью для зоны com;
  5. Резолвер валидирует DS запись полученным и проверенным ZSK ключом корневой зоны;
  6. Теперь резолвер знает, что зона com подписана, так что он спрашивает у ее DNS сервера DNSKEY и валидирует их, после чего интересуется про bar.example.com. Естественно, что сервер зоны com про таких не знает, ему только известно, что зона example.com живет на ns.example.com и ns1.example.com, именно это он и отвечает резолверу вместе с - да-да - DS записью;
  7. Так резолвер выстроил цепочку доверия до example.com, где он узнает серверы имен зоны bar.example.com и ее DS;
  8. В конце концов резолвер итеративно узнает адреса DNS серверов, отвечающих за bar.example.com, идет к ним и наконец-то получает желаемое, валидирует всю информацию и отдает нам адресную запись, выставив в ответе бит AD.
При невозможности что-то провалидировать резолвер вернет servfail.
Оказываемые эффекты
  1. Исходящий трафик авторитетного DNS сервера увеличивается примерно в 4 раза;
  2. Размер файла зоны после подписи (без OPT-OUT) вырастает в 6-7 раз;
  3. Увеличение длины ключа приводит к заметному снижению qps резолвера, на авторитетный сервер влияет в меньшей степени;
  4. Наоборот действует увеличение кол-ва итераций при использовании NSEC3;
  5. DNSSec приводит к значительному увеличению DNS ответа и, следовательно, необходимо чтобы все сетевое оборудование корректно работало с DNS пакетами более 512 байт.

Зачем это нужно

Это сложный вопрос. Во-первых, надо учитывать создаваемые эффекты; во-вторых, требуется организовать надежное хранилище для ключей; в-третьих, следить за ротацией ключей; в-четвертых, следить за сроком годности подписей; в-пятых, DNSSec усиливает эффект amplified ddos.
Все это является платой за то, чтобы быть уверенным в информации, получаемой от авторитетных DNS серверов. Сейчас, правда, сообщество придумывает что еще можно включить в DNSSec, чтобы его можно было монетизировать, а некоторые и вовсе задаются весьма смелыми и интересными вопросами, например Phil Regnauld, член научного совета AFNIC, поинтересовавшийся «Will DNSSEC bring down the certificate industry?» на семинаре этого совета.

We all know that DNS is a protocol which resolves domain names to IP addresses, but how do we know the authenticity of the returned IP address? It is possible for an attacker to tamper a DNS response or poison the DNS cache and take users to a malicious site with the legitimate domain name in the address bar. DNS Security Extensions (DNSSEC) is a specification which aims at maintaining the data integrity of DNS responses. DNSSEC signs all the DNS resource records (A, MX, CNAME etc.) of a zone using PKI (Public Key Infrastructure). Now DNSSEC enabled DNS resolvers (like Google Public DNS) can verify the authenticity of a DNS reply (containing an IP address) using the public DNSKEY record.

DNSSEC Resource Records

A Resource Record (RR) contains a specific information about the domain. Some common ones are A record which contains the IP address of the domain, AAAA record which holds the IPv6 information, and MX record which has mail servers of a domain. A complete list of DNS RRs can be found .

Likewise DNSSEC too requires several RRs.

  • DNSKEY Holds the public key which resolvers use to verify.
  • RRSIG Exists for each RR and contains the digital signature of a record.
  • DS - Delegation Signer – this record exists in the TLD"s nameservers. So if example.com was your domain name, the TLD is "com" and its nameservers are a.gtld-servers.net. , b.gtld-servers.net. up to m.gtld-servers.net. . The purpose of this record is to verify the authenticity of the DNSKEY itself.

Setup Environment

Domain Name: example.com

I used a real .COM domain to do this, but have replaced it with example.com for this article.

Master Nameserver:
IP Address: 1.1.1.1
Hostname: master.example.com
OS: Debian 7

Slave Nameserver:
IP Address: 2.2.2.2
Hostname: slave.example.com
OS: CentOS

File locations and names

The names and locations of configuration and zone files of BIND different according to the Linux distribution used.

Debian/Ubuntu

Service name:
bind9
Main configuration file:
/etc/bind/named.conf.options
Zone names file:
/etc/bind/named.conf.local
Default zone file location:
/var/cache/bind/

CentOS/Fedora

Service name:
named
Main configuration and zone names file:
/etc/named.conf
Default zone file location:
/var/named/

These may change if you"re using bind-chroot . For this tutorial, I"ve used Debian for the Master NS and CentOS for the Slave NS, so change it according to your distribution.

DNSSEC Master Configuration

Enable DNSSEC by adding the following configuration directives inside options{ }

nano /etc/bind/named.conf.options

Dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto;

It is possible that these are already added in some distributions. Navigate to the location of your zone files.

Cd /var/cache/bind

Create a Zone Signing Key(ZSK) with the following command.

Dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE example.com

The first tool is a simple one, while the second gives you a visual representation of things. Here is a screenshot from the first tool.

Notice the lines I"ve marked. The first one mentions the Key tag value (62910) of the DS record while the second one key id (40400) of the DNSKEY record which holds the ZSK (Zone Signing Key).

Modifying Zone Records

Each time you edit the zone by adding or removing records, it has to be signed to make it work. So we will create a script for this so that we don"t have to type long commands every time.

Root@master# nano /usr/sbin/zonesigner.sh #!/bin/sh PDIR=`pwd` ZONEDIR="/var/cache/bind" #location of your zone files ZONE=$1 ZONEFILE=$2 DNSSERVICE="bind9" #On CentOS/Fedora replace this with "named" cd $ZONEDIR SERIAL=`/usr/sbin/named-checkzone $ZONE $ZONEFILE | egrep -ho "{10}"` sed -i "s/"$SERIAL"/"$(($SERIAL+1))"/" $ZONEFILE /usr/sbin/dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) -N increment -o $1 -t $2 service $DNSSERVICE reload cd $PDIR

Save the file and make it executable.

Root@master# chmod +x /usr/sbin/zonesigner.sh

Whenever you want to add or remove records, edit the example.com.zone and NOT the .signed file . This file also takes care of incrementing the serial value, so you needn"t do it each time you edit the file. After editing it run the script by passing the domain name and zone filename as parameters.

Root@master# zonesigner.sh example.com example.com.zone

You do not have to do anything on the slave nameserver as the incremented serial will ensure the zone if transferred and updated.

Securing the DNSSEC setup from Zone Walking

Zone Walking is a technique used to find all the Resource Records of a zone by querying the NSEC (Next-Secure) record. NSEC3 was released which "hashed" this information using a salt. Recall the dnssec-signzone command in which we specified a -3 option followed by another elaborate command to generate a random string. This is the salt which can be found using the following dig query.

# dig NSEC3PARAM example.com. @master.example.com. +short 1 0 10 7CBAA916230368F2

All this makes zone walking difficult but not impossible. A determined hacker using rainbow tables can break the hash, though it"ll take a long time. To prevent this we can recompute this salt at regular intervals, which makes a hacker"s attempt futile as there is a new salt before he/she can find the hash with the old salt. Create a cron job to do this for you using the zonesigner.sh script we created previously. If you run the cronjob as root you don"t have to worry about file ownership. Or else make sure the user under whom you"re placing the cron has write permission on the zone directory and read permission on the private keys (Kexample.com.*.private).

Root@master:~# crontab -e 0 0 */3 * * /usr/sbin/zonesigner.sh example.com example.com.zone

This will sign the zone every 3 days and as a result a new salt will be generated. You"ll also receive an email containing the output of the dnssec-signzone command.

В системе DNS долгое время не было механизмов защиты от подмены информации. Это значит, что операция обмена данными между клиентом (резолвером) и сервером провайдера не была застрахована от вторжения «третьей стороны» (злоумышленника). Он перехватывает запрос резолвера, возвращает ему произвольный IP-адрес, вместо запрашиваемого. Также атака переходит и на серверы провайдера: их кэш заполняется ложными данными.

Протокол-DNSSEC исключает из цепи возможного злоумышленника. Если ответ на запрос резолвера проходит проверку на авторитетность, то «кража» и «подмен» будут обнаружены и предотвращены сразу.

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

Ключ состоит из 2 частей:

  • Секретная часть известна только владельцу ключа и хранится в безопасном месте. Используется для генерирования электронной подписи.
  • Публичная часть может быть опубликована и доступна для проверки подписей, осуществленных секретной частью ключа. Открытая часть ключа подписи вычисляется, как значение некоторой функции от закрытой части ключа, но знание открытой части ключа не дает возможности определить закрытый ключ.

В работе DNSSEC используется 2 типа ключей:

    ZSK — ключ подписывания зоны . Используется для подписывания наборов ресурсных записей доменной зоны. Обычно, имеется один ключ, которым подписываются данные зоны, но допускается и несколько ключей. Например, могут быть ключи для каждого из разных алгоритмов цифровой подписи. Важной концепцией DNSSEC является то, что ключ, которым подписаны данные зоны, ассоциирован с самой зоной, а не с ответственным сервером имён зоны.

    KSK — ключ подписывания ключей . Используется для подписывания ключей ZSK. Он также связывает цепочкой доверия вашу и родительскую доменные зоны.