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

Служба Доменных Имен была разработана для именования машин в глобальной сети. Основной особенностью глобальной сети является распределенное администрирование, когда один администратор физически не может уследить за выделением имен. Поэтому Служба Доменных Имен функционирует на принципе делегирования полномочий. Каждая машина либо знает ответ на вопрос, либо знает кого спросить. При правильном функционировании система замкнута, т.е. если запрошенная информация имеется у кого-либо, то она будет найдена и сообщена клиенту, либо, если вопрос не имеет ответа, клиент получит сообщение о невозможности получения ответа на вопрос.

Каждый клиент знает своего сервера; обычно указывается не один, а несколько серверов - если первый не отвечает, клиент обращается ко второму и так далее до исчерпания списка. В принципе неважно, к какому серверу обращаться - они дают (должны давать при правильном функционировании) одинаковые ответы на любой запрос. Поэтому для ускорения работы обычно указывают ближайший. Следует помнить, что на одной машине могут функционировать одновременно Name-сервер и программы-клиенты; поэтому если на машине запущен Name-сервер, то в качестве Name-сервера на ней должен быть прописан "я сам".

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

Мне неизвестна ни одна машина с доменным именем из одного сегмента; очень редко используются доменные имена из двух сегментов; имена из трех и четырех сегментов составляют подавляющую долю всех имен Internet; имена из пяти сегментов встречаются довольно редко, а из шести и более мне неизвестны.

Допустим, клиент запросил адрес "www.организация.город.страна". Поиск информации по доменному имени происходит следующим образом:

1. Клиент спрашивает своего сервера.
2. Если тот является сервером данной зоны, то ответит, на чем все заканчивается.
3. Сервер спрашивает корневой сервер.
4. Тот не может ответить, потому что не знает; зато знает, какой сервер отвечают за зону "страна".
5. Сервер зоны "страна" тоже не может ответить, но знает, что нужно спросить сервер зоны "город.страна".
6. Тот в свою очередь отсылает запрос серверу зоны "организация.город.страна", который сообщит нужную информацию.

Это приближенная модель, которая тем не менее позволяет представить работу системы DNS.

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

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

Хочу обратить особое внимание на сходство, различие и взаимодействие систем DNS и IP-маршрутизации. Как и IP-маршрутизация, DNS работает по принципу делегирования полномочий, но выделение доменных имен совершенно не зависит от выделения IP-адресов. Для примера рассмотрим домен freebsd.org. Это - домен организации, занимающейся распространением операционной системы FreeBSD Unix. FTP-сервер, содержащий дистрибутив операционной системы и множества утилит для нее, имеет копии в нескольких десятках стран. Имена серверов выглядят так:

Ftp.freebsd.org первичный сервер в США ftp.страна.freebsd.org основной сервер в стране ftpчисло.страна.freebsd.org дополнительный сервер в стране

• ftp.ru.freebsd.org соответствует ftp.ru
• ftp2.ru.freebsd.org соответствует ftp.gamma.ru
• ftp3.ru.freebsd.org соответствует ftp.chg.ru

Таким образом, машины, находящиеся в России оказались произвольно (по воле DNS-мастера из университета Bercley) включенными в домен freebsd.org; однако, они также состоят в своих зонах. Система DNS позволяет любому DNS-мастеру включить любой сервер в свою зону, хотя это включение никого ни к чему не обязывает.

Однако, некоторым сервисам этого недостаточно - так E-mail требует, чтобы машина, принимающая письмо, признала своим адрес, указанный в качестве пункта назначения. Протокол HTTP 1.1 (в 1.0 этого не было) требует, чтобы в HTTP-запросе указывался не путь к файлу, отсчитанный от корня сервера (хотя такие запросы тоже признаются), но и имя сервера; при этом сам сервер знает, какие имена - его, а остальные обрезает и обслуживает в соответствии с HTTP 1.0.

