Как работает DNS (domain name system)? Формат сообщения dns

Отображение адресов в имена

IP адрес записывается в десятично-точечной нотации . Для поиска доменных имен по IP адресам используется домен in-addr.arpa. Его поддоменами являются домены с простыми именами от 0 до 255, соответствующими старшему октету IP адреса. Их поддоменами явлются домены с простыми именами от 0 до 255, соответствующие второму октету IP адреса и т.д. до 4-го октета. Таким образом, IP адрес оказывается записанным в доменном имени в обратном порядке. Например, адресу 195.161.72.28 соответствует доменное имя 28.72.161.195.in-addr.arpa. (и значение PTR – deol.deol.ru). Обратная запись необходима для более легкого делегирования зон в соответствии с выделением IP адресов.

Зоны верхнего уровня в домене in-addr.arpa. делегированы IANA региональным регистраторам (RIR, Regional Internet Registrator) вместе с блоками IP-адресов.

RIPE для делегирования подзоны требует от LIR внесения информации в БД RIPE. Если вы представляете LIR, то должны были закончить специальные курсы, а если нет, то прав на внесение информации в БД RIPE вам не дадут и придется просить свой LIR. В БД должны быть как сеть (whois [email protected]), так и зона (whois [email protected])

Отображение адресов в имена может быть обязательным для работы некоторых сервисов Интернет: нет отображения – нет обслуживания.

Записи о ресурсах (RR, Resource Records)

Записи ресурсов могут быть представлены в текстовом формате в файле данных зоны и в двоичном формате при обмене сообщениями протокола DNS. Текстовый формат зоны может отличаться для различных реализаций DNS сервера, здесь описывается формат, упомянутый в стандарте (RFC 1035) и используемый в BIND 4/8/9. Файл зоны должен содержать записи только одного класса.

Каждая запись расположена на отдельной строке. Пустые строки игнорируются. Границы строк не распознаются внутри круглых скобок и текстовых литералов в кавычках. Разделителями полей являются пробелы и табуляции. Комментарии начинаются с символа точки с запятой в любом месте строки и продолжаются до конца строки. Кроме записей ресурсов файл зоны может содержать директивы $ORIGIN, $INCLUDE и $TTL (начиная с BIND 8.2). Символ “@” используется для обозначения текущего суффикса по умолчанию для относительных доменных имен. Обратная косая черта маскирует специальный смысл следующего символа. Возможно задание произвольных октетов в виде восьмеричных чисел (\012). Регистр букв не учитывается при поиске, но возвращается в ответе.

Директива $ORIGIN задает текущий суффикс по умолчанию для относительных доменных имен. Директива $INCLUDE вставляет указанный файл в файл зоны и задает (только для записей из вставляемого файла) текущий суффикс для относительных доменных имен (суффикс может быть опущен). В старых версиях BIND и его производных (например, in.named в Solaris 2.5) изменение суффикса не срабатывает (хотя и сообщения об ошибке не выдается!) и приходится “обрамлять” директиву $INCLUDE директивами изменения $ORIGIN и его восстановления. Директива $TTL задает TTL по умолчанию (RFC 2308).

Запись ресурса состоит из доменного имени (если опущено, то подразумевается значение из предыдущей записи ресурса), имени класса (может быть опущено и браться из предыдущей записи), TTL (число секунд, может быть опущено и браться из директивы $TTL для BIND 8.2 и новее или из поля MINIMUMTTL в SOA для старых версий; рекомендуемое значение – одни сутки; разумное – от 1 часа до недели; TTL всех записей с одинаковым ключом должны быть одинаковы), типа записи и данных записи (формат определяется классом и типом). В новых версиях (BIND ?) времена могут задаваться как в секундах, так и минутах (суффикс m), часах (суффикс h), днях (суффикс d), неделях (суффикс w). Только имена узлов обязаны соответствовать синтаксису доменных имен (буквы, цифры и минус), остальные (например, первая метка почтового адреса в записи SOA) могут состоять из произвольных символов ASCII.

Классы записей (в тяжелой эволюционной борьбе выжил только IN), в скобках – код для сообщений протокола DNS:

