Кто ты такой, DNS?

Основные понятия

Не секрет, что каждая машина в сети, работающая по протоколу IP, уникально идентифицируется либо IPv4, либо IPv6. Использование данного номера при организации работы в сети имеет ряд существенных недостатков. Вот лишь некоторые из них:

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

Для решения проблемы именования была создана DNS (Domain Name System). Сервер DNS способен возвратить запрошенному "названию" IP адрес. Название имеет древовидную структуру и состоит из частей, разделенных точкой. Корнем дерева является узел сети с названием ".". "Название" есть не что иное как имя домена. А сам домен - это узел в дереве имён, вместе со всеми подчинёнными ему узлами (если таковые имеются), то есть именованная ветвь или поддерево в дереве имен. Уровень домена определяется количеством частей в названии (высотой дерева). Так, к примеру, домен hoxnox1.otdel4.a - домен третьего уровня, otdel4.a - второго, a - первого.

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

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

• A (запись адреса) связывает имя хоста с его IP адресом.
• AAAA (IPv6 запись адреса) связывает имя хоста с IPv6 адресом
• CNAME (каноническая запись имени) используется для перенаправления на другое имя
• MX (почтовый обменник) указывает серверы обмена почтой для данного домена
• NS указывает DNS сервер, обслуживающий данный номен
• PTR (запись указателя) - связывает IP адрес хоста с его каноническим именем
• SOA (начальная запись зоны) указывает сервер, на котором хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги кеширования зонной информации и взаимодействия DNS серверов

Дополнительные типы ресурсных записей:

• HINFO информация о хосте (тип железа и операционной системы).

  example.com  IN  HINFO  "Watch Dog Hardware"  "Rabid OS"
  

• AFSDB указывает расположение AFS или DCE серверов (см. Andrew project)

• X25, ISDN, RT Первые две связывают имя хоста с адресом в сети X.25 или ISDN соответственно. Эти записи интересны в совокупности с RT (route throught) записями. Последние, аналогично MX записям, содержат данные, описывающие методы доставки пакетов определенному хосту. Например следующая запись

  housesitter.movie.edu.  IN  RT  10 relay.pink.com.
                          IN  RT  20 delay.hp.com.
  

сообщает хосту, о том, что маршрут к housesitter.movie.edu лежит через relay.pink.com, либо через delay.hp.com.

• LOC (дислокация) экспериментальный тип записи. Описывается RFC1876 и содержит широту, долготу и высоту над уровнем море.

  Формат:

  <degrees> [minutes [seconds.<fractional seconds>]] (N|S|E|W)
  

  Высота над уровнем моря указывается в метрах.

• SRV указывает на серверы для сервисов, используется, в частности для Jabber и Active Directory

Обратный поиск

Существует другая задача - установить имя хоста по его IP адресу. Для этих целей можно использовать домен in-addr.arpa. В его зоне имеются PTR ресурсные записи вида

XXX.XXX.XXX.XXX.in-addr.arpa

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

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

Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP датаграммы. TCP используется для AXFR-запросов (запрос всей зоны). Для исполнения последних, необходимы специальные права.

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

Аналогично, DNS-сервер может быть рекурсивным (умеющим выполнять полный поиск) и нерекурсивным (не умеющим выполнять полный поиск). Некоторые программы DNS-серверов, например, BIND, можно сконфигурировать так, чтобы запросы одних клиентов выполнялись рекурсивно, а запросы других — нерекурсивно.

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

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

Рассмотрим на примере работу всей системы.

Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org»? Однако, сервер DNS может ничего не знать не только о запрошенном имени, но даже обо всём домене wikipedia.org. В этом случае сервер обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является ответственным за зону org.» Тогда сервер DNS направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является ответственным за зону wikipedia.org.» Наконец, тот же запрос отправляется к третьему DNS-серверу и получает ответ — IP-адрес, который и передаётся клиенту — браузеру.

В данном случае при разрешении имени, то есть в процессе поиска IP по имени:

• браузер отправил известному ему DNS-серверу рекурсивный запрос — в ответ на такой тип запроса сервер обязан вернуть «готовый результат», то есть IP-адрес, либо сообщить об ошибке;
• DNS-сервер, получивший запрос от браузера, последовательно отправлял нерекурсивные запросы, на которые получал от других DNS-серверов ответы, пока не получил ответ от сервера, ответственного за запрошенную зону;
• остальные упоминавшиеся DNS-серверы обрабатывали запросы нерекурсивно (и, скорее всего, не стали бы обрабатывать запросы рекурсивно, даже если бы такое требование стояло в запросе).

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

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

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

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

TSIG DNSSEC Extensions

Инструменты

Самым распространённым DNS сервером является BIND, консольные клиенты - dig и nslookup.

dig hoxnox1.otdel4.a

dig @128.44.44.100 +short hoxnox1.otdel4.a

dig @server4ibm otdel4.a axfr

dig @pdns1.ultradns.net +short 144.22.15.112.in-addr.arpa PTR

Структура сообщения

+---------------------+
|        Header       |
+---------------------+
|       Question      | the question for the name server
+---------------------+
|        Answer       | RRs answering the question
+---------------------+
|      Authority      | RRs pointing toward an authority
+---------------------+
|      Additional     | RRs holding additional information
+---------------------+

Header:

                                1  1  1  1  1  1
  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      ID                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    QDCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ANCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    NSCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ARCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Литература

• DNS and BIND, 4th Edition By Paul Albitz, Cricket Liu
• wikipedia.org
• RFC1034, RFC1035