Делегирование зоны...in-addr.arpa дается только от провайдера вместе с IP-адресами. Собственно, это связано с предназначением ReverceDNS - сообщать доменное имя по IP-адресу. Наверняка мастер зоны freebsd.org держит Reverce-зону для IP-номеров, выделенных университету Bercley; но все эти серверы (кроме сервера, расположенного в университете) не входят в эту Reverce-зону, а значит, ему неподконтрольны.

Одна из проблем состит в том, что Reverce-зону можно выделить только на сеть класса A, B или C (на 16777216, 65536 или 256 адресов) и никак иначе. Можно получить правА на несколько зон одного или разных классов, но что делать тем, кому выделили меньше 256 адресов? А ведь в условиях исчерпания адресного пространства не редкость выделения пула уже на 16 адресов!

DNS-услуги Internet-провайдера

Как правило, провайдер предоставляет клиенту целый комплекс услуг. В число оказываемых DNS-услуг входят:

• делегирование зоны...in-addr.arpa клиентам, имеющим пул адресов, кратный 256.
• регистрация доменного имени клиента у держателя той зоны, в которой клиент хочет зарегистрироваться;
• поддержание вторичного сервера прямой и обратной DNS-зон клиента;
• поддержание первичного сервера этих зон, если клиент по какой-либо причине не поддерживает их сам (особенно это относится к случаю виртуальных зон и к случаю выделения малого пула адресов);

Если провайдер будет отказываться - сошлитесь на меня. :-)

Политика и стратегия назначения имен

Имена зон условно можно разделить на "организационные" и "географические". В высшей зоне зарегестрированы следующие "организационные" зоны:

Com commercial (коммерческие) edu educational (образовательные) gov goverment (правительственные) mil military (военные) net network (организации, обеспечивающие работу сети) org organization (некоммерческие организации)

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

Каждая страна (государство) имеет свой географический домен из двух букв:

Ae United Arab Emirates (Объединенные Арабские Эмираты) au Australia (Австралия) be Belgium (Бельгия) br Brazil (Бразилия) by Belarus (Белоруссия) ca Canada (Канада) ch Switzerland (Швейцария) cz Czech Republic (Чехия) de Germany (Германия) dk Denmark do Dominican Republic (Доминиканская республика) ee Estonia (Эстония) eo ??? es Spain (Испания) fi Finland (Финляндия) fr France (Франция) hu Hungary (Венгрия) il Israel (Израиль) in India (Индия) iz ??? jp Japan (Япония) kg Kyrgyzstan (Кыргызстан) kr South Korea (Южная Корея) kz Kazakhstan (Казахстан) lt Lithuania (Литва) lv Latvia (Латвия) mx Mexico (Мексика) nl Netherlands (Нидерланды) no Norway (Норвегия) nz New Zealand (Новая Зеландия) pl Poland (Польша) ro Romania (Румыния) ru Russia (Россия) si Slovenia (Словения) sk Slovak Republic (Словакия) su Soviet Union (Советский Союз - поддерживается, но не распределяется) ua Ukraine (Украина) uk United Kingdom (Соединенное Королевство ВеликоБритания / Англия) yu Yugoslavia (Югославия) za South Africa (Южная Африка)

Я перечислил отнюдь не все страны - кто хочет, может прислать мне другие названия.

В зонах государств опять же имеются "организационные" и "географические" зоны. "Организационные" в большинстве своем повторяют структуру "организационных" зон верхнего уровня, разве что вместо "com" используется "co". "Географические" выделяются городам, областям и т.п. территориальным образованиям. Непосредственно в тех и других размещаются домены организаций или домены персональных пользователей.

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

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

Имена "функциональные" вытекают из функций, выполняемых машиной:

Www HTTP (WWW) сервер ftp FTP сервер ns, nss, dns DNS (Name) сервер mail Mail сервер relay Mail Exchanger *proxy соответствующий Proxy сервер