• IN (1) – Интернет
• CS (2) – CSNET
• CH (3) – CHAOS
• HS (4) – Hesiod

Типы записей, в скобках – код для сообщений протокола DNS:

BIND версии? позволяет дополнительно использовать директиву $GENERATE для создания последовательности RR, отличающихся лишь параметром:

$GENERATE интервал левая-часть тип-записи правая-часть

Интервал чисел задается либо в виде начало-конец, либо в виде начало-конец/шаг. По умолчанию, шаг равен 1. Левая часть задает правило формирования доменных имен для последовательности записей, у которых индекс пробегает от начало до конец с шагом шаг. Правая часть задает правило формирования данных записи (пока разрешены только типы PTR, CNAME, DNAME, A, AAAA и NS). В правилах одинокий символ $ заменяется текущим значением индекса. Значение индекса может быть модифицировано заданием смещения (вычитается из индекса), ширины поля (используется для форматирования результата) и системы счисления (d, o, x, X) в фигурных скобках через запятую. Если получилось относительное имя, то оно дополняется текущим суффиксом. Используется в основном для автоматической генерации обратных зон:

$ORIGIN 0.0.192.IN-ADDR.ARPA.
$GENERATE 1-127 $ CNAME $.0

преобразуется в

1.0.0.192.IN-ADDR.ARPA CNAME 1.0.0.0.192.IN-ADDR.ARPA
2.0.0.192.IN-ADDR.ARPA CNAME 2.0.0.0.192.IN-ADDR.ARPA
...
127.0.0.192.IN-ADDR.ARPA CNAME 127.0.0.0.192.IN-ADDR.ARPA

Протокол DNS

Запросы и ответы DNS обычно используют протокол UDP (порт 53, domain ), однако могут использовать и протокол TCP (порт 53, domain). Каждое сообщение полностью помещается в один UDP пакет, стало быть не может быть более 64 KB. В реальности, многие реализации имеют ограничение на размер нефрагментируемого UDP пакета в 576 байт. В такой пакет помещается информация о 10 записях типа NS в общем случае. Доменные имена корневых серверов Интернет были помещены в один домен, что позволило упаковать информацию с помощью ссылок (см. ниже) о 13 серверах. Если ответ не поместился в один фрагмент UDP, то в заголовке устанавливается бит TC (truncated), что приводит к повторному запросу с использованием протокола TCP. При использовании протокола TCP к каждому сообщению добавляется префикс (2 байта), содержащий длину сообщения без учета префикса. Первым передается левый бит (нулевой) – старший по значению.

Формат запросов и ответов одинаков (подробнее см. RFC 1035 )

Расширение протокола TSIG

RFC 2845 расширяет протокол DNS возможностью проверки целостности запросов и ответов (QUERY), передачу зон, а также аутентификацию динамических изменений (UPDATE, RFC 2136) с помощью криптографически стойких контрольных сумм – TSIG (transaction signatures). При генерации хеша используется алгоритм HMAC-MD5 и разделяемый между двумя участниками секрет (симметричный ключ). Механизм распределения ключей не определяется. Участники транзакции могут разделять несколько ключей, поэтому для идентификации конкретного ключа используется его имя в формате доменного имени. Для предотвращения атак повторного воспроизведения запись содержит время подписи (требуется синхронизация времени с помощью, например, NTP). Отвечая на защищенный запрос сервер посылает ответ, защищенный тем же алгоритмом и ключом. В качестве ключей рекомендуется использовать случайные последовательности длиной не менее 128 бит.

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

RFC 2845 вводит новый тип записи TSIG (250) и несколько новых кодов ответа. Запись типа TSIG является виртуальной, т.е. вычисляется во время транзакции, не содержится в файле данных зоны и не кешируется. Запись добавляется в раздел дополнительных данных; включает имя разделяемого ключа, класс (ANY), TTL (0), имя алгоритма (сейчас всегда HMAC-MD5), время подписи, интервал отклонения времени, хеш, идентификатор исходного сообщения (используется при ретрансляции динамических изменений), код ошибки, дополнительный данные об ошибке (например, расхождение часов участников). Для генерации хеша используется исходное сообщение, имя ключа, класс, TTL, имя алгоритма, время подписи, интервал отклонения времени. При генерации хеша ответа в исходные данные включается также хеш запроса.

