Принципы безопасного развертывания сервисов DNS

Введение

Рассмотрим сервис DNS и принципы его безопасного развертывания, а именно следующее:

Безопасность DNS

Рассмотрим общие принципы безопасного развертывания сервисов DNS. Начнем с анализа целей безопасности и согласованных подходов к защите всех компонентов DNS.

Спецификации механизмов безопасного развертывания сервисов DNS приводятся в следующих документах:

Сервисы DNS

Интернет представляет собой самую большую компьютерную сеть. С точки зрения пользователя, каждый узел или ресурс в этой сети идентифицируется уникальным именем – так называемым доменным именем. Некоторыми примерами ресурсов Интернет, для которых определяются доменные имена, являются:

С точки зрения сетевого оборудования (например, роутера), которое перенаправляет коммуникационные пакеты по Интернет, уникальный ресурс идентифицируется IP-адресом, который представляет собой набор из четырех чисел, разделенных точками (например, 123.67.43.245). Для доступа к ресурсам Интернета по доменным именам, понятным пользователям, а не по этим IP-адресам, пользователям нужна система, которая преобразовывает доменные имена в IP-адреса и обратно. Такое преобразование является первоочередной задачей сервисов, называемых Domain Name System (DNS).

Пользователи получают доступ к ресурсам Интернета (например, web-серверу) с помощью соответствующей клиентской программы (например, web-браузера), указывая доменное имя этого ресурса. Для соединения с web-сервером и получения соответствующей web-страницы браузеру необходим IP-адрес этого имени. Браузер вызывает функцию DNS для получения данной информации. Функция отображения доменных имен в IP-адреса, которую предоставляет DNS, называется name resolution (разрешение имен). Протокол, который используется для выполнения функции разрешения имен, называется DNS-протокол.

Функция DNS, описанная выше, включает следующие составные части. Во-первых, необходимо иметь репозиторий для хранения доменных имен и соответствующих им IP-адресов. Так как количество доменных имен весьма велико, то основными требованиями являются масштабируемость и эффективность. Это означает, что данный репозиторий должен быть распределенным. Доменные имена могут также нуждаться в репликации для защиты от разного рода сбоев. Также должно существовать ПО, которое управляет этим репозиторием и предоставляет функцию разрешения имен. Эти две функции (управление репозиторием доменных имен и предоставление сервиса разрешения имен) выполняются компонентой DNS, называемой name-сервер. Существует несколько категорий name-серверов, различаемых по типу обрабатываемых данных и выполняемым функциям. Для доступа к сервисам, предоставляемым name-сервером, от имени пользовательских программ, существует другой компонент DNS, называемый resolver. Существуют две основных категории resolver’ов – рекурсивный name-сервер и stub resolver, различающиеся по своим возможностям. Коммуникационный протокол, различные компоненты DNS, политики, которые определяют конфигурацию этих компонент, процедуры создания, хранения и использования доменных имен составляют инфраструктуру DNS.

Инфраструктура DNS

Инфраструктура DNS состоит из вычислительных и коммуникационных элементов, географически распределенных по всему миру. Для того, чтобы понять инфраструктуру DNS, необходимо, во-первых, проанализировать структуру доменных имен. Пространство доменных имен организовано в виде иерархической структуры. Самым верхним уровнем иерархии является root domain, который представим в виде точки ("."). Следующий уровень называется top-level domain (TLD) (домен верхнего уровня). Существует только один root domain, но много TLDs. Каждый TLD называется дочерним доменом от домена root. В данном контексте root домен является родительским доменом, потому что он на один уровень выше TLD. Каждый TLD, в свою очередь, может иметь много дочерних доменов. Дочерние домены для TLDs называются second-level или enterprise-level доменами (доменами второго уровня).

Символ, обозначающий root-домен, обычно опускается. Например, рассмотрим доменное имя marketing.example.ru. Самая правая часть данного доменного имени ( ".ru" ) является TLD. Следующая часть ( "example" ) есть домен второго или enterprise уровня. Самая левая часть ( "marketing" ) есть домен третьего уровня. Также возможно существование доменов четвертого, пятого и т.д. уровней. Каждая из частей в marketing.example.ru называется доменом, конкатенация всех этих частей от текущего уровня до TLD называется полностью определенным доменным именем (Fully Qualified Domain Name – FQDN). Однако часто FQDN называется просто доменным именем.

Существует только один root домен. Существуют более 250 TLDs, разделенных на следующие категории:

Имеется несколько миллионов доменов второго уровня.

