Система Доменных Имен (Domain Name System)

Г.В. Ключников, grn@ispras.ru

Содержание

1. Введение
2. Компоненты DNS
2.1. Пространство доменных имен
2.1.1. Доменные имена
2.1.2. Домены
2.1.3. Записи о ресурсах
2.1.4. Домены верхнего уровня
2.2. Серверы имен (name servers)
2.2.1. Делегирование полномочий
2.2.2. Сервер имен
2.2.3. Типы серверов имен
2.2.4. Файлы данных
2.3. Решающие программы (resolvers)
3. Разрешение доменных имен (name resolution)
3.1. Корневые серверы имен
3.2. Рекурсивное и итеративное разрешения имен
4. Преобразование адресов в доменные имена
5. Обратные запросы (inverse queries)
6. Кэширование
7. Спецификация DNS
7.1. Формат сообщения DNS
7.2. Формат секции заголовка
7.3. Формат секции запроса
7.4. Формат записи о ресурсе
7.5. Сжатие сообщений
7.6. Передача сообщений
8. Внутренности сервера имен
8.1. Общие понятия
8.2. Запросы и ответы
8.3. Алгоритм
8.4. Универсальные символы
8.5. Кэширование отрицательных ответов
8.6. Обслуживание и перекачка зоны
9. Настройка сервера имен
9.1. Выбор типа
9.2. Настройка демона сервера имен
9.3. Файлы данных записей о ресурсе
9.4. Пример
10. Настройка решающей программы
11. Утилиты для отладки и контроля работы DNS
11.1. Nslookup
11.2. Host
11.3. Dig
Литература

1. Введение

    Internet представляет собой конгломерат сотен тысяч взаимосвязанных гетерогенных сетей и компьютеров (хост-машин). Построение Internet базируется на концепции иерархии протоколов. Протоколы Internet именуются семейством протоколов TCP/IP. В TCP/IP компьютеры взаимодействуют друг с другом на базе различных типов адресов. На физическом уровне используются низкоуровневые физические адреса, соответствующие используемым аппаратным устройствам. С уровня звена данных  по уровень представления данных применяется первая абстракция, использующая адреса хост-машин, такие как IP-адреса. И на прикладном уровне применяется абстракция второго уровня, использующая удобные для восприятия пользователей имена хост-машин (hostnames). В семействе протоколов TCP/IP преобразование физических адресов в адреса транспортного уровня (IP-адреса) выполняется протоколом ARP. Для преобразования (или связывания (binding)) IP-адресов в имена хост-машин используется Служба Доменных Имен (Domain Name System или DNS).
    В ранние годы существования Internet (ARPANET) рост этой сети был умеренным, и отображение имен хост-машин на IP-адреса поддерживалось Сетевым Информационным Центром (NIC - Network Information Center) с помощью единственного файла (hosts.txt). Каждый администратор хост-машины или организации периодически копировал этот файл с использованием электронной передачи файлов или, в экстремальных ситуациях, путем передачи магнитной или даже бумажной ленты, и загружал в каждую подсоединенную к сети хост-машину. Всякий раз, когда требовалось найти сетевой адрес какой-либо хост-машины по ее имени, разрешение имен выполнялось с использованием этого  файла.
    Эта система работала достаточно хорошо до тех пор, пока ARPANET была сравнительно небольшой сетью. Но по мере роста и изменения состава сети, из-за постоянного роста частоты выборки файла hosts.txt из NIC, необходимости отделения вопросов управления локальными именами и адресами в разных организациях, а также необходимости все более частого внесения изменений в файл hosts.txt, стало ясно, что централизованная схема оказывается неработоспособной и должно быть найдено альтернативное решение.
Первая реализация Системы Доменных Имен (DNS) называлась JEEVES, автором которой является Paul Mockapetris. Более поздней реализацией была BIND (Berkeley Internet Name Domain), которая была написана для 4.3BSD UNIX, ее автор - Kevin Dunlap. На сегодняшний день BIND является наиболее популярной реализацией DNS. Она перенесена на большинство ОС UNIX и поставляется, как стандартная часть операционной системы, большинством производителей ОС UNIX.
    Первоначальные результаты разработки DNS были опубликованы в 1983 году в RFC 882 и 883. После экспериментов с несколькими реализациями, DNS была формально определена в RFC 1034 и 1035 в 1987 году.
DNS базируется на двух основных концепциях:
    (1) распределенной базы данных, хранящей обобщенные записи о ресурсах сети (resource records), с децентрализованным управлением;
    (2) схемы именования, основанной на иерархически структурированных доменных именах.
