Точки доверия dns что это

Обновлено: 07.07.2024

Служба доменных имен (DNS) — это распределенная база данных, представляющая пространство имен. Пространство имен содержит все сведения, необходимые любому клиенту для поиска любого имени. Любой DNS-сервер может отвечать на запросы о любом имени в своем пространстве имен. DNS-сервер отвечает на запросы одним из следующих способов:

Важно понимать основные возможности DNS, такие как делегирование, рекурсивное разрешение имен и интегрированные в Active Directory зоны DNS, так как они непосредственно влияют на структуру Active Directory логической структуры.

Дополнительные сведения о DNS и службах домен Active Directory (AD DS) см. в разделе DNS и AD DS.

Делегирование

Чтобы DNS-сервер ответил на запросы о любом имени, он должен иметь прямой или косвенный путь к каждой зоне в пространстве имен. Эти пути создаются с помощью делегирования. Делегирование — это запись в родительской зоне, которая содержит сервер доменных имен, полномочный для зоны на следующем уровне иерархии. Делегирование позволяет серверам в одной зоне ссылаться на клиентов на серверы в других зонах. На следующем рисунке показан один пример делегирования.

Делегирование использует два типа записей. В записи ресурса сервера имен (NS) содержится имя полномочного сервера. Записи ресурсов узла (A) и узла (AAAA) предоставляют адреса IP версии 4 (IPv4) и IP версии 6 (IPv6) полномочного сервера.

Эта система зон и делегирования создает иерархическое дерево, представляющее пространство имен DNS. Каждая зона представляет слой в иерархии, и каждое делегирование представляет собой ветвь дерева.

Используя иерархию зон и делегирования, корневой сервер DNS может найти любое имя в пространстве имен DNS. Корневая зона включает делегирования, которые напрямую или косвенно переводят на все другие зоны в иерархии. Любой сервер, который может запрашивать корневой DNS-сервер, может использовать сведения в делегировании для поиска любого имени в пространстве имен.

Рекурсивное разрешение имен

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

В некоторых конфигурациях DNS-серверы включают корневые ссылки (то есть список имен и IP-адресов), которые позволяют им запрашивать корневые серверы DNS. В других конфигурациях серверы пересылают все запросы, которые они не могут ответить на другой сервер. Пересылка и корневые указания являются методами, которые DNS-серверы могут использовать для разрешения запросов, для которых они не являются полномочными.

Разрешение имен с помощью корневых ссылок

Корневые ссылки позволяют любому DNS-серверу размещать корневые серверы DNS. После того как DNS-сервер обнаружит корневой сервер DNS, он может разрешить любой запрос для этого пространства имен. На следующем рисунке показано, как DNS разрешает имя с помощью корневых ссылок.

В этом примере происходят следующие события:

Разрешение имен с помощью пересылки

Пересылка позволяет маршрутизировать разрешение имен через определенные серверы вместо использования корневых ссылок. На следующем рисунке показано, как DNS разрешает имя с помощью пересылки.

31.01.2014

Windows Server 2012 R2

комментариев 5

Недостатки DNS

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

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

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

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

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

DNSSEC в системах Windows

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

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

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

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

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

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

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

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

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

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

В 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:

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

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

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

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

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

В Windows Server 2008 R2 включены мощные технологии, которые могут дать такую уверенность. Давайте сначала кратко пройдемся по основам DNS, а потом посмотрим, какие возможности открывают перед нами новые функции, такие как DNS Security Extensions (DNSSEC), DNS Devolution и DNS Cache Locking.

Недостатки обычной службы DNS

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

Даже использование нового механизма случайного выбора порта-источника, представленного в системе Server 2008 R2, не столько снижает риск, сколько увеличивает время, необходимое для проведения атаки. Случайное значение XID, посылаемое клиентом (и включаемое в ответ), передается в виде открытого текста, поэтому его легко дублировать. Кроме того, в существующей службе DNS на запрос клиента сервер DNS отвечает откликом, но если технология взлома позволяет перехватывать запросы и подделывать ответы, то имитация изначального отклика не составит труда.

DNSSEC для всех

Технология DNS Security Extensions (DNSSEC) представляет собой расширение стандарта DNS, описанное в документах RFC 4033, 4034 и 4035, которое было реализовано компанией Microsoft при создании серверной роли Server 2008 R2 DNS. Предыдущая версия технологии DNSSEC была описана в документе RFC 2535, который в дальнейшем был заменен документами RFC, указанными выше. Системы Windows Server 2003 и даже Server 2008 несовместимы с реализацией данной технологии на платформе Server 2008 R2.

