DNS (Domain Name System) ­ Дневник ­ Максим Боголепов

Система доменных имен (DNS, Domain Name System) представляет собой механизм, а именно распределенную БД, предназначенный для поиска по имени хоста его IP адреса и некоторой другой информации (например, имени почтового сервера). В статье описываются: пространство доменных имен архитектура системы доменных имен пространство доменных имен Интернет отображение адресов в имена записи ресурсов протокол запросов и ответов DNS расширение протокола TSIG (проверки целостности сообщений) динамические изменения зоны клиент DNS (resolver)

 

Пространство доменных имен

Пространство доменных имен имеет вид дерева (иерархии) узлов. Каждый узел дерева помечен простым именем. Простое имя начинается на букву Latin-1 (в процессе эволюции стандарта было разрешено начинать простое имя с цифры), кончается на букву или цифру, в промежутке буквы или цифры или минус (RFC 952).

Протокол DNS допускает использование любых значений октетов в простом имени, но традиции нарушать не стоит – последствия вам не понравятся. Прописные и строчные буквы не различаются. Длина простого имени – не более 63 символов. Простые имена узлов, имеющих общего предка, должны быть уникальны. Полное имя узла записывается как последовательность простых имен самого узла и всех его предков до корня включительно, записываемых слева направо и разделяемых точками. Имя корня – пустая строка, т.е. полное имя обязательно завершается точкой (заметьте, что в некоторых случаях, например, при записи почтовых адресов, заключительная точка должна быть опущена). Максимальная длина полного имени – 255 символов, включая точки. Максимальное число уровней дерева – 127.

Кроме полного (абсолютного) имени узла (FQDN, fully qualified domain name) некоторые программы позволяют использовать относительные (относительно некоторого опорного узла) имена. Относительные имена отличаются отсутствием завершающей точки (и путаются при этом с именами почтовых доменов также не имеющими завершающей точки!)

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

Поддерево вместе со своим корневым узлом называется доменом (поддоменом). Имя домена определяется полным именем его корневого узла. Группировка узлов в домены является чисто логической, т.е. не определяется ни месторасположением, ни IP-адресом, ни маршрутизацией. Узел входит в состав нескольких вложенных доменов (поддеревьев) по пути от узла к корню. Домен первого (высшего) уровня в качестве непосредственного предка имеет корневой узел. Домен второго уровня в качестве непосредственного предка имеет домен первого уровня.

Дерево доменых имен делится на независимо администрируемые части, называемые зонами (здесь имеются в виду права на администрирование части БД пространства доменных имен, а не на администрирование самих хостов). Зона включает в себя домен, делегированный данной организации, за вычетом поддоменов, право администрирования которыми было делегировано ею другим организациям.

Кроме пространства доменных имен Интернет допустимы частные пространства имен.

 

Архитектура системы доменных имен

Пространство доменных имен реализовано в виде распределенной БД, включающей в себя серверы DNS, клиенты DNS (resolver), объединенные общим протоколом запросов к БД и обмена информацией между серверами. Информация, индексированная доменным именем, хранится в записях ресурсов (RR, resource records). Запись ресурса имеет класс (в настоящее время используются записи класса интернет – IN), тип записи (определяет характер хранимой информации) и саму информацию. В частности, для каждого ресурса хранится максимально допустимое время кеширования полученной информации (TTL, time to live). Совокупность записей ресурсов, имеющих совпадающее доменное имя, класс и тип, называется набором записей ресурсов (RRset). Основным типом хранимой информации являются IP адреса. Доменному имени может соответствовать несколько IP-адресов (несколько сетевых интерфейсов на компьютере), одному адресу может соответствовать несколько имен (синонимы). Порядок выдачи записей при запросе не обязан соответствовать порядку записей при описании зоны.