Я считаю нежелательным присваивать какой-либо машине функциональное имя - в любой момент может потребоваться перенести соответствующую функцию на другую машину. Для этого лучше всего использовать псевдонимы, которые перенаправляют запросы к данному имени на записи, относящиеся к другому имени. Но вот ссылаться на псевдонимы при обьявлении Mail Exchanger"ов и вообще использовать их в правой части записей считается нежелательным, а зачастую является недопустимым

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

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

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

Записи DNS бывают разных типов и содержат разную информацию. Основные записи, которые необходимо упомянуть, отображены в таблице 1.

Тип	Расшифровка	Описание
A	Address	Адресная запись, соответствие между именем и IP-адресом
CNAME	Canonical name	Каноническое имя для псевдонима (одноуровневая переадресация)
NS	Authoritative name server	Адрес узла, отвечающего за доменную зону. Критически важна для функционирования самой системы доменных имён
PTR	Domain name pointer	Реализует механизм переадресации
SOA	Start of authority	Указание на авторитетность информации, используется для указания на новую зону

Табл. 1. Основные ресурсные записи DNS

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

CNAME записи позволяют задать «псевдоним» или «каноническое имя» для хоста, с целью привязать его не к конкретному IP-адресу, а сослаться на другой хост. Например, если узел имеет несколько доменных имён, достаточно указать одну Aзапись и ссылаться на неё. В записи содержится доменное имя.

NS записи служат для указания NS-серверов, обслуживающих данную зону и зоны следующего уровня. В записи содержится адрес ответственного DNS сервера.

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

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

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

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 [email protected]), так и зона (whois [email protected])

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

Записи о ресурсах (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:

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 )

Расширение протокола TSIG

RFC 2845 расширяет протокол DNS возможностью проверки целостности запросов и ответов (QUERY), передачу зон, а также аутентификацию динамических изменений (UPDATE, RFC 2136) с помощью криптографически стойких контрольных сумм – TSIG (transaction signatures). При генерации хеша используется алгоритм HMAC-MD5 и разделяемый между двумя участниками секрет (симметричный ключ). Механизм распределения ключей не определяется. Участники транзакции могут разделять несколько ключей, поэтому для идентификации конкретного ключа используется его имя в формате доменного имени. Для предотвращения атак повторного воспроизведения запись содержит время подписи (требуется синхронизация времени с помощью, например, NTP). Отвечая на защищенный запрос сервер посылает ответ, защищенный тем же алгоритмом и ключом. В качестве ключей рекомендуется использовать случайные последовательности длиной не менее 128 бит.

Данный механизм требует меньшей нагрузки на процессор и меньших затрат на создание инфраструктуры при небольшом количестве узлов по сравнению с DNSSEC с его механизмами ассиметричного шифрования и публичных ключей (RFC 2535, RFC 2137). С другой стороны DNSSEC позволяет легко масштабировать установленную инфраструктуру распределения ключей и обеспечивать цифровую подпись (TSIG несмотря на название не позволяет производить подтверждение авторства запросов из-за симметричности ключа).

RFC 2845 вводит новый тип записи TSIG (250) и несколько новых кодов ответа. Запись типа TSIG является виртуальной, т.е. вычисляется во время транзакции, не содержится в файле данных зоны и не кешируется. Запись добавляется в раздел дополнительных данных; включает имя разделяемого ключа, класс (ANY), TTL (0), имя алгоритма (сейчас всегда HMAC-MD5), время подписи, интервал отклонения времени, хеш, идентификатор исходного сообщения (используется при ретрансляции динамических изменений), код ошибки, дополнительный данные об ошибке (например, расхождение часов участников). Для генерации хеша используется исходное сообщение, имя ключа, класс, TTL, имя алгоритма, время подписи, интервал отклонения времени. При генерации хеша ответа в исходные данные включается также хеш запроса.

Динамические изменения зоны

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