По сути дела, DNSSEC обеспечивает целостность инфраструктуры DNS с помощью технологий, проверяющих подлинность получаемых данных, включая авторизованные ответы типа denial-of-existence. Верификация осуществляется с помощью технологии шифрования с открытым ключом, которая позволяет использовать цифровые подписи в ответах DNS. Успешная проверка подписи означает, что данные подлинные и им можно доверять. Цифровая подпись генерируется на основе закрытого ключа зоны DNS (он держится в секрете) и содержания записи и может быть проверена с помощью открытого ключа. Если пакет был создан подозрительным источником, проверка его подписи закончится неудачно, а если пакет был изменен, то его цифровая подпись не будет соответствовать содержанию.

В реализации шифрования с открытым ключом помогают новые типы записей DNS: DNS Public Key (DNSKEY), представляющий собой контейнер для открытого ключа зоны; Resource Record Signature (RRSIG), содержащий цифровую подпись ответа сервера; Delegation Signer (DS), используемый для обмена между дочерней и родительской зоной, при условии что для них разрешены механизмы DNSSEC; и Next Secure (NSEC), позволяющий обрабатывать проверенные записи denial-of-existence. NSEC использует эффективный механизм, при котором в ответ на запрос с несуществующим именем возвращается предшествующая запись (в алфавитном порядке) и уведомление о следующей безопасной записи. Например, если в зоне DNS описаны записи A и E, а вы запрашиваете запись С, то на выходе получите ответ A NSEC E с цифровой подписью. Таким образом система проинформирует вас, что запрашиваемой записи не существует, так как между A и E других записей не обнаружено.

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

Рисунок. Настройка якоря доверия

На сегодня данная схема работает для обычных сертификатов инфраструктуры PKI. На основной массе компьютеров настроено доверие определенным корневым центрам сертификации, размещенным в Интернете, таким как VeriSign, Thawte и Equifax. Данные центры предоставляют сайтам сертификаты, подписанные корневыми центрами сертификации. Клиенты доверяют корневым центрам сертификации, следовательно, они доверяют сертификатам, подписанным центрами сертификации, чьи полномочия подтверждены корневыми центрами. Цепочка DNS работает аналогично: клиенты доверяют корневым доменам и доменам верхнего уровня (предполагается, что корневые домены и домены верхнего уровня являются якорями доверия), которые в свою очередь гарантируют безопасность дочерних сайтов.

На данный момент корневая зона DNS и домен. COM не поддерживают использование механизмов DNSSEC, но с учетом того, что многие правительства по всем миру санкционируют использование технологии DNSSEC, стоит ожидать изменения ситуации в ближайшем будущем. Поддержка технологии DNSSEC в корневой зоне DNS должна быть реализована в конце 2010 года, в зоне COM — в 2011 или 2012 году. Таким образом, нам необходимо промежуточное решение, которое бы позволило клиентам устанавливать отношения доверия с зонами DNS, поддерживающими технологию DNSSEC.

В любом процессе, использующем цифровые подписи, нам необходим механизм, с помощью которого клиенты будут эти подписи проверять. В нашем случае проблема решается с помощью шифрования с открытым ключом. Открытый ключ для защищенной зоны DNS известен клиентам, которые используют его для проверки цифровой подписи, создаваемой с помощью закрытого ключа зоны DNS. Открытый ключ, назначенный для корневой зоны доверенного пространства имен DNSSEC — например, зоны. net, — называют якорем доверия. Он поддерживает отношение доверия между клиентом и пространством имен DNS. Если клиенту известен якорь доверия, он может построить цепочку аутентификации к любой дочерней зоне для данного якоря доверия. Исчезает необходимость в построении отношений доверия непосредственно между клиентами DNS и каждой зоны внутри пространства имен. И все же разворачивать в вашем окружении полную инфраструктуру PKI не требуется. Действительно, открытые ключи для зон безопасности хранятся внутри инфраструктуры DNS, но как узнать, кому доверять? Как получить якорь доверия в ситуации, когда корневая зона DNS не может подписывать дочерние зоны?

С помощью процесса, названного DNSEC Lookaside Validation (DLV), можно настроить отношение доверия между клиентами DNS и открытыми ключами. В Интернете существуют хранилища, в которые зоны с поддержкой технологии DNSSEC могут загружать открытые ключи. После этого ключи могут использоваться клиентами. Считается, что данные хранилища гарантируют легитимность находящихся в них ключей — точно так же мы доверяем центру VeriSign в процессе проверки компаний и выдачи им сертификатов с подписью кода или сертификатов SSL. Организация может скачать содержимое хранилища, и средствами Active Directory (AD) реплицировать информацию DNSSEC между всеми серверами DNS (механизм DLV не поддерживается платформой Server 2008 R2).