DNS является распределенной базой данных. Это позволяет локально контролировать отдельные сегменты общей базы данных. Данные в каждом сегменте доступны по сети с использованием технологии клиент-сервер. Адекватная производительность достигается с помощью использования механизмов копирования (replication) и кэширования (caching).
    Программы, реализующие серверную часть DNS, называются серверами имен (name servers). Сервер имен содержит информацию о некотором сегменте общей базы данных DNS, для которого он будет являться полномочным сервером, и делает ее доступной для клиентов, называемых решающими программами (resolvers). Решающие программы обычно представляют собой библиотечные функции, которые генерируют запросы и посылают их по сети серверам имен.

    Структура базы данных DNS, показанная на рисунке 8.1, представляется, как инвертированное дерево, с корнем (root) на верху дерева.

    Корневое имя (root's name) имеет нулевую метку ("") и обозначается одиночной точкой ("."). Каждый узел (node) дерева представляет раздел общей базы данных или домен (domain). Каждый домен в дальнейшем может делиться на подразделы, называемые в DNS поддоменами. Поддомены представляются как потомки своих родительских узлов (parent nodes). Каждый домен имеет метку (label), которая идентифицирует его местоположение относительно его родительского домена. Кроме того домен имеет доменное имя (domain name), которое идентифицирует его местоположение в базе данных DNS. Полное доменное имя представляет собой последовательность меток от корневого домена, которые разделяются между собой символом ".".
    В DNS каждый домен может администрироваться различными организациями. При этом каждая такая организация может затем делить свой домен и предоставлять полномочие на администрирование этих поддоменов другим организациям. Например, Сетевой Информационный Центр (NIC) отвечает за домен "edu" (educational), но предоставляет полномочия для поддомена "berkeley.edu" университету Беркли в Калифорнии. Домены могут содержать как хост-машины, так и другие домены (свои поддомены). Доменные имена используются, как индексы в базе данных DNS.
    Каждая хост-машина в сети имеет доменное имя, которое является указателем на информацию об этой хост-машине. Эта информация может содержать IP-адрес, маршрутную информацию почтовой системы и т.д.. Хост-машина может иметь одно или несколько доменных имен-псевдонимов (domain name aliases), которые является простыми указателями одного доменного имени (имени-псевдонима) на другое (каноническое доменное имя (canonical domain name)).

2. Компоненты DNS

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

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

2.1.1. Доменные имена

    Каждый узел (node) в пространстве имен имеет собственную метку (без точек). В качестве разделителей меток используется символ точки ("."). Максимальная длина метки может составлять 63 байта. Максимальная длина доменного имени (сумма всех меток и разделителей) равна 255 байтам. Корневой домен имеет метку нулевой длины (null). Полное доменное имя каждого узла в дереве - это последовательность меток в пути от этого узла до корня. По соглашению, метки, составляющие доменное имя читаются слева направо, начиная с нижней, наиболее удаленной от корня, и заканчивая самой верхней, наиболее близкой к корню.

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

    Так как абсолютное доменное имя связывается с корнем, оно однозначно специфицирует местоположение узла в иерархии. Имена без точки на конце иногда интерпретируются, как связанные с некоторым доменом, отличным от корневого. Абсолютное доменное имя также называют полно-квалифицированным доменным именем (fully-qualifed domain name или FQDN).

2.1.2. Домены

    Доменом является некоторое поддерево пространства доменных имен. Доменное имя домена представляет собой имя самого верхнего узла домена. Например, верхним узелом домена "gnu.ru" является узел, имеющий доменное имя "gnu.ru", как показано на рисунке 8.4.

    Каждое доменное имя может находиться в нескольких поддеревьях, и соответственно в нескольких доменах. Например, доменное имя "main.gnu.ru" является частью домена "gnu.ru", а также и частью домена "ru".
    Хост-машины также являются узлами DNS-дерева, и ,кроме того, также являются доменами. Доменные имена хост-машин указывают на информацию об определенной хост-машине. Домен содержит все хост-машины, доменные имена которых находятся внутри этого домена. Хост-машины в домене связаны логически, часто по географическому или организационному признаку, а не по принадлежности к определенной сети или классу IP-адресов. В одном домене могут находиться хост-машины из разных сетей и даже из разных стран.
Доменные имена внутри домена могут быть именами хост-машин или ссылаться на структурную информацию о поддоменах. Причем, одно и тоже доменное имя может выступать как в качестве имени хост-машины, так и в качестве имени домена. Например, имя "hp.com" является именем домена компании Hewlett-Packard и именем хост-машины, которая осуществляет маршрутизацию почты между HP и Internet. Тип информации, которую необходимо найти (о хост-машине или поддомене), зависит от контекста использования доменного имени.

2.1.3. Записи о ресурсах

    Данные, ассоциированные с доменными именами, содержатся в записях о ресурсах (resouce records или RR). Записи делятся на классы. Одним из классов является internet (TCP/IP сети). Кроме того, записи делятся на типы. Тип записи определяют тип информации, которая может храниться в пространстве доменных имен. Каждый тип записи имеет определенный формат. В internet-классе присутствуют адресные записи, записи серверов имен, записи указателей и другие. Подробнее типы записей рассматриваются в следующих разделах.

2.1.4. Домены верхнего уровня

    Пространство имен DNS имеет иерархическую структуру и содержит множество вложенных доменов, каждый из которых представляет административно связанный набор хост-машин Internet. Непосредственно ниже корня этой иерархии находится набор доменов верхнего уровня, которые первоначально представляли организационную иерархию:     По мере экспансии современной Internet за пределы США, были добавлены дополнительные домены верхнего уровня, соответствующие отдельным странам (иерархия по географическому признаку), например, au, ca, us, uk, se, ru. Эти доменные имена кодов стран обычно выбираются из двухбуквенных кодов, зарегистрированных в стандарте ISO 3166:1988, Codes for the Representation of Names of Countries.
Ниже доменов верхнего уровня, имена конструируются иерархически путем определения поддоменов, под-поддоменов и т.д., в принципе до любой требуемой глубины, пока конечное имя (на листе дерева, см. рисунок 8.1) не завершит процесс идентификации каждой отдельной хост-машины Internet.
    Многие международные организации были зарегистрированы как по географической, так и по организационной схеме. Например, utzoo.toronto.edu, который также известен как utzoo.utoronto.ca (рисунок 8.5).

2.2. Серверы имен (name servers)

2.2.1. Делегирование полномочий

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

2.2.2. Сервер имен

    Программы, которые хранят информацию о пространстве доменных имен, называют серверами имен (name servers). Сервер имен обычно имеют полную информацию о некоторой части пространства доменных имен, называемой зоной. О таком сервере говорят, что он является авторизованным или полномочным сервером для данной зоны. Сервер имен может быть авторизованным для нескольких зон.
Зона содержит доменные имена и данные, которые содержит домен, исключая доменные имена и данные, делегированных поддоменов. Например, домен верхнего уровня "ru" может содержать поддомены "ab.ru", "bc.ru" и "cd.ru", полномочия на которые могут делегироваться каким-либо организациям. В этом случае домен "ru" содержит все данные в "ru" и все данные в "ab.ru", "bc.ru" и "cd.ru". Но зона "ru" содержит данные только "ru" (рисунок 8.6).

    Однако если поддомен какого-либо домена не делегируется, то зона будет содержать доменные имена и данные этого поддомена. Например, могут существовать поддомены "de.ru" и "ef.ru" домена "ru", но не делегироваться. В этом случае зона "ru" будет содержать данные поддоменов "de.ru" и "ef.ru", но не будет включать данные других поддоменов (рисунок 8.7).

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

2.2.3. Типы серверов имен

    В DNS определено два типа серверов имен: первичные (primary masters) и вторичные (secondary masters). Первичный сервер имен получает данные о зоне, для которой он является полномочными, из файлов на хост-машине, где он выполняется. Вторичный сервер имен получает данные о зоне от другого полномочного сервера имен. Когда стартует вторичный сервер, он связывается с полномочным (первичным) сервером зоны и скачивает данные о зоне. Такую процедуру называют передачей зоны (zone transfer). В процессе работы вторичный сервер периодически опрашивает первичный сервер. Если данные на первичном сервере были изменены, то вторичный сервер обновляет свои данные, заново перекачивая все данные зоны с первичного сервера.
    Обычно для зоны создается один первичный сервер имен и один или несколько вторичных серверов. Сервер имен может быть первичным для некоторой зоны и вторичным для другой зоны.
 

2.2.4. Файлы данных

    Файлы, из которых первичные серверы загружают данные о своей зоне, называются файлами данных (db files или database files). Вторичные серверы имен по определенным правилам также загружают данные о зоне из файлов данных. Вторичные серверы можно сконфигурировать так, чтобы они сохраняли полученные от первичного сервера данные о зоне в backup-файлах. Если в последствии вторичный сервер переинициализируется, он сначала читает данные из backup-файлов, а затем проверяет их соответствие с данными первичного сервера. В этом случае, если данные на первичном сервере не изменились в сравнении с данными backup-файлов, то вторичный сервер перекачивать зону не будет.
    Файлы данных содержат записи о ресурсах, описывающих зону. Записи о ресурсах описывают все хост-машины в зоне, а так же делегирование поддоменов.

2.3. Решающие программы (resolvers)

    Решающая программа (resolver) - это клиентская часть DNS, посредством которой прикладные программы получают информацию о доменных именах от серверов имен. Решающая программа выполняет следующие функции:
     - запрашивает сервер имен;
     - интерпретирует ответ (который может быть записью о ресурсах или ошибкой);
     - возвращает информацию запрашивающей программе.
    Решающая программа обычно представляет собой набор библиотечных подпрограмм, которые вызываются прикладной программой, когда ей нужно выполнить преобразование имени в адрес и обратно. Например, в BSD UNIX такими подпрограммами являются gethostbyname и gethostbyaddr. Решающая программа поддерживает кэш записей о ресурсах, полученных в ответ на недавно выполненные запросы.

3. Разрешение доменных имен (name resolution)

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

3.1. Корневые серверы имен

    Корневые серверы имен имеют информацию о полномочных серверах всех доменов верхнего уровня. В ответ на запрос о каком-либо доменном имени корневой сервер имен может выдать имена и адреса полномочных серверов имен домена верхнего уровня, в который входит запрашиваемое имя. Серверы имен верхнего уровня могут выдать имена и адреса полномочных серверов имен домена второго уровня, в который входит данное доменное имя. Каждый запрашиваемый сервер имен выдает запрашивающей стороне информацию о том, как подобраться ближе к ответу, который он ищет, или сам ответ.
    Так как разрешение всех доменных имен в Internet начинается с корневых серверов, они являются наиболее критичным ресурсом в DNS. Если все корневые сервера будут недоступны определенный период времени, разрешение имен в Internet станет невозможным. Для предотвращения этой ситуации в Internet существует несколько корневых серверов, расположенных в различных сетях различных частей света.
На рисунке 8.8 представлен процесс разрешения имени хост-машины girigiri.gbrmpa.gov.au.

    Локальный сервер имен посылает запрос корневому серверу имен об адресе хост-машины girigiri.gbrmpa.gov.au. Корневой сервер возвращает адрес сервера имен домена "au". Затем локальный сервер обращается к серверу "au" с тем же вопросом, и получает указатель на сервер имен "gov.au".  Сервер имен "gov.au" указывает локальному серверу на сервер "gbrmpa.gov.au". В заключении локальный сервер запрашивает сервер "gbrmpa.gov.au" и получает от него требуемый адрес.

3.2. Рекурсивное и итеративное разрешения имен

    Запросы, направляемые серверам имен, могут быть рекурсивными или итеративными. В зависимости от типа полученного запроса сервер выполняет рекурсивное или итеративное разрешение имен.
    Получив рекурсивный запрос, сервер имен должен вернуть запрашивающей стороне требуемые данные или сообщение об ошибке, указывающее на то, что данные запрошенного типа или запрошенное доменное имя не существуют. При рекурсивном запросе сервер имен не может просто вернуть ссылку на другой сервер имен, он обязан произвести поиск запрошенных данных в пространстве имен. Если сервер имен не является полномочным сервером для запрошенного имени, он будет запрашивать другие сервера до тех пор, пока не найдет ответ. Он может посылать им рекурсивные запросы, тем самым, обязывая их найти ответ и вернуть его. Или он может посылать итеративные запросы и сам выполнять дальнейший поиск.
    По итеративному запросу сервер имен возвращает данные из локальной базы данных (либо из своего кэша), не выполняя при этом никаких дополнительных запросов. Если он не находит запрашиваемые данные, то возвращает информацию, которая поможет запрашивающей стороне продолжить поиск. Обычно это - имена и адреса серверов имен наиболее "близких" к данным, которые требуется найти.
    В примере на рисунке 8.8 только локальный сервер имен выполняет рекурсивное разрешение, остальные сервера выполняют итеративное разрешение.

4. Преобразование адресов в доменные имена

    Данные, содержащие адресную информацию, в пространстве доменных имен индексируются по имени. Поэтому нахождение адреса по данному имени является относительно простой задачей. Но нахождение доменного имени, которому соответствует определенный адрес, в такой модели не является тривиальной задачей, так как требует перебора адресных значений каждого доменного имени в дереве. Для предоставления такого поиска было выбрано довольно простое и эффективное решение. Так как найти данные, индексированные по имени, в дереве имен просто, в пространстве доменных имен Internet был создан специальный домен in-addr.arpa.
    Узлы в домене in-addr.arpa именуются по номерам в представлении IP-адресов четырьмя десятичными цифрами, разделенными точками (каждая десятичная цифра находится в диапазоне от 0 до 255). В этом случае домен in-addr.arpa может иметь до 256 поддоменов, каждый из которых соответствует каждому возможному значению первой цифры IP-адреса. Каждый из этих поддоменов может иметь до 256 поддоменов нижнего уровня, соответствующие возможным значениям второй цифры IP-адреса. На последнем четвертом уровне будут находиться записи о ресурсах, связанные с последней цифрой IP-адреса, которые будут содержать полные доменные имена хост-машин или сетей, соответствующих этим IP-адресам. Структура домена in-addr.arpa представлена на рисунке 8.9.

    Заметим, что когда читается доменное имя из домена in-addr.arpa, IP-адрес представляется в обратном порядке. Например, если хост winnie.corp.hp.com имеет IP-адрес 15.16.192.152, то соответствующий ему поддомен in-addr.arpa будет 152.192.16.15.in-addr.arpa, который устанавливает обратное соответствие на доменное имя winnie.corp.hp.com.
 

5. Обратные запросы (inverse queries)

    Серверы имен могут поддерживать обратные запросы (inverse queries), которые связывают определенный ресурс с доменным именем, которое имеет этот ресурс. Например, стандартный запрос может связывать доменное имя с записью о ресурсе SOA, а соответствующий ему обратный запрос будет связывать SOA-запись обратно с доменным именем.
    Такой поиск доменных имен по данным, которые они индексируют, будет требовать другого специального пространства имен такого, как домен in-addr.arpa, или полного поиска по всем возможным значениям.
    В некоторых случаях такой поиск возможен. Обратный запрос - это поиск доменного имени, которое индексирует указанные в запросе данные. Сервер имен, получивший такой запрос, производит поиск только в своих локальных данных по указанному в запросе значению. Если сервер не может найти данные, то он возвращает отрицательный ответ и не производит попыток контакта с другими серверами имен для нахождения положительного ответа.
    Так как определенный сервер имен имеет информацию только о некоторой части пространства имен, обратный запрос никогда не гарантирует, что будет возвращен положительный ответ. Если сервер получает обратный запрос для IP-адреса, о котором он ничего не знает, он не может вернуть ответ и даже не знает, существует ли вообще такой IP-адрес, так как он хранит только часть DNS базы данных.
    Необходимо отметить, что реализация обратных запросов является необязательной в спецификации DNS. Поэтому не все сервера имен могут выполнять такие запросы.

6. Кэширование

    Для повышения эффективности выполнения разрешения имен применяется механизм кэширования. При выполнении рекурсивных запросов сервер имен опрашивает некоторое количество других серверов и получает при этом информацию о полномочных серверах для различных зон, а также конечный результат разрешения имен. Эту информацию сервер сохраняет в своем кэше. Если сервер в дальнейшем получает запрос на имя, информация о котором имеется в его кэше, он возвращает эту информацию запросившей стороне. Либо если в кэше находится информация о полномочных серверах для запрошенного имени, сервер может использовать ее для разрешения этого имени, непосредственно обращаясь к этим серверам, минуя лишние запросы. Данные в ответе сервера имен, которые взяты из кэша, помечаются как неавторизованные (non-authoritative binding) и к ним прилагаются имена и адреса серверов имен, который являются полномочными для этих данных.
    Время, которое данные могут храниться в кэше, называется временем жизни данных (time to live) и определяются администратором этой зоны. По истечении времени жизни данные должны быть удалены из кэша. Для их получения необходимо вновь обратиться к полномочному серверу имен этого доменного имени.

7. Спецификация DNS

7.1. Формат сообщения DNS

    Все взаимодействия, определенные протоколом DNS, осуществляются с использованием сообщений определенного формата. Формат сообщение DNS верхнего уровня разделенный на пять секций (некоторые из которых при определенных обстоятельствах остаются незаполненными), представлен на рисунке 8.10.

    Секция заголовка (header) присутствует всегда и включает поля, которые описывают другие секции, присутствующие в сообщении. Секция запроса (question) содержит поля, описывающие запрос: тип запроса (QTYPE), класс (QCLASS) и доменное имя запроса (QNAME). Остальные три секции имеют одинаковый формат: связанный список записей о ресурсах (RRs), который может быть пустым. Секция ответов (answer) содержит записи о ресурсах, которые отвечают на запрос. Секция полномочий (authority) содержит записи о ресурсах, которые указывают на полномочные серверы; дополнительно может содержать запись о ресурсе "начала полномочий" (start of authority или SOA) для авторизованных данных в секции ответов. Дополнительная секция (additional) содержит записи о ресурсах, которые связаны с запросом, но не точно отвечают на запрос.

7.2. Формат секции заголовка

На рисунке 8.11 показан формат секции заголовка сообщения DNS

Поля заголовка имеют следующие значения:
    ID идентификатор сообщения  (16 бит), который генерируется программой, выполняющей запрос; этот идентификатор копируется в соответствующий ответ и используется запрашивающей программой для проверки.
    QR  однобитовое поле, определяющее является ли сообщение запросом (0) или ответов (1).
    Opcode код операции (4 бита); значение устанавливается запрашивающей программой и копируется в ответное сообщение; значения могут быть следующие:
          0 стандартный запрос (QUERY),
          1 инверсный запрос (IQUERY),
          2 запрос состояния сервера (STATUS),
          3-15 зарезервированы.
    AA полномочный ответ (1 бит); этот бит имеет значение только для ответа и, если установлен в 1, то он указывает, что отвечающий сервер имен является полномочным по отношению к имени домена, представленному в запросе.
    TC усечение (1 бит); если этот бит установлен в 1, то указывает, что сообщение было усечено по причине того, что его длина больше разрешенного значения канала передачи.
    RD требуется рекурсия (1 бит); если этот бит установлен, то требует от сервера имен выполнения запроса рекурсивно; копируется в ответ.
    RA рекурсия доступна (1 бит); устанавливается или сбрасывается в ответе и указывает, поддерживает ли сервер имен рекурсивные запросы.
    Z  зарезервировано (3 бита); должно быть нулевым в запросе и ответе.
    RCODE код ответа (4 бита); устанавливается в ответных сообщениях и имеет следующие значения:
        0 ошибок нет (no error condition);
        1 ошибка формата (format error) - сервер не в состоянии интерпретировать запрос;
        2 ошибка сервера (server failure) - сервер не способен обработать запрос из-за проблем с сервером имен;
        3 ошибка в имени (name error) - значимо только в ответе полномочного сервера имен и означает, что доменное имя, указанное в запросе, не существует;
        4 не реализован (not implemented); сервер не поддерживает требуемый вид запроса;
        5 отказ (refused); сервер имен отказывается выполнять указанную операцию, так как выполнение этой операции для данной запрашивающей стороны запрещено политикой сервера;
          6-15 зарезервировано.
    QDCOUNT определяет количество элементов в секции вопросов (2 байта);
    ANCOUNT определяет количество записей о ресурсах в секции ответов (2 байта);
    NSCOUNT определяет количество записей о ресурсах о полномочных серверах имен в секции полномочий (2 байта);
    ARCOUNT определяет количество записей о ресурсах в дополнительной секции (2 байта).

7.3. Формат секции запроса

    Секция запроса используется для определения запроса, т.е. параметров, которые определяют то, что спрашивается. Секция содержит QDCOUNT (обычно 1) записей, каждая из которых имеет формат представленный на рисунке 8.12.

Поля имеют следующие значения:
QNAME запрашиваемое доменное имя (question name) (переменной длины);
QTYPE  тип запроса (question type); двухбайтовый код, описывающий тип запроса:
  1 адрес хост-машины (a),
  2 полномочный сервер имен (ns),
  5 каноническое имя для псевдонима (cname),
  6 начало полномочий (soa),
  11 описание стандартной услуги (wks),
  13 информация о хост-машине (hinfo),
  14 информация о почтовом ящике или списке почтовых адресов (minfo),
  15 запись о почтовом сервере (mx).
QCLASS двухбайтовый код, специфицирующий класс запроса:
  1 Internet (in),
  3 M.I.T. Сhaosnet (ch),
  255 любой класс.

7.4. Формат записи о ресурсе

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

Поля имеют следующие значения:
NAME  доменное имя, к которому относится данная запись о ресурсе (переменной длины);
TYPE определяет один из типов записей о ресурсах (2 байта); это поле определяет смысл данных поля RDATA;
CLASS  определяет класс данных поля RDATA (2 байта);
TTL время жизни (time to live) (4 байта); временной интервал (в секундах), в течение которого данная запись о ресурсе может кэшироваться; нулевое значение означает, что она не должна кэшироваться;
RDLENGTH определяет количество байтов в поле RDATA (2 байта);
RDATA строка переменной длины, описывающая ресурс; формат этой информации зависит от полей TYPE и CLASS; например, если TYPE = A и CLASS = IN, то поле RDATA содержит 4-байтный IP-адрес.

7.5. Сжатие сообщений

    Доменное имя представляется последовательностью меток, в которой каждая метка состоит из байта длины, за которым следует указанное длиной количество символов метки. Метка по длине ограничена 63 байтами. Доменное имя завершается байтом нулевой длины для нулевой метки корня. Заметим, что поля доменного имени могут иметь нечетное количество байтов. Никакие заполнители не используются. Например, представление доменного имени F.ISI.ARPA показано на рисунке 8.13.

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

    Первые 2 бита байта равны 1. Это позволяет отличить указатель от метки, так как метка должна начинаться с нулевых битов, потому что она ограничена длиной в 63 октета. Поле OFFSET, представленное следующими 14 битами, является смещением от начала сообщения DNS (т.е. от первого октета поля ID в заголовке). Нулевое смещение специфицирует первый байт поля ID.
    Например, в дейтограмме необходимо использовать доменные имена F.ISI.ARPA, FOO.F.ISI.ARPA, ARPA и метку корня. Игнорируя другие поля сообщения, доменные имена будут представляться, как показано на рисунке 8.15.

    На рисунке 8.15 доменное имя F.ISI.ARPA имеет смещение 20. Доменное имя FOO.F.ISI.ARPA имеет смещение 40; его описание использует указатель для связывания метки FOO с именем F.ISI.ARPA, определенным выше. Доменное имя ARPA имеет смещение 64 и использует указатель на компонент ARPA в имени F.ISI.ARPA, т.е. указывает на последнюю метку со смещением 26. Доменное имя корня определяет одиночный нулевой октет на смещении 92; доменное имя корня не имеет меток.
 

7.6. Передача сообщений

    В DNS сообщения передаются либо UDP-дайтограммами, либо по виртуальному каналу протокола TCP. Дейтограммы являются предпочтительными для передачи запросом, так как они меньше загружают сеть и обладают более высокой производительностью, тогда как передача зоны должна осуществляться с использованием виртуального канала, потому что требуется надежная передача. Для доступа к серверу имен используется порт 53 протокола TCP и порт 53 протокола UDP.
    Сообщения, посылаемые по UDP-протоколу, ограничиваются 512 байтами (не включая IP и UDP заголовки). Сообщения большей длины разбиваются, и в заголовке устанавливается бит TC. UDP не доступен для передачи зоны, но является стандартным методом передачи запросов. Сообщения, посланные с использованием UDP, могут быть потеряна, поэтому требуется стратегия повторной передачи. Запросы и ответы на них могут переупорядочиваться в сети или при обработке сервером имен, поэтому решающие программы не должны зависеть от порядка прихода ответов и должны корректно разбирать эти ситуации.

8. Внутренности сервера имен

8.1. Общие понятия

    Серверы имен являются хранилищами информации, которая составляет базу данных доменных имен. База данных делится на области, называемые зонами, которые распределяются между серверами имен. Каждая зона имеет самый верхний узел, который находится ближе всего к корневому узлу, чем любой другой узел в зоне. Имя этого узла обычно используется для идентификации зоны. Каждый сервер имен является ответственным  за определенную зону, т.е. он хранит данные обо всех именах в зоне и является авторизованным (или полномочным) для этих данных. Связывание зоны нижнего уровня с зоной верхнего уровня производится путем описания в самом верхнем узле зоны верхнего уровня данных о самом верхнем узле зоны нижнего уровня (так называемые склеивающие записи ("glue" records)). Таким образом, если север имен получает запрос о данных из нижележащей зоны, для которой он не является авторизованным, то этот сервер имен может вернуть ответ с данными, указывающими на авторизованный сервер для запрошенных данных, что позволяет запрашивающей стороне получить доступ к этим данным.
    Основная задача сервера имен - ответы на запросы с использованием данных о своей зоне. Ответ может генерироваться, используя только локальные данные, и содержать либо ответ на запрос, либо ссылку на другие серверы имен, "ближайшие" к требуемой информации.
Данная зона должна быть доступна с нескольких серверов имен для обеспечения ее доступности в случае неработоспособности одного из серверов или неисправности коммуникационной линии. Для каждой зоны рекомендуется иметь как минимум два сервера.
    Данный сервер имен обычно поддерживает одну или несколько зон, для которых он является авторизованным (полномочным) сервером. Он также может иметь некоторые неавторизованные данные, хранящиеся в его кэше. В ответах на запросы сервер имен указывает, являются ли данные авторизованными или нет.
    Данные, описывающие зону, имеют четыре основные части:
            1) Авторизованные данные для всех узлов внутри зоны.
            2) Данные, описывающие верхний узел зоны (могут рассматриваться как часть авторизованных данных).
            3) Данные, описывающие делегированные подзоны.
            4) Данные, которые позволяют получать доступ к серверам имен для подзон (иногда называемые связывающие данные ("glue" data)).
    Все эти данные представляются в формате записей о ресурсах (RRs) так, что зона может быть полностью описана набором записей о ресурсах. Вся зона может передаваться между серверами передачей записей о ресурсах либо серией сообщений, либо путем передачи всего мастер-файла, который представляется в текстовом виде.
    Авторизованные данные для зоны - это все записи о ресурсах, связанные со всеми узлами, начиная с верхнего узла зоны до нижних листьевых узлов или узлов, находящихся выше нижнего края зоны.
    Логической частью авторизованных данных являются записи о ресурсах, описывающие верхний узел зоны. Эти записи о ресурсах особенно важны для управления зоной и могут быть двух типов:     Записями о ресурсах, описывающими делегированные подзоны, являются записи о ресурсах серверов имен (записи типа NS), которые указывают на имена серверов этих подзон. Эти записи не являются частью авторизованных данных зоны и должны быть в точности такие же, как соответствующие записи в верхнем узле делегированной подзоны.
    Любая зона должна иметь все данные необходимые для взаимодействия с серверами имен любой подзоны. То есть родительская зона имеет всю информацию необходимую для доступа к серверам своих подзон. Кроме NS-записей, которые указывают имена серверов подзон, на родительском сервере необходимо хранить адресные записи (записи типа A) этих серверов. Такие адресные записи называют связывающие записи ("glue" records).
    Когда какая-либо организация желает взять под контроль свой собственный домен, первым делом необходимо выбрать родительскую зону и договориться с ее владельцами о делегировании полномочий на свою подзону (все правила обычно устанавливают владельцы зоны). После этого владельцы новой подзоны должны настроить серверы имен своей подзоны и продемонстрировать их работоспособность владельцам родительской зоны. На последнем этапе необходимо добавить делегированные NS-записи и связывающие A-записи ("glue" RRs) в родительскую зону. Администраторы обеих зон должны убедится в корректности и согласованности этих NS-записей и связывающих A-записей ("glue" RRs).

