Bog BOS: DNS (Domain Name System)

Последние изменения: 2018.12.21: sysadmin: bacula 9 и схема исключительно инкрементального копирования

Последнее изменение файла: 2019.12.05 Скопировано с www.bog.pp.ru: 2021.04.13

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

• пространство доменных имен
• архитектура системы доменных имен
• пространство доменных имен Интернет
• отображение адресов в имена
• записи ресурсов
• протокол запросов и ответов DNS
• расширение протокола TSIG (проверки целостности сообщений)
• динамические изменения зоны
• клиент DNS (resolver)
• сервера DNS
• утилиты

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

Пространство доменных имен имеет вид дерева (иерархии) узлов. Каждый узел дерева помечен простым именем. Простое имя начинается на букву 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.; список адресов можно узнать командой host -t NS .; зеркало f.root-servers.net расположено на M9-IX) являются уполномоченными для корневой зоны и содержат ссылки на уполномоченные сервера зон первого уровня или сами являются уполномоченными серверами некоторых зон первого уровня (например, 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 (когда-то здесь были коммерческие организации, сейчас свалка), регистраторы по версии Verisign, регистраторы по версии Internic
• coop (кооперативы), регистраторы
• edu (образовательные организации, в основном из США), EDUCAUSE
• gov (правительственные организации США), http://www.nic.gov
• info (свалка по замыслу), регистраторы
• int (международные организации), IANA
• mil (военные организации США), http://www.nic.mil
• museum (музеи), регистраторы
• name (персональные домены), регистраторы
• net (когда-то здесь были организации, обеспечивающие сетевую инфраструктуру, сейчас такая же свалка, как и в com), регистраторы
• org (когда-то здесь были некоммерческие организации, сейчас такая же свалка, как и в com), регистраторы
• pro (лицензированные профессионалы), регистраторы

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

• список Norid
• список IANA
• Who is hosting this?

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

ICANN вводит RDAP вместо WHOIS (nicinfo).

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

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 и его производных (например, 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:

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

• заголовок
• идентификатор запрос (копируется в ответ), 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 бит)
• 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) для получения информации любого класса
• RR ответа (число записей указано в заголовке)
• доменное имя (формат такой же, как в запросе)
• тип записи
• класс записи
• TTL (32 бита, в секундах)
• число байт данных записи (16 бит)
• данные записи, формат определяется типом записи
• RR, ссылающиеся на уполномоченный сервер (число записей указано в заголовке), формат такой же, как в разделе ответа
• 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 секунд или ⅓ от времени обновления зоны.

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/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

Сервера DNS

• Установка, настройка и обслуживание сервера BIND 9

Утилиты

Вместе с сервером BIND поставляются утилиты dig, host и nslookup для исследования доменного пространства.

Утилита host позволяет получать значения RR указанного типа для указанного доменного имени. Формат вызова:

host [-управляющие-ключи] [-ключи-запроса] доменное-имя-или-адрес [опрашиваемый-сервер].

По умолчанию, используется сервер, описанный при настройке клиентской библиотеки. Доменные имена считаются абсолютными и список поиска не используется. Управляющие ключи модифицируют поведение утилиты:

• -r (делать нерекурсивные запросы)
• -R *число-попыток*
• -W *число-секунд-ожидания*
• -w (ждать до победного конца)
• -T (использовать TCP вместо UDP)

Ключи запроса указывают тип требуемой информации

• -c класс (позволяет указать класс записи; по умолчанию - IN)

• -t тип-записи (позволяет указать требуемый тип записи; по умолчанию используется тип A для доменного имени и тип PTR для адреса; можно использовать также псевдотипы AXFR и ANY)

• -v