Кроме того, вы можете вручную настроить якоря доверия внутри службы DNS, указав имя зоны и открытый ключ, выдаваемый серверами именования (экран 1). После того как будет настроена точка входа (то есть якорь доверия) для цепочки доверия и вы зададите ключ подписывания ключа (подробнее я расскажу о нем ниже), необходимо установить флаги Secure Entry Point (SEP) и Zone Signing Key. Если вы хотите настроить общий доступ к открытому ключу, чтобы другая организация или хранилище могли добавить его в качестве якоря доверия, данная организация должна получить доступ к содержимому файла \%systemroot%\System32\dns\keyset- (экран 2).

Экран 1. Настройка доверия к откликами DNS

Экран 2. Настройка общего доступа к открытому ключу

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

Экран 3. Настройка требований DNSSEC для зоны

Чтобы активировать технологию DNSSEC для зоны в системе Server 2008 R2, используйте утилиту DnsCmd. Создайте ключи подписывания ключей и ключи подписывания зон и сохраните их в локальном хранилище сертификатов (MS-DNSSEC). Ключ подписывания зон (ZSK в приведенном ниже коде) подписывает все записи в зоне, а ключ подписывания ключей (KSK в коде) подписывает только другие ключи. Необходимо также создать запись ресурса DNSSEC в корне цепочки доверия (это происходит автоматически). Например, для создания моих сертификатов я использовал команды

При работе с зонами, интегрированными в каталог AD, необходимо сначала экспортировать зону в файл, подписать зону в файле с помощью сертификатов и сохранить ее в новый файл. Затем удалите существующую зону, импортируйте зону из файла и установите статус AD integrated. Вот основные команды, которые я использовал в своем окружении после создания вышеупомянутых сертификатов:

На экране 4 приведены различные записи DNSSEC.

Экран 4. Записи DNSSEC

DNS Devolution

Вы можете настраивать механизм DNS Devolution с помощью групповой политики, используя параметры Primary DNS Suffix Devolution и Primary DNS Suffix Devolution Level, расположенные в узле \Computer Configuration\Policies\Administrative\Templates\Network\DNS Client (экран 5). Также можно напрямую задать значения параметров реестра HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\UseDomainNameDevolution и HKEY_ LOCAL_MACHINE\SYSTEM\Current ControlSet\services\Dnscache\Parameters\DomainNameDevolutionLevel, управляющих работой функции DNS Devolution. Данный механизм полезен в окружениях с многоуровневым пространством имен DNS.

Экран 5. Настройка уровня регрессии

DNS Cache Locking

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

Функция DNS Cache Locking — новый механизм, появившийся в системе Server 2008 R2, позволяющий уменьшить негативный эффект от фальсификации кэша: он не дает перезаписывать записи кэша DNS в течение всего времени их жизни. То есть если кто-то пытается сфальсифицировать кэш, заменив в нем запись, сервер DNS проигнорирует такую замену. Таким образом поддерживается «чистота» кэша.

Для использования механизма Cache Locking необходимо задать процентную долю времени жизни записей кэша, в течение которых они будут защищены от перезаписи: например, значение 75 означает, что кэшированные записи не могут быть перезаписаны, пока не пройдет 75% времени их жизни. По умолчанию используется значение 100, означающее, что записи не могут быть перезаписаны в течение всего времени жизни. Однако можно изменить это значение, обратившись к параметру реестра HKEY_LOCAL_ MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters\CacheLockingPercent. Если значение не задано, используется настройка по умолчанию, то есть 100%.

Еще об NRPT

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

Помимо службы DNSSEC, таблица NRPT используется в работе еще одного ключевого механизма систем Windows 7 и Server 2008 R2, а именно новой функции DirectAccess, позволяющей клиентам с системой Windows 7 подключаться к корпоративным ресурсам, расположенным в любой точке Интернета, не используя каналы VPN. Клиент устанавливает соединение, и механизм DirectAccess обеспечивает безопасное обратное подключение.

Автоматическое использование DirectAccess при доступе к ресурсам вызывает один важный вопрос: как клиентская система Windows 7 определяет, к каким ресурсам корпоративной сети необходимо обращаться через механизм DirectAccess, а к каким — через обычное подключение к Интернету.