8.2. Запросы и ответы

    Основной функцией сервера имен является возвращение ответов на стандартные запросы. Каким образом сервер имен будет отвечать на запрос, зависит от того, работает ли он в рекурсивном режиме или нет:     Использование рекурсивного режима возможно в случае, если обе стороны, клиент и сервер имен, договариваются о его использовании. Это достигается использованием двух бит в сообщениях запроса и ответа:     Сервер выполняет рекурсивный поиск, когда получает запрос с установленным битом RD и для этого клиента сервер предоставляет рекурсивный сервис. Клиент может проверить, установлены ли биты RA и RD в ответе. Если эти биты установлены, то это означает, что сервер выполнил запрос в рекурсивном режиме. Следует отметить, что сервер никогда не будет выполнять рекурсивный поиск, если в запросе не установлен бит RD.
    Если запрошен рекурсивный сервис и он доступен, ответ на запрос может быть одним из следующих:     Если рекурсивный сервис не запрошен и не доступен, нерекурсивный ответ может быть одним из следующих:
        а) Авторизованная ошибка имени, указывающая, что имя не существует.
        б) Указание временной ошибки (temporary error).
        в) Различные комбинации из:
              -  записей о ресурсах, отвечающие на запрос вместе с указанием на то, из кэша ли данные или из файлов зоны;
              - указателей на серверы имен, имеющих зоны, более "близкие" к предкам запрошенного имени, чем отвечающий сервер.
              - записи о ресурсах, которые, по мнению сервера, могут пригодиться запрашивающему клиенту.