Динамические изменения зоны

RFC 2136 расширяет протокол DNS возможностью динамического изменения содержимого зоны по требованию клиента. Это избавляет от необходимости при частых изменениях (например, работа DHCP) редактировать текстовый файл с описанием зоны и перезапускать сервер. С помощью данного расширения можно одним пакетом внести несколько изменений в зону, управляемую данным первичным уполномоченным сервером (все доменные имена должны быть внутри зоны):

• добавить запись ресурса (RR) в набор записей ресурсов (RRset); записи типа SOA и CNAME не добавляются, а замещаются; если SOA не было или её серийный номер был больше, то добавление игнорируется; попытка заменить нормальный набор записей на CNAME или CNAME на нормальный набор записей игнорируется; попытка добавить дублирующую запись игнорируется
• удалить запись ресурса (RR) с заданным значением из набора записей ресурсов (RRset); не удаляются последняя запись NS и SOA самой зоны; попытка удалить несуществующую запись игнорируется
• удалить набор записей ресурсов (RRset); не удаляются записи NS и SOA самой зоны; попытка удалить несуществующий набор игнорируется
• удалить все наборы ресурсов, относящиеся к указанному доменному имени; не удаляются записи NS и SOA самой зоны; попытка удалить несуществующий набор игнорируется

Набор изменений может быть предварён набором условий следующих типов (все доменные имена должны быть внутри зоны):

• указанное доменное имя имеет хотя бы одну запись ресурса указанного типа
• указанное доменное имя имеет записи ресурсов указанного типа с заданными значениями (значение TTL не учитывается, при сравнении имён прописные и строчные буквы не различаются, шаблоны не обрабатываются, синонимы (CNAME) не обрабатываются)
• указанное доменное имя не имеет ни одной записи ресурса указанного типа
• указанное доменное имя имеет хотя бы одну запись ресурса
• указанное доменное имя не имеет ни одной записи ресурса

есь пакет условий и изменений является атомарным, т.е. обрабатывается как единое неделимое целое (как транзакция в СУБД). При этом сервер обязан записать изменения на диск до ответа клиенту. bind временно записывает изменения в журнал и сливает его с файлом зоны позднее. Если изменения не затронули SOA, то сервер должен увеличить серийный номер автоматически. Метод стандартом не задаётся. Если автоувеличение серийного номера производится с задержкой, но она не должна быть более 300 секунд или 1/3 от времени обновления зоны.

RFC 2136 вводит новый класс NONE (254) и несколько новых кодов ответа. Формат запросов и ответов совпадает с форматом обычных запросов и ответов, но имеет код запроса – UPDATE (5). Секция запроса содержит имя изменяемой зоны (ровно одна запись ресурса типа SOA), секция ответа – набор условий, секция ссылок на уполномоченные сервера – добавляемые или удаляемые записи, секция дополнительной информации – связующие записи доменных имён вне зоны (может игнорироваться сервером).

Клиент может получить список потенциальных серверов из записей SOA, NS или внешними средствами.

Сервер может проверять право клиента на изменение зоны по его IP адресу (не рекомендуется) или при помощи механизма TSIG.

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

Обеспечение правильного порядка применения изменений (так чтобы “задержавшиеся в пути” старые изменения не перекрывали более новые) является нетривиальной задачей в среде TCP/IP, особенно при наличии нескольких делающих запросы клиентов и нескольких перенаправляющих вторичных серверов. Ответ сервера также может задержаться или затеряться. Авторы RFC рекомендуют пользоваться “маркерными” записями ресурсов для обеспечения синхронизации (такой маркер может, например, содержать время выдачи запроса).

DNS клиент (resolver)

