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

Введение

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

1. Основные функции и свойства протокола DNS и инфраструктуры DNS. Также обсудим, что означает безопасность для сервисов DNS.
2. Основные компоненты DNS, такие как зонный файл, содержащий DNS-данные, name-серверы и resolver’ы, которые предоставляют DNS-сервисы.
3. Различные типы DNS-транзакций и типы информации, участвующие в этих транзакциях.
4. Возможные угрозы различным информационным объектам DNS.
5. Способы обеспечения безопасности для сервисов DNS.
6. Обеспечение безопасности для DNS Query/Response транзакций.
7. Способы минимизации информации, раскрываемой посредством сервисов DNS.
8. Способы администрирования, обеспечивающие безопасность DNS.

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

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

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

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

• спецификации DNSSEC описаны IETF в RFC 4033, 4034, 4035 и 3833;
• спецификации Transaction Signature (TSIG) описаны IETF в RFC 2845 и 3007.

Сервисы DNS

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

• Web-серверы;
• Mail-серверы.

С точки зрения сетевого оборудования (например, роутера), которое перенаправляет коммуникационные пакеты по Интернет, уникальный ресурс идентифицируется 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, разделенных на следующие категории:

• TLDs кода страны (country-code TLDs – ccTLDs) – домены, связанные со странами и территориями. Определено более 240 ссTLDs. Примерами являются .ru, .uk, .jp.
• Общие спонсируемые TLDs (sponsored generic TLDs – gTLDs) – специализированные домены, представляющие сообщества по интересам. Данные TLDs включают .edu, .gov, .int, .mil, .aero, .coop и .museum.
• Общие неспонсируемые TLDs (unsponsored generic TLDs – gTLDs) – домены без спонсорской организации. Список неспонсируемых TLDs включает .com, .net, .org, .biz, .info, .name и .pro.

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

В инфраструктуре 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.

Рис. 6.1. Последовательность запросов и ответов при разрешения имен

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

• предоставляет referral к дочерней зоне;
• предоставляет отображение доменного имени на IP-адрес, называемое разрешением доменного имени, или IP-адрес на доменное имя, называемое инверсным разрешением;
• предоставляет сообщение об ошибке, если запрос сделан для записи DNS, которой не существует.

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

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

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

• платформа (аппаратура и ОС), на которой выполняются name-сервер и resolver’ы;
• ПО name-сервера и resolver’а;
• транзакции DNS;
• репозиторий DNS (зонные файлы);
• конфигурационные файлы для name-сервера и resolver’а.

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

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

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

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

• Окружение, в котором выполняются сервисы DNS:
  • платформа хоста (ОС, файловая система, стек протокола);
  • ПО DNS (name-сервера, resolver’а);
  • данные DNS (зонный файл, конфигурационный файл).
• Транзакции DNS:
  • запрос / ответ DNS;
  • зонные пересылки;
  • динамические обновления;
  • DNS NOTIFY.
• Администрирование DNS с учетом требований безопасности:
  • выбор алгоритмов и размеров ключей (TSIG и DNSSEC);
  • управление ключом (создание, хранение и использование);
  • опубликование открытого ключа и определение доверенных корневых ключей;
  • восстановление ключа (плановое и аварийное).