• добавить запись ресурса (RR) в набор записей ресурсов (RRset); записи типа SOA и CNAME не добавляются, а замещаются; если SOA не было или её серийный номер был больше, то добавление игнорируется; попытка заменить нормальный набор записей на CNAME или CNAME на нормальный набор записей игнорируется; попытка добавить дублирующую запись игнорируется
• удалить запись ресурса (RR) с заданным значением из набора записей ресурсов (RRset); не удаляются последняя запись NS и SOA самой зоны; попытка удалить несуществующую запись игнорируется
• удалить набор записей ресурсов (RRset); не удаляются записи NS и SOA самой зоны; попытка удалить несуществующий набор игнорируется
• удалить все наборы ресурсов, относящиеся к указанному доменному имени; не удаляются записи NS и SOA самой зоны; попытка удалить несуществующий набор игнорируется

Набор изменений может быть предварён набором условий следующих типов (все доменные имена должны быть внутри зоны):

• указанное доменное имя имеет хотя бы одну запись ресурса указанного типа
• указанное доменное имя имеет записи ресурсов указанного типа с заданными значениями (значение TTL не учитывается, при сравнении имён прописные и строчные буквы не различаются, шаблоны не обрабатываются, синонимы (CNAME) не обрабатываются)
• указанное доменное имя не имеет ни одной записи ресурса указанного типа
• указанное доменное имя имеет хотя бы одну запись ресурса
• указанное доменное имя не имеет ни одной записи ресурса

есь пакет условий и изменений является атомарным, т.е. обрабатывается как единое неделимое целое (как транзакция в СУБД). При этом сервер обязан записать изменения на диск до ответа клиенту. bind временно записывает изменения в журнал и сливает его с файлом зоны позднее. Если изменения не затронули SOA, то сервер должен увеличить серийный номер автоматически. Метод стандартом не задаётся. Если автоувеличение серийного номера производится с задержкой, но она не должна быть более 300 секунд или 1/3 от времени обновления зоны.

RFC 2136 вводит новый класс NONE (254) и несколько новых кодов ответа. Формат запросов и ответов совпадает с форматом обычных запросов и ответов, но имеет код запроса – UPDATE (5). Секция запроса содержит имя изменяемой зоны (ровно одна запись ресурса типа SOA), секция ответа – набор условий, секция ссылок на уполномоченные сервера – добавляемые или удаляемые записи, секция дополнительной информации – связующие записи доменных имён вне зоны (может игнорироваться сервером).

Клиент может получить список потенциальных серверов из записей SOA, NS или внешними средствами.

Сервер может проверять право клиента на изменение зоны по его IP адресу (не рекомендуется) или при помощи механизма TSIG.

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

Обеспечение правильного порядка применения изменений (так чтобы “задержавшиеся в пути” старые изменения не перекрывали более новые) является нетривиальной задачей в среде TCP/IP, особенно при наличии нескольких делающих запросы клиентов и нескольких перенаправляющих вторичных серверов. Ответ сервера также может задержаться или затеряться. Авторы RFC рекомендуют пользоваться “маркерными” записями ресурсов для обеспечения синхронизации (такой маркер может, например, содержать время выдачи запроса).

DNS клиент (resolver)

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

Статья взята с сайта Bog BOS , автор Сергей Евгеньевич Богомолов.

Так, вот DNS — это одна из основополагающих вещей, на которых построена работа всего интернета. Это аббревиатура расшифровывается как Domain Name System, что в переводе означает доменная система имен .

Этого вопроса (устройства доменной системы имен) я уже касался, когда рассказывал о том, но только вскользь. Сегодня я хочу поговорить о роли ДНС-серверов в работе сайтов и всего интернета в целом.

Зачем нужны DNS-сервера и что это такое?

Система же доменных имен оперирует уже полноценными именами (буквы латиницы, цифры, тире и нижнее подчеркивание допускается при их формировании)..120.169.66 малоинформативен) и ими проще оперировать.

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