В инфраструктуре DNS насчитывается большое количество name-серверов. Каждый name-сервер содержит информацию о части пространства доменных имен и связан с определенным уровнем. Существует 13 name-серверов, связанных с уровнем root; они называются root servers. Два из этих серверов расположены в частной корпорации VeriSign в США; остальные функционируют в добровольных организациях по всему миру. Организации, в которых функционируют name-серверы, связанные с TLD, называются registries. Обычно ссTLDs поддерживаются специально назначенными регистрационными органами в каждой стране, gTLDs поддерживаются глобальными регистрационными органами. Например, VeriSign в настоящее время управляет name-серверами для .org и .net TLDs, непрофицитная организация, называемая Public Internet Registry (PIR), управляет name-серверами для .org TLD; другая непрофицитная организация, называемая EDUCAUSE, управляет name-серверами для .edu TLD. Однако все эти регистрационные органы могут быть изменены. Name-серверы, связанные с доменами второго уровня и ниже, выполняются либо непосредственно в организациях, которые владеют этими доменами, либо у Интернет Сервис Провайдера (ISP) или провайдеров других сервисов.

Инфраструктура DNS функционирует посредством соглашения среди различных участников, включая организации, в которых функционируют root-серверы, registries, в которых функционируют TLDs, и т.п. Непрофицитная корпорация Internet Corporation for Assigned Names and Numbers (ICANN) действует в качестве технического координатора всех аспектов, касающихся DNS. Например, ICANN формулирует политики для управления root-серверами. ICANN также отвечает за создание новых TLDs.

Пользователь (как индивид, так и корпорация), желающий зарегистрировать доменное имя (которое может быть не выше второго уровня), должен обратиться к своему уполномоченному органу, называемому регистратором (registrar). Регистраторами являются компании, которые уполномочены выделять доменные имена в конкретном TLD конечным пользователям или организациям. Регистраторы существуют во всем мире. Когда регистратор получает запрос на регистрацию, он проверяет в соответствующем реестре, что имя свободно, и регистрирует его в данном реестре.

Владельцы доменных имен второго уровня часто создают дочерние домены, чтобы различные ресурсы, расположенные в их домене, могли быть доступны в Интернете. Например, собственник имени домена example.ru может создать поддомен unit для того, чтобы ресурсы, связанные с подразделением, могли быть доступны в Интернете. Аналогично, поддомены могут создавать свои поддомены (в данном контексте, домены третьего уровня) для доступа к своим ресурсам из Интернета. Очень часто в некоторой организации, которая является собственником домена второго уровня, определено много доменов третьего уровня, но в каждом из них существует всего несколько ресурсов, доступных из Интернета (web-серверов, прикладных серверов и т.п.). Следовательно, неэкономично связывать уникальный name-сервер с каждым из доменов третьего и более низкого уровня. Более того, с точки зрения администрирования, удобнее сгруппировать всю информацию, относящуюся к основному домену организации (например, домену второго уровня) и всем его поддоменам, в единый ресурс и управлять им как одним блоком.

Чтобы облегчить возможность такого группирования, в DNS определено понятие "зоны". Зоной может являться либо весь домен, либо домен с группой поддоменов. Зона является конфигурируемой сущностью внутри name-сервера, которая описывает все ресурсы Интернета, относящиеся к домену и выбранному множеству поддоменов. Таким образом, зоны — это административно созданные блоки пространства имен DNS, а домены — структурно созданные блоки. Как результат, термин зона обычно используется и для ссылки на домен, который управляется как отдельная административная единица (например, зона root, зона .ru). Будем использовать термин зона для ссылки на ресурсные записи, которые содержат информацию о доменных именах для одного или более доменов и управляются как единая административная сущность. Другими словами, зона есть конфигурируемый ресурс внутри развернутого name-сервера.

Имея общее представление об инфраструктуре DNS (name-серверах и resolver’ах), доменных именах, зонах, name-серверах различного уровня (например, root-сервера и TLD-сервера) и resolver’ах, функцию разрешения имени теперь можно определить более детально. Когда пользователь вводит URL ресурса (например, www.example.ru) в web-браузер, программа браузера соединяется с resolver’ом, тип которого называется stub resolver, который, в свою очередь, соединяется с локальным name-сервером (называемым рекурсивным name-сервером или resolving name-сервером). Рекурсивный name-сервер проверяет свой кэш, чтобы узнать, имеется ли там корректная информация (информация определяется как корректная на основе критерия, который будет описан далее) об IP-адресе для этого ресурса. Если такой информации нет, то рекурсивный name-сервер проверяет кэш, чтобы узнать, имеется ли информация, относящаяся к name серверу для зоны example.ru (так как считается, что эта зона содержит ресурс www.example.ru). Если IP-адрес name-сервера есть в кэше, следующий запрос resolver’а будет перенаправлен на данный name-сервер. Если IP-адреса name-сервера для example.ru нет в кэше, то resolver определяет, имеется ли у него информация о name-сервере для зоны, которая расположена на один уровень выше, чем example.ru (т.е. ru ).