(подробная интерпретация пакета, полученного в ответ на запрос: флаги, секции; к сожалению, имена флагов сокращены до 2 букв

• qr - пакет является ответом
• aa - ответ получен от уполномоченного сервера
• rd - запрос был рекурсивным

• ra - обслуживание рекурсивных запросов разрешено на сервере

• -l (запрашивает AXFR зоны, синоним для -t AXFR)

• -C (получает список уполномоченных серверов зоны, после чего по очереди запрашивает запись SOA у каждого из них; требуется доступ к этим серверам!)
• -a (сокращение для -v -t ANY)

Утилита dig позволяет получать значения RR указанного типа для указанного доменного имени в формате файла зоны. В виде комментариев выдается масса вспомогательной информации, в т.ч. интерпретация пакета, полученного в ответ на запрос (см. описание утилиты host). Формат вызова:

dig [@опрашиваемый-сервер] [-опции-dig] доменное-имя [тип-записи] [класс-записи] [+опции-запроса]

По умолчанию, используется сервер, описанный при настройке клиентской библиотеки. Доменные имена считаются абсолютными и список поиска не используется. В качестве требуемого типа записи можно использовать также псевдотипы AXFR (зона передается только от уполномоченного сервера), ixfr=опорный-номер-версии и ANY, по умолчанию: A. В одной командной строке можно сделать несколько запросов.

Опции dig:

• -b исходящий-IP-адрес-запроса
• -c класс-записи
• -f имя-файла (список запросов читается из файла, один запрос на строку)
• -k имя-файла (файл ключей для подписи запроса и ответа TSIG)
• -p порт-сервера
• -t тип-записи (по умолчанию: A, если не указан ключ -x)
• -x addr (запрос имени по IP адресу)
• -y имя-ключа:ключ (явное задание ключа для подписи запроса и ответа TSIG)

Опции запроса:

• +[no]tcp (по умолчанию TCP используется для AXFR и IXFR, UDP - для остальных запросов)
• +[no]vc (синоним +[no]tcp)
• +[no]ignore (по умолчанию TCP используется, если ответ не поместился в UDP пакет)
• +domain=локальный-домен (установить локальный домен для расширения относительных имен)
• +[no]search (по умолчанию - nosearch, использовать список поиска для расширения относительных имен)
• +[no]cdflag (устанавливать ли флаг CD, отменяющий проверку DNSSEC сервером)
• +[no]recurse (по умолчанию - recurse, рекурсивный запрос, автоматически отключается при использовании опций +nssearch и +trace)
• +[no]nssearch (по умолчанию - nonssearch; записи SOA зоны, в которую входит доменное имя, запрашиваются у всех уполномоченных серверов)
• +[no]trace (по умолчанию - notrace; проследить цепочку делегирования)
• +[no]cmd (по умолчанию - cmd; выводить начальный блок комментариев, содержащий информацию о версии dig и опции запроса)
• +[no]short (по умолчанию - noshort; короткий формат вывода)
• +[no]identify (по умолчанию - noidentify; выдавать информацию о сервере при использовании короткого формата вывода)
• +[no]comments (по умолчанию - comments; выдавать ли флажки ответа и заголовки секций в виде комментариев)
• +[no]stats (по умолчанию - stats; выдавать ли статистику обработки запроса в виде комментариев)
• +[no]qr (по умолчанию - noqr; выдавать ли сам запрос в виде комментариев)
• +[no]question (по умолчанию - question; выдавать ли секцию вопроса в ответе в виде комментариев)
• +[no]answer (по умолчанию - answer; выдавать ли секцию ответа в ответе в виде комментариев)
• +[no]authority (по умолчанию - authority; выдавать ли секцию полномочий в ответе в виде комментариев)
• +[no]additional (по умолчанию - question; выдавать ли секцию дополнительной информации в ответе в виде комментариев)
• +[no]all (установить или сбросить все флажки вывода)
• +time=секунд (по умолчанию - 5; время ожидания)
• +tries=число-попыток (по умолчанию - 3)
• +ndots=число-точек (по умолчанию - 1 или из /etc/resolv.conf; минимальное число точек в имени для признания его абсолютным)
• +bufsize=байт (размер буфера UDP)
• +[no]multiline (по умолчанию - nomultiline; выводить записи типа SOA в несколько строк в человеколюбивом формате)
• +[no]fail (по умолчанию - nofail; пробовать следующий сервер при получении ошибки SERVFAIL)
• +[no]besteffort (по умолчанию - nobesteffort; попытаться показать хоть какую-нибудь информацию из неверно сформированного ответа)
• +[no]dnssec (установить бит DNSSEC OK в запросе)

Значение опций можно установить в файле настройки ~/.digrc.

Полезный пример использования dig для отладки зоны, dig имитирует поведения сервера, выдавая нерекурсивные запросы с трассировкой:

dig +trace company.ru mx

Утилита nslookup объявлена устаревшей и навязчиво напоминает об этом при каждом запуске (даже документация не поставляется, отсутствует команда help и некоторые другие). Формат вызова:

nslookup [-ключи] доменное-имя [опрашиваемый-сервер]

Если доменное имя и имя сервера опущены или используется символ минус вместо доменного имени, то утилита переходит в интерактивный режим работы. Выход из интерактивного режима происходит по команде exit или по нажатию ^D (конец ввода). По нажатию ^С (прерывание программы) утилита прерывает выполнение текущей операции и возвращается в интерактивный режим. Предусмотрены следующие команды (имена параметров можно сокращать):

• *доменное-имя* (произвести поиск записи установленного класса и типа)

• set all (показать текущие значения всех параметров)

• set [no] параметр

(установить значение переключателя)

• debug (по умолчанию: nodebug, подробно расшифровывать полученные ответы: флаги, секции)
• d2 (по умолчанию: nod2, подробно расшифровывать посылаемые вопросы)
• defname (имя локального домена добавляется к относительным именам)
• ignoretc (игнорировать сообщения с установленным битом “усечения” и повторять запрос с использованием TCP вместо UDP)
• recurse (использовать рекурсивные запросы)
• search (использовать список поиска для относительных имен)

• vc (по умолчанию: novc, использовать TCP вместо UDP)

• set параметр=значение

(установить значение параметра)

• port=номер-порта (по умолчанию: 53)
• type=тип-записи (по умолчанию: A для имени и PTR для адреса; можно использовать также псевдотипы AXFR и ANY)
• class=имя-класса (по умолчанию: IN)
• timeout=секунд
• retry=число-попыток (по умолчанию: 2)
• root=корневой-сервер
• domain=имя-локального-домена (по умолчанию берется из /etc/resolver.conf)
• srchlist=список-поиска (по умолчанию берется из /etc/resolver.conf)
• server опрашиваемый-сервер (использовать указанный сервер при последующих запросах, адрес сервера определить с помощью текушего сервера)
• lserver опрашиваемый-сервер (использовать указанный сервер при последующих запросах, адрес сервера определить с помощью сервера по умолчанию)
• ls [-d] имя-зоны (передать зону целиком; -d есть синоним для -t ANY)

Значение параметра или переключателя можно установить ключом командной строки (символ минус перед именем параметра) или в файле настройки ~/.nslookuprc (может содержать команды set по одной в строке).

Ссылки

• Альбитц П., Ли К.. DNS и BIND (четвертое издание). - Пер. с англ. - СПб: Символ-Плюс, 2002
• DNS Resources Directory (сайт замерз в 2000)
• DNSSEC (проект цифровых подписей для ответов DNS)
• DNSSEC в RIPE
• DJBDNS (“альтернативный” DNS сервер)
• RFC, относящиеся к DNS
• RFC 3467. Role of the Domain Name System (DNS). J. Klensin. February 2003.
• RFC 3445. Limiting the Scope of the KEY Resource Record (RR). D. Massey, S. Rose. December 2002.
• RFC 3425. Obsoleting IQUERY. D. Lawrence. November 2002.
• RFC 3364. Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6). R. Austein. August 2002.
• RFC 3363. Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS). R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain. August 2002.
• RFC 3226. DNSSEC and IPv6 A6 aware server/resolver message size requirements. O. Gudmundsson. December 2001.
• RFC 3152. Delegation of IP6.ARPA. R. Bush. August 2001.
• RFC 3090. DNS Security Extension Clarification on Zone Status. E. Lewis. March 2001.
• RFC 3008. Domain Name System Security (DNSSEC) Signing Authority. B. Wellington. November 2000.
• RFC 3007. Secure Domain Name System (DNS) Dynamic Update. B. Wellington. November 2000.
• RFC 2931. DNS Request and Transaction Signatures ( SIG(0)s). D. Eastlake 3^rd. September 2000.
• RFC 2874. DNS Extensions to Support IPv6 Address Aggregation and Renumbering. M. Crawford, C. Huitema. July 2000.
• RFC 2845. Secret Key Transaction Authentication for DNS (TSIG). P. Vixie, O. Gudmundsson, D. Eastlake 3^rd, B. Wellington. May 2000.
• RFC 2826. IAB Technical Comment on the Unique DNS Root. Internet Architecture Board. May 2000.
• RFC 2821. Simple Mail Transfer Protocol. J. Klensin, Ed.. April 2001.
• RFC 2673. Binary Labels in the Domain Name System. M. Crawford. August 1999.
• RFC 2672. Non-Terminal DNS Name Redirection. M. Crawford. August 1999.
• RFC 2535. Domain Name System Security Extensions. D. Eastlake 3^rd. March 1999. (отменен?)
• RFC 2308. Negative Caching of DNS Queries (DNS NCACHE). M. Andrews. March 1998.
• RFC 2181. Clarifications to the DNS Specification. R. Elz, R. Bush. July 1997.
• RFC 2163. Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM). C. Allocchio. January 1998.
• RFC 2136. Dynamic Updates in the Domain Name System (DNS UPDATE). P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997.
• RFC 1996. A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY). P. Vixie. August 1996.
• RFC 1995. Incremental Zone Transfer in DNS. M. Ohta. August 1996.
• RFC 1982. Serial Number Arithmetic. R. Elz, R. Bush. August 1996.
• RFC 1918. Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996.
• RFC 1912. Common DNS Operational and Configuration Errors. D. Barr. February 1996.
• RFC 1886. DNS Extensions to support IP version 6. S. Thomson, C. Huitema. December 1995.
• RFC 1876. A Means for Expressing Location Information in the Domain Name System. C. Davis, P. Vixie, T. Goodwin, I. Dickinson. January 1996.
• RFC 1794. DNS Support for Load Balancing. T. Brisco. April 1995.
• RFC 1788. ICMP Domain Name Messages. W. Simpson. April 1995.
• RFC 1713. Tools for DNS debugging. A. Romao. November 1994.
• RFC 1712. DNS Encoding of Geographical Location. C. Farrell, M. Schulze, S. Pleitner, D. Baldoni. November 1994.
• RFC 1706. DNS NSAP Resource Records. B. Manning, R. Colella. October 1994.
• RFC 1612. DNS Resolver MIB Extensions. R. Austein, J. Saperia. May 1994.
• RFC 1611. DNS Server MIB Extensions. R. Austein, J. Saperia. May 1994.
• RFC 1591. Domain Name System Structure and Delegation. J. Postel. March 1994.
• RFC 1536. Common DNS Implementation Errors and Suggested Fixes. A. Kumar, J. Postel, C. Neuman, P. Danzig, S. Miller. October 1993.
• RFC 1535. A Security Problem and Proposed Correction With Widely Deployed DNS Software. E. Gavron. October 1993.
• RFC 1464. Using the Domain Name System To Store Arbitrary String Attributes. R. Rosenbaum. May 1993.
• RFC 1401. Correspondence between the IAB and DISA on the use of DNS. Internet Architecture Board. January 1993.
• RFC 1383. An Experiment in DNS Based IP Routing. C. Huitema. December 1992.
• RFC 1279. X.500 and Domains. S.E. Hardcastle-Kille. November 1991.
• RFC 1183. New DNS RR Definitions. C.F. Everhart, L.A. Mamakos, R. Ullmann, P.V. Mockapetris. Oct-01-1990.
• RFC 1136. Administrative Domains and Routing Domains: A model for routing in the Internet. S. Hares, D. Katz. Dec-01-1989.
• RFC 1101. DNS encoding of network names and other types. P.V. Mockapetris. Apr-01-1989.
• RFC 1035. Domain names - implementation and specification. P.V. Mockapetris. Nov-01-1987.
• RFC 1034. Domain names - concepts and facilities. P.V. Mockapetris. Nov-01-1987.
• RFC 1033. Domain administrators operations guide. M. Lottor. Nov-01-1987.
• RFC 1032. Domain administrators guide. M.K. Stahl. Nov-01-1987. (устаревшая инструкция по регистрации доменов времен существования SRI-NIC.ARPA)
• http://www.internic.net/whois.html
• whois.networksolutions.com

Copyright © 1996-2018 Sergey E. Bogomolov