Уполномоченный (авторитативный, authoritative) сервер обладает полной информацией об определенной зоне. Адреса уполномоченных серверов зоны (домена, объемлющего зону) указываются в информации о родительском домене. Уполномоченные сервера делятся на первичные (primary master) и вторичные (secondary master, slave). Первичный сервер загружает данные зоны из локального источника (обычно из файла). Вторичный сервер получает данные зоны от другого уполномоченного сервера (обычно, но не обязательно от первичного сервера). Этот процесс называется передачей зоны (zone transfer). При недоступности исходного уполномоченного сервера вторичный сервер может загружать зону из резервной копии, предусмотрительно сохраненной в файле. Наличие нескольких уполномоченных серверов позволяет разделить нагрузку и обеспечить защиту от сбоев. DNS сервер (процесс) может быть уполномоченным сразу для нескольких зон или ни для одной (кеширующий сервер), причем для одних зон он может быть первичным, а для других – вторичным. Уполномоченный сервер, указанный в родительском домене (при делегировании зоны), но не описанный в записи самой зоны, называется скрытым (stealth) уполномоченным сервером. Скрытым может быть и первичный сервер (hidden primary). Используется в ситуации, когда первичный сервер находится за сетевым экраном. Неверная настройка, при которой уполномоченный сервер, указанный в родительском домене (при делегировании зоны), отказывается признавать себя уполномоченным, называется ламерским делегированием (lame delegation, lame servers).

Клиенты обычно реализуются в виде библиотеки подпрограмм, присоединяемых к каждой программе (статически или динамически), которой требуется сервис доменных имен. Простой (stub) клиент обращается к указанному при настройке DNS серверу (серверам), интерпретирует ответ и возвращает результат запросившей программе. Если используется протокол UDP, то клиент должен уметь обрабатывать ошибки. Если сервер не отвечает, клиент должен уметь использовать запасной(ые). Реализация клиента в Solaris и Linux позволяет также получить информацию из других источников (локальный файл, NIS, NIS+ и т.д.) в зависимости от настройки Name Service Switch. Некоторые клиенты позволяют кешировать информацию самостоятельно, либо с помощью nscd.

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