Если полный поиск в кэше (как описано выше) не принес требуемой информации, рекурсивный name-сервер не имеет альтернативы и начинает свой поиск с запроса name-сервера самой верхней зоны в иерархии пространства имен DNS (т.е. root-сервера). Если поиск в кэше успешен, то рекурсивный name-сервер запрашивает name-серверы в одном из уровней ниже зоны root (в нашем случае либо example.ru, либо .ru ). Так как множество итеративных запросов, начинающихся от root-сервера, аналогично множеству запросов, начинающихся от любых серверов более низкого уровня, опишем процесс разрешения имен, который начинается с запроса, посылаемого к root-серверу рекурсивным name-сервером второго уровня.

Соединение с root-сервером возможно благодаря файлу, называемому root.hint, который есть в каждом name-сервере. Файл root.hint содержит IP-адреса нескольких root-серверов. Root-сервер, в свою очередь, содержит информацию о name-серверах в своих дочерних зонах (т.е. TLDs). TLD (например, .ru ) содержит информацию о name-серверах для своих дочерних зон (например, example.ru ). Информация name-сервера о name-серверах в своих дочерних зонах называется информацией делегирования. Информация делегирования является информацией, которая используется для перенаправления запросов разрешения имен для ресурса, расположенного ниже, чем данный, в иерархии доменных имен. Пусть запрос разрешения имени относится к ресурсу в домене третьего уровня (www.example.ru). Root сервер перенаправляет запрос name-серверу более низкого уровня. Ответ рекурсивному name-серверу, который включает посылку информации делегирования, называется referral. В данном случае referral предоставляет IP-адрес name-сервера для TLD-зоны, которая соответствует запросу (т.е. .ru зона, так как запрос выполняется для ресурса в example.ru ). Используя данный referral, рекурсивный name-сервер затем формулирует и посылает запрос к name-серверу зоны .ru. Данный сервер уже предоставит referral на example.ru name-сервер. Если www.example.ru ресурс существует в зоне example.ru, то запрос name-сервера для www.example.ru предоставит IP-адрес для ресурса www.example.ru Диаграмма процесса разрешения имени (без операций поиска в кэше) приведена на рис. 6.1.

Name-сервер выполняет следующие функции:

Name-сервер выполняет эти три функции, используя некоторую базу данных, которая называется зонным файлом. Класс информации, называемый информацией делегирования, содержит информацию name-сервера о дочерних зонах в родительской зоне и использует ее при выполнении функции предоставления referral’а. Функция отображения выполняется классом информации в файле зоны, называемом авторитетной информацией, и обеспечивается набором записей, которые перечислены в ресурсах для данной зоны вместе с их доменными именами и соответствующими IP-адресами. Так как ресурсы принадлежат данной зоне, предоставляемая информация считается авторитетной. Таким образом, файл зоны содержит две категории информации: авторитетную информацию (информацию обо всех ресурсах во всех доменах в зоне) и информацию делегирования (информацию о name-серверах в дочерних зонах). Строки в файле зоны, в которых указывается информация делегирования, называются точками делегирования. Уровень файла зоны есть уровень самого верхнего домена, для которого он содержит авторитетную информацию.

Компоненты DNS и понятие безопасности для них

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

Технология сетевого доступа (например, Ethernet-сеть, соединяющая stub resolver и локальный рекурсивный name-сервер) не рассматривается при описании DNS.

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

Основные механизмы безопасности для сервисов DNS

Основные механизмы безопасности для сервисов DNS описаны в документах IETF, специфицирующих DNSSEC и TSIG. Рассмотрим эти спецификации, конфигурационные опции и список необходимых действий для различных компонент DNS и систем, на которых они развернуты.

Данные DNS и ПО DNS

Двумя основными компонентами ПО DNS являются name-сервер и resolver. Основные функции name-сервера состоят в обслуживании базы данных (называемой зонным файлом), содержащей информацию о зоне, и в предоставлении ответов на запросы разрешения имени посредством авторитетных ответов или referral’ов. Основной функцией ПО resolver’а является запрос или серия запросов разрешения имени. Основными данными DNS является зонный файл; другим типом данных DNS является конфигурационный файл. Сначала обсудим структуру зонного файла, а затем функции различных типов name-серверов и resolver’ов. Обсуждение name-серверов и resolver’ов будет вестись в контексте уровня предприятия и может быть неприменимо к аналогичным сущностям уровней root и TLD.