8.3. Алгоритм

    Реальный алгоритм, используемый сервером имен, будет зависеть от операционной системы и структур данных, используемых для хранения записей о ресурсах. Нижеследующий алгоритм предполагает, что записи о ресурсах организуются в нескольких структурах деревьев, по одной для каждой зоны и еще одна для кэша:
    1. Если бит RA установлен, т.е. рекурсивный режим доступен, и установлен бит RD в полученном запросе, переход на шаг 5, иначе на шаг 2.
    2. Поиск доступных зон для зоны, "ближайшей" к предку имени, указанного в поле QNAME. Если зона найдена, переход на шаг 3, иначе на шаг 4.
    3. Начать поиск в зоне последовательно по все меткам (label by label). Процесс поиска может быть остановлен одним из следующих событий:
            a. Если для QNAME найдено соответствие, то мы нашли узел.
                Если данные об узле имеют тип CNAME и поле QTYPE в запросе не CNAME типа, копировать CNAME-запись в секцию ответов       (answer section) ответного сообщения, заменить поле QNAME на каноническое имя из CNAME-записи и вернуться на шаг 1.
Иначе копировать все записи о ресурсах, тип которых совпадает с QTYPE в запросе, и перейти на шаг 6.
            b. Если поиск выходит за пределы авторизованных данных, мы имеем указатель. Это происходит, когда мы находим узел с NS-записями, описывающими нижележащие подзоны.
                Копировать NS-записи для подзоны в секцию полномочий (authority section) ответного сообщения. Вставить все известные адреса в дополнительную секцию (additional section), использую склеивающие записи (glue RRs), если адреса не доступны из авторизованных данных или кэша. Перейти на шаг 4.
            c. Если для некоторой метки сравнение невозможно (т.е. соответствующая метка не существует), произвести проверку существования метки "*".
                Если метка "*" не существует, проверить, является ли имя, которое мы ищем, оригинальным QNAME в запросе или это имя является псевдонимом (CNAME). Если имя является оригиналом, установить авторизованную ошибку имени в ответе и выйти. Иначе только выйти.
                Если метка "*" существует, сравнить типы записей о ресурсах этого узла с QTYPE.  Записи, типы которых совпадают, копировать в секцию ответов, но установить владельцем этих записей QNAME, а не узел с меткой. Перейти на шаг 6.
    4. Начать поиск в кэше. Если QNAME найдено в кэше, копировать все записи о ресурсах, связанные с ним, тип которых совпадает с QTYPE, в секцию ответов. Если информация о делегировании полномочий не присутствует в области авторизованных данных, искать наилучшие данные полномочиях в кэше и внести ее в секцию полномочий. Перейти на шаг 6.
    5. Используя локальную решающую программы или копию его алгоритма, ответить на запрос. Сохранить результаты, включая любые промежуточные псевдонимы (CNAMEs), в секцию ответов.
    6. Используя только локальные данные, попытаться добавить другие записи о ресурсах, которые могут быть полезны, в дополнительную секцию. Выход.