Клиенты DNS обычно реализуются в виде библиотеки подпрограмм, присоединяемых к каждой программе (статически или динамически), которой требуется сервис доменных имен. Простой (stub) клиент обращается к указанному при настройке DNS серверу (серверам), интерпретирует ответ и возвращает результат запросившей программе. Реализация клиента в Solaris (Solaris 2.5.1 и младше соответствует BIND 4.8.3; с заплатками – BIND 4.9.3; Solaris 2.6, 7 и 8 – BIND 4.9.4-P1) и Linux (клиент DNS входит в состав пакета glibc, а не bind) позволяет также получить информацию из других источников (локальный файл, NIS, NIS+ и т.д.) в зависимости от настройки Name Service Switch. Некоторые клиенты позволяют кешировать информацию самостоятельно, либо с помощью nscd.

Общий алгоритм запроса таков: прикладная программа, которой необходимо, например, получить адрес хоста по его имени, вызывает подпрограмму gethostbyname(3) или аналогичную ей. При сборке программы к ней прилинковываются подпрограммы из библиотеки libc (glibc), которые проверяют наличие требуемой информации в кеше nscd (если, конечно, запущен сервер nscd). Если информацию из кеша извлечь не удалось, то используется NSS для определения сервиса имен, который (которые) будет использован для поиска адреса по имени. В частности, в настройках NSS может быть указан dns в качестве сервиса имен для поиска доменных имен. В этом случае используются функции, указанные в resolver(3), которые и являются “настоящим” клиентом DNS (они формируют запрос к серверу в соответствии с DNS протоколом и обрабатывают ответ).

Настройка работы клиента DNS производится с помощью файла /etc/resolv.conf или переменных окружения при запуске процесса.

Каждая строка /etc/resolv.conf содержит одну инструкцию, комментарии начинаются с точки с запятой или символа # (осторожно! клиент может не сообщать об ошибках в этом файле!):