Зонный файл

Зонный файл содержит информацию о различных ресурсах в данной зоне. Информация о каждом ресурсе представлена в записи, называемой Resource Record (RR). Так как зона может содержать несколько доменов и несколько типов ресурсов внутри каждого домена, формат каждой RR содержит поля для указания этой информации. В частности, ресурсная запись состоит из следующих основных полей:

Некоторые наиболее часто используемые типы ресурсов:

В RFC 1035 приведен полный формат допустимых RRType в DNS. Множество ресурсных записей с одним и тем же именем собственника, TTL, классом и RRType называется RRSet. Следовательно, логически зонный файл можно представить состоящим из нескольких RRSets.

Name-серверы

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

Авторитетные name-серверы

Существует два типа авторитетных name-серверов: master (или первичный) name-сервер и slave (или вторичный) name-сервер. Для обеспечения большей надежности от сбоев может существовать несколько slave name-серверов для каждого master-сервера. Master name-сервер содержит зонные файлы, которые создаются и редактируются вручную администратором зоны. Иногда master name-сервер допускает, чтобы зонный файл мог динамически изменяться авторизованными DNS-клиентами. Slave name-сервер также содержит авторитетную информацию для зоны, но его зонный файл является репликацией зонного файла связанного с ним master name-сервера. Репликация осуществляется с помощью транзакции, называемой зонной пересылкой, которая пересылает все ресурсные записи из зонного файла в master name-сервере на slave name-сервер. Так как запрос разрешения имени выполняется для конкретной ресурсной записи, зонная пересылка на самом деле рассматривается как категория запроса разрешения имен с кодом типа AXFR, который означает "все ресурсные записи для зоны, которая запрашивается". Всякий раз, когда содержимое зонного файла изменяется на master name-сервере, slave name-сервер уведомляется об изменении с помощью транзакции, называемой DNS NOTIFY. Когда slave name-сервер получает данное сообщение, он инициализирует запрос зонной пересылки к master name-серверу. Для обозначения данных типов name-серверов могут использоваться также термины первичный и вторичный name-сервера.

Кэширующие name-серверы

Кэширующий name-сервер обычно является локальным name-сервером, выполняющим функции разрешения имен для различных клиентов. Кэширующий name-сервер также является рекурсивным name-сервером. Функция разрешения имен выполняется кэширующим name-сервером в ответ на запросы от stub resolver’а. Процесс поиска, выполняемый при разрешении имен, означает либо поиск в своем собственном кэше, либо последовательность запросов к различным авторитетным серверам.

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

Resolver’ы

Такое ПО, как web-браузеры и e-mail клиенты, которые требуют доступа к ресурсам Интернета, используют DNS-клиент, называемый client resolver или stub resolver. Stub resolver формулирует запрос на разрешение имени для ресурса, который отыскивается в Интернете, и посылает этот запрос кэширующему name-серверу. Как правило, stub resolver сконфигурирован таким образом, чтобы иметь список кэширующих name-серверов для обеспечения большей надежности данной операции. Stub resolver обычно называется просто resolver’ом. Кэширующий name-сервер, который получил запрос от stub resolver’а, также формирует запросы для посылки их авторитетным name-серверам (если он не может ответить на запрос из своего кэша), и, следовательно, также иногда указывается как resolver, потому что он имеет рекурсивную компоненту и компоненту кэширования.

Транзакции DNS

Существуют следующие типы DNS-транзакций:

Опишем каждый из этих типов.

Запрос / ответ DNS

Это наиболее распространенная транзакция в DNS. Запрос DNS исходит от resolver’а; получателем является авторитетный или кэширующий name-сервер. Наиболее распространенным запросом является поиск ресурсной записи по имени владельца или типу. Ответ может состоять из единственной ресурсной записи, множества ресурсных записей или сообщения о соответствующей ошибке.

Существует два типа запросов: нерекурсивный и рекурсивный. DNS-resolver’ы, которые обычно посылают нерекурсивные запросы, как правило, предоставляют более стабильные ответы, потому что они могут переходить по referral’ам для получения окончательного ответа на запрос. Если они также имеют кэш DNS, они могут обладать достаточно полной информацией о пространстве name-серверов в DNS, полученной из ответов на предыдущие запросы. Это может быть использовано для уменьшения времени ответа на последующие запросы. Рекурсивные запросы обычно посылаются от stub resolver’ов, которые не имеют возможности выполнять сложные операции DNS. Вместо этого они полагаются на вышележащий сервер DNS (обычно name-сервер с кэшем, который посылает нерекурсивные запросы от имени нескольких stub resolver’ов) для выполнения запроса и возврата окончательного ответа.