Вот именно на этих ДНС-серверах (иногда их еще называют NS от Name Server, т.е server имен ) и держится весь интернет (как плоский мир на трех китах, стоящих на черепахе). не требующий непосредственного участия человека в своей работе (настроили его — он и пашет в режиме 24 на 7). И таких DNS-серверов в сети очень много.

Как работает DNS и причем тут файл Hosts?

На заре интернета ДНС вообще не существовало. Но как же тогда работала сеть?.120.169.66? За это дело тогда (да и сейчас тоже) отвечал так называемый , где были прописаны все хосты тогда еще маленького интернета.

Такой файл находился (и сейчас находится) на каждом компьютере пользователя (на вашем тоже он есть) подключенного к сети (как его найти смотрите по приведенной выше ссылке).

В файле Hosts было прописано несколько тысяч строк (по числу сайтов в интернете на тот момент), в каждой из которых сначала был прописал IP адрес, а затем через пробел соответствующий ему домен. Вот так выглядела бы запись для моего блога, существуй он в сети лет так двадцать пять — тридцать назад:

109.120.169.66 сайт

Удачи вам! До скорых встреч на страницах блога сайт

посмотреть еще ролики можно перейдя на

");">

Вам может быть интересно

Сервер - что это такое
Покупка домена (доменного имени) на примере регистратора Reghouse WHOIS сервисы - информация о домене (чей он, каков его возраст и история, когда освобождается) или IP адресе
Файл Hosts - что это такое, где он находится в Windows, что с ним делать вебмастеру и как удалить из него записи вирусов
Проверка на занятость и покупка доменного имени, чем отличаются регистраторы и реселлеры доменов и что такое WHOIS Как зарегистрировать домен (купить доменное имя у регистратора)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 23:48, 28 ноября 2016.

DNS

Уровень (по модели OSI):	Прикладной
Семейство:	TCP/IP
Порт/ID:	53/TCP, 53/UDP
Назначение протокола:	Разрешение доменных имен
Спецификация:	RFC 1034 , RFC 1035 / STD 13
Основные реализации (клиенты):	Встроен во все сетевые ОС
Основные реализации (серверы):	BIND, PowerDNS или Microsoft DNS Server

DNS (англ. D omain N ame S ystem - система доменных имён) - компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста (компьютера или устройства), получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене (SRV-запись). Распределённая база данных DNS поддерживается с помощью иерархии DNS-серверов, взаимодействующих по определённому протоколу.

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

Пример структуры доменного имени

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

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

Уровни DNS

Дерево DNS принято делить по уровням: первый, второй, третий и так далее. При этом начинается система с единственного корневого домена (нулевой уровень). Интересно, что про существование корневого домена сейчас помнят только специалисты, благодаря тому, что современная DNS позволяет не указывать этот домен в адресной строке. Впрочем, его можно и указать. Адресная строка с указанием корневого домена выглядит, например, так: «site.test.ru.» – здесь корневой домен отделен последней, крайней справа, точкой. Как несложно догадаться, адреса с использованием DNS записываются в виде последовательности, отражающей иерархию имен. Чем «выше» уровень домена, тем правее он записывается в строке адреса. Разделяются домены точками. Разберем, например, строку www.site.nic.ru. Здесь домен www – это домен четвертого уровня, а другие упомянутые в этой строке домены расположены в домене первого уровня RU. Например, site.nic.ru – это домен третьего уровня. Очень важно понимать, что привычный адрес веб-сайта, скажем, www.test.ru, обозначает домен третьего уровня (www), расположенный внутри домена второго уровня test.ru.

Ключевые характеристики DNS

DNS обладает следующими характеристиками:

• Распределённость администрирования. Ответственность за разные части иерархической структуры несут разные люди или организации.
• Распределённость хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности, и (возможно) адреса корневых DNS-серверов.
• Кеширование информации. Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.
• Иерархическая структура , в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.
• Резервирование. За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделённые как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.

