Протоколы DNS (структура, обработка запросов, ресурсные записи), ARP и RARP

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 определяет начало зоны. Символ @ в начале первой строки файла определяет имя зоны. Здесь же указываются опционные параметры:

• номер версии файла (увеличивается каждый раз при внесении любых изменений, этот параметр отслеживается вторичным сервером);
• время обновления данных (период запросов, посылаемых вторичным сервером первичному) в секундах;
• длительность периода повторных попыток (retry) вторичного сервера в случае неудачи;
• продолжительность пригодности данных (expiration time) в секундах, по истечении этого времени вторичный сервер считает всю базу данных устаревшей.
• значение TTL по умолчанию.

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

@ IN SOA SRINIC.ARPA. HOSTMASTER.SRINIC.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 SRINIC.ARPA.
NS C.ISI.EDU.
NS BRLAOS.ARPA.
NS C.ISI.EDU.
;and their addresses
SRINIC.ARPA. A 10.0.0.51
A 26.0.0.73
C.ISI.EDU. A 10.0.0.52
BRLAOS.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сервер по ошибке может включить себя в такой список серверов. Если программное обеспечение клиента не проверяет список, запрос может быть послан этому серверу повторно, что вызовет бесконечный цикл запросов.

Возможна и другая схема возникновения циклов запросов. Предположим, что сервер <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-адресом. Причем эта ЭВМ может находиться где угодно в Интернет, но непременно работать c OS Windows. Формат поля данных UDP-дейтограммы запроса показан на рис. 5.7.

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

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

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

Поле флаги имеет следующую структуру (таблица 5.3.2.).

Для поля флаги имени характерна следующая структура (таблица 5.3.3).

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