Запросы DNS посылаются в виде одного UDP-пакета. Ответ обычно также является одним UDP-пакетом, но данные могут быть усечены – в этом случае выполняется повторный запрос с использованием ТСР. UDP используется потому, что он требует меньше вычислительных ресурсов и является более быстрым, чем ТСР, который требует процедуры установления соединения.

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

Зонная пересылка

Зонная пересылка является способом, которым вторичный (slave) сервер обновляет все содержимое своего зонного файла от первичного (master) сервера. Этот процесс дает возможность вторичному name-серверу поддерживать свой зонный файл в синхронном состоянии с первичным name-сервером. Транзакция зонной пересылки начинается в виде запроса от вторичного name-сервера к первичному name-серверу. Запрос зонной пересылки – в противоположность запросу DNS – запрашивает все ресурсные записи из зоны вместо конкретных ресурсных записей для данного владельца или типа. Этот запрос начинается с вторичного name-сервера либо в ответ на сообщение DNS NOTIFY, либо основываясь на значении элемента данных Refresh в поле RData в Start of Authority (SOA) ресурсной записи.

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

Динамические обновления

Если происходит добавление, удаление или перемещение сетевых ресурсов (например, серверов баз данных, web-серверов, почтовых серверов или name-серверов), соответствующие изменения необходимо делать в зонном файле, содержащим информацию о доменах, в которых размещены эти ресурсы. На ранних стадиях развития DNS администратор зоны делал такие изменения вручную. Когда такие изменения становятся большими и частыми, ручное изменение затрудняется, поэтому было введено понятие динамического обновления. Независимо от объема и частоты обновлений, существуют некоторые приложения, которые требуют немедленных автоматических изменений зонного файла с помощью прикладных программ. Примерами этого являются серверы DHCP.

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

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

В RFC 2136 описан механизм динамического изменения, который затем был реализован в BIND 8-й версии и поддерживается во всех последующих версиях.

Возможность динамического изменения определяет операции для добавления и удаления ресурсных записей в зонном файле.

Набор операций для динамического изменения определен следующим образом:

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

DNS NOTIFY

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

Посылка сообщения DNS NOTIFY, называемая операцией notify, является способом синхронизации по умолчанию в BIND 9.x. Возникает вопрос: как name-сервер узнает, каким серверам сообщение DNS NOTIFY должно быть послано? В BIND 9.x уведомление посылается серверам, которые определены в NS ресурсных записях для зоны. Если существуют дополнительные серверы, которым администратор зоны хочет посылать сообщение DNS NOTIFY (так называемые невидимые slave-серверы), администратор DNS может добавить IP-адреса этих серверов в конфигурационный файл BIND. Администратор может также с помощью конфигурационных опций не разрешать серверу посылать сообщения NOTIFY о некоторых зонах, обслуживаемых данным name-сервером.

После того как вторичный сервер получил сообщение DNS NOTIFY, он посылает запрос зонной пересылки к первичному серверу, независимо от того, как давно в последний раз зонная пересылка осуществлялась. Данная процедура позволяет распространять изменение зоны всем вторичным name-серверам более быстро.

Так как сообщение DNS NOTIFY запускает зонную пересылку, ложные сообщения DNS NOTIFY могут привести к ненужным зонным пересылкам и, следовательно, потенциальным DoS-атакам.

Безопасность окружения DNS

Окружение, в котором выполняются сервисы DNS, состоит из следующих элементов:

Рассмотрим угрозы и возможные подходы к защите для окружения DNS.

Угрозы и обеспечение защиты платформы хоста

Угрозы для платформы, на которой выполняется ПО DNS, не отличаются от угроз, с которыми сталкивается любой хост в Интернете. Рассмотрим с точки зрения сервисов DNS эти общие угрозы и их воздействие на DNS:

Обеспечение защиты и/или уменьшению угроз для платформы хоста DNS состоит в следующем:

Угрозы ПО DNS

Угрозы для самого ПО DNS могут серьезно повлиять на безопасность. Большинство общих проблем, связанных с ПО, следующие:

Наилучшими подходами к обеспечению защиты ПО DNS являются следующие:

Угрозы для данных DNS

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

Различные типы нежелательного содержимого в зонном файле могут привести к различным воздействиям на безопасность и в дальнейшем к следующим потенциальным угрозам:

Подходы, обеспечивающие защиту от этих угроз, будут обсуждаться далее.