previous up down next index search
Previous: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    UP: 4.4 Интернет
Down: 4.4.12.1 Безопасность DNS (DNSSEC)
    Next: 4.4.13 Протокол управления SNMP

4.4.12 DNS (структура, обработка запросов, ресурсные записи)

Семенов Ю.А. (ИТЭФ-МФТИ)
Yu. Semenov (ITEP-MIPT)

Номер раздела Название раздела Объем в страницах Объем в кбайт
4.4.12.1 Безопасность DNS (DNSSEC) 60 215
4.4.12.2 Протокол динамического конфигурирования ЭВМ DHCP (и NAT/PAT) 30 235
Итого  

Структура взаимодействия с серверами имен
Стандартизованные суффиксы имен
Формат DNS-сообщений
Формат секции запросов в DNS-сообщении
Разновидности полей типа запроса
Ресурсные записи
Каноническое имя узла CNAME
Базовые файлы протокола DNS
Раширение DNSSEC
Динамическая инфраструктура DNS

Главной ЭВМ любой системы является та, на которой работаете вы. Но помимо этой машины и маршрутизатора локальной сети не последнюю роль играет сервер имен (DNS-система, RFC-4032, -4034, -4035, -2137, -2052, -2136, -1996, -1918, -1793, -1712-13, -1706, -1664, -1611-12, -1536-37, -1401, -1383, -1183, -1101, -1034-35).


Сервер имен это программа управления распределенной базой данных, в которой хранятся символьные имена сетей и ЭВМ вместе с их IP-адресами.

Наиболее распространенным программным продуктом, решающим данную задачу является BIND (Berkrley Internet Name Domain). Иногда для этой цели выделяют специальную машину. Задача DNS - преобразование символьного имени в IP-адрес и наоборот в условиях, когда число узлов Internet растет экспоненциально, совсем не проста. Сама иерархическая система имен (DNS) настроена на упрощение решения этой проблемы. Схема взаимодействия программы пользователя с локальным и удаленными DNS-серверами показана ниже на рисунке 4.4.12.1.

Структура взаимодействия с серверами имен

Рис. 4.4.12.1. Структура взаимодействия с серверами имен

База имен является распределенной, так как нет такой ЭВМ, где бы хранилась вся эта информация. Как уже отмечалось имя содержит несколько полей (длиной не более 63 символов), разделенных точками. Имя может содержать не более 255 октетов, включая байт длины. Анализ имени производится справа налево. Самая правая секция имени характеризует страну (двухсимвольные национальные коды смотри в приложении), или характер организации образовательная, коммерческая, правительственная и т.д.).

Следующие 3-х символьные коды в конце Internet-адреса означают функциональную принадлежность узла.

Стандартизованные суффиксы имен

Таблица 4.4.12.1. Стандартизованные суффиксы имен