Выбор основывается на таблице NRPT: точно так же, как мы настраивали определенные действия механизма DNSSEC для различных имен DNS и IP-адресов, мы можем задать параметры обработки механизма DirectAccess с помощью вкладки DirectAccess, приведенной на экране 6. Если вы хотите проверить правила для данной машины, настроенные через групповую политику, обратитесь к разделу реестра HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig. Также вы можете создать исключения, позволяющие настроить глобальные правила для пространств имен, но в дальнейшем использовать альтернативные варианты обработки для определенного узла или части пространства имен.

Экран 6. Активация механизма DirectAccess

, и я рекомендую вам заменить им устаревшие службы Microsoft DNS, чтобы обеспечить максимальную безопасность работы.

Интересуетесь протоколом DNSSEC (расширениями безопасности системы доменных имен)? Нажмите на изображение ниже, чтобы изучить нашу инфографику с описанием принципов работы DNSSEC и преимуществ его развертывания.

Краткое описание принципов работы DNS

Для понимания протокола DNSSEC (расширения безопасности системы доменных имен) важно иметь общее представление о системе доменных имен (DNS).

Пользование интернетом на любом устройстве начинается с DNS. Представьте, например, момент ввода пользователем имени сайта в браузер на телефоне. Браузер при помощи stub-резолвера, являющегося частью операционной системы устройства, начинает преобразование доменного имени сайта в адрес интернет-протокола (IP-адрес). Stub-резолвер представляет собой простейший DNS-клиент, передающий запрос данных DNS более сложному DNS-клиенту, называемому рекурсивным резолвером. У многих сетевых операторов есть рекурсивные резолверы для обработки DNS-запросов — или просто запросов — отправляемых устройствами в их сети. (Менее крупные операторы и организации иногда пользуются рекурсивными резолверами других сетей, в том числе предоставляемыми открыто в качестве услуги, такими как Google Public DNS, OpenDNS и Quad9).

Сама по себе DNS не имеет системы защиты

Рассмотрим пример угрозы, которую представляет собой атака типа «отравление кэша». Представим, что пользователь заходит на сайт своего банка. Устройство пользователя запрашивает у заданного рекурсивного DNS-сервера IP-адрес сайта банка. Но некий злоумышленник мог отравить резолвер IP-адресом, который ведет не к настоящему сайту, а к сайту, созданному этим злоумышленником. Этот мошеннический сайт имеет вид сайта банка и выглядит точно так же. Ничего не подозревающий пользователь, вводит свое имя и пароль, как обычно. К сожалению, таким образом пользователь раскрывает свои учетные данные злоумышленнику, который затем может под видом этого пользователя войти в систему на настоящем сайте банка, чтобы перевести средства или совершить другие несанционированные действия.

Расширения безопасности DNS (DNSSEC)

Члены Инженерной проектной группы интернета (IETF) — организации, ответственной за стандарты протокола DNS — давно осознали проблему недостаточной надежности механизмов проверки подлинности в DNS. Работа над выработкой решения началась в 1990-х годах, и ее результатом стал протокол DNSSEC (расширения безопасности системы доменных имен).

Протокол DNSSEC позволяет повысить надёжность проверки подлинности в DNS при помощи цифровых подписей, основанных на криптографии открытого ключа. При использовании DNSSEC не запросы и ответы DNS подписываются криптографически, а сами данные DNS подписываются владельцем этих данных.

У каждой зоны DNS есть пара открытых/закрытых ключей. Владелец зоны использует ее закрытый ключ для подписания данных DNS в этой зоне и генерирования цифровых подписей для этих данных. Как следует из названия «закрытый ключ», сведения о нем держатся владельцем зоны в секрете. А вот открытый ключ зоны публикуется в ней свободно, и получить его может каждый. Любой рекурсивный резолвер, производящий поиск данных в зоне, также получает открытый ключ этой зоны и использует его для проверки подлинности данных DNS. Резолвер проверяет подлинность цифровой подписи полученных им данных DNS. Если подлинность подтверждается, то данные DNS считаются настоящими и возвращаются пользователю. Если подпись не проходит проверку подлинности, то резолвер предполагает, что произошла атака, избавляется от данных и сообщает пользователю об ошибке.

Применение DNSSEC позволяет обеспечить две важные функции в DNS:

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

Доверие к ключам DNSSEC

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

Проверка подлинности и подписание посредством DNSSEC

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

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

Дальнейшие действия, связанные с DNSSEC

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

Читайте также: