DNSSec: Что такое и зачем. Проверка максимального значения TTL в доменной зоне. Принципы работы DNSSEC

Как оказалось, не так много людей знают что такое 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?» на семинаре этого совета.

Корпорация по управлению доменными именами и IP–адресами, ICANN, предупреждает о возможных перебоях в работе глобальной сети из–за обновления ключа шифрования запросов к серверам разрешения имён по протоколу DNSSEC, об этом сообщается в пресс–релизе ICANN .

Ключи шифрования протокола DNSSEC обновляются впервые с момента запуска системы 15 июля 2010 года, когда была подписана корневая зона, иногда именуемая «точкой», то есть зона, стоящая над доменами верхнего уровня, такими как.com., .ru., .org., .net. и другими (в интерфейсах браузеров замыкающая точка обычно опускается). Решение о перевыпуске «ключа подписи ключей», Key Signing Key или KSK, для корневой зоны несколько раз откладывалось, изначально планировалось, что корневая зона в целях безопасности будет заново подписываться каждые пять лет - первая замена ключа была запланирована на 2015 год. Опасения корпорации ICANN вызваны тем, что не все серверы DSN с поддержкой DNSSEC переключатся на использование нового ключа шифрования: единожды сконфигурированные серверы всё это время могли работать корректно, но их владельцы могли не учесть возможность обновления KSK.

Простой сервис настройки DNSSEC для владельцев доменов из российского сегмента, то есть в зонах ru, «рф» и su, предоставляют только три регистратора, которые также владеют и собственными серверами DNS: nic.ru , reg.ru и webnames.ru . Пока особой популярностью протокол не пользуется: из 5,6 млн российских доменов, по статистике регулирующего российские зоны «Координационного центра», число доменов с поддержкой DNSSEC на сентябрь 2018 года не превысило 3 000 штук, хотя в их число входят наиболее крупные и популярные ресурсы рунета. В тоже время наиболее популярный среди владельцев российских доменов сервис «Яндекс Коннект» не поддерживает DNSSEC, хотя «Яндекс.DNS» для домашних пользователей поддержку безопасного протокола обеспечивает. В глобальном доменном пространстве доменов, работающих по DNSSEC, на порядки больше: по данным statdns , из 135 млн доменов в одной только зоне com доменных имён с DNSSEC почти миллион.

В комментариях UPgrade все три российских регистратора, поддерживающих DNSSEC, заявили о том, что готовы к смене KSK, в настоящий момент они работают со старым ключом в активном режиме, а с новым ключом, открытая часть которого была опубликована ICANN ещё 11 сентября 2017 года, - в пассивном режиме. По команде ICANN регистраторы готовы поменять статус ключей и не ожидают сбоев. Крупнейшие держатели собственных серверов разрешения доменных имён не из числа регистраторов, «Ростелеком», «Мегафон», «Билайн» и МТС, в комментариях РБК заявили, что также готовы к смене ключа. Однако приведёт ли смена KSK к сбоям у владельцев менее крупных серверов DNS, например, у провайдеров в небольших городах, предугадать невозможно, хотя корпорация ICANN активно работает с техническими администраторами провайдеров, операторами связи и другими компаниями, работающими с интернет–инфраструктурой напрямую.

Служба DNS или Domain Name System была разработана практически одновременно с введением доменов в 1980–х годах. При обращении к доменному имени (например, сайт) через службу DNS интернет–провайдер находит IP–адрес (например, 87.236.16.85), соответствующий доменному имени. Владельцы доменов указывают на собственных DNS–серверах (например, ns1.beget.com) так называемые «ресурсные записи» (например, * A 87.236.16.85). Другие серверы DNS через некоторое время копируют эти записи и создают из них кэш, чтобы каждый раз не обращаться к исходному серверу. До введения DNSSEC серверы DNS безоговорочно доверяли информации друг друга, что делало их уязвимыми перед попытками злоумышленников «отравить кэш», то есть предоставить «доверчивому» серверу DNS запись с подменой IP–адреса на адрес злоумышленника. Таким образом посетители крупных ресурсов, онлайн–банков, социальных сетей, поисковых служб и прочих сайтов могли быть перенаправлены на поддельный ресурс.

Чтобы исключить отравление кэша DNS и другие угрозы были разработаны «расширения безопасности DNS», DNS Security Extensions или DNSSEC. Внедрение расширенного протокола замедлялось из–за его требовательности к вычислительным мощностям серверов и высокой нагрузки на сети. Упрощённый протокол DNSSEC–bis с обратной совместимостью с системой DNS ввёл в действие каскад не столь требовательных к вычислениям электронных сертификатов от корневой зоны до индивидуальных доменов, которые DNS–серверы могли бы на лету проверять на подлинность при каждом запросе. KSK корневой зоны требует периодического обновления: созданный в 2010 году 1024–битный ключ KSK–2010 в 2017 году был усложнён до 2048–битного KSK–2017 в ответ на повышение мировых вычислительных мощностей, которых могло бы хватить для подбора шифра.

Системы разрешения имен 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 - это расширение протокола 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.