8.4. Универсальные символы (wildcards)

    Записи о ресурсах, в которых имена начинаются с символа "*", называются универсальными (wildcards). Универсальные записи о ресурсах можно представить себе, как инструкции для синтезирования записей о ресурсах. Когда встречаются соответствующие совпадения, сервер имен создает записи о ресурсах, у которых имя владельца эквивалентно запрошенному имени, а содержание взято из универсальных записей.
Содержимое универсальной записи подчиняется правилам и форматам записей о ресурсах. Каждая универсальная запись имеют имя владельца, которое влияет на запрошенные имена при совпадении с ними. Имя владельца универсальной записи о ресурсе представляется в формате "*.<anydomain>", где <anydomain> - какое-либо доменное имя. <anydomain>  не должен содержать другие метки "*" и должен быть в авторизованной зоне. Универсальные символы применяются к потомкам <anydomain>, но не самому домену <anydomain>.
    Имя запроса с меткой "*" не имеет специального эффекта, но может использоваться для тестирования универсальных записей в авторизованной зоне. Результат таких запросов не кэшируется.
    Для иллюстрации использования универсальных записей представим себе компанию, желающую создать почтовый шлюз. Если компания имеет имя X.COM и TCP/IP-шлюз имеет имя A.X.COM, то следующие записи о ресурсах могут быть введены в зону COM:

    X.COM           MX      10      A.X.COM

    *.X.COM         MX      10      A.X.COM

    A.X.COM         A       1.2.3.4
    A.X.COM         MX      10      A.X.COM

    *.A.X.COM       MX      10      A.X.COM

    Это приведет к тому, что на все MX-запросы к любому доменному имени, заканчивающемуся на X.COM, будет возвращаться MX-запись, указывающая на A.X.COM. Здесь требуются две универсальные записи, т.к. действие универсальной записи *.X.COM блокировано в A.X.COM поддереве непосредственным определением данных для A.X.COM. Следует отметить, что для X.COM и A.X.COM требуется отдельно определить MX-данные.

8.5. Кэширование отрицательных ответов

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

8.6. Обслуживание и перекачка зоны

    Одной из задач администратора зоны является обслуживание зоны на все полномочных серверах имен этой зоны. Когда вносятся изменения в данные зоны, они должны распространяться на все сервера имен.
    Для автоматической передачи или обновления зоны применяется модель, в которой один из серверов имен становится основным или первичным сервером (primary server) для зоны. Все изменения производятся на первичном сервере, а все остальные неосновные или вторичные серверы этой зоны периодически проверяют, не изменились ли данные, и скачивают новые копии файлов зоны, в случае их изменения.
    Для обнаружения изменения данных о зоне вторичные серверы проверяют поле SERIAL записи SOA. При внесении любых изменения в файлы данных зоны необходимо увеличить значение поля SERIAL записи SOA. Данные, имеющие большее значение поля SERIAL, считаются более новыми.
    Параметры периодического опроса первичного сервера вторичными определяются полями REFRESH, RETRY и EXPIRE записи SOA.
При необходимости получения новой копии зоны вторичный сервер должен запросить перекачку зоны посредством запроса AXFR. В ответ на запрос AXFR вторичный сервер получает последовательность сообщений. Первое и последнее сообщения должны содержать данные о верхнем полномочном узле зоны. Промежуточные сообщения содержат все другие записи о ресурсах зоны, включая авторизованные и неавторизованные записи. Этот набор сообщений позволяет сформировать копию зона на вторичном сервере. Для передачи зоны используется протокол TCP, т.к. требуется надежная передача данных. Вторичные серверы обычно производят копирование зоны с основного сервера, но в некоторых случаях они могут обращаться и к другим вторичным серверам для этой цели. Это позволяет повысить эффективность передачи зоны в случае проблем с первичным сервером либо в ситуации, когда имеется более лучший канал к промежуточным вторичным серверам, чем к первичному.

9. Настройка сервера имен

    Одной из реализаций севера имен является BIND (Berkeley Internet Name Domain). BIND является реализацией протокола DNS, которая предоставляет свободно-распространяемую реализацию основных компонентов DNS, включающую:     В настоящее время существуют реализация BIND версии 4 (BIND4) и реализация BIND версии 8 (BIND8). Реализация BIND версии 4 считается устаревшей и ее не рекомендуется использовать. Подробную информацию о BIND можно получить на web-сервере ISC (The Internet Software Consortium) http://www.isc.org/bind.html.
    Настройка сервера имен сводится к следующим шагам:

9.1. Выбор типа

    Сервер может быть первичным для некоторой зоны и вторичным для других зон, или может быть только первичным, или только вторичным, или он может только отвечать на запросы, используя свой кэш, не имея собственной зоны (так называемые кэш-серверы).
Все серверы являются кэш-серверами. Кэширующими являются серверы, которые не являются авторизованными для какой-либо зоны. Такие серверы направляют все запросы к полномочным серверам для получения необходимой информации.
    Существует еще один тип серверов, подчиненные (slave servers), только перенаправляющие запросы, которые не могут разрешить из кэша, определенному в конфигурации набору серверов, взамен взаимодействия с серверами имен корневого или других доменов. Серверы, к которым перенаправляются запросы, называют ретранслирующими серверами (forwarding servers). Запросы, направляемые к ретранслирующим серверам, всегда являются рекурсивными.

9.2. Настройка демона сервера имен

    Сервер имен реализуется демоном, который называется named. Обычно демон named стартует  во время начальной загрузки из определенного командного файла начальной загрузки. При старте демон считывает файл конфигурации, в котором описывается тип сервера, полномочные зоны и местоположение файлов данных зоны. По умолчанию этот файл располагается в /etc/named.boot (для BIND версии 4).
Рассмотрим формат конфигурационного файла /etc/named.boot на примере, представленном ниже:

;boot file for the name server
directory /var/named

;type  domain   source host/file          backup_file