Для начала поиска информации о любом доменном имени серверу (или продвинутому клиенту) необходимо знать лишь адреса корневых серверов DNS. Корневые сервера (их 13 штук, от a.root-servers.net. до m.root-servers.net. – список корневых серверов в формате зоны можно получить командой fetch ftp://ftp.internic.net/domain/named.root) являются уполномоченными для корневой зоны и содержат ссылки на уполномоченные сервера зон первого уровня или сами являются уполномоченными серверами некоторых зон первого уровня (например: com. или net.). Число 13 определяется максимальным размером пакета UDP, который не будет фрагментирован в любой реализации (576 байт), в такой пакет как раз помещается ответ о 13 адресах. Список корневых серверов используется при запуске сервера, чтобы обратиться к одному из корневых серверов из этого списка для получения текущего состояния корневой зоны. По истечении TTL запрос текущего состояния корневой зоны повторяется с использованием первоначального списка (root hints). На запрос о домене корневой сервер возвращает как минимум имя и адрес уполномоченного сервера домена первого уровня, в который входит указанный в запросе домен. Обратившись по полученному адресу можно получить имя и адрес уполномоченного сервера домена второго уровня и т.д.

Запросы клиентов (или серверов) могут быть рекурсивными или итеративными. Рекурсивный запрос подразумевает, что запрашиваемый сервер должен самостоятельно пробежаться по всей цепочке до получения конечного ответа (в т.ч. отрицательного) и вернуть его клиенту. При этом сам сервер может пользоваться итеративными или рекурсивными запросами. Сервер может отказаться выполнять рекурсивные запросы “чужих” клиентов. При итеративном запросе сервер делает только один шаг поиска и возвращает ссылку на “более подходящий” сервер (или конечный ответ, если он сам является авторитативным для данного домена). Цикл поиска производится самим клиентом. Вся полученная информация как о запрашиваемом домене, так и о “промежуточных” уполномоченных серверах кешируется. Кешироваться могут и отрицательные ответы. При кешировании используется значение TTL.

Еще существуют (существовали, RFC 3425?) инверсные запросы (inverse queries), при котором DNS сервер производит поиск в локальных данных доменного имени, имеющего требуемое значение RR.
При выборе одного из уполномоченных серверов зоны используется время отклика (RTT, roundtrip time). При первых запросах уполномоченные сервера опрашиваются по очереди в случайном порядке. В дальнейшем используется уполномоченный сервер зоны, имеющий минимальное RTT.

 

Пространство доменных имен Интернет

Корневой зоной Интернет и системой корневых серверов управляет ICANN (Internet Corporation for Assigned Names and Numbers, не прибыльная частная организация с неясными юридическими правами относительно Интернет, ее “власть” основана на всеобщем добровольном доверии, организована по решению Министерства Торговли США). Ранее этим занималась IANA (Internet Assigned Numbers Authority), за которой и сейчас остались административные функции. В частности, ICANN делегирует права управления зонами первого уровня gTLD (generic top-level domains) и ccTLD (country code top-level domains).

gTLD управляет GNSO ICANN, (общий список регистраторов). Хотя права на администрирование каждого конкретного домена высшего уровня делегированы одной конкретной организации (оператору регистра), но зарегистрировать свой домен второго уровня в большинстве из них можно у одного из многочисленных регистраторов (коммерческие организации, имеющие доступ к общей базе данных оператора регистра). На сайте регистратора имеется whois-сервис для соответствующего домена. Такая двухуровневая система была разработана для обеспечения конкуренции между регистраторами. Более того, так как в таких странах как Россия нет действующих местных регистраторов gTLD, то для оплаты услуг в местной валюте придется прибегнуть к услугам агентов, посредников или провайдера (это уже третий уровень). Список gTLD:

• .aero – организации, связанные с авиацией;
• .arpa – используется для отображения адресов в имена, IANA и IAB;
• .biz – коммерческие организации;
• .com – когда-то здесь были коммерческие организации, сейчас свалка;
• .coop – кооперативы;
• .edu – образовательные организации, в основном из США;
• .gov – правительственные организации США;
• .info -свалка по замыслу;
• .int – международные организации;
• .mil – военные организации США;
• .museum – музеи;
• .name – персональные домены;
• .net – когда-то здесь были организации, обеспечивающие сетевую инфраструктуру, сейчас такая же свалка, как и в .com;
• .org – когда-то здесь были некоммерческие организации, сейчас такая же свалка, как и в .com;
• .pro – лицензированные профессионалы.

Список ccTLD базируется на стандарте двухбуквенных кодов государств и зависимых територрий ISO 3166. В каждой стране свои правила регистрации доменов второго уровня. Поиск информации можно начать со списков регистраторов и whois-сервисов:

• список Norid;
• список IANA;
• allwhois.

Администратор зоны .ru – РосНИИРОС (RIPN), whois-сервер – whois.ripn.net, список регистраторов зон .ru и .su, статистика по регистраторам и серверам зоны .ru.

 

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

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 195.161.72.0@whois.ripe.net), так и зона (whois 72.161.195.in-addr.arpa@whois.ripe.net)

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

 

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

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

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

Директива $ORIGIN задает текущий суффикс по умолчанию для относительных доменных имен. Директива $INCLUDE вставляет указанный файл в файл зоны и задает (только для записей из вставляемого файла) текущий суффикс для относительных доменных имен (суффикс может быть опущен). В старых версиях BIND и его производных изменение суффикса не срабатывает (хотя и сообщения об ошибке не выдается!) и приходится “обрамлять” директиву $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:

1. SOA (6) – запись SOA должна быть ровно одна;
   описание зоны должно начинаться с записи данного типа;
   определяет для указанного домена:
   — первичный уполномоченный сервер (primary master);
   — e-mail адрес ответственного за зону (символ “@” в почтовом адресе заменяется на точку, в конце добавляется точка);
   — номер версии (32 бита, должен увеличиваться при каждом изменении) используется вторичным уполномоченным сервером для проверки необходимости обновления зоны; принято записывать в виде даты в лексикографическом порядке и номера изменения в этот день – ГГГГММДДNN, например, 2004011501);
   — интервал обновления зоны (в секундах) для вторичных уполномоченных серверов;
   — интервал попытки обновления зоны (в секундах) при неудаче обновления;
   — интервал истечения полномочий для вторичных уполномоченных серверов при неудаче обновления (в секундах);
   — TTL: до RFC 2308 – минимальное TTL для ресурсов зоны (оно же значение по умолчанию), после – время жизни отрицательного кеширования (не более 3 часов).