Поле адресаТип сети
.aeroФирма или организация, относящаяся к сфере авиации;
.artsКультура и досуг;
.bizОрганизация, относящаяся к сфере бизнеса;
.comКоммерческая организация;
.coopКооперативная организация;
.firmКоммерческое предприятие;
.govГосударственное учреждение (США);
.infoОткрытая TLD-структура (регистрация имен доменов)
.orgБесприбыльная организация;
.eduУчебное заведение;
.jobsРаботодатели;
.milВоенное предприятие или организация (США);
.mobiCайты и сервисы, ориентированные на работу с мобильными телефонами и беспроводными устройствами
.museumИмя домена музея
.nameИмя домена частного лица
.netБольшая сеть;
.proПрофессионал, достойный доверия. Управляется RegistryPro (http://www.nic.pro/);
.intМеждународная организация;
.recРазвлечения;
.telХранение и управление персональными и корпоративными контактными данными;
.travelТурагенства;
.tvТелевидение. Хотя существует домен bbc.tv, а регистрация в этой зоне в РФ процветает (см. Ru center, официального статуса в качестве TLD этот домен не получил. В базе данных IANA (см. Национальные коды доменов в Интернет этот домен записан попрежнему за TUVALU
.arpaСпециальный домен, используемый для преобразования IP-адреса в имя
.webОрганизация, вовлеченная в WEB-активность

Секции .mil и .gov принадлежат исключительно американским сетям (хотя и многие другие трех-символьные секции адреса, например .edu, чаще, но не всегда, принадлежат американским университетам и другим учебным организациям). Структура имен обычно отражает структуру организации, которой принадлежат сети или ЭВМ, но не архитектуру сети в этой организации. Так имя itep.ru - это имя домена itepnet (Институт Теоретической и Экспериментальной физики, Москва). cl.itep.ru - имя mvax-кластера в ИТЭФ, vxitep.itep.ru - имя vax-кластера, а suncom.itep.ru - имя одной из ЭВМ SUN в той же сети. По имени, как правило, нельзя определить является ли оно именем сети, маршрутизатора или конкретной ЭВМ. Для записи символьных имен используется исключительно латинский алфавит.

Маленький фрагмент интернетовской иерархии имен показан на рис. 4.4.12.2. Число уровней реально больше, но обычно не превышает 5.

Рис. 4.4.12.2. Иерархия имен в Интернет-DNS (I - домен первого уровня; II - второго уровня)

Каждому узлу (прямоугольнику на рисунке) соответствует имя, которое может содержать до 63 символов. Только самый верхний, корневой узел не имеет имени. При написании имени узла строчные и прописные символы эквивалентны. Имя домена, завершающееся точкой называется абсолютным или полным именем домена (например, itep.ru.). В некоторых странах создана структура имен сходная с com/edu/org. Так в Англии можно встретить адреса .ac.uk для академических учреждений и .co.uk - для коммерческих. Если имя домена не завершено символом точки, DNS может попытаться его дополнить, например имя ns может быть преобразовано в ns.itep.ru. На приведенной схеме каждому объекту трех верхних уровней соответствуют серверы имен, которые могут взаимодействовать друг с другом при решении задачи преобразования имени в IP-адрес. Можно было бы построить схему, при которой в любом сервере имен имелись адреса серверов .com, .edu, .ru и т.д. и при необходимости он мог бы послать туда запрос. Реальная схема серверов не столь идеальна и стройна - существуют серверы nsf.gov, oakland.edu и т.д., которые непосредственно связаны с базовым сервером имен.

Каждый сервер содержит лишь часть дерева имен. Эта часть называется зоной ответственности сервера. Зона представляет собой часть субдерева имен, представленного на рис. 4.4.12.2. DNS-сервер может делегировать ответственность за часть зоны другим серверам, создавая субзоны. Когда в зоне появляется новая ЭВМ или субдомен, администратор зоны записывает ее имя и IP-адреса в базу данных сервера. Администратор зоны определяет, какой из DNS-серверов имен является для данной зоны первичным. Число вторичных серверов не лимитировано. Первичный и вторичный серверы должны быть независимыми и работать на разных ЭВМ, так чтобы отказ одного из серверов не выводил из строя систему в целом. Отличие первичного сервера имен от вторичного заключается в том, что первичный загружает информацию о зоне из файлов на диске, а вторичный получает ее от первичного. Администратор вносит любые изменения в соответствующие файлы первичного сервера, а вторичные серверы получают эту информацию, периодически (раз в 3 часа) запрашивая первичный сервер. Пересылка информации из первичного во вторичные серверы имен называется зонным обменом. Как будет вести себя сервер, если он не имеет запрашиваемой информации? Он должен взаимодействовать с корневыми серверами. Таких серверов насчитывается около десяти и их IP-адреса должны содержаться в конфигурационных файлах.

В 2010 году появился русскоязычный домен .рф, что активно приветствовали хакеры, а немного позднее было объявлено о возможности домена первого уровня вообще любого вида, что еще более облегчит работу хакеров.

Список корневых серверов вы можете получить по адресам: www.internic.net . Корневые серверы хранят информацию об именах и адресах всех серверов доменов второго уровня. Существует два вида запросов: рекурсивные и итеративные. Первый вид предполагает получение клиентом IP-адреса, а второй - адреса сервера, который может сообщить адрес. Первый вид медленнее, но дает сразу IP-адрес, второй эффективнее - в вашем сервере копится информация об адресах серверов имен. Одним из способов повышения эффективности трансляции имен в адреса является кэширование, то есть хранение в оперативной памяти имен-адресов, которые использовались последнее время особенно часто. Рассмотрение процесса обмена между ЭВМ-клиентом и сервером имен может прояснить работу системы в целом. Прежде чем использовать протоколы UDP или TCP прикладная программа должна узнать IP-адрес объекта, куда она хочет послать дейтограмму. Для решения этой проблемы программа посылает запрос в локальный сервер имен. В Unix-системах имеются специальные библиотечные процедуры gethostbyname и gethostbyaddr, которые позволяют определить IP-адрес по имени ЭВМ и наоборот. В одном запросе может содержаться несколько вопросов. Если сервер не сможет ответить на вопросы, он пришлет отклик, где содержатся адреса других серверов, способных решить эту задачу. Ниже на рисунке 4.4.12.3 представлен формат таких сообщений (в качестве транспорта используется UDP или TCP, порт 53).

Формат DNS-сообщений

Рис. 4.4.12.3. Формат DNS-сообщений

Каждое сообщение начинается с заголовка, который содержит поле идентификация, позволяющее связать в пару запрос и отклик. Поле флаги определяет характер запрашиваемой процедуры, а также кодировку отклика. Поля число... определяют число записей соответствующего типа, содержащихся в сообщении. Так число запросов задает число записей в секции запросов, где записаны запросы, требующие ответов. Каждый вопрос состоит из символьного имени домена, за которым следует тип запроса и класс запроса. Значения битов поля флаги в сообщении сервера имен отображены в таблице 4.4.12.2. Разряды пронумерованы слева направо, начиная с нуля рис. 4.4.12.4.

Рис. 4.4.12.4. Назначение битов поля флаги.

Таблица 4.4.12.2. Коды поля флаги

Код поля флагиОписание

0 (QR)

Операция: 0 Запрос
1 Отклик
1…4 Тип запроса (opcode): 0 стандартный
1 инверсный
2 запрос состояния сервера
5 (AA) Равен 1 при отклике от сервера (RR), в ведении которого находится домен, упомянутый в запросе.
6 (TC) Равен 1 при укорочении сообщения. Для UDP это означает, что ответ содержал более 512 октетов, но прислано только первые 512.
7 (RD) Равен 1, если для получения ответа желательна рекурсия.
8 (RA) Равен 1, если рекурсия для запрашиваемого сервера доступна.
9…11 Зарезервировано на будущее. Должны равняться нулю.
12…15 Тип отклика (rcode): 0   нет ошибки
1   ошибка в формате запроса
2   сбой в сервере
3   имени не существует

Формат секции запросов в DNS-сообщении

Ниже описан формат секции запросов в DNS-сообщении.

Рис. 4.4.12.5. Формат секции вопросов DNS-запроса.

Поле символьное имя домена имеет переменную длину, содержит одно или более субполей, начинающихся с байта длины (0-63). Поле завершается 0. Например, для ns.itep.ru (цифры представляют собой октеты длины):

В реальной нотации байты длины субполя могут иметь два старших бита равные 1, что преобразует интервал значений из 0-63 в 192-255. Такой байт в поле означает, что это не мера длины секции, а 16-битный указатель, 14 бит которого являются смещением от начала DNS-сообщения, указывающим на место продолжения секции. Смещение для первого байта поля идентификации равно нулю. Эти ухищрения придуманы для сокращения длины сообщений, так как одно и то же имя домена в отклике может повторяться много раз. Поле тип запроса характеризует разновидность запроса:

Разновидности полей типа запроса

Таблица 4.4.12.3. Разновидности полей тип запроса и их коды

Тип запроса Код запроса Описание
A 1 IP-адрес
NS 2 Сервер имен.
CNAME 5 Каноническое имя.
SOA 6 Начало списка серверов. Большое число полей, определяющих часть иерархии имен, которую использует сервер.
MB 7 Имя домена почтового ящика.
WKS 11 well-known service - стандартная услуга.
PTR 12 Запись указателя.
HINFO 13 Информация об ЭВМ.
MINFO 14 Информация о почтовом ящике или списке почтовых адресов.
MX 15 Запись о почтовом сервере. Включает в себя значение приоритета обработчика почты.
TXT 16 Связывает имя ЭВМ с адресом ISDN.
ISDN 16 Не интерпретируемая строка ASCII символов.
AXFR 252 Запрос зонного обмена
* или ANY255Запрос всех записей.

(Пропущенные коды являются устаревшими или экспериментальными).

Наиболее часто используются запросы типа А - преобразование имени в IP-адрес. Для обратного преобразование служит запрос PTR.

Последние две строки в таблице 4.4.12.3 относятся только к запросам. Поле класс запроса позволяет использовать имена доменов для произвольных объектов (все официальные имена Интернет относятся к одному классу [IN] - 1). В сообщении DNS-сервера каждая из секций (дополнительной информации, ответов или узловых серверов имен) состоит из набора ресурсных записей, которые описывают имена доменов и некоторую другую информацию (например, их адреса). Появление ресурсных полей в DNS базе данных придают ей новые качества. Каждая запись описывает только одно имя, формат этих записей отображен на рис. 4.4.12.6.

Ресурсные записи

Рис. 4.4.12.6. Формат ресурсных записей в DNS (RR)

Всего существует 20 различных типов RR-записей. Имя домена в такой записи может иметь произвольную длину. Поля тип и класс характеризуют тип и класс данных, включенных в запись (аналогичны используемым в запросах). Поле время жизни (TTL) содержит время (в секундах), в течение которого запись о ресурсах может храниться в буферной памяти (в кэше). Обычно это время соответствует двум дням. Формат информации о ресурсах зависит от кода в поле тип, так для тип=1 - это 4 байта IP-адреса. Сервер имен может обслуживать и другие запросы, например, по IP-адресу определять символьное имя домена или преобразовать имя домена в адрес почтового сервера. Когда организация присоединяется к Интернет, она получает в свое распоряжение не только определенную DNS-область, но и часть пространства в in-addr.arpa, соответствующую ее IP-адресам. Домен in-addr.arpa предназначен для определения имен по их IP-адресам. Такая схема исключает процесс перебора серверов при подобном преобразовании.

Ресурсная запись SOA говорит о том, что сервер имен является источником данных для данного домена. Записи SOA содержат электронный адрес администратора данной зоны. Адрес администратора задается в формате admin.dns.net (здесь вместо @ после слова admin следует точка). Комментарии начинаются с точки с запятой.

Имена в домене IN-ADDR.ARPA могут иметь до четырех субполей помимо суффикса IN-ADDR.ARPA. Каждое субполе представляет собой октет IP-адреса, и содержит последовательность символов, отображающую коды в диапазоне 0-255. Так имя для IP-адреса 192.148.166.137 (если оно существует) содержится в домене с именем 137.166.148.192.IN-ADDR.ARPA. Запись адреса задом наперед диктуется общими принципами записи имен доменов (корневая часть имени находится справа). Направив несколько запросов в домен IN-ADDR.ARPA относительно имен объектов с интересующими вас IP-адресами, можно получить следующий результат:

IP_address Hard-addr Delay Date Host_name
128.141.202.101 00.00.0c.02.69.7d 440 10/10/95 na48-1.cern.ch
192.148.166.102 00.00.a7.14.41.c2 5 10/10/95
192.148.166.237 00.00.0c.02.69.7d 5 10/10/95 ITEP-M9.Relcom.ITEP.RU

где в левой колонке записаны IP-адреса, имена которых ищутся, во второй - записаны аппаратные адреса интерфейсов, через которые доступны искомые объекты. Поскольку первая и третья строки относятся к внешним по отношению к узлу ITEP объектам, здесь записан адрес интерфейса пограничного маршрутизатора. В третьей колонке содержится значение RTT в мсек, а в последней - имена объектов. IP-адресу 192.148.166.102 не соответствует никакого имени.

Задержка при выполнении команды telnet между выдачей команды и появлением на экране IP-адреса связана с доступом и работой DNS-сервера. Пауза между появлением надписи Trying и Connected to определяется временем установления TCP-связи между клиентом и сервером. База данных имен может содержать и другую информацию. Типы такой информации представлены в таблице 4.4.12.3. Для извлечения информации из этой распределенной базы данных можно воспользоваться программой host (SUN или другая ЭВМ, работающая под UNIX). Рассмотрим несколько примеров (курсивом выделены команды, выданные с терминала).

host -t cname cernvm.cern.ch

cernvm.cern.ch is a nickname for crnvma.cern.ch

Каноническое имя узла CNAME

Напомним, что CNAME - каноническое имя узла или ЭВМ, иногда называемое также псевдонимом (alias).

host -t hinfo ns.itep.ru

ns.itep.ru HINFO SparcStation-1 SunOS-4.1.3

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

host -t mx cl.itep.ru
cl.itep.ru is a nickname for r02vax.itep.ru
r02vax.itep.ru mail is handled by relay1.kiae.su
r02vax.itep.ru mail is handled by relay2.kiae.su
r02vax.itep.ru mail is handled by mx.itep.ru
r02vax.itep.ru mail is handled by x4u2.desy.de

host -v info.cern.ch
Trying domain "itep.ru"
rcode = 3 (Non-existent domain), ancount=0
Trying null domain
rcode = 0 (Success), ancount=2

info.cern.ch 86400 IN CNAME www6.cern.ch
www6.cern.ch 86400 IN A 128.141.202.119

Trying domain "itep.ru"
rcode = 3 (Non-existent domain), ancount=0
Trying null domain
rcode = 0 (Success), ancount=1
The following answer is not authoritative:

www6.cern.ch 86400 IN A 128.141.202.119

For authoritative answers, see:

CERN.CH 52256 IN NS dxmon.cern.ch
CERN.CH 52256 IN NS ns.eu.net
CERN.CH 52256 IN NS sunic.sunet.se
CERN.CH 52256 IN NS scsnms.switch.ch

Additional information:

dxmon.cern.ch 79157 IN A 192.65.185.10
ns.eu.net 56281 IN A 192.16.202.11
sunic.sunet.se 85087 IN A 192.36.125.2
sunic.sunet.se 85087 IN A 192.36.148.18
scsnms.switch.ch 72545 IN A 130.59.1.30
scsnms.switch.ch 72545 IN A 130.59.10.30

Опция -v, используемая совместно с командой host позволяет получить более полную информацию об узле. Во второй колонке данной выдачи указано время жизни (TTL) в секундах. Значение TTL в первых строках соответствует суткам (24x60x60=86400). IN в следующей колонке указывает на принадлежность к классу Интернет. В четвертой колонке проставлены указатели типов запроса (см. табл. 4.4.12.3). В пятой колонке идут названия серверов имен и IP-адреса ЭВМ. Далее следуют коды предпочтения. MX-записи активно используются почтовыми серверами. Обмен MX-записями производится в следующих случаях:

MX-записи снабжены 16-битными кодами предпочтения. Если для адреса имеется несколько MX-записей, они используются в порядке нарастания этого кода. Если вы хотите узнать список доступных услуг на той или иной ЭВМ, вы можете напечатать команду (WKS - Well Known Services, сюда не входят услуги прикладного уровня, например, услуги NEWS-сервера и пр.):

host -tv wks ns.itep.ru
ns.itep.ru WKS 193.124.224.35 udp domain tftp
ns.itep.ru WKS 193.124.224.35 tcp echo ftp telnet smtp time finger

Если вам нужно узнать IP-адреса того или иного узла можно также воспользоваться командой host:

host vxdesy.desy.de
vxdesy.desy.de has address 131.169.35.78
vxdesy.desy.de has address 131.169.35.79
vxdesy.desy.de has address 131.169.35.76
vxdesy.desy.de has address 131.169.35.77

Большая часть данных относится к типу "А".

Выше уже говорилось, что для транспортировки DNS-запросов применяются протоколы UDP и TCP. Когда же следует использовать эти протоколы? Обычно используется UDP. Когда в ответ на запрос программа получает отклик с битом флагов TC=1 (сообщение укорочено), программа повторяет запрос, но уже с использованием протокола TCP. Этот протокол применяется также для зонных обменов между первичным и вторичным DNS-серверами.

Обычно реализация сервера имен (версия BIND - Berkeley Internet Name Domain) предполагает наличие трех конфигурационных файлов:

named.boot - файл начальной загрузки сервера имен;
named.local - стартовый файл клиента DNS;
named.ca - исходный буфер имен и адресов.

Текстовые строки и фрагменты, начинающиеся с точки с запятой, представляют собой комментарии. В первом из перечисленных файлов строка, начинающаяся со слова sortlist, указывает на порядок присылки адресов при условии, что отклик на запрос содержит несколько адресов. Строка, начинающаяся со слова directory, содержит название каталога, где хранятся конфигурационные файлы (по умолчанию /etc). Строка cache сообщает имя файла-буфера имен и адресов (по умолчанию named.ca). Далее обычно следует несколько строк, начинающихся со слова primary. Эти строки указывают имена файлов (например, named.hosts или named.local), где содержится информация о соответствии имен и адресов для определенных субдоменов. Вместо имени файла может быть указан IP-адрес. Укладка данных в файле соответствует требованиям документа RFC-1033. Для вторичного (secondary) DNS файл named.boot имеет схожую структуру. Вместо строк со словом primary в этом файле присутствуют строки secondary. Эти строки содержат помимо имен субдоменов и файлов IP-адрес первичного DNS. Последний выполняет и функцию переадресации запросов вышестоящим серверам. Вторичный DNS-сервер при невозможности выполнить запрос переадресует его первичному серверу, а не вышестоящему. Первичный сервер может создавать большой кэш-буфер для локального обслуживания часто поступающих запросов.

Файл named.local служит для спецификации интерфейса сервера имен и содержит в себе запись SOA (Start of Authority) и две ресурсных записи. Запись SOA определяет начало зоны. Символ @ в начале первой строки файла определяет имя зоны. Здесь же указываются опционные параметры:

Базовые файлы протокола DNS

Запись может выглядеть как (RFC-1033):

@ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
45 ;serial
3600 ;refresh
600 ;retry
3600000 ;expire
86400 ) ;minimum

В файле приводится имя первичного сервера имен для данного субдомена (флаг NS) и имя администратора с указанием адреса его электронной почты. Последняя запись в файле содержит указатель на местную ЭВМ. Первая цифра в строке этой записи содержит суффикс IP-адреса этой машины.

Файл named.ca используется для заполнения кэша при первичной загрузке DNS. Примером, иллюстрирующим возможное содержимое файла можно считать следующее (взято из RFC-1033):

;list of possible root servers
. 1 IN NS SRI-NIC.ARPA.
NS C.ISI.EDU.
NS BRL-AOS.ARPA.
NS C.ISI.EDU.
;and their addresses
SRI-NIC.ARPA. A 10.0.0.51
A 26.0.0.73
C.ISI.EDU. A 10.0.0.52
BRL-AOS.ARPA. A 192.5.25.82
A 192.5.22.82
A 128.20.1.2
A.ISI.EDU. A 26.3.0.103

Первое поле представляет собой имя домена или субдомена, второе поле - значение TTL, третье - поле класс (Internet), четвертое - тип записи (NS для сервера имен или A для адреса), и последнее поле характеризует имя ЭВМ или IP-адрес. Если какие-то поля пусты, это означает, что они тождественны приведенным выше. Точка в начале первой строки указывает на корневой домен.

Для администраторов, обслуживающих DNS, весьма полезно ознакомиться с документом RFC-1536 (“Common DNS Implementation Errors and Suggested Fixes”). Ошибки при конфигурации DNS-сервера могут привести к досадным ошибкам и отказам системы. Обычно, при получении запроса DNS сначала определяется его зона и просматривается кэш. Если запрос не может быть выполнен, просматривается список вышестоящих DNS-серверов, которые могут содержать необходимую информацию, и запрос пересылается одному из них. Если клиент прислал рекурсивный запрос и сервер поддерживает рекурсию, запрос пересылается соответствующим серверам. Если рекурсия не поддерживается, сервер возвращает клиенту список DNS-серверов, предоставляя ему решать свои проблемы самостоятельно. Однако в некоторых случаях DNS-сервер по ошибке может включить себя в такой список серверов. Если программное обеспечение клиента не проверяет список, запрос может быть послан этому серверу повторно, что вызовет бесконечный цикл запросов.

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

Возможна и другая схема возникновения циклов запросов. Предположим, что сервер <1> содержит в своем списке внешних DNS сервер <2>, а последний в свою очередь содержит в своем списке сервер <1>. Такого рода перекрестные ссылки трудно обнаружить особенно, если в перечне фигурирует большое число серверов. Иногда возникает ситуация, когда клиент, получив список DNS-серверов, не знает, что с ним делать и посылает запрос повторно тому же серверу. Идентифицировать такого рода ошибки весьма трудно, особенно когда в это вовлечены внешние серверы, содержимое конфигурационных файлов которых недоступно.

Иногда DNS-сервер в ответ на запрос не присылает сообщений об ошибке или каких-либо данных клиенту. Это случается когда запрашиваемое имя вполне корректно, но записей нужного типа не найдено. Например, запрошен адрес почтового сервера домена xxx.com. Домен этот существует, но рекорда типа MX не обнаружено. Дальнейшие события зависят от характера программного обеспечения клиента. Если клиент считает такого рода “отклик” некорректным, он может послать запрос повторно и т.д. и т.д. По этой причине в случае, если программное обеспечение это позволяет, рекомендуется ограничить число повторных запросов клиента. Приведенные примеры показывают, насколько актуальна корректная конфигурация DNS клиента и сервера.


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

В системах Windows часто используется своя служба имен WINS (Windows Internet Naming Service, см. RFC-2136 и RFC-2137). Эта служба совместима с системой динамического конфигурирования сети DHCP (Dynamic Host Configuration Protocol, использует динамическое распределение IP-адресов). В WINS, также как и в DHCP, имеются части, работающие у клиента и на сервере. WINS автоматически устанавливается и конфигурируется при установке системы DHCP. Эта система имеет удобную встроенную диагностику, позволяющую контролировать процесс обработки запросов к службе имен. WINS осуществляет преобразование NETBIOS-имен в IP-адреса. Эта техника предполагает использование протокола NetBIOS поверх TCP/IP (NetBT). В ОС WINDOWS 2000 технология WINS заменена DDNS (Dynamic Domain Name Service).

WINS-запросы обычно транспортируются в UDP-дейтограммах. При этом используется порт отправителя=137. В поле данных размешается 2-октетное поле идентификатора, позволяющего связать запрос с откликом. Далее следует 2 байта флагов, в случае запроса туда записывается 0. За ним размещается два октета, содержащие число вопросов, 2 октета числа ответов и еще 4 нулевых октетов. Завершается кадр запроса двумя октетами поля типа (00 21 -> статус узла NetBIOS) и полем класса (для Интернет 00 01 -> (IN,1)). Такие запросы позволяют получить дополнительные данные (имя узла, его MAC-адрес, NetBIOS-имя, имя группы) об ЭВМ с заданным IP-адресом. Причем эта ЭВМ может находиться где угодно в Интернет, но непременно работать в OS Windows. Формат поля данных UDP-дейтограммы запроса показан на рис. 4.4.12.7.

Рис. 4.4.12.7. Формат запроса WINS

В поле данных UDP-дейтограммы отклика располагается 2-байтовое поле идентификатора, идентичного содержащемуся в пакете запроса. Далее следует поле флагов с длиной в два октета. Формат поля данных UDP-дейтограммы отклика показан на рис. 4.4.12.8.

Рис. 4.4.12.8. Формат отклика на WINS-запрос

Поле флаги имеет следующую структуру:

0 _ _ _ _ _ _ _ Команда
_ 000 0 _ _ _ Запрос
_ _ _ _ _ _ 0 _ Не укорочено
_ _ _ _ _ _ _ 0 Рекурсия нежелательна

1 _ _ _ _ _ _ _ Отклик
_ 000 0 _ _ _ Запрос
_ _ _ _ _ _ 0 _ Не укорочено
_ _ _ _ _ 1 _ _ Официальный ответ

Для поля флаги имени характерна следующая структура


0 _ _ _ _ _ _ _ Уникальное имя NetBIOS

_ 10 _

_ _ _ _ Узел М-типа
_ _ _ _ _ 1 _ _ Активное имя
_ _ _ _ _ _ 0 _ Временное имя

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

1 _ _ _ _ _ _ _ Имя группы NetBIOS
_ 10 _ _ _ _ _ Узел М-типа
_ _ _ _ _ 1 _ _ Активное имя
_ _ _ _ _ _ 0 _ Временное имя

В последнее время развивается технология DDNS динамического обновления ресурсных записей зоны DNS внешними ЭВМ или процессами (Dynamic DNS; RFC-2136). Клиенты с возможностями DDNS могут сами обновлять записи локальных серверов имен. Еще более интересное решение базируется на интеграции служб DHCP и DNS. В этом варианте серверы DHCP, поддерживающие DDNS, посылают соответствующему серверу DNS данные для обновления записей, включая имена NetBIOS клиентов DHCP. Запись обновляется после выделения IP-адреса. При реализации DDNS возникают проблемы безопасности. Часть этих проблем может быть решено путем использования цифровых подписей (RFC-2137).

Еще одной проблемой, связанной со службой имен, являются атаки, которые сопряжены с имитацией DNS. Для преодоления таких атак разработан метод транзакционных подписей TSIG (Transaction SIGnature).

Число доменов второго уровня в российском сегменте Интернет превысило 800 тысяч к марту 2007 года. Недостающие до круглого числа 200 000 имен появятся в домене RU, по прогнозам специалистов, за 3 - 4 месяца, так что миллионный рубеж национальный домен России преодолеет уже летом этого года (2011г). Рост числа регистраций наблюдается, в основном, за счет активности физических лиц. Средний возраст владельца доменов снизился за последний год с 28 до 26 лет.

Редактирование рекордов DNS должно проводиться особенно аккуратно. Проблемы может вызвать вполне добросовестный сетевой администратор. Например, в окрябре 2009 года весь шведский Интернет (зона .se) на целый час перестал работать из-за опечатки администратора, который редактировал записи DNS-сервера. Смотри DNS: Risk, Reward and Managed Services.

Три-четыре года назад запрос пользователя подключиться к определенному WEB-сайту вызывал лишь один DNS-запрос. Сейчас многие Web-сайты имеют много встроенных ссылок, например, рекламодателей, что приводит к существенному увеличения числа DNS-запросов вплоть до 30.

Расширение DNSSEC

Базовая версия протокола DNS имеет ряд уязвимослей, которые позволяют хакерам предпринять атаки:

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

Уязвимость традиционного протокола DNS стимулировало разработку его более безопасного варианта DNSSEC, а также OpenDNS. Главная цель хакеров - перенаправление легальных запросов на нелегальные серверы, которые могут заразить машину клиента. Такая цель может быть достигнута разными способами, например с помощью DNS cache poisoning. Многие из приемов хакеров предполагают перехват запросов или откликов DNS и их подмену или модификацию. Клиент должен быть уверен, что отклик пришел от легального сервера и он не был модифицирован по дороге. Чтобы исключить возможность подмены или модификации сообщений серверы DNSSEC снабжают их электронными подписями. Безопасность таких процедур гарантируется системой сертификации (см. RFC-4398 - Storing Certificates in the Domain Name System, а также RFC 4033, RFC 4034, RFC 4035). Сертификаты гарантируют то, что присланное сообщение послано именно тем сервером, к которому был послан запрос. Смотри также Уязвимости DNS, DNSSEC: DNS Security Extensions Securing the Domain Name System, DNSSEC Information (IANA) и Global Upgrade Makes Internet More Secure. Helps defend users against specific types of cyber crime.

Динамическая инфраструтура DNS (by David Holms)

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

Рост Интернет в последние годы в основном происходит за счет мобильных устройств, смотри рис. 4.4.12.9.

Рис. 4.4.12.9. Рост числа доменов за 2000-2012гг

На рис. 4.4.12.9A представлено распределение TLD (Top Level Domain) доменов по суффиксам их имен на апрель 2017 года.

Рис. 4.4.12.9A. Распределение TLD доменов по суффиксам имен

Соответствующим образом растет и DNS-трафик. За последние 5 лет число DNS-запросов выросло на 200% (в первом квартале 2011 года это число составляло 57 млрд). По мере усложнения структуры сайтов и приложений растет нагрузка DNS. Отображение некоторых WEB-страниц требует до дюжины DNS-запросов, а иногда и до сотни запросов. На рис. 4.4.12.10 показана реализация F5 DNS сервисов и управления трафиком.

Рис. 4.4.12.10. Сервис DNS F5

Для глобальных организаций с большим числом информаионных центров и существующей DNS-инфраструктуре система F5 BIG-IP GTM предоставляет большое число сервисов, включая балансировку нагрузки информационных центров в облаке (см. рис. 4.4.12.11).

Рис. 4.4.12.11. Балансировка нагрузки информационных центров в облаке

Рис. 4.4.12.12. Технология защиты DNS F5

Предлагаемая схема хорошо согласуется с технологией DNSSEC и может работать как с адресами IPv4, так и с IPv6.

С учетом массовых атак против DNS разрабатывается большое число средств противодействия, например, Infoblox DNS Firewall.

Отмечается, что поддержка протокола multicast DNS открывает широкие возможности для DDoS атак (см. "Over 100,000 devices can be used to amplify DDoS attacks via multicast DNS", Lucian Constantin, IDG News Service, April 1, 2015 ). Domain Name System (mDNS; RFC-6762 и RFC-6804) является протоколом, который позволяет устройствам в локальной сети распознавать друг друга и выявлять доступные виды сервиса. Поддержка протокола возможна также системами NAS (Network Attached Storage). К сожалению, практические реализации протокола не следуют строго его регламентациям, допускают выход запросов за пределы локальной судсети, что создает условия для DDoS-атак.

В зависимости от типа запроса mDNS может выдать данные об устройстве (модель, серийный номер, MAC-адрес и предоставляемых сервисах). Эти данные могут помочь хакеру спланировать будущую атаку. Протокол mDNS помогает организовать DoS-атаку, так как отклик всегда по размеру в несколько раз больше запроса.


Previous: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)    UP: 4.4 Интернет
Down: 4.4.12.1 Безопасность DNS (DNSSEC)
    Next: 4.4.13 Протокол управления SNMP