cache        .                           root.cache
primary     Berkeley.EDU      berkeley.edu.zone
primary     32.128.IN-ADDR.ARPA     ucbhosts.rev
secondary CC.Berkeley.EDU                128.32.137.8 128.32.137.3 cc.zone.bak
secondary 6.32.128.IN-ADDR.ARPA  128.32.137.8 128.32.137.3 cc.rev.bak
primary     0.0.127.IN-ADDR.ARPA     localhost.rev
forwarders 10.0.0.78 10.2.0.78
options forward-only
query-log fake-iquery

    Комментарий начинается с символа и продолжается до конца строки.
    Ключевое слово directory определяет каталог (/var/named), где демон named будет искать файлы данных своей зоны.
    Ключевое слово cache определяет имя файла (root.cache), в котором перечислены полномочные корневые серверы имен. Второй аргумент определяет зону ответственности данных в этом файле (в данном случае v это корневая зона (".")). Корневые серверы в этом файле описываются в формате записей о ресурсах типа NS и A. Этот файл необходимо периодически скачивать с ftp-сервера FTP.RS.INTERNIC.NET, т.к. список корневых серверов время от времени обновляется.
    В нашем примере файл корневых серверов называется root.cache и располагается в каталоге /var/named, где будут находиться все остальные файлы данных зоны.
    Ключевое слово primary определяет данный сервер имен в качестве основного (первичного) полномочного сервера для зоны, указанной в первом аргументе. Второй аргумент определяет имя мастер-файла, содержащего данные этой зоны. Каждый мастер-файл должен начинаться с SOA-записи для данной зоны.
    В нашем примере первая строка primary специфицирует, что файл berkeley.edu.zone содержит  авторизованные данные для зоны Berkeley.EDU. Все доменные имена в этом файле связаны с так называемым начальным адресом (origin), которым в этом случае является Berkeley.EDU. Вторая строка primary специфицирует, что файл ucbhosts.rev содержит авторизованные данные для зоны 32.128.IN-ADDR.ARPA. Эти данные используются для трансляции адресов из сети 128.32 в доменные имена. Третья строка primary описывает файл обратной зоны для интерфейса обратной связи (loopback intrface).
    Ключевое слово secondary определяет данный сервер имен в качестве вспомогательного (вторичного) сервера имен для зоны, указанной в первом аргументе. Вторым аргументом выступает список IP-адресов машин, с которых данный сервер будет получать авторизованные данные зоны. В списке можно указать до десяти серверов, которые опрашиваются по порядку следования в списке. Аргумент после списка адресов интерпретируется, как имя резервного файла для полномочной зоны (zone-backup-file), в который сервер будет сохранять резервную копию полученной зоны. Если резервный файл не указан, то используется временный файл.
    В нашем примере первая строка secondary определяет данную хост-машину в качестве вспомогательного (вторичного) сервера имен для зоны CC.Berkeley.EDU. Вслед за именем зоны располагается список IP-адресов серверов зоны ?128.32.137.8 128.32.137.3. Ими могут быть основной сервер или другие вспомогательные серверы. Следующее за списком серверов имя файла cc.zone.bak  определяет файл для резервной копии. Вторая строка secondary определяет, что информация о разрешение адресов в имена для подсети 128.32.136 (зона 6.32.128.IN-ADDR.ARPA) должна получаться с серверов, IP-адреса которых указаны в списке ?128.32.137.8 128.32.137.3, после которого указано имя резервного файла cc.rev.bak для хранения копии этой зоны.
    Ключевое слово forwarders определяет IP-адреса серверов, которые принимают рекурсивные запросы от других серверов. Если файл конфигурации определяет один или несколько ретранслирующих серверов, то данный сервер будет посылать все запросы, которые не может разрешить с использованием кэша, этим серверам.
    Ключевое слово options переопределяет различные опции, воздействующие на поведение BIND-сервера. В примере опция forward-only заставляет сервер перенаправлять все запросы на ретранслирующие серверы, query-log заставляет сервер журнализировать все запросы через систему syslog,  fake-iquery определяет, что сервер не будет выполнять обратные запросы.
    Для получения более подробной информации о формате конфигурационного файла необходимо обратиться к документации по BIND.

9.3. Файлы данных записей о ресурсе

    Все файлы данных, используемые named, имеют стандартный формат. Каждая строка является записью, которая называется записью о ресурсе (RR - Resource Record) и содержит следующие поля, разделенные пробелами:

[NAME] [TTL]  CLASS  RECORD_TYPE  RECORD_DATA

где,

NAME Доменное имя, которое определяет запись. Если это поле остается незаполненным, то по умолчанию используется имя предыдущей RR.
TTL Значение времени жизни (time-to-live) для данной RR. Если это поле отсутствует, то по умолчанию используется минимальное время, определенное в записи SOA для этого домена.
CLASS   Для семейства протоколов TCP/IP ограничен значением IN (internet).
RECORD_TYPE Тип записи о ресурсе.
RECORD_DATA Данные типа RECORD_TYPE, определенные для этого доменного имени.

Следующие символы имеют специальный смысл внутри записи о ресурсе:
.            Одиночная точка в поле имени относится к текущему домену.
@         Одиночный символ @ в поле имени относится к текущему первоисточнику.
..           Две одиночных точки в поле имени относятся к нулю или корневому доменному имени.
()           Символы конца строки не распознаются, если оказываются заключенными в круглые скобки. Это позволяет записи занимать более одной строки.
;            Точка с запятой является признаком начала комментария. Весь текст до конца строки игнорируется.
*           Звездочка обозначает универсальный символ.

Кроме этого в файле данных можно использовать две специальные записи $ORIGIN и $INCLUDE следующего формата:

$ORIGIN <domain-name> [<comment>]
$INCLUDE <file-name> [<domain-name>] [<comment>]

Ключевое слово $ORIGIN определяет новое начальное доменное имя для всех последующих имен. $INCLUDE вставляет указанный первым параметром файл в текущий файл и может определять вторым параметром доменное имя, которое будет выступать в качестве начального имени (origin) для данных вставляемого файла. Отметим, что $INCLUDE никогда не воздействует на начальное имя родительского файла.
Типы записей могут быть следующими:

1) SOA Запись начала полномочий (start of authority) определяет начало зоны, которая заканчивается в случае появления следующей записи SOA. Ее формат следующий:

[NAME] [TTL] CLASS  SOA  NSNAME  PERSON_IN_CHARGE (
   SERIAL
   REFRESH
   RETRY
   EXPIRE
   MINIMUM)

Поля RDATA записи SOA имеют следующий формат:
NSNAME Доменное имя сервера имен, который является первичным для данных этой зоны.
PERSON_IN_CHARGE Доменное имя, которое специфицирует почтовый адрес персоны, ответственной за зону.
SERIAL   Номер версии данного файла.
REFRESH Определяет интервал времени, через который вторичные серверы имен должны опрашивать первичный сервер на факт изменения данных. Если номер версии увеличился, то вторичные серверы имен будут перекачивать зону с первичного сервера.
RETRY Определяет интервал времени, через который вторичные серверы имен должны повторить опрос первичного сервера после неудавшейся попытки.
EXPIRE Определяет, сколько должно пройти времени, прежде чем зона перестанет быть полномочной.
MINIMUM Минимальное значение TTL для использования в случае отсутствия в записи о ресурсе спецификации поля TTL.

2) NS Запись сервера имен указывает на имя сервера, ответственного за домен, определенный в поле NAME:

[NAME] [TTL]  CLASS  NS SERVER_NAME

Например,
berkeley.edu. IN  NS ucbvax.berkeley.edu.

3) A Адресная запись указывает на IP-адрес доменного имени, определенного в поле NAME:

[NAME] [TTL]  CLASS  A  ADRESS

Например,
ucbvax.berkeley.edu. IN  A 10.0.0.78

4) PTR Запись указателя определяет указатель на доменное имя, имеющее IP-адрес, описанный в поле NAME специальным образом (IP-адрес записывается слева направо в обратном порядке с прибавлением имени IN-ADDR.ARPA на конце). Записи типа PTR используются для поиска доменных имен по их IP-адресам в специальной области пространства имен IN-ADDR.ARPA.

SPECIAL_NAME  [TTL]  CLASS PTR REAL_NAME

В случае использования для описания домена IN-ADDR.ARPA, в поле SPECIAL_NAME определяется IP-адрес, а в поле REAL_NAME - доменное имя, соответствующее этому адресу.

Например,
78.0.0.10.IN-ADDR.ARPA.  IN PTR  ucbvax.berkeley.edu.

5) HINFO Запись информации о хост-машине содержит определенную информацию об аппаратных средствах и операционной системе хост-машины.

[NAME] [TTL]  CLASS  HINFO  HARDWARE  OS

6) WKS Запись об общедоступных сервисах описывает различные протоколы и услуги, которые предоставляет хост-машина.

[NAME] [TTL]  CLASS  WKS ADDRESS PROTOCOL SERVICE

7) CNAME Определяет псевдоним для канонического доменного имени.

NICKNAME [TTL]  CLASS  CNAME  CANONICAL_NAME

8) MX Запись о почтовом сервере (mail exchanger) определяет машину, которая знает, как доставить почту для указанного в поле NAME домена.

NAME [TTL]  CLASS  MX PREFERENCE  EXCHANGER

где,
PREFERENCE указывает порядок, которому должен следовать почта, если имеется более одного пути доставки. EXCHANGER определяет имя почтового сервера.
 

9.4. Пример

Загрузочный файл /etc/named.boot имеет следующий вид:
     ; sample named.boot file for primary name server
     ;
     ; type          domaim                 sourse file or host
     directory                              /var/named
     cache           .                      named.root
     primary         net.com                net.zone
     primary         2.1.184.in-addr.arpa   net.revzone
     primary         0.0.127.in-addr.arpa   named.local
     secondary       sub1.net.com           184.1.42.41  sub1.zone
     secondary       sub2.net.com           184.1.7.14  sub2.zone

Файл кеша /var/named/named.root:
     ; initial cashe file for root domain servers
     ; list of servers...
                     99999999   in   ns   ns.nic.ddn.mil.
                     99999999   in   ns   aos.brl.mil.
                     99999999   in   ns   c.nyser.net.
                     99999999   in   ns   terp.umd.ru.
                     99999999   in   ns   ns.nasa.gov.
                     99999999   in   ns   nic.nordu.net.
     ; and their addresses...
     ns.nic.ddn.mil  99999999   in   a    192.112.36.4
     aos.brl.mil       99999999   in   a    128.63.4.82
                           99999999   in   a    26.3.0.29
                           99999999   in   a    192.5.25.82
     c.nyser.net      99999999   in   a    192.33.4.12
     terp.umd.ru     99999999   in   a    128.8.10.90
     ns.nasa.gov     99999999   in   a    192.52.195.10
                           99999999   in   a    128.102.16.10
     nic.nordu.net   99999999   in   a    192.36.148.17

Значение 99999999 указывает время жизни этих записей (примерно 3 года). В файле корневого кэша перечисляются хост-машины, которые функционируют в качестве корневых серверов доменных имен.