2. NS (2) – доменное имя уполномоченного сервера указанного домена; может (и должно) быть несколько серверов (в т.ч. и указанный в SOA); не обязано лежать в том же домене;
3. A (1) – IP адрес для указанного доменного имени;
4. CNAME (5) – каноническое доменное имя для определяемого синонима;
   доменное имя-синоним не должно иметь других записей ресурсов;
   синонимы не должны использоваться в данных других ресурсов.
5. HINFO (13) – тип процессора и тип ОС; зачем сообщать об этом всем?
6. MX (15) – приоритет (число 16 бит, чем меньше число, тем больше приоритет) и доменное имя (не адрес!) почтового сервера для указанного доменного имени;
   доменное имя почтового сервера должно иметь запись A, не CNAME;
7. PTR (12) – доменное имя для соответствующего IP адреса (см. отображение адреса в имя);
8. TXT (16) – текстовая строка с произвольной информацией (не забывайте про кавычки!);
9. RP (17) – почтовый ящик ответственного лица (опять с заменой @ на .) и доменное имя, для которого существуют TXT записи с пояснениями;
10. WKS (11) – IP-адрес, IP-протокол (8 бит; например: TCP, UDP), список сервисов (битовая карта портов 0-255; например: smtp, ftp), предполагается замена на SRV (33, RFC 2782);
11. A6 (38), AAAA (28), DNAME (39) – IPv6 (RFC 2874, RFC 2672);
12. CERT (37) – цифровой сертификат (RFC 2538);
13. KEY (25) – публичный ключ (DNSSEC, RFC 2535);
14. KX (36) – сервер ключей (RFC2230);
15. NAPTR (35) – Naming Authority Pointer (RFC 2168, RFC 2915);
16. NXT (30) – следующий домен (DNSSEC, RFC 2535);
17. SIG (24) – цифровая подпись (DNSSEC, RFC 2535);
18. MB (7), MD, MF, MG (8), MINFO (14), MR (9) – остатки проекта по использованию DNS для хранения информации о почтовых ящиках и списках рассылки;
19. NULL (10) – произвольные данные (до 64 KB);
20. AFSDB (18), ISDN (20), RT (21), X25 (19), PX (26), GPOS (27), LOC (29) – экспериментальные, в реальности не используемые типы;
21. SRV (33), (RFC 2782), предложение “A DNS RR for specifying the location of services”) – локатор службы (сервиса): приоритет (0 имеет наивысший приоритет), вес, порт, доменное имя сервера;
    для доменного имени сервера должна быть соответствующая A-запись (а CNAME можно?);
    доменное имя локатора службы LDAP;
    для сетей MS выглядит так: _ldap._tcp.dc._msdcs;
    чтобы клиент получал адрес нужного сервера можно сделать несколько A-записей (клиент должен выбрать ближайший IP адрес) или развести их по сайтам: _ldap._tcp.имя-сайта._sites.dc._msdcs.

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):

1. Заголовок

• идентификатор запрос (копируется в ответ), 16 бит;
• запрос (0) или ответ (1);
• код запроса (4 бита);
  — QUERY (0), стандартный запрос;
  — IQUERY (1), инверсный запрос (отменен RFC 3425);
  — STATUS (2), запрос состояния сервера;
  — NOTIFY (4), извещение об изменении зоны для вторичных серверов (RFC 1996);
  — UPDATE (5), требование на изменение зоны к первичному серверу (RFC 2136);