• nameserver IP-адрес-обслуживающего-сервера (можно указать до 3 строк с адресами серверов; по умолчанию используется сервер, расположенный на этом же хосте (его также можно указать с помощью его IP адреса или адреса 0.0.0.0 или loopback адреса 127.0.0.1); клиент опрашивает указанные сервера в порядке их перечисления, если не дождался ответа от предыдущего сервера из списка или получил сообщение об ошибке (недоступен порт на сервере, хост сервера или вся сеть); опрос по списку повторяется несколько раз в зависимости от версии клиента (от 2 до 4); интервал первоначального ожидания зависит от версии (от 2 до 5 секунд) и числа серверов в списке; при каждом следующем прохождении по списку интервал ожидания удваивается; суммарное время ожидания достигает 80 секунд для версии до 8.2 и 24 секунд для более новых версий)
• domain имя-локального-домена (добавляется к относительным доменным именам перед поиском; точка в конце имени не нужна; по умолчанию извлекается из доменного имени хоста (см. hostname(1)); имя локального домена также задает список поиска по умолчанию (для bind 4.8.3: имя локального домена и список его предков, имеющих не менее 2 простых имен; для новых версий bind: только имя локального домена))
• search список-имен-доменов-через-пробел (до 6 имен доменов в порядке предпочтения; первое имя в списке устанавливает имя локального домена; инструкции domain и search – взаимоисключающие (выполняется последняя из них); список поиска используется для разрешения относительных доменных имен; для bind 4.8.3 разрешение относительного имени делается сначала по списку поиска (имена доменов из списка поиска приписываются по очереди справа от относительного имени перед запросом к серверу DNS), при неудаче имя считается абсолютным и делается еще один запрос; для новых версий bind сначала разрешение для относительного имени, содержащего хотя бы одну точку, делается так как будто оно является абсолютным, при неудаче используется список поиска)
• sortlist IP-адрес-сети/маска … (версия 4.9 и выше; позволяет клиенту отдавать предпочтение указанным сетям при получении ответов, содержащих несколько адресов – их он помещает в начало списка, остальные в конец; можно указывать до 10 сетей)
• options опция … (версия 4.9 и выше; позволяет изменять настройки клиента
  • debug (на stdout)
  • ndots:число-точек (минимальное число точек в аргументе, при котором поиск по имени осуществляется до использования списка поиска; по умолчанию – 1)
  • attempts:число-опросов-списка-серверов (по умолчанию – 2; максимум – 5)
  • timeout:начальный-интервал-ожидания (по умолчанию – 5 секунд; максимум – 30 секунд)
  • rotate (при каждом обращении использовать другой порядок серверов с целью распределения нагрузки; распределение осуществляется только в рамках одного процесса – при следующем запуске программы первый сервер в списке опять станет первым используемым)
  • no-check-names (запретить лексическую проверку простых имен, которая включена в версии 4.9.4 и старше)

Конкретная реализация resolver(3) может иметь другие значения параметров по умолчанию – смотри /usr/include/resolv.h. Различные программы могут быть собраны с различными версиями клиента DNS. К счастью, клиент DNS пропускает непонятные ему строки из файла /etc/resolv.conf. Старые версии клиента DNS (resolv+) могут управляться файлом /etc/host.conf, в этом случае см. host.conf(5). Некоторые программы самостоятельно устанавливают нестандартные значения параметров клиента DNS при инициализации.

Переменная окружения LOCALDOMAIN перекрывает действие инструкций domain и search. Переменная окружения RES_OPTIONS перекрывает действие инструкции options. Переменная окружения HOSTALIASES позволяет задать имя файла (например, /etc/host.aliases), содержащего список синонимов доменных имен (по одному простому имени и его доменному синониму без завершающей точки на строке через пробел).

Если при загрузке компьютера требуется наличие работающего локального сервера DNS (обычно из-за указания доменных имен в ifconfig или route), то желательно обеспечить резервный метод разрешения доменных имен с помощью настройки NSS и заполнения /etc/hosts, иначе клиентские компьютеры будут вынуждены дожидаться загрузки одного из серверов DNS. Тем более важно обеспечить резервный метод для хостов, на которых работают серверы DNS. А лучше всего не использовать DNS во время загрузки. Ещё имеется загадочный файл /etc/ppp/resolv.conf.

Настройка DNS в MS Windows производится с помощью графического интерфейса. Изготовитель уверяет, что это очень просто;). Вот только отличаются реализации клиента DNS в различных версиях MS Windows больше, чем Unix от Linux (в частности, TCP/IP стек в W2000 и XP взят из FreeBSD (NetBSD?):

• W95 – отдельные стеки для локальной сети (Control Panel -> Network -> TCP/IP -> DNS) и коммутируемых соединений (My Computer -> Dial-up Networking -> right click на нужном соединении -> Properties -> Server Types -> TCP/IP); при использовании коммутируемого доступа рекомендуется оставлять пустым список DNS серверов в основном стеке и выбирать вариант “Server assigned name server addresses” при настройке коммутируемых соединений
• W98 – визуально настройка ничем не отличается; возвращаемые сервером адреса сортируются в соответствии с таблицей маршрутизации; клиент работает одновременно и с серверами, указанными для основного стека, и с серверами, указанными для данного коммутируемого соединения
• NT – визуально очень похоже на W95; настройки для основного стека (Control Panel -> Network -> Protocols -> TCP/IP -> DNS) и коммутируемого соединения (My Computer -> Dial-up Networking -> выбрать нужное соединение из выпадающего меню -> More -> Edit Entry -> Modem Properies -> Server -> TCP/IP) используются в нужное время; клиент кеширует полученные результаты (в пределах процесса); в SP4 клиент после неудачи с первым сервером начинает рассылать запросы всем известным ему серверам параллельно
• W2000 (Start -> Setting -> Network and Dial-up -> right click на Local Area Connection -> Properies -> TCP/IP); поведение клиента аналогично NT SP4

Сервера DNS

Немного позднее опубликую статью о Bind 9

Статья взята с сайта Bog BOS , автор Сергей Евгеньевич Богомолов.

Добавить коротко про ARP/RARP

Помимо основных протоколов стек протоколов TCP/IP содержит большое количество вспомогательных и сопутствующих. Среди них: Dynamic Host Configuration Protocol (DHCP) - сервис, используемый для автоматического назначения IP-адресов хостам.

Windows Internet Name Service (WINS) - сервис, поддерживающий распределенную, динамически обновляемую базу имен хостов и соответствующих им IP-адресов

Domain Name System (DNS) - служба разрешения доменных имен, базовая для Интернета. В традиционной реализации DNS требует указывать статическое соответствие между именем хоста и его адресом.

Domain Name System (DNS) - служба разрешения доменных имен, базовая для Интернета. В традиционной реализации DNS требует указывать статическое соответствие между именем хоста и его адресом. Так как служба DNS не динамична, изменения в базе данных DNS (например, при добавлении нового хоста или перемещении его в другую подсеть) необходимо делать вручную. В Windows NT Server 4.0 реализован полный сервер DNS, который интегрирован со службой WINS и снабжен графической утилитой администрирования. Объединение DNS и WINS позволяет создать некоторую форму динамического DNS. Это объединение поддерживается сервисом DNS, выполняемым на Windows NT Server 4.0. Теперь можно, обратившись к DNS, запросить у WINS имя нижнего уровня в дереве DNS.

DNS преобразует символические имена машин в IP-номера (IP-адреса), которые являются адресами машин и из IP-номеров (IP-адресов) в имена. Преобразование, в данном случае, это создание ассоциации между доменным именем и IP-номером. Так, например, имени www.gu.net соответствует IP-адрес 194.93.190.121. За эти преобразования несут ответственность name servers (сервера имен).

DNS-сервер (или сервер имен) - это программа (одна или несколько), обрабатывающая запросы типа:

"определить IP-адрес по имени",

"определить имя по IP-адресу",

"определить имя сервера, на который должна направлятся электронная почта для заданного домена",

"определить имя другого сервера имен, ответственного за заданный домен".

На одном компьютере может находится одновременно несколько серверов имен.

DNS имеет иерархическую древовидную структуру, "корнями" которой являются так называемые root-сервера . На root-серверах хранится информация о том, какие есть домены первого уровня (com, org, net, gov, ua, ru и другие) и ссылки на DNS-сервера отвечающие за эти домены.

DNS (Domain Name System) - это распределенная база данных, поддерживающая иерархическую систему имен для идентификации узлов в сети Internet. Служба DNS предназначена для автоматического поиска IP-адреса по известному символьному имени узла. Спецификация DNS определяется стандартами RFC 1034 и 1035. DNS требует статической конфигурации своих таблиц, отображающих имена компьютеров в IP-адрес.

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

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

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

Корень базы данных DNS управляется центром Internet Network Information Center. Домены верхнего уровня назначаются для каждой страны, а также на организационной основе. Имена этих доменов должны следовать международному стандарту ISO 3166. Для обозначения стран используются трехбуквенные и двухбуквенные аббревиатуры, а для различных типов организаций используются следующие аббревиатуры:

com - коммерческие организации (например, microsoft.com);

edu - образовательные (например, mit.edu);

gov - правительственные организации (например, nsf.gov);

org - некоммерческие организации (например, fidonet.org);

net - организации, поддерживающие сети (например, nsf.net).

Каждый домен DNS администрируется отдельной организацией, которая обычно разбивает свой домен на поддомены и передает функции администрирования этих поддоменов другим организациям. Каждый домен имеет уникальное имя, а каждый из поддоменов имеет уникальное имя внутри своего домена. Имя домена может содержать до 63 символов. Каждый хост в сети Internet однозначно определяется своим полным доменным именем (fully qualified domain name, FQDN) , которое включает имена всех доменов по направлению от хоста к корню. Пример полного DNS-имени: citint.dol.ru. Чтобы дать возможность шлюзам в интернете сообщать об ошибках или предоставлять информацию о нестандартных условиях работы, разработчики добавили механизм сообщений специального назначения в протоколы TCP/IP. Этот механизм, известный как Межсетевой Протокол Управляющих Сообщений(ICMP), считается необходимой частью IP и должен включаться в каждую реализацию IP.

Протокол обмена управляющими сообщениями ICMP (Internet Control Message Protocol) позволяет маршрутизатору сообщить конечному узлу об ошибках, с которыми машрутизатор столкнулся при передаче какого-либо IP-пакета от данного конечного узла.

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

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

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

Как и весь другой траффик, сообщения ICMP передаются по интернету в поле данных IP-дейтаграмм. Конечным назначением сообщений ICMP, тем не менее, является не прикладная программа или пользователь на машине назначения, а программное обеспечение IP на этой машине. То есть, когда прибывает сообщение ICMP об ошибке, его обрабатывает модуль программного обеспечения ICMP. Конечно, если ICMP определит, что ошибка была вызвана конкретным протоколом более высокого уровня или прикладной программой, он сообщит об этом соответствующему модулю. Т.о., Межсетевой Протокол Управляющих Сообщений позволяет шлюзам посылать управляющие сообщения или сообщения об ошибках на другие шлюзы или ГВМ; ICMP обеспечивает взаимодействие между программным обеспечением Межсетевого Протокола разных машин.

СущностьDNS

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

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

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

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

Функции DNS

ДНС протокол можно охарактеризовать такими функциями:

Распределенность администрирования. Люди или разные организации несут ответственность за некоторые части иерархической структуры.

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

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

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

Резервирование. За обслуживание и хранение собственных зон отвечают сразу несколько серверов, которые разделены на физические и логические, что в результате гарантирует сохранность данных и продолжение работы даже при сбое одного из узлов.

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

Протокол DNS выполняет две основные функции. Он позволяет клиентским компьютерам запрашивать DNS-сервер об IP-адресе или имени какого-либо хоста в сети, а также позволяет производить обмен информацией между базами данных серверов DNS. В этом протоколе используется стандартный формат типа "запрос-ответ", где клиент посылает пакет запроса, и сервер отвечает либо пакетом с информацией, полученной из базы данных, либо сообщением об ошибке, в котором указывается причина отказа в обработке запроса. В своей работе этот протокол использует порт 53 и хорошо известные протоколы - TCP или UDP. Причем в последнее время UDP стал более распространенным методом транспортировки пакетов по сети Internet. Пакет DNS состоит из пяти полей: заголовка, вопроса, ответа, полномочий и поля дополнительной информации. На рис. 4.5 показана общая структура пакета DNS.

Рис. 4.5.

Поле заголовка

В поле заголовка содержится информация о пакете и его назначении. В нем дается общее описание пакета (пакет запроса или пакет ответа) и указывается количество данных, содержащихся в каждом поле данных пакета. Описание заголовка приводится в табл. 4.3 .

Таблица 4.3. Поле заголовка DNS-пакета

Бит	Описание
0-15	ID
16	QR
17-20	OPCODE
21	AA
22	TC
23	RD
24	RA
25-27	Z
28-31	RCODE
32-47	QDCOUNT
48-63	ANCOUNT
64-79	NSCOUNT
80-95	ARCOUNT

Биты ID являются уникальным 16-битовым идентификационным номером пакета запроса. Пакет ответа, формируемый сервером, также использует этот идентификационный номер, чтобы клиент мог сопоставить ответ сервера со своим запросом. Бит QR обозначает тип пакета (пакет запроса - 0, пакет ответа - 1). Поле OPCODE определяет тип запроса - стандартный (0), обратный (1) или запрос о статусе сервера (2).

Следующие четыре бита определяют различные параметры пакета. Бит AA устанавливается, когда ответ является авторитетным (данные поступают напрямую от DNS-сервера, ответственного за зону). Неавторитетные ответы могут поступать от серверов DNS, в кэше которых сохранилась информация об исходных записях от предыдущих запросов. Эта информация считается неавторитетной, так как есть вероятность, что с момента последнего обращения к серверу информация была изменена. Бит TC устанавливается, когда требуется урезать данные в пакете до вида, удобного для передачи по сети. Такое вполне возможно при использовании протокола UDP, согласно которому размер пакета не должен превышать 512 байт. Бит RD включается, когда клиент желает рекурсивно запрашивать DNS-сервер на постоянной основе. Если этот бит установлен, то DNS-сервер будет запрашивать другие DNS-серверы, пока не получит ответ. Если этот бит не установлен, то DNS-сервер будет возвращать на запрос любую информацию, которая у него имеется. Бит RA устанавливается, чтобы уведомить клиента о возможности рекурсивного запроса на данный сервер. Биты Z в настоящее время не используются и зарезервированы на будущее.

Биты RCODE используются только в пакетах ответов. Они отображают состояние ответа - без ошибок (0), ошибки в пакете запроса (1), внутренние ошибки не дали возможности серверу обработать запрос (2), имя, указанное в запросе, не существует (3), данный тип запроса не поддерживается сервером (4) и сервер отказался обработать запрос (5).

Остальные четыре параметра заголовка представляют собой 16-битовые числа и используются в качестве счетчиков. С их помощью ведется учет количества исходных записей, возвращаемых в пакете. QDCOUNT отображает количество запросов (в пакет может включаться более одного запроса). ANCOUNT - количество исходных записей, включенных в ответ. NSCOUNT обозначает число исходных записей об авторитетных серверах имен, а ARCOUNT - число записей в поле дополнительной информации.

Поле вопроса

Поле вопроса содержит запросы, ответы на которые клиент желает получить от DNS-сервера. В одном пакете DNS может содержаться несколько запросов. Количество запросов в пакете определяется параметром QDCOUNT из поля заголовка. Поле вопроса состоит из трех частей: списка преобразуемых доменных имен; поля типов записей, которые клиент желает получить в ответе, и параметра класса запроса. Список преобразуемых доменных имен представляет собой список имен, для которых клиент желает получить IP-адреса. Для формирования списка имен используется специальный формат. Перед каждым именем ставится однобайтное значение, которое определяет длину имени. Конец списка обозначается именем с нулевой длиной. После текстовой части следует двубайтная запись QTYPE . В ней определяется, в каком виде клиент желает принимать информацию о имеющихся доменах. Эти значения полностью соответствуют типам исходных записей в DNS. Например, для того чтобы найти почтовый сервер для определенного домена, вам следует воспользоваться типом записи МХ . И, наконец, последний параметр в поле вопроса - QCLASS . Он определяет класс запроса, который в нашем случае для сети Internet всегда будет IN .

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

Также стоит пару слов сказать про процедуру обратного сопоставления – получение имени по предоставленному IP-адресу. Это происходит, например, при проверках сервера электронной почты. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя.

Кто управляет и поддерживает DNS-сервера?

Когда вы вводите адрес интернет-ресурса в строку браузера, он отправляет запрос на DNS-сервер отвечающий за корневую зону. Таких серверов 13 и они управляются различными операторами и организациями. Например, сервер a.root-servers.net имеет IP-адрес 198.41.0.4 и находится в ведении компании Verisign, а e.root-servers.net (192.203.230.10) обслуживает НАСА.

Каждый из этих операторов предоставляет данную услугу бесплатно, а также обеспечивает бесперебойную работу, поскольку при отказе любого из этих серверов станут недоступны целые зоны интернета. Ранее корневые DNS-серверы, являющиеся основой для обработки всех запросов о доменных именах в интернете, располагались в Северной Америке. Однако с внедрением технологии альтернативной адресации они «распространились» по всему миру, и фактически их число увеличилось с 13 до 123, что позволило повысить надёжность фундамента DNS.

Еще один вариант – использование функции IP Source Guard. Она основывается на технологии uRPF и отслеживании DHCP-пакетов для фильтрации поддельного трафика на отдельных портах коммутатора. IP Source Guard проверяет DHCP-трафик в сети и определяет, какие IP-адреса были назначены сетевым устройствам.

После того как эта информация была собрана и сохранена в таблице объединения отслеживания DHCP-пакетов, IP Source Guard может использовать ее для фильтрации IP-пакетов, полученных сетевым устройством. Если пакет получен с IP-адресом источника, который не соответствует таблице объединения отслеживания DHCP-пакетов, то пакет отбрасывается.

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