Файл хост-машин зоны /var/named/net.zone:
     ; sample hosts file
     @           in   soa     net.com. root.net.com.  (
                              1.1       ; version number
                              21600     ; refresh - 6 hours
                              900       ; retry - 15 minutes
                              2592000   ; expire 30 days
                              21600 )   ; minimum - 6 - hours
                     in   ns      net.com.
                     in   ns      hostK.net.com.
     net.com    in   mx      10 hostK.net.com.
     *.net.com   in   mx      10 hostK.net.com.
     hostD       in   a       184.1.2.7
                     in   a       184.1.42.3
                     in   hinfo   sun-4/630 unix
     hostB       in   a       184.1.2.86
                     in   a       188.177.33.145
                     in   hinfo   sun-4/70
                     in   wks     184.1.2.86 udp syslog domain
                     in   wks     184.1.2.86 tcp (telnet ftp sunrpc
                              nntp smtp domain)
     hostA       in   a       184.1.2.40
     hostC       in   a       184.1.2.99
     hostG       in   a       184.1.42.41
     hostI         in   a       184.1.7.14
     mainhost   in   cname   net.com.

Файл обратных адресов /var/named/net.revzone:
     ;reverse address file
     $ORIGIN 2.1.184.in-addr.arpa
     @           in   soa   net.com. root.net.com. (
                            1.1       ; version number
                            21600     ; refresh - 6 hours
                            900       ; retry - 15 minutes
                            2592000   ; expire 30 days
                            21600 )   ; minimum - 6 - hours
                                in   ns    net.com.
     7                         in   ptr   hostD.net.com.
     86                       in   ptr   hostB.net.com.
     40                       in   ptr   hostA.net.com.
     99. 2.1.184.in-addr.arpa   in   ptr   hostC.net.com.

Файл обратных адресов /var/named/named.local:
     @          in   soa   net.com. root.net.com. (
                            1.1       ; version number
                            21600     ; refresh - 6 hours
                            900       ; retry - 15 minutes
                            2592000   ; expire 30 days
                            21600 )   ; minimum - 6 - hours
                  in   ns    net.com.
     1           in   ptr   localhost.

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

10. Настройка решающей программы

    Решающая программа (resolver) является клиентской частью DNS. Она предназначена для трансляции запросов программ в запросы к серверу имен, получения ответа и возвращения результата запроса вызывающей программе. Решающая программа обычно реализуется набором библиотечных функций.
    Для того чтобы программы имели возможность использовать сервис доменных имен необходимо соответствующим образом настроить решающую программу на локальной хост-машине. Поведение решающей программы управляется файлом конфигурации /etc/resolv.conf. Этот файл содержит информацию, которая читается библиотечными функциями всякий раз, когда они вызываются каким-либо процессом. Файл содержит список ключевых слов со значениями, определяющими различные типы информации для решающей программы.

Основные ключевые слова, которые используются в конфигурационном файле /etc/resolv.conf, следующие:

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

domain             Локальное доменное имя. Большинство запросов внутри этого домена могут использовать короткие имена относительно локального домена. Если ключевое слово domain не присутствует, то домен определяется из имени локальной хост-машины (вызовом функции gethostname).

search                 Может содержать список доменных имен, разделенных пробелами или знаками табуляции, каждое из которых будет использовано, при попытках решающей программы разрешить запрос. Если в запросе используется короткое имя, то решающая программа будет по порядку прибавлять к этому имени доменное имя из списка и пытаться его разрешить, пока не получит положительный ответ или не исчерпается список.
sortlist                 Позволяет сортировать адреса, возвращаемые функцией gethostbyname. Список сортировки определяется парами "IP-адрес/сетевая маска" (маска не обязательна). Можно указывать до десяти таких пар.
Например:
   sortlist 130.155.160.0/255.255.240.0 130.155.0.0

    Обычно для нормальной работы достаточно определить в файле конфигурации имя домена, в который входит данная хост-машина и один или несколько серверов имен, к которым будет обращаться решающая программа для разрешения имен.
Ниже приведен пример конфигурационного файла решающей программы /etc/resolv.conf:
     ; sample resolv.conf file
     domain net.com
     nameserver 184.1.2.7
     nameserver 184.1.2.86
     nameserver 184.1.7.14
    Первая строка представляет собой комментарий (комментарии начинаются с точки с запятой (";") и продолжаются до конца строки). Строка с ключевым словом domain - это домен по умолчанию, который добавляется к именам, которые не содержат точек. Строка с ключевым словом nameserver - IP-адрес сервера доменных имен. В этом файле можно перечислить до трех серверов имен (по умолчанию, количество серверов имен определяется переменной окружения MAXNS). Серверы опрашиваются по очереди до тех пор, пока на запрос не будет получен ответ или не наступит тайм-аут.
    В некоторых реализациях ОС UNIX может использоваться файл /etc/nsswitch.conf, который определяет, в каком порядке различные сервисы системы должна опрашивать свои ресурсы. Для того чтобы функции решающей библиотеки обращались к DNS для разрешения имен, необходимо ключевому слову hosts в этом файле указать значение dns.
Например,
     hosts:      files dns

    В этом случае функции решающей библиотеки будут обращаться сначала к локальной таблице /etc/hosts и, если запрошенного имени в нем нет, запрос будет направлен к DNS.
    В BSD-подобных системах (например, в BSDI и FreeBSD) порядок обращения функций решающей библиотеки к различных ресурсам определяется файлом конфигурации /etc/host.conf.
Пример содержимого этого файла представлен ниже:
    # Пример файла /etc/host.conf.
    # Сначала обращаются к локальному файлу /etc/hosts.
    hosts
    # Затем к серверам имен.
    bind
    # Затем к YP/NIS, если он используется
    nis

11. Утилиты для отладки и контроля работы DNS

11.1. Nslookup

Nslookup v это утилита, с помощью которой можно запрашивать сервера доменных имен. Она имеет два режима: интерактивный и неинтерактивный (командный). Интерактивный режим позволяет пользователям запрашивать сервера имен о различных хост-машинах и доменах или выводить список хост-машин домена. Командный режим используется только для получения информации о конкретной хост-машине или домене в одной команде.
Пример использования командного режима:
# Запрашиваем адресную запись для доменного имени www.sun.com
#
% nslookup  www.sun.com
Server:  ispgate-root.ispras.ru  # имя сервера имен
Address:  194.67.37.200    # и его IP-адрес (из /etc/resolv.conf)

Non-authoritative answer:   # указывается, что данные из кэша
Name:    wwwwseast2.usec.sun.com  # каноническое имя
Address:  192.9.49.33    # IP-адрес
Aliases:  www.sun.com    # запрошенное имя было псевдонимом

Выполнение nslookup без параметров переводит утилиту в интерактивный режим; команда help выводит информацию обо всех возможных командах:

$ nslookup
Default Server:  ispgate-root.ispras.ru
Address:  194.67.37.200

# команда help выводит список команд nslookup
#
> help
$Id: nslookup.help,v 8.4 1996/10/25 18:09:41 vixie Exp $

Commands:       (identifiers are shown in uppercase, [] means optional)
NAME            - print info about the host/domain NAME using default server
NAME1 NAME2     - as above, but use NAME2 as server
help or ?       - print info on common commands; see nslookup(1) for
                  details
set OPTION      - set an option
    all         - print options, current server and host
    [no]debug   - print debugging information
    [no]d2      - print exhaustive debugging information
    [no]defname - append domain name to each query
    [no]recurse - ask for recursive answer to query
    [no]vc      - always use a virtual circuit
    domain=NAME - set default domain name to NAME
    srchlist=N1[/N2/.../N6] - set domain to N1 and search list
                              to N1,N2, etc.
    root=NAME   - set root server to NAME
    retry=X     - set number of retries to X
    timeout=X   - set initial time-out interval to X seconds
    querytype=X - set query type, e.g.,
                  A,ANY,CNAME,HINFO,MX,PX,NS,PTR,SOA,TXT,
                  WKS,SRV,NAPTR
    port=X      - set port number to send query on
    type=X      - synonym for querytype
    class=X     - set query class to one of IN (Internet), CHAOS,
                  HESIOD or ANY
server NAME     - set default server to NAME, using current
                  default server
lserver NAME    - set default server to NAME, using initial server
finger [USER]   - finger the optional USER at the current default host
root            - set current default server to the root
ls [opt] DOMAIN [> FILE] - list addresses in DOMAIN (optional: output to FILE)
    -a          -  list canonical names and aliases
    -h          -  list HINFO (CPU type and operating system)
    -s          -  list well-known services
    -d          -  list all records
    -t TYPE     -  list records of the given type (e.g., A,CNAME,MX, etc.)
view FILE       - sort an 'ls' output file and view it with more
exit            - exit the program, ^D also exits
>

В этом режиме можно получать различную информацию системы доменных имен, при этом можно выбирать сервер имен, от которого необходимо получить эту информацию, например:

$ nslookup
Default Server:  ispgate-root.ispras.ru
Address:  194.67.37.200

# получить IP-адрес хоста www.linux.org (тип запроса A)
#
> www.linux.org
Server:  ispgate-root.ispras.ru
Address:  194.67.37.200

Name:    www.linux.org
Address:  198.182.196.56

# устаноаить тип запроса PTR
#
> set q=ptr

# получить доменное имя по адресу 198.182.196.56
#
> 198.182.196.56
Server:  ispgate-root.ispras.ru
Address:  194.67.37.200

56.196.182.198.in-addr.arpa     name = www.linux.org
196.182.198.in-addr.arpa        nameserver = ns.invlogic.com
196.182.198.in-addr.arpa        nameserver = ns0.aitcom.net
ns.invlogic.com internet address = 205.134.175.254
ns0.aitcom.net  internet address = 208.234.1.34
>

# устаноаить тип запроса MX
#
> set q=mx

# получить все МХ-записи домена linux.org
#
> linux.org
Server:  ispgate-root.ispras.ru
Address:  194.67.37.200

linux.org       preference = 10, mail exchanger = mail.linux.org
linux.org       preference = 20, mail exchanger = router.invlogic.com
linux.org       preference = 30, mail exchanger = border-ai.invlogic.com
linux.org       nameserver = ns.invlogic.com
linux.org       nameserver = ns0.aitcom.net
mail.linux.org  internet address = 198.182.196.60
router.invlogic.com     internet address = 198.182.196.1
border-ai.invlogic.com  internet address = 205.134.175.254
ns.invlogic.com internet address = 205.134.175.254
ns0.aitcom.net  internet address = 208.234.1.34
>

# сменить сервер имен на ns0.aitcom.net
#
> server ns0.aitcom.net
Default Server:  ns0.aitcom.net
Address:  208.234.1.34

# устаноаить тип запроса А
#
> set q=a

# получить адресную информацию для имени www.hp.com
#
> www.hp.com
Server:  ns0.aitcom.net
Address:  208.234.1.34

Name:    www.hp.com
Addresses:  192.151.11.13, 192.151.11.32, 192.151.52.13, 192.6.35.16

>
 

11.2. Host

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

# Получить адресную информацию для имени ispgate.ispras.ru
#
$ host ispgate.ispras.ru

ispgate.ispras.ru has address 194.186.94.6
ispgate.ispras.ru mail is handled (pri=20) by relay1.sovam.com
ispgate.ispras.ru mail is handled (pri=10) by gate.ispras.ru

# Получить адресную информацию для имени ispgate.ispras.ru
# с сервера ns.css-mps.ru
#
$ host -t a ispgate.ispras.ru ns.css-mps.ru

Using domain server:
Name: ns.css-mps.ru
Address: 194.154.87.5
Aliases:

ispgate.ispras.ru has address 194.186.94.6

# Получить MX-информацию для имени ispras.ru
# с сервера ns.sovam.com
#
$ host -t mx ispras.ru ns.sovam.com

Using domain server:
Name: ns.sovam.com
Address: 194.67.2.97
Aliases:

ispras.ru mail is handled (pri=20) by relay1.sovam.com
ispras.ru mail is handled (pri=10) by gate.ispras.ru
$

С помощью опции vа можно получить все записи о ресурсах связанных с запрашиваемым именем. Аналогичную информацию можно получить при использовании опций  -v  -t any. Например:

$ host -a www.linux.org
Trying null domain
rcode = 0 (Success), ancount=4
www.linux.org   43200 IN        MX      30 border-ai.invlogic.com
www.linux.org   43200 IN        MX      10 mail.linux.org
www.linux.org   43200 IN        MX      20 router.invlogic.com
www.linux.org   43200 IN        A       198.182.196.56
For authoritative answers, see:
linux.org       43200 IN        NS      ns.invlogic.com
linux.org       43200 IN        NS      ns0.aitcom.net
Additional information:
border-ai.invlogic.com  43200 IN        A       205.134.175.254
mail.linux.org  43200 IN        A       198.182.196.60
router.invlogic.com     43200 IN        A       198.182.196.1
ns.invlogic.com 43200 IN        A       205.134.175.254
ns0.aitcom.net  86400 IN        A       208.234.1.34

$ host -v -t any www.linux.org
Trying null domain
rcode = 0 (Success), ancount=4
The following answer is not authoritative:
www.linux.org   43149 IN        A       198.182.196.56
www.linux.org   43149 IN        MX      30 border-ai.invlogic.com
www.linux.org   43149 IN        MX      10 mail.linux.org
www.linux.org   43149 IN        MX      20 router.invlogic.com
For authoritative answers, see:
linux.org       75383 IN        NS      NS.invlogic.com
linux.org       75383 IN        NS      NS0.AITCOM.NET
Additional information:
mail.linux.org  43149 IN        A       198.182.196.60
NS.invlogic.com 75383 IN        A       205.134.175.254
NS0.AITCOM.NET  75383 IN        A       208.234.1.34
$
 

11.3. Dig

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

dig @server domain query-type query-class

где
server доменное имя или IP-адрес запрашиваемого сервера имен; если не указан, используетсясервер по умолчанию;
domain  доменное имя, для которого запрашивается информация.
query-type тип запроса; если не указан принимается тип А;
Возможны следующие значения:
                  a     T_A  сетевой адрес
                  any  T_ANY  вся информация о данном имени
                  mx   T_MX        почтовые серверы для домена
                  ns    T_NS        серверы имен
                  soa   T_SOA       запись начала полномочий
                  hinfo T_HINFO    информация о хосте
                  axfr   T_AXFR    передача зоны
                  txt     T_TXT    arbitrary number of strings
                  (RFC 1035 описывает полный список.)
query-class класс сети; по умолчанию класс ``in''.

Например:

# Запросить сервер имен ns.sovam.com об адресной записи (RR типа А)
# для доменного имени www.linux.org.
#
$ dig @ns.sovam.com www.linux.org a in

# Ответ возвращается в виде сообщения DNS
; <<>> DiG 8.1 <<>> @ns.sovam.com www.linux.org a in
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

# Секция запроса
;; QUERY SECTION:
;;      www.linux.org, type = A, class = IN

# Секция ответа
;; ANSWER SECTION:
www.linux.org.          12H IN A        198.182.196.56

# Секция полномочных серверов
;; AUTHORITY SECTION:
linux.org.              12H IN NS       ns.invlogic.com.
linux.org.              12H IN NS       ns0.aitcom.net.

# Секция дополнительной информации
;; ADDITIONAL SECTION:
ns.invlogic.com.        12H IN A        205.134.175.254
ns0.aitcom.net.         1D IN A         208.234.1.34

;; Total query time: 2877 msec
;; FROM: ispgate to SERVER: ns.sovam.com  194.67.2.97
;; WHEN: Wed May  5 16:49:01 1999
;; MSG SIZE  sent: 31  rcvd: 145

$
 
 

Литература

[Albitz 92] Albitz P., Liu C., "DNS and BIND in a Nutshell", O'Reilly & Associates, 1992.
[Vixie 95] Vixie, P., "DNS and BIND Security Issue", Internet Software Consortium, 2 May, 1995.
[RFC-819] Su Z., and Postel J., "The Domain Naming Convention for Internet User Applications", RFC-819, Network Information Center, SRI International, August 1982.
[RFC-920] Postel J. and Reynolds J., "Domain Requirements", RFC-920, USC/Information Sciences Institute October 1984.
[RFC-974] Partridge C., "Mail routing and the domain system", RFC-974, CSNET CIC BBN Labs, January 1986.
[RFC-1032] Stahl M., "Establishing a Domain - Guidelines for Administrators", RFC-1032, November 1987.
[RFC-1033] Lottor M., "Domain Administrators Operations Guide", RFC-1033, November 1987.
[RFC-1034] Mockapetris, P., "Domains Names - Concepts and Facilities", RFC-1034, USC/Information Sciences Institute, November 1987.
[RFC-1035] Mockapetris, P., "Domain Names - Implementations Specification", RFC-1035, USC/Information Sciences Institute, November 1987.
[RFC-1101] Mockapetris, P., "DNS Encoding of Network Names and Other Types", RFC-1101, USC/Information Sciences Institute, April 1989.
[RFC-1535] Gavron E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC-1535, ACES Research Inc., October 1993.
[RFC-1591] Postel J., "Domain Name System Structure and Delegation", RFC-1591, USC/Information Sciences Institute, March 1994.
[RFC-1712] Farrell, C., Schulze, M., Pleitner, S., and D. Baldoni, "DNS Encoding of Geographical Location", RFC-1712, November 1994.
[RFC-1713] Romao, A., "Tools for DNS debugging", RFC-1713, November 1994.
[RFC-1912] Barr, D., "Common DNS Operational and Configuration Errors", RFC-1912, February 1996.
[RFC-1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC-1995, Tokyo Institute of Technology, August 1996.
[RFC-1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC-1996, ISC,August 1996.
[RFC-2010] Manning, B., Vixie, P., "Operational Criteria for Root Name Servers", RFC-2010, ISI, October 1996.
[RFC-2052] Gulbrandsen, A., Vixie, P., "A DNS RR for specifying the location of services (DNS SRV)", RFC-2052, October 1996.
[RFC-2065] Eastlake 3rd, D., Kaufman, C., "Domain Name System Security Extensions", RFC-2065, January 1997.
[RFC-2136] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC-2136, April 1997.
[RFC-2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic Update", RFC-2137, April 1997.
[RFC-2219] Hamilton, M., Wright, R., "Use of DNS Aliases for Network Services", RFC-2219, October 1997.
[RFC-2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC-2308, CSIRO, March 1998.