• является ли отвечающий сервер уполномоченным для запрашиваемого доменного имени (относится к имени в запросе или первому имени в ответе);
• был ли ответ урезан из-за ограничений на размер UDP пакета;
• является ли запрос рекурсивным;
• доступна ли поддержка рекурсивных запросов на отвечающем сервере;
• нули (3 бита);
• код ответа (4 бита):
  — NoError (0) – OK;
  — FormErr (1) – ошибка формата запроса;
  — ServFail (2) – сбой сервера;
  — NXDomain (3) – доменное имя не существует (при ответе уполномоченного сервера);
  — NotImp (4) – данный вид запросов не поддерживается;
  — Refused (5) – нет прав доступа;
  — YXDomain (6) – доменное имя существует, а не должно бы (UPDATE, RFC 2136);
  — YXRRSet (7) – RR существует, а не должна бы (UPDATE, RFC 2136);
  — NXRRSet (8) – RR не существует, а должна бы (UPDATE, RFC 2136);
  — NotAuth (9) – сервер не является уполномоченным для зоны (UPDATE, RFC 2136);
  — NotZone (10) – доменное имя вне зоны (UPDATE, RFC 2136);
  — BADVERS (16?) – неверная версия OPT (RFC 2671);
  — BADSIG (16) – ошибка подписи транзакции TSIG (RFC 2845);
  — BADKEY (17) – ключ не признан (RFC 2845);
  — BADTIME (18) – подпись вне разрешенного интервала времени действия (RFC 2845);
  — BADMODE (19) – неверный режим TKEY (RFC 2930);
  — BADNAME (20) – дублирование имени ключа (RFC 2930);
  — BADALG (21) – алгоритм не реализован (RFC 2930);
• число записей в разделе запроса (16 бит);
• число записей в разделе ответа (16 бит);
• число записей в разделе уполномоченных серверов (16 бит);
• число записей в разделе дополнительной информации (16 бит).

2. RR запроса (число записей указано в заголовке)

• доменное имя (последовательность простых имен, каждое простое имя указано в виде байта длины и строки, завершается нулевым байтом);
  доменное имя (или несколько простых имен в конце доменного имени) могут быть заменены ссылкой на предшествующее вхождение того же имени – указатель состоит из 2 бит ‘11’ (вот почему длина простого имени ограничена 63 символами!) и 14 бит смещения от начала сообщения (т.е. с пакетами длинее 16 KB будут проблемы)
• тип требуемой записи (2 байта):
  — код типа записи;
  — TKEY (249) – ключ транзакции (RFC 2930);
  — TSIG (250) – цифровая подпись транзакции (RFC 2845);
  — IXFR (251) – запрос на передачу изменений зоны (RFC 1995);
  — AXFR (252) – запрос на передачу всей зоны;
  — MAILB (253) – запрос записей типа MB, MG или MR;
  — MAILA (254) – запрос записей типа MD или MF, не используется, заменен на MX;
  — * (255) – запрос записей любого типа.

• класс требуемой записи (2 байта), код класса или * (255) для получения информации любого класса.

3. RR ответа (число записей указано в заголовке):

• доменное имя (формат такой же, как в запросе);
• тип записи;
• класс записи;
• TTL (32 бита, в секундах);
• число байт данных записи (16 бит);
• данные записи, формат определяется типом записи.

4. RR, ссылающиеся на уполномоченный сервер (число записей указано в заголовке), формат такой же, как в разделе ответа.

5. RR с дополнительной информацией (число записей указано в заголовке), формат такой же, как в разделе ответа.

 

Расширение протокола 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 серверу (серверам), интерпретирует ответ и возвращает результат запросившей программе. Клиенты позволяют также получить информацию из других источников (локальный файл, 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/hosts (рекомендуется указывать как полное, так и краткое имя; обязательно иметь соответствие 127.0.0.1 – localhost.localdomain и localhost):

• символ ‘#’ является началом комментария (до конца строки);
• каждая строка задаёт соответствие между IP адресом и именем хоста, поля (через пробел):
  — IP адрес
  — имя
  — синоним
  — …

Формат локального файла /etc/networks (задаёт соответствие между именем сети и адресом сети; устарел, так как не позволяет задавать маску):

• символ ‘#’ является началом комментария (до конца строки)
• каждая строка задаёт соответствие между IP адресом и именем сети, поля (через пробел):
  — имя
  — IP адрес

Ещё имеется загадочный файл /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.

____________________
Оригинал статьи на сайте www.bog.pp.ru