DNS важна для работы Интернета, так как для соединения с узлом необходима информация о его IP-адресе, а для людей проще запоминать буквенные (обычно осмысленные) адреса, чем последовательность цифр IP-адреса. В некоторых случаях это позволяет использовать виртуальные серверы, например, HTTP-серверы, различая их по имени запроса. Первоначально преобразование между доменными и IP-адресами производилось с использованием специального текстового файла hosts, который составлялся централизованно и автоматически рассылался на каждую из машин в своей локальной сети. С ростом Сети возникла необходимость в эффективном, автоматизированном механизме, которым и стала DNS. DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы содержится в RFC 882 и RFC 883 . В 1987 публикация RFC 1034 и RFC 1035 изменила спецификацию DNS и отменила RFC 882 , RFC 883 и RFC 973 как устаревшие.

Дополнительные возможности

• поддержка динамических обновлений
• защита данных (DNSSEC) и транзакций (TSIG)
• поддержка различных типов информации

Как работает DNS

Доменное имя содержит, как минимум, две части (обычно называются метками), разделённые точкой. Самая правая метка является доменом верхнего уровня (например, для адреса ru.wikipedia.org домен верхнего уровня - org). Каждая следующая метка справа налево является поддоменом (например, wikipedia.org - поддомен домена org, а ru.wikipedia.org - домена wikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения. Система DNS содержит иерархию серверов DNS. Каждый домен или поддомен поддерживается как минимум одним авторизированным сервером DNS, на котором расположена информация о домене. Иерархия серверов DNS совпадает с иерархией доменов.

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

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

Записи DNS

Записи DNS , или Ресурсные записи (англ. Resource Records, RR) - единицы хранения и передачи информации в DNS. Каждая ресурсная запись состоит из следующих полей:

• имя (NAME) - доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись,
• тип (TYPE) ресурсной записи - определяет формат и назначение данной ресурсной записи,
• класс (CLASS) ресурсной записи; теоретически считается, что DNS может использоваться не только с TCP/IP, но и с другими типами сетей, код в поле класс определяет тип сети,
• TTL (Time To Live) - допустимое время хранения данной ресурсной записи в кэше неответственного DNS-сервера,
• длина поля данных (RDLEN),
• поле данных (RDATA), формат и содержание которого зависит от типа записи.

Наиболее важные типы DNS-записей:

• Запись A (address record) или запись адреса связывает имя хоста с адресом протокола IPv4. Например, запрос A-записи на имя referrals.icann.org вернёт его IPv4-адрес - 192.0.34.164.
• Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.NET вернёт его IPv6-адрес - 2001:7fd::1.
• Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя.
• Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена.
• Запись NS (name server) указывает на DNS-сервер для данного домена.
• Запись PTR (point to reverse) или запись указателя связывает IP-адрес хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP-адрес хоста в reverse-форме вернёт имя (FQDN) данного хоста (см. Обратный DNS-запрос). Например (на момент написания), для IP-адреса 192.0.34.164 запрос записи PTR 164.34.0.192.in-addr.arpa вернёт его каноническое имя referrals.icann.org. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR-записи для хоста, с которого происходит отправка. В этом случае PTR-запись для IP-адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP-сессии.
• Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги (параметры времени) кеширования зонной информации и взаимодействия DNS-серверов.
• SRV-запись (server selection) указывает на серверы для сервисов, используется, в частности, для Jabber и Active Directory.

Зарезервированные доменные имена

Документ RFC 2606 (Reserved Top Level DNS Names - Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. Кроме example.com, example.org и example.net, в эту группу также входят test, invalid и др.

Интернациональные доменные имена

Доменное имя может состоять только из ограниченного набора ASCII-символов, позволяя набрать адрес домена независимо от языка пользователя. ICANN утвердил основанную на Punycode систему IDNA, преобразующую любую строку в кодировке Unicode в допустимый DNS набор символов.