Domain name service cлужба доменных имен


Содержание

8. СЛУЖБА ДОМЕННЫХ ИМЕН (DNS)

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

В бытность существования ARPANET соответствия между IP-адресами и их текстовыми эквивалентами хранились в файле hosts.txt. Ежесуточно все хосты получали этот файл, что обеспечивало актуальность (авторитетность) хранящихся в нем записей, и пока к сети было подключено несколько сотен машин, это было вполне приемлемым решением.

Но когда сеть разрослась до нескольких тысяч компьютеров, стало ясно, что этому механизму надо искать какую-то замену. В самом деле, размер файла становился слишком большим, а главное, в результате децентрализации неизбежно должны были возникнуть конфликты имен. Эту проблему была призвана решить служба доменных имен (Domain Name System, DNS).

Идея DNS состоит в разбиении всего адресного пространства на несколько непересекающихся зон (доменов), которые делятся на подзоны (поддомены).

Весь Интернет разделен на 200 доменов верхнего уровня, число которых постоянно увеличивается. Доменом называют множество хостов, объединенных в логическую группу. Каждый домен верхнего уровня подразделяется на поддомены, которые так же могут состоять из других доменов и т. д. (рис. 13,а).

Рис. 13. Служба доменных имен (DNS)

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

Обзор доменной службы имен DNS

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

В сетях TCP/IP компьютеры для общения между собой используют IP-адреса. Однако то, что удобно машинам, неудобно людям. Есть спорное мнение, что сама человеческая натура протестует против запоминания чисел типа 192.168.1.34 (что не мешает нам запоминать телефонные номера с кодом города и страны, типа 380-564-40-06-24). К тому же IP-адреса совсем не информативны. По IP-адресу невозможно понять, что это: сервер, ПК, маршрутизатор или сетевой принтер. Приятней работать с осмысленными именами, такими как account-server.

Тем не менее сетевые устройства обращаются друг к другу, используя IP-адрес, а не имена.

Решает эту проблему система именования сетевых объектов, которая отвечает за преобразование символьных имен в IP-адреса. Система именования выполняет функции телефонной книги, в которой каждому номеру телефона поставлена в соответствие запись о фамилии или названии фирмы. Системе передается имя (например archie.univie.ac.at), а она возвращает IP-адрес (140.78.3.8).

Системы именования сетевых объектов делятся на «плоские» и иерархические (доменные).

В «стародавние времена», когда Internet еще называлась ARPANET и Сеть состояла лишь из многотерминальных компьютеров типа мэйнфреймов (при этом их количество оставалось относительно невелико), была реализована система именования для одноуровневого (плоского) пространства имен. Ее также называют «плоской» системой именования. Каждый компьютер имел файл (обычно /etc/hosts) со списком IP-адресов хостов и их символьные имена. При появлении в Internet нового компьютера информация о нем заносилась в файл hosts, затем этот файл рассылался на все другие машины.

Недостатки такой схемы начали проявляться довольно быстро: с переходом от больших машин к персональным и с ростом Internet. Трафик, связанный с обновлением информации при добавлении компьютеров в Internet, грозил забить все линии связи. Кроме того, каждое имя в сети должно быть уникальным, а сделать это становится все труднее и труднее. Поэтому к середине 80-х годов появилась другая, более гибкая система именования — система имен доменов (Domain Name System, DNS).

DNS реализует иерархическое пространство имен. Единицей измерения является домен (территория, область). Понятие домена DNS не надо путать с доменом Windows NT или доменом NIS. Они не имеют друг к другу никакого отношения.

В DNS вся сеть представляется в виде единого иерархического дерева. На вершине располагается корневой домен (обозначается символом «.»). Ниже находятся домены первого уровня. Поскольку Internet развивался в первую очередь в США и за счет американских налогоплательщиков, это вызвало некоторый крен при формировании доменов первого уровня: Internet как бы оказался поделенным между США и всем остальным миром.

Наиболее известные домены первого уровня: com — коммерческие организации (главным образом в США); edu — учебные заведения США; gov — правительственные учреждения США; mil — военные учреждения США; net — различные сетевые агентства и Internet-провайдеры; int — международные организации; org — некоммерческие учреждения; код страны — двухбуквенный код для обозначения государства (ru — для России, ua — для Украины и т.п.). Ниже доменов первого уровня располагаются домены второго уровня и так далее вплоть до хостов. Для доменов первого уровня, обозначающих государства, доменами второго уровня часто бывают города или области (например, kiev — для Киева или dp -Днепропетровская область), а доменами третьего уровня — предприятия и организации.

Любой хост или домен в Internet однозначно идентифицируется так называемым полным доменным именем (Fully Qualified Domain Name, FQDN). Его иногда еще называют абсолютным доменным адресом. Домены в FQDN записываются справа налево в порядке подчинения и разделяются точками. Каждая отдельная составляющая FQDN называется меткой (label). Длина метки не должна превышать 63 символа, а полная длина FQDN — 255 символов.

Допустимыми символами являются буквы английского языка, цифры и знак дефиса «-» (знак дефиса не может стоять в начале или конце метки). Регистр букв значения не имеет, т. е. company1.krcrme.dp.ua. и COMPANY1.KRCRME.DP.UA. обозначают один и тот же домен.

Обратите внимание на конечную точку в полном доменном имени. Она обозначает, во-первых, корневой домен, и, во-вторых, что используется абсолютная адресация.

Кроме абсолютной применяется и относительная доменная адресация. Когда два устройства находятся в одном и том же домене, они могут обращаться друг к другу по имени, не указывая полного доменного пути. Так, host2 обращается к host1 двумя способами: по полному доменному имени host1.company1.krcrme.dp.ua. по относительному доменному адресу host1

В полном доменном имени конечную точку можно не ставить, поскольку обычно программное обеспечение TCP/IP подразумевает, что составное доменное имя (т.е. когда присутствует более двух меток) обозначает FQDN. Таким образом, company1.krcrme.dp.ua. и company1.krcrme.dp.ua суть одно и то же.

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

Как уже отмечалось, основное назначение DNS состоит в преобразовании имени хоста в его IP-адрес. На самом деле DNS является системой, не зависимой от протокола сетевого уровня, т. е. она может быть реализована не только в среде TCP/IP.

Однако функции DNS этим не ограничиваются. DNS позволяет получить следующую информацию:

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

Существует и ряд других, реже используемых параметров.

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

Программное обеспечение, которое общается с серверами имен, называют клиентом DNS (Resolver DNS). Клиент DNS выполняет роль посредника между сетевыми приложениями и серверами имен. При этом он, как правило, скрыт от пользовательских программ. Сетевые приложения используют клиент DNS чаще всего неявно, через функции стека TCP/IP. Однако приложение nslookup позволяет получить любую информацию из базы DNS. Клиент DNS входит в состав программного обеспечения TCP/IP. Но стек TCP/IP, по-мимо DNS, поддерживает и «плоскую» систему именования (через файл hosts). Это позволяет обеспечить работоспособность сетевых устройств при проблемах с DNS (например при отсутствии связи с сервером имен). Клиент DNS может функционировать как на отдельном компьютере, так и на сервере имен.

Сервер имен на самом деле отвечает не за домен, а за так называемую зону управления (Zone of Authority), в которую могут входить несколько смежных доменов. Более того, сервер имен способен управлять несколькими, причем не обязательно смежными, зонами одновременно.

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

Время, в течение которого информация хранится в кэше, определяется источником информации и обычно составляет от десятков минут до нескольких суток.

Кэширование позволяет уменьшить трафик в сети, а также снизить нагрузку на серверы имен.

Серверы имен бывают нескольких типов. Первичный сервер имен (Primary Name Server) хранит на своих дисках главные файлы (master files), в которых содержится вся информация о зонах управления данного сервера. Эти файлы загружаются в память сервера имен при его запуске.

Вторичный сервер имен (Secondary Name Server) используется как дубликат первичного сервера, что обеспечивает отказоустойчивость DNS. Он загружает информацию с первичного сервера и затем периодически ее обновляет, посылая первичному серверу запросы.

Серверы «только для кэширования» (Cache-Only Server) записывают в кэш информацию, полученную от других серверов имен. Чаще всего они используются в больших сетях для разгрузки первичного сервера.

Это, однако, еще не все типы серверов имен, но оставшиеся (серверы Forwarder и Slave Forwarder) имеют лишь незначительные отличия в обработке информации DNS.

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

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

Серверам имен других зон передается только конкретная информация (а не данные по всей зоне) и только по их запросам.

Таким путем удалось резко снизить в Internet трафик, связанный с преобразованием имен в IP-адреса.

Серверы имен могут работать в двух режимах: нерекурсивном и рекурсивном.

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

Таким образом, в нерекурсивном режиме клиент сам осуществляет все запросы к серверам имен.

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

Чтобы работать в рекурсивном режиме, сервер и клиент должны быть настроены соответствующим образом. Однако в большинстве случаев пользователь не имеет возможности менять настройку режима работы клиента, поскольку она «зашита» в программное обеспечение TCP/IP.

Рекурсивный режим применяется реже нерекурсивного, так как нагрузка на серверы имен в этом случае значительно возрастает. Да и для клиента такой режим не оптимален, ибо в случае задержки ответа ему трудно определить, что произошло: сбой на линии или просто опрашивается очень длинная цепочка серверов имен.

Сервисы DNS в AIX

Все сервисы доменного именования полностью реализованы в AIX. Поддерживаются следующие типы серверов имен:

1. Первичный сервер имен;
2. Вторичный сервер имен;
3. Сервер «только для кэширования»;
4. Сервер Forwarder;
5. Удаленный сервер.

Клиент DNS в AIX, gethostbyaddr() и gethostbyname(), пытается определить имена ис-пользуя следующую процедуру:

Если файл /etc/resolv.conf не существует, клиент DNS считает, что в сети используется плоская система именования. Тогда он использует для определения имен файл /etc/hosts.

В обратном случае, клиент DNS считает локальную сеть доменной сетью и пытается использовать для определения имени нижеследующие источники в показанном ниже порядке:

1. Сервер DNS;
2. Локальный файл /etc/hosts.

Функции сервера имен в AIX выполняет демон named. Он контролируется посредством AIX SRC (system resource control). Этот демон может стартовать автоматически при каждом перезапуске системы используя команду smit stnamed или если будет отредактирован файл rc.tcpip убрав комментарий в сроке #start /etc/named «$src_running» Демон named стартует также при команде startsrc -s named.

Хост AIX конфигурируется для использования сервера имен используя следующие шаги:

1. Создайте файл /etc/resolv.conf включив в него имя домена и адреса до 16-ти серверов имен. Например:

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

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

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

2. Создайте файл /etc/named.boot для определения имени и типа локального демона named.

3. Создайте файлы /etc/named.* для определения требуемых для демона данных. Формат этих файлов должен соответствовать формата записей стандартных ресурсов (Standard Resource Record Format).

Демон named в AIX также поддерживает записи ресурсов для почты типа MB (mailbox domain name), MR (mail rename domain name), MG (mail group member), MINFO (mailbox or mail list information) и MX (mail exchange).

Приложения пользователя AIX/6000 включает в себя программы host и nslookup. В AIX/6000 также можно воспользоваться программой dig для запросов к серверам имен.

Настройка клиентской части

Как уже было отмечено, программное обеспечение TCP/IP одновременно поддерживает и клиента DNS, и файл hosts. Содержимое файла /etc/resolv.conf мы рассмотрели уже выше. Файл hosts отвечает за «плоскую» систему именования. Местонахождение этого файла зависит от операционной системы (AIX — /etc/hosts, DOS и Windows — ETC\HOSTS, NetWare — SYS:\ETC\HOSTS).

Формат его очень прост: он состоит из строк, каждая из которых определяет один хост: [ . ]

Обратите внимание, что файл hosts может содержать имена в доменном формате.

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

Среди администраторов сетей бытует мнение, что DNS следует использовать только при наличии подключения к Internet. Но DNS позволяет упростить администрирование локальных сетей TCP/IP независимо от того, имеют они выход в Internet или нет. При отсутствии DNS добавление компьютера в локальную сеть приводит к тому, что в файл hosts каждого хоста необходимо ввести информацию о новом компьютере. Это нетрудно, если машин в сети немного. А если их десятки или сотни? При использовании DNS вся процедура сводится к добавлению одной-двух строк в файлы базы DNS на первичном сервере имен. После этого хосты сети будут распознавать новый компьютер по имени автоматически. Если по каким-либо причинам необходимо изменить IP-адрес или имя хоста, то с DNS сделать это довольно просто. Кроме того, использование DNS значительно облегчает процедуру подключения корпоративной сети к Internet.

Стандарты DNS

Настройка базы DNS задается в специальных текстовых файлах на серверах имен. Форматы записей в этих файлах регламентируются стандартами, изложенными в документах RFC (Request For Comments). Они разрабатываются «законодательным» органом Internet — IETF (Internet Engineering Task Force). Однако сам набор файлов и порядок их загрузки на серверах имен RFC не регламентируется. Для этого существует стандарт de facto под названием BIND (Berkley Internet Name Domain). Данная спецификация была разработана в университете Беркли и впервые реализована в BSD Unix. Подавляющее большинство серверов имен поддерживают спецификацию BIND.

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

В общем случае порядок запуска серверов имен следующий: сначала создаются файлы базы DNS (напрямую или через административные утилиты), а затем запускается сервис DNS (в AIX — демон named).

Формат записей в файлах базы DNS

В файлах базы DNS серверов имен используется так называемый формат записи стандартных ресурсов (Standard Resource Record Format). Выглядит этот формат следующим образом:


Каждая составляющая здесь является полем записи и отделена от других пробелами или знаками табуляции.

— имя описываемого ресурса. Оно зависит от поля и может обозначать домен, зону управления, имя хоста и т. д. Если поле пустое, то в качестве него используется последнее заданное поле (в предыдущих записях).

— время жизни (в секундах). Определяет, как долго клиент DNS будет хранить запись в кэш-памяти. Если данное поле пустое, то в качестве берется значение поля , задаваемое в записи SOA (см. ниже).

описание класса используемых протоколов. Для Internet (TCP/IP) значение этого поля — IN. Если поле пустое, то в качестве него используется последний заданный класс.

— поле, задающее тип ресурса записи. Возможные значения этого поля приведены в разделе «Типы ресурсов».

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

Следующие символы в записях имеют специальное значение (ниже перечислены некоторые из этих символов).

. Отдельно стоящая точка в поле обозначает текущий домен.

@ Отдельно стоящий символ «@» в поле обозначает текущий исходный домен.

( ) Скобки используются для размещения поля на нескольких строках (когда поле занимает несколько строк).

* Метасимвол. Заменяет любой набор символов.

; Символ комментария. От этого символа и до конца строки информация игнорируется.

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

Типы ресурсов

Тип ресурса задается в поле записи ресурса. Типов ресурсов множество. Полный их список можно узнать в соответствующих RFC (см. «Дополнительную информацию»). Ниже приводятся наиболее используемые типы.

· SOA Начало полномочий (управления) сервера имен.
· NS Сервер имен.
· A Адрес хоста.
· CNAME Каноническое имя. Используется для задания псевдонимов.
· HINFO Информация о хосте.
· MX Почтовый шлюз.
· PTR Указатель.

Рассмотрим каждый из этих типов.

SOA (начало полномочий)

Запись с ресурсом типа SOA обозначает начало зоны управления сервера имен. Зона управления действует до следующей записи SOA.

ПРИМЕР ЗАПИСИ SOA

Здесь поле является составным и включает поля ,

Обозначает имя домена зоны управления.

Имя первичного сервера имен зоны.

Почтовый ящик лица, ответственного за зону. Данное поле формируется аналогично электронному адресу, но вместо символа «@» ставится точка (т. е. alex@komtek.dp.ua заменяется на alex.komtek.dp.ua).

Номер версии зоны. Когда производятся изменения в зоне, то это число необходимо увеличить. Именно по данному полю ориентируется вторичный сервер имен, определяя необходимость обновления информации по зоне.

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

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

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

Значение TTL в записях ресурсов данной зоны по умолчанию, т. е. когда поле пустое.

NS (сервер имен)

Запись с ресурсом типа NS обозначает имя хоста, являющегося первичным сервером имен для домена.

ПРИМЕР ЗАПИСИ NS

обозначает домен, а — имя сервера имен. В примере показывается, что серверы srv1.komtek.dp.ua и srv2.komtek.dp.ua представляют собой серверы имен домена komtek.dp.ua.

A (адрес)

Запись с ресурсом типа A служит для задания сетевого адреса хоста. Здесь — доменное имя хоста, а — его IP-адрес.

ПРИМЕР ЗАПИСИ A

sri-nic.arpa. A 10.0.0.51

CNAME (каноническое имя)

Запись с ресурсом типа CNAME применяется для указания псевдонима хоста. обозначает псевдоним, а — официальное (каноническое) имя хоста.

ПРИМЕР ЗАПИСИ CNAME

HINFO (информация о хосте)

Запись с ресурсом типа HINFO служит для хранения информации о хосте, в частности об аппаратной платформе и операционной системе компьютера.

Поле обозначает доменное имя хоста, — аппаратную платформу, — ОС хоста. Значения полей и стандартизированы, их следует брать из RFC 1700.

ПРИМЕР ЗАПИСИ HINFO

MX (почтовый шлюз)

Так как не на всех хостах запущен сервер e-mail, то для отдельных хостов или всего домена запись с ресурсом типа MX позволяет определить почтовый шлюз — компьютер, куда будет направляться электронная почта, предназначенная для этих хостов. Поле обозначает домен или имя хоста, для которого устанавливается почтовый шлюз. — имя хоста почтового шлюза. задает приоритет доставки, при этом ноль означает самый высокий приоритет.

В примере показано, что если почта предназначена для домена komtek.dp.ua, то она доставляется на машину unix1.komtek.dp.ua. Если же почта предназначена для любого компьютера домена, имя которого оканчивается на -dos, то она направляется на unix2.komtek.dp.ua.

ПРИМЕР ЗАПИСИ MX

Таким образом, письмо, отправленное по адресу:

1. alex@komtek.dp.ua, переадресуется alex@unix1.komtek.dp.ua;
2. vad@pc-dos.komtek.dp.ua, переадресуется vad@unix2.komtek.dp.ua;
3. dba@host1.komtek.dp.ua, попадет к dba@host1.komtek.dp.ua.

Если администратор определяет несколько записей MX, то для указания порядка опроса почтовых шлюзов используется число (в примере — 10) первым опрашивается шлюз с меньшим числом.

PTR (указатель)

Прежде чем рассматривать записи с ресурсом типа PTR, следует остановиться на поиске доменного имени хоста по его IP-адресу (так называемое обратное преобразование).

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

Для того чтобы облегчить эту задачу, в пределах общей доменной структуры был создан вспомогательный домен. Он имеет специальное название IN-ADDR.ARPA. Внутри этого домена существуют поддомены для каждой IP-сети. Имена этих поддоменов основаны на сетевых адресах, причем байты (октеты) IP-адресов представлены в обратном порядке.

Например, сеть cso.uiuc.edu имеет сетевой адрес 128.174 (вернее, 128.174.0.0, это IP-сеть класса B). Внутри этой сети имеется хост vmd.cso.uiuc.edu с IP-адресом 128.174.5.98. Тогда для всей сети вспомогательный домен будет 174.128.in-addr.arpa. Имя хоста в этом домене будет 98.5.174.128.in-addr.arpa.

Ресурсы с записью типа PTR служат для отображения этих специальных доменных имен в обычные. Поле обозначает специальное доменное имя (в домене IN-ADDR.ARPA), а поле — официальное доменное имя хоста.

ПРИМЕР ЗАПИСИ PTR ДЛЯ ХОСТА

Вспомогательный домен IN-ADDR.ARPA используется также для указания шлюза (маршрутизатора) для сетей. Шлюз представляет собой хост, соединяющий несколько IP-сетей. Для него существуют обычные записи PTR хоста, но, кроме того, имеются специальные записи PTR, представляющие IP-сети целиком. Эти записи включают только первые 1, 2 или 3 байта (октета) IP-адреса сети в зависимости от класса IP-сети (A, B или C).

Допустим, имеется шлюз gw.komtek.dp.ua, объединяющий сети класса A, B и C и имеющий соответствующие IP-адреса: 12.2.0.7, 129.14.1.3 и 194.140.13.2. Ниже представлены записи A и PTR для данного шлюза.

ПРИМЕР ЗАПИСЕЙ PTR И A ДЛЯ ШЛЮЗА

Спецификация BIND

Как уже отмечалось, стандартом de facto в описании состава файлов DNS и порядка их загрузки на сервере имен является спецификация BIND. Она поддерживается во всех Unix-системах, в NetWare (программные продукты Novell NFS Services, FTP Services, NetWare/IP) и ряде других систем.

Согласно данной спецификации существует файл загрузки базы DNS. В Unix-системах обычно это файл /etc/named.boot, в NetWare — SYS:ETC\NAMED.CFG, который загру-жается при запуске сервиса DNS на сервере имен.

Основное назначение файла загрузки — указывать, где расположены файлы базы DNS, а также адреса серверов имен. При любом изменении как файла загрузки, так и файлов базы DNS сервис DNS необходимо перезапускать.

Файл загрузки базы DNS является текстовым и состоит из отдельных записей. Наиболее часто используются следующие записи:

Устанавливает каталог хранения файлов базы DNS, если не указаны абсолютные пути к файлам. Пример: directory /etc

2. domain Определяет домен по умолчанию для данного сервера имен. Пример: domain komtek.dp.ua

3. primary Показывает, что сервер имен является первичным для домена и что база домена хранится в файле . Пример: primary komtek.dp.ua /usr/named.data

Илон Маск рекомендует:  Что такое код pg_host

4. secondary [ . ] Указывает, что данный сервер имен является вторичным для домена . Первичные серверы расположены по IP-адресам , и т. д. Данный вторичный сервер запрашивает по порядку первичные серверы и копирует полученную с первого ответившего первичного сервера информацию в файл . Пример: secondary komtek.dp.ua 192.168.1.3 named.bak

5. cache Указывает, что данный сервер является кэш-сервером имен для домена . Параметры кэш-сервера (прежде всего адреса и имена серверов имен корневого домена) считываются из файла . Пример: cache . named.ca

6. Строка, начинающаяся с символа «;», считается комментарием. Кстати, для обозначения полного доменного имени в файле загрузки ставить точку в конце имени не обязательно: здесь все имена считаются полными.

Пример реализации DNS в локальной сети

Подводя итоги, рассмотрим пример настройки DNS на серверах имен типичной локальной сети TCP/IP. В примере принято, что локальная сеть подключена к Internet. В то же время показываются настройки, когда локальная сеть не имеет выхода в Internet. IP-адреса сетей и хостов, а также доменные имена вымышленные и приведены лишь для простоты понимания.

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

Если локальная сеть не имеет выхода в Internet, то IP-адреса и доменные имена можно выбрать по своему усмотрению. Если в дальнейшем возникнет потребность подключения к Internet, то перестроить DNS не составит труда.

Рассматриваемая локальная сеть состоит из двух IP-сетей класса C: 194.170.12.0 и 194.170.13.0. Допустим, эти сети образуют один домен komtek.dp.ua.


IP-сети объединяют шлюз (маршрутизатор) gw с адресами: 194.170.12.1 и 194.170.13.4. Подключение к Internet также происходит через данный шлюз.

В домене имеется первичный сервер имен srv1 (194.170.12.2) и вторичный сервер имен srv2 (194.170.13.3), а также ряд хостов: host1, host2, host3.

Хост mail (194.170.13.2) является почтовым шлюзом для всего домена, к тому же у него есть псевдоним host4.

Ниже представлены состав и содержимое базы DNS для первичного сервера имен srv1.komtek.dp.ua и для вторичного сервера srv2.komtek.dp.ua.

СОСТАВ И СОДЕРЖИМОЕ БАЗЫ DNS НА ПЕРВИЧНОМ СЕРВЕРЕ SRV1

СОСТАВ И СОДЕРЖИМОЕ БАЗЫ DNS НА ВТОРИЧНОМ СЕРВЕРЕ SRV

Как для первичного, так и для вторичного сервера имен, в случае если локальная сеть не имеет выхода в Internet, следует убрать строку cache в файле /etc/named.boot и удалить файл /etc/named.ca.

Об именах и адресах серверов имен корневого домена, перечисленных в файле /etc/named.ca, необходимо справиться у Internet-провайдера. Кроме того, Internet-провайдер должен внести данные о серверах имен srv1.komtek.dp.ua и srv2.komtek.dp.ua в свою базу DNS, чтобы обеспечить доступ из Internet к машинам домена komtek.dp.ua.

Вспомогательный домен 0.0.127.in-addr.arpa, а также хост localhost (127.0.0.1) в каждой из зон необходимы для создания локальной «петли» TCP/IP.

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

Служба доменных имен (DNS)

Ежедневно для получения доступа к услугам, доступным по сети Интернет, мы обращаемся к тысячам серверов, расположенных в различных географических точках.

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

Было бы невозможно запомнить все IP-адреса всех серверов, предоставляющих различные услуги по сети Интернет. Вместо этого предлагается более простой способ поиска серверов – сопоставить имя с некоторым IP-адресом.

Служба доменных имен ( DNS ) позволяет использовать имя узла для запроса IP-адреса отдельного сервера. Регистрация и организация имен в этой системе выполняется по специальным высокоуровневым группам, именуемым доменами. К числу наиболее популярных высокоуровневых доменов сети Интернет относятся .com, .edu и .net.

В DNS-сервере записана специальная таблица, ассоциирующая имена узлов в домене с соответствующим IP-адресом. Если клиент знает имя сервера, например, веб-сервера, но требуется найти IP-адрес, он направляет запрос на этот DNS-сервер через порт 53. Клиент использует этот IP-адрес DNS-сервера, прописанного в настройках DNS раздела конфигурации IP этого узла.

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

Процесс определения IP-адреса по DNS-протоколу из клиентского программного обеспечения достаточно прост и прозрачен для пользователя.

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

Содержание

1. Введение

Корневое имя (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. Пространство доменных имен

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

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

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

2.1.2. Домены

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заметим, что когда читается доменное имя из домена 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)

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

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

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

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

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

Поля заголовка имеют следующие значения:
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. Формат секции запроса

Поля имеют следующие значения:
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. Формат записи о ресурсе

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

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

Для уменьшения размера сообщений доменная система применяет схему сжатия, которая исключает повторение доменных имен в сообщении. В этой схеме все доменное имя или список меток на конце доменного имени заменяется указателем на такое же имя, встреченное ранее в этом сообщение.
Указатель имеет длину 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. Передача сообщений

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

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

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

8.3. Алгоритм

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

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. Кэширование отрицательных ответов

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

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

9.1. Выбор типа

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

;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. Файлы данных записей о ресурсе

[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 определяет новое начальное доменное имя для всех последующих имен. $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. Пример

Файл кеша /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. Настройка решающей программы

Основные ключевые слова, которые используются в конфигурационном файле /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

Илон Маск рекомендует:  Что такое код getcurrentposition

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

11.1. Nslookup

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

# Получить адресную информацию для имени 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 @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».

Основы работы со службой DNS

Общая информация

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

Бесплатный DNS-хостинг

  • Надёжные DNS-сервера
  • Автоматическая миграция
  • API

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

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

DNS обеспечивает преобразование запрашиваемого клиентом символьного имени домена в IP-адрес (адреса) обслуживающего эту доменную зону сервера (серверов). Изначально, до разрастания сети интернет, адреса преобразовывались согласно содержимому файла «hosts», составлявшегося централизованно и автоматически рассылавшегося на каждую из машин в сети. По мере роста глобальной сети такой метод перестал оправдывать себя — появилась потребность в новом механизме, которым и стала DNS, разработанная в 1983 году Полом Мокапетрисом.

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

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

Иерархия и делегирование доменных имен

Домен представляет собой именованную ветвь в дереве имен, включающую в себя сам узел (напр., домен первого уровня «.com»), а также подчиненные ему узлы (напр., домен второго уровня «example.com», домен третьего уровня «mail.example.com» и т.д.). Для обозначения иерархической принадлежности доменных имен принято использовать понятие «уровень» — показатель положения узла в дереве доменов. Чем ниже значение уровня, тем выше иерархическое положение домена

  • «.» — домен нулевого уровня
  • «.ru» — домен первого (верхнего) уровня
  • «example.com» — домен второго уровня
  • «mail.example.com» — домен третьего уровня
  • Этот список можно продолжать

Обратите внимание на домен нулевого уровня «.» (dot — точка), также называемый корневым. На практике точку обычно не указывают («example.com» вместо «example.com.»), т.е. указание корневого домена не является обязательным условиям разрешения IP-адреса. Большинство клиентских программ (интернет-браузеров и т.д.) добавляют домен нулевого уровня автоматически и не отображают его пользователю. Доменное имя, не включающее обозначение домена нулевого уровня называется относительным, включающее же точку на конце — полностью определенным (FQDN — Fully Qualified Domain Name).

Доменная зона — часть иерархического дерева доменных имен (напр. «.ru»), целиком переданная на обслуживание определенному DNS-серверу (чаще нескольким) с целью делегирования другому лицу ответственности за этот и все подчиненные домены («anyaddress.ru», «any.anyaddress.ru»).

Делегирование — передача ответственности за определенную ветвь дерева доменных имен другому физическому или юридическому лицу. Именно эта процедура практически реализует важный принцип работы DNS — распределенность хранения записей и обработки запросов. Сам процесс делегирования представляет собой добавление в ресурсные записи родительской зоны («.ru»), так называемых «склеивающих» («glue») NS-записей для делегируемой дочерней зоны («example.com»), указывающих на DNS-сервера принимающей домен стороны (например, DNS-сервера нашей компании). С этого момента все ресурсные записи домена второго уровня «example.com» и всех его дочерних доменов (например, «mail.example.com» и т.д.) хранятся на DNS-серверах этой компании, а родительская зона «.ru» хранит только указывающие на эти сервера NS-записи.

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

DNS-клиент — набор программных средств для работы с DNS. Сам DNS-сервер периодически также выступает в качестве клиента.

Основные типы ресурсных записей

Ресурсная запись (RR — Resource Record) — единица хранения и передачи информации в DNS, включающая в себя следующие элементы (поля):

  • Имя (Name) — имя домена, к которому относится запись
  • TTL (Time To Live) — допустимое время хранения записи неответственным сервером
  • Тип (Type) — параметр, определяющий назначение и формат записи в поле данных (Rdata)
  • Класс (Class) — тип сети передачи данных (подразумевается возможность DNS работать с типами сетей, отличных от TCP/IP)
  • Длина поля данных (Rdlen)
  • Поле данных (Rdata) — содержание и формат поля зависят от типа записи

Ниже представлены типы ресурсных записей, используемые чаще всего:

  • A (IPv4 Address Record — адресная запись) — связывает доменное имя с IPv4-адресом хоста
  • AAAA (IPv6 Address Record) — связывает доменное имя с IPv6-адресом хоста (аналогично А-записи)
  • CNAME (Canonical Name Record — каноническая запись имени) — используется для перенаправления на другое доменное имя
  • MX (Mail Exchange — почтовый обменник) — ссылается на почтовый сервер, обслуживающий домен
  • NS (Name Server — сервер имен) — ссылается на DNS-сервер, ответственный за домен
  • TXT — текстовое описание домена. Зачастую требуется для выполнения специфических задач (например, подтверждения права собственности на домен при привязке его к почтовому сервису)
  • PTR (Point to Reverse — запись указателя) — связывает ip-адрес машины с доменом, используется преимущественно для проверки сторонними почтовыми сервисами отправляемых через эту машину электронных писем на отношение к домену, указанному в параметрах почтового сервера. При несоответствии этих параметров письмо проверяется более тщательно по другим критериям.

Рекурсивные и нерекурсивные DNS-запросы

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

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

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

Введение в терминологию, элементы и понятия DNS

Введение

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

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

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

Терминология доменов

Мы должны начать с определения терминов. Хотя некоторые из этих тем могут быть вам знакомы из других сфер, есть много других терминов, используемых в разговоре о доменных именах и DNS, которые не слишком часто используются в других компьютерных областях. Давайте начнем с простого:

Система доменных имен

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

Доменное имя

Доменное имя это удобная для человека форма имени, которую мы привыкли ассоциировать с интернет-ресурсом. Например, «google.com» является доменным именем. Некоторые скажут, что часть «Google» является доменом, но в целом мы можем считать эту комбинированную форму доменным именем.

URL-адрес «google.com» соединен с сервером, находящимся в собственности Google Inc. Система доменных имен позволяет нам соединиться с сервером Google при вводе «google.com» в браузере.

IP-адрес

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

IPv4, наиболее распространенная форма адресов, записывается в виде четырех наборов цифр, каждый набор содержит до трех цифр, разделенных точкой. Например, «111.222.111.222» может считаться правильным IPv4 IP-адресом. С помощью DNS мы соединяем имя с этим адресом и избавляем себя от необходимости запоминать сложный набор цифр для каждого места посещения в сети.

Домен верхнего уровня

Домен верхнего уровня, или TLD, это самая общая часть домена. Является последней частью доменного имени справа (отделен точкой). Распространенными доменами верхнего уровня считаются «com», «net», «org», «gov», «edu» и «io».

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

Узел

В пределах домена его владелец может определять собственные узлы, которые ссылаются на отдельные компьютеры или услуги, доступные через домен. Например, большинство владельцев доменов делают свой веб-сервер доступным через корневой домен (example.com), а также через «узел», определенный как «www» (www.example.com).
У вас могут быть другие определения узлов под общим доменом. Вы можете иметь API доступ через «api» узел (api.example.com) или FTP доступ, обозначив узел «FTP» или «files» (ftp.example.com или files.example.com). Имена узлов могут быть произвольными, при условии, что они являются уникальными для данного домена.

Поддомен

Объект, связанный с узлами, называется поддомен.
DNS работает в иерархии. Домены верхнего уровня могут иметь множество доменов под ними. Например, домен верхнего уровня «com» включает в себя «google.com» и «ubuntu.com». Поддомен это домен, который является частью домена более высокого уровня. В этом случае можно сказать, что «ubuntu.com» явлется поддоменом «com». Как правило, он называется просто доменом или часть «Ubuntu» называется SLD, что означает домен второго уровня.

Точно так же каждый домен может контролировать «поддомены», которые находятся под ним. Например, у вас мог бы быть поддомен для отдела истории в вашей школе по адресу «www.history.school.edu». В этом случае часть «history» считается поддоменом.
Разница между именем узла и поддомена в том, что узел указывает на компьютер или ресурс, в то время как поддомен расширяет родительский домен.

Читая о поддоменах или узлах, вы можете заметить, что самый левые части доменов наиболее конкретные. Это объясняет работу DNS: от наиболее конкретного к наименее конкретному, так как вы читаете слева направо.

Полностью определенное имя домена

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

Это означает, что он указывает на каждый родительский домен, включая TLD. Правильный FQDN заканчивается точкой, указывая на корень иерархии DNS. Примером FQDN является «mail.google.com.». Иногда программное обеспечение, которое запрашивает FQDN, не нуждается в точке на конце, но завершающая точка требуется для соответствия стандартам ICANN.

DNS-сервер

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

DNS-сервера могут быть «авторитетными», что означает, что они предоставляют ответы на запросы о доменах под своим контролем. В противном случае они могут указать на другие серверы или предоставить кэшированные копии данных других DNS-cерверов.

Файл зоны

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

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

Ресурсные записи

Записи хранятся в пределах файла зоны. В своей простейшей форме запись это простое соединение между ресурсом и именем. Эти записи могут соединять имя домена с IP-адресом, определять DNS-серверы и почтовые серверы для домена и т.д.

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

Теперь, когда вы знакомы с некоторой терминологией, связанной с DNS, возникает вопрос, как действительно работает система?

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


Корневые серверы DNS

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

В настоящее время 13 корневых серверов находятся в эксплуатации. Тем не менее, так как каждую минуту появляется немыслимое количество имен для преобразования, каждый из этих серверов имеет зеркало. Интересно, что все зеркала для одного корневого сервера делят один IP-адрес. Когда выполняется запрос к определенному серверу, он будет перенаправлен к ближайшему зеркалу этого корневого сервера.

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

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

Таким образом, если запрос «www.wikipedia.org» производится в корневой сервер, то он ответит, что не может найти результат в своих записях. Он проверит свои файлы зоны на наличие соответствий «www.wikipedia.org». И также не найдет их.
Вместо этого он найдет запись для домена верхнего уровня «org» и предоставит запрашивающему адрес DNS-сервера, отвечающего за адреса «org».

TLD Серверы

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

Продолжая наш пример, запрос был бы отправлен на DNS-сервер, отвечающий за информацию о домене «org», чтобы проверить, есть ли у него информация о том, где находится «www.wikipedia.org».
Опять же запрашивающий будет искать «www.wikipedia.org” в своих файлах зоны. И не найдет эту запись в своих файлах
Тем не менее он найдет запись с упоминанием IP-адреса DNS-сервера, ответственного за «wikipedia.org». И это приближает нас гораздо ближе к результату.

DNS-сервер на уровне домена

На этом этапе у запрашивающего есть IP-адрес DNS-сервера, который хранит информацию о фактическом IP-адресе ресурса. Он отправляет новый запрос на DNS-сервер с уточнением, может ли он предоставить «www.wikipedia.org».

DNS-сервер проверяет свои файлы зоны и обнаруживает, что у него есть файл зоны, соотносящийся с «wikipedia.org». Внутри этого файла находится запись для «WWW» узла. Эта запись указывает IP-адресу, где находится этот узел. DNS-сервер возвращает окончательный ответ на запрос.

Что такое публичный DNS-сервер?

В приведенном выше сценарии мы ссылались на «запрашивающего”. Что же это может значить?

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

Как правило, пользователь будет иметь несколько публичных DNS-серверов, настроенных на их компьютерной системе. Публичные DNS-серверы обычно предоставляются ISP или другими организациями. Например, Google предоставляет публичные DNS-сервера, которые вы можете запросить. Они могут быть настроены на вашем компьютере автоматически или вручную.

При вводе URL в адресной строке браузера ваш компьютер прежде всего проверяет, может ли он найти, где находится ресурс, на локальном уровне. Он проверяет «узлы» файлов на компьютере и других местах. Затем он отправляет запрос на публичный DNS-сервер и ожидает получить обратно IP-адрес ресурса.
Затем публичный DNS-сервер проверяет свой кэш на наличие ответа. Если он не найдет то, что необходимо, он проделает шаги, указанные выше.

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

Файлы зоны

Мы уже упоминали в перечисленных выше процессах «файлы зоны» и «записи».

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

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

Параметр зоны $ORIGIN эквивалентен высшему уровню полномочий в зоне по умолчанию.
Таким образом, если файл зоны используется для настройки домена «example.com.», то параметр $ORIGIN также будет установлен для этого домена.

Это настраивается на верхнем уровне файла зоны или может быть указано в настройках файла DNS-сервера, который ссылается на файл зоны. В любом случае этот параметр описывает то, за что зона будет ответственна.

Точно так же $TTL настраивает «время жизни» информации, которую он предоставляет. По сути, это таймер. Кэширующий DNS-сервер может использовать ранее запрошенные результаты для ответа на вопросы, пока заданное значение TTL не истечет.

Типы записи

В файле зоны может быть множество различных типов записей. Мы рассмотрим некоторые из наиболее распространенных видов (или обязательных) ниже.

Записи SOA

Начальная запись зоны или SOA (Start of Authority) — обязательная запись для всех файлов зоны. Она должна быть первой записью в файле (хотя $ORIGIN или $TTL могут появиться выше). Она также является одной из самых сложных для понимания.

Начальная запись зоны выглядит примерно так:

Поясним, что означает каждая часть:

  • domain.com.: Это корень зоны. Он указывает, что файл зоны относится к домену domain.com.domain. Часто вы будете видеть, что он заменен на “@”, что является только заполнителем, который замещает содержимое переменной $ORIGIN, о которой мы узнали выше.
  • In SOA: Часть «In» означает Интернет (и будет присутствовать во многих записях). SOA является показателем того, что это начальная запись зоны.
  • ns1.domain.com.: Эта часть определяет мастер-сервер для этого домена. DNS-сервер может быть либо мастером, то есть первичным, либо слейв, или вторичным.
  • admin.domain.com.: Это электронный адрес администратора этой зоны. Символ «@» заменяется точкой в ​​адресе электронной почты. Если в части имени email адреса обычно стоит точка, это означает замену символа «\» в этой части (your.name@domain.com становится your\name.domain.com).
  • 12083: Это серийный номер файла зоны. Каждый раз, когда вы редактируете файл зоны, необходимо увеличивать это число. Слейв серверы проверят, если серийный номер мастер сервера для зоны больше, чем тот, который находится у них в системе. Если это так, то сервер запросит новый файл зоны, а если нет, то он продолжит обслуживать исходный файл.
  • 3h: Это интервал обновления для зоны. Это количество времени, которое слейв сервер будет ждать прежде, чем запросит у мастер сервера изменение файла зоны.
  • 30m: Это интервал повтора для этой зоны. Если слейв сервер не может подключиться к мастеру, когда наступает период обновления, он будет ждать данное количество времени, а после повторит запрос мастер серверу.
  • 3w: Это период истечения. Если слейв DNS-сервер не смог связаться с мастер сервером в течение этого периода времени, он больше не будет возвращать запросы к авторитетному источнику этой зоны.
  • 1h: Это количество времени, которое DNS-сервер будет кэшировать ошибку, если не сможет найти запрашиваемое имя в файле.

А и AAAA записи

Обе эти записи соединяют узел с IP-адресом. «А» запись используется для соединения узла с IPv4 IP-адреса, в то время как запись “AAAA» используется для соединения хоста для адреса IPv6.
Общий формат этих записей выглядит следующим образом:
host IN IPv4_address
host IN AAAA IPv6_address

Таким образом, если SOA запись обращается к основному мастер серверу в «ns1.domain.com», мы должны соединить этот адрес с IP-адресом, так как «ns1.domain.com» находится в зоне domain.com, которую определяет этот файл.
Запись может выглядеть примерно так:
ns1 IN A 111.222.111.222

Обратите внимание, что нет необходимости указывать полное имя. Мы можем просто указать узел (без FQDN), и DNS-сервер заполнит остальное согласно значению $ORIGIN. Тем не менее мы могли бы так же легко использовать FQDN:
ns1.domain.com. IN A 111.222.111.222

Илон Маск рекомендует:  crc32 - Вычисляет CRC32 для строки

В большинстве случаев это то место, где вы укажете свой веб-сервер как «WWW»:
WWW IN A 222.222.222.222

Мы должны также сказать, где находится основной домен. Мы можем сделать это следующим образом:
domain.com. IN A 222.222.222.222

Мы также могли бы использовать символ «@», чтобы обратиться к основному домену:
@ IN A 222.222.222.222

У нас также есть возможность преобразования всего, что находится под этим доменом, но не явно относится к этому серверу. Мы можем сделать это с помощью символа «*»:
* IN A 222.222.222.222

Все выше перечисленное также работает с AAAA записями для IPv6-адресов.

Запись CNAME

CNAME записи указывает псевдоним для канонического имени вашего сервера (который определен А или AAAA записью).

Например, у нас может быть A запись, определяющая узел «server1», а затем мы можем использовать «WWW» в качестве псевдонима для данного узла:
server1 IN A 111.111.111.111
www IN CNAME server1

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

CNAME рекомендуется использовать, когда необходимо предоставить псевдоним ресурсу за пределами текущей зоны.

Запись MX

MX записи указывают серверы обмена почты для домена. Это помогает сообщениям электронной почты приходить в ваш почтовый сервер правильно.
В отличие от многих других типов записей, почтовые записи, как правило, не присоединяют узел к чему-либо, потому что они распространяются на всю зону. Они, как правило, выглядит следующим образом:
IN MX 10 mail.domain.com.

Обратите внимание, что в начале нет имени узла.
Также в записи присутствует дополнительный номер. Это предпочтительный номер, который помогает компьютерам определить, какому серверу отправлять почту, если указаны несколько почтовых серверов. Более низкие значения имеют более высокий приоритет.

Запись MX должна, по сути, переправлять на узел, указанный в записи A или AAAA, а не к той, что указана CNAME.
Представим, что у нас есть два почтовых сервера. Там должны быть записи, которые выглядят примерно так:
IN MX 10 mail1.domain.com.
IN MX 50 mail2.domain.com.
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222

В этом примере узел «mail1» является предпочтительным сервером обмена почты.
Мы могли бы также написать это следующим образом:
IN MX 10 mail1
IN MX 50 mail2
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222

NS записи

Этот тип записи указывает на DNS-сервера, используемые для этой зоны.
Вы можете спросить: “Почему файлу зоны, находящемуся на DNS-сервере, необходимо ссылаться на себя самого?” DNS-сервер настолько удобен, потому что имеет несколько уровней кэширования. Одной из причин для указания DNS-серверов в файле зоны служит то, что файл зоны может быть фактически обслужен с кэшированной копии на другом DNS-сервере. Есть и другие причины, объясняющие необходимость DNS-серверов ссылаться на сами DNS-сервера, но мы не будем вдаваться в эти подробности.

Как MX записи, NS записи являются параметрами всей зоны, так что они также не соединяют узлы. Выглядят они так:
IN NS ns1.domain.com.
IN NS ns2.domain.com.

Вы должны иметь по крайней мере два DNS-сервера, указанные в каждом файле зоны для того, чтобы правильно действовать, если есть проблема с одним из серверов.
Большая часть программного обеспечения DNS-серверов считает файл зоны недействительным, если указан только один DNS-сервер.

Как всегда, учитывайте соединение для узлов с записями A или AAAA:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
ns1 IN A 111.222.111.111
ns2 IN A 123.211.111.233

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

Вывод

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

Протокол TCP/IP, служба DNS

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

Историческая справка: Систему доменных имен разработал в 1983 году Пол Мокапетрис. Тогда же было проведено первое успешное тестирование DNS, ставшей позже одним из базовых компонентов сети Internet. С помощью DNS стало возможным реализовать масштабируемый распределенный механизм, устанавливающий соответствие между иерархическими именами сайтов и числовыми IP-адресами.

В 1983 году Пол Мокапетрис работал научным сотрудником института информатики (Information Sciences Institute, ISI ), входящего в состав инженерной школы университета Южной Калифорнии ( USC ). Его руководитель, Джон Постел, предложил Полу придумать новый механизм, устанавливающий связи между именами компьютеров и адресами Internet, — взамен использовавшемуся тогда централизованному каталогу имен и адресов хостов, который поддерживала калифорнийская компания SRI International.

«Все понимали, что старая схема не сможет работать вечно, — вспоминает Мокапетрис. — Рост Internet становился лавинообразным. К сети, возникшей на основе проекта ARPANET, инициированного Пентагоном, присоединялись все новые и новые компании и исследовательские институты».

Предложенное Мокапетрисом решение — DNS — представляло собой распределенную базу данных, которая позволяла организациям, присоединившимся к Internet, получить свой домен.

«Как только организация подключалась к сети, она могла использовать сколь угодно много компьютеров и сама назначать им имена», — подчеркнул Мокапетрис. Названия доменов компаний получили суффикс .com , университетов — .edu и так далее.

Первоначально DNS была рассчитана на поддержку 50 млн. записей и допускала безопасное расширение до нескольких сотен миллионов записей. По оценкам Мокапетриса, сейчас насчитывается около 1 млрд. имен DNS, в том числе почти 20 млн. общедоступных имен. Остальные принадлежат системам, расположенным за межсетевыми экранами. Их имена неизвестны обычным Internet-пользователям.

Новая система внедрялась постепенно, в течение нескольких лет. В это время ряд исследователей экспериментировали с ее возможностями, а Мокапетрис занимался в ISI обслуживанием и поддержанием стабильной работы «корневого сервера», построенного на мэйнфреймах компании Digital Equipment. Копии таблиц хостов хранились на каждом компьютере, подключенном к Internet, еще примерно до 1986 года. Затем начался массовый переход на использование DNS.

Необходимость отображения имен сетевых узлов в IP-адреса

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

Есть два таких механизма — локальный для каждого компьютера файл hosts и централизованная иерархическая служба имен DNS.

Использование локального файла hosts и системы доменных имен DNS для разрешения имен сетевых узлов

На начальном этапе развития сетей, когда количество узлов в каждой сети было небольшое, достаточно было на каждом компьютере хранить и поддерживать актуальное состояние простого текстового файла, в котором содержался список сетевых узлов данной сети. Список устроен очень просто — в каждой строке текстового файла содержится пара «IP-адрес — имя сетевого узла». В системах семейства Windows данный файл расположен в папке %system root%\system32\drivers\etc (где %system root% обозначает папку, в которой установлена операционная система). Сразу после установки системы Windows создается файл hosts с одной записью 127.0.0.1 localhost .

С ростом сетей поддерживать актуальность и точность информации в файле hosts становится все труднее. Для этого надо постоянно обновлять содержимое этого файла на всех узлах сети. Кроме того, такая простая технология не позволяет организовать пространство имен в какую-либо структуру. Поэтому появилась необходимость в централизованной базе данных имен, позволяющей производить преобразование имен в IP-адреса без хранения списка соответствия на каждом компьютере. Такой базой стала DNS (Domain Name System) — система именования доменов, которая начала массовую работу в 1987 году.

Заметим, что с появлением службы DNS актуальность использования файла host совсем не исчезла, в ряде случаев использование этого файла оказывается очень эффективным.

Служба DNS: пространство имен, домены


DNS — это иерархическая база данных , сопоставляющая имена сетевых узлов и их сетевых служб IP-адресам узлов. Содержимое этой базы, с одной стороны, распределено по большому количеству серверов службы DNS, а с другой стороны, является централизованно управляемым. В основе иерархической структуры базы данных DNS лежит доменное пространство имен (domain namespace), основной структурной единицей которого является домен, объединяющий сетевые узлы (хосты), а также поддомены. Процесс поиска в БД службы DNS имени некоего сетевого узла и сопоставления этому имени IP-адреса называется «разрешением имени узла в пространстве имен DNS».

Служба DNS состоит из трех основных компонент:

  • Пространство имен DNS и соответствующие ресурсные записи (RR, resource record) — это сама распределенная база данных DNS;
  • Серверы имен DNS — компьютеры, хранящие базу данных DNS и отвечающие на запросы DNS-клиентов;
  • DNS-клиенты (DNS-clients, DNS-resolvers) -компьютеры, посылающие запросы серверам DNS для получения ресурсных записей.

Пространство имен DNS — иерархическая древовидная структура, начинающаяся с корня, не имеющего имени и обозначаемого точкой «.». Схему построения пространства имен DNS лучше всего проиллюстрировать на примере сети Интернет (рис. 4.8).

Для доменов 1-го уровня различают 3 категории имен:

  • ARPA — специальное имя, используемое для обратного разрешения DNS (из IP-адреса в полное имя узла);
  • Общие (generic) имена 1-го уровня — 16 (на данный момент) имен, назначение которых приведено в табл. 4.4;
  • Двухбуквенные имена для стран — имена для доменов, зарегистрированных в соответствующих странах (например, ru — для России, ua — для Украины, uk — для Великобритании и т.д.).
Таблица 4.4.
Имя домена Назначение
aero Сообщества авиаторов
biz Компании (без привязки к стране)
com Коммерческие организации, преимущественно в США (например, домен microsoft.com для корпорации Microsoft)
coop Кооперативы
edu Образовательные учреждения в США
gov Правительственные учреждения США
info Домен для организаций, предоставляющих любую информацию для потребителей
int международные организации (например, домен nato .int для НАТО)
mil Военные ведомства США
museum Музеи
name Глобальный домен для частных лиц
net Домен для Интернет-провайдеров и других организаций, управляющих структурой сети Интернет
org Некоммерческие и неправительственные организации, преимущественно в США
pro Домен для профессиональных объединений (врачей, юристов, бухгалтеров и др.)
job Кадровые агентства
travel Туроператоры

Для непосредственного отображения пространства имен в пространство IP-адресов служат т.н. ресурсные записи (RR, resource record). Каждый сервер DNS содержит ресурсные записи для той части пространства имен, за которую он несет ответственность ( authoritative ). табл. 4.5 содержит описание наиболее часто используемых типов ресурсных записей.

Таблица 4.5.
Тип ресурсной записи Функция записи Описание использования
A Host Address Адрес хоста, или узла Отображает имя узла на IP-адрес (например, для домена microsoft.com узлу с именем www.microsoft.com сопоставляется IP-адрес с помощью такой записи: www A 207.46.199.60 )
CNAME Canonical Name (alias) Каноническое имя (псевдоним) Отображает одно имя на другое
MX Mail Exchanger Обмен почтой Управляет маршрутизацией почтовых сообщений для протокола SMTP
NS Name Server Сервер имен Указывает на серверы DNS, ответственные за конкретный домен и его поддомены
PTR Pointer Указатель Используется для обратного разрешения IP-адресов в имена узлов в домене in-addr.arpa
SOA Start of Authority Начальная запись зоны Используется для указания основного сервера для данной зоны и описания свойств зоны
SRV Service Locator Указатель на службу Используется для поиска серверов, на которых функционируют определенные службы (например, контроллеры доменов Active Directory или серверы глобального каталога )

Полное имя узла (FQDN, fully qualified domain name) состоит из нескольких имен, называемых метками (label) и разделенных точкой. Самая левая метка относится непосредственно к узлу, остальные метки — список доменов от домена первого уровня до того домена, в котором находится узел (данный список просматривается справа налево).

Серверы имен DNS.

Серверы имен DNS (или DNS-серверы) — это компьютеры, на которых хранятся те части БД пространства имен DNS, за которые данные серверы отвечают, и функционирует программное обеспечение, которое обрабатывает запросы DNS-клиентов на разрешение имен и выдает ответы на полученные запросы.

DNS-клиент — это любой сетевой узел, который обратился к DNS-серверу для разрешения имени узла в IP-адрес или, обратно, IP-адреса в имя узла.

Domain name service cлужба доменных имен

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

В адресе электронной почты формально доменным именем можно считать то, что написано после символа коммерческого ат — «@». Например, в user@test.ru доменное имя почтового узла — test.ru.

Имя Web-узла — это доменное имя этого узла. Например, Web-узел компании Microsoft имеет доменное имя Microsoft.com.

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

Довольно часто наряду со словосочетанием «интернет-адрес» употребляют «доменный адрес». Вообще говоря, ни того, ни другого понятий в сетях TCP/IP не существует. Есть числовая адресация, которая опирается на IP-адреса, (группа из 4-ех чисел, разделенных символом «.») и Internet-сервис службы доменных имен (Domain Name System — DNS).

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

Тем не менее, установка соединений для обмена информацией в Интернет осуществляется по IP-адресам. Символьные имена системы доменных имен — суть сервис, который помогает найти необходимые для установки соединения IP-адреса узлов сети.

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

DNS существовала не с момента рождения TCP/IP сетей. Поначалу для облегчения взаимодействия с удаленными информационными ресурсами в Интернет стали использовать таблицы соответствия числовых адресов именам машин.

Авторство создания этих таблиц принадлежит доктору Постелю (Dr. Jon Postel — автор многих RFC — Request For Comments). Именно он первым поддерживал файл hosts.txt, который можно было получить по FTP.

Современные операционные системы тоже поддерживают таблицы соответствия IP-адреса и имени машины (точнее хоста) — это файлы с именем hosts. Если речь идет о системе типа Unix, то этот файл расположен в директории /etc и имеет следующий вид:

127.0.0.1 localhost
144.206.130.137 polyn Polyn polyn.net.kiae.su polyn.kiae.su
144.206.160.32 polyn Polyn polyn.net.kiae.su polyn.kiae.su
144.206.160.40 apollo Apollo www.polyn.kiae.su

Пользователь для обращения к машине может использовать как IP-адрес машины, так и ее имя или синоним (alias). Как видно из примера, синонимов может быть много, и, кроме того, для разных IP-адресов может быть указано одно и то же имя.

Напомним еще раз, что по самому мнемоническому имени никакого доступа к ресурсу получить нельзя. Процедура использования имени заключается в следующем:

  • сначала по имени в файле hosts находят IP-адрес,
  • затем по IP-адресу устанавливают соединение с удаленным информационным ресурсом.

Обращения, приведенные ниже аналогичны по своему результату — инициированию сеанса telnet с машиной Apollo:

В локальных сетях файлы hosts используются достаточно успешно до сих пор. Практически все операционные системы от различных клонов Unix до Windows последних версий поддерживают эту систему соответствия IP-адресов именам хостов.

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

DNS была описана Полом Мокапетрисом (Paul Mockapetris ) в 1984. Это два документа: RFC-882 и RFC-883 (Позже эти документы были заменены на RFC-1034 и RFC-1035). Пол Мокапетрис написал и реализацию DNS — программу JEEVES для ОС Tops-20. Именно на нее в RFC-1031 предлагается перейти администраторам машин с ОС Tops-20 сети MILNET. Не будем подробно излагать содержание RFC-1034 и RFC-1035. Ограничимся только основными понятиями.

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

Система доменных имен строится по иерархическому принципу. Точнее по принципу вложенных друг в друга множеств. Корень системы называется «root» (дословно переводится как «корень») и никак не обозначается (имеет пустое имя согласно RFC-1034).

Часто пишут, что обозначение корневого домена — символ «.», но это не так, точка — разделитель компонентов доменного имени, а т.к. у корневого домена нет обозначения, то полное доменное имя кончается точкой. Тем не менее символ «.» достаточно прочно закрепился в литературе в качестве обозначения корневого домена. От части это вызвано тем, что в файлах конфигурации серверов DNS именно этот символ указывается в поле имени домена (поле NAME согласно RFC-1035) в записях описания ресурсов, когда речь идет о корневом домене.

Корень — это все множество хостов Интернет. Данное множество подразделяется на домены первого или верхнего уровня (top-level или TLD). Домен ru, например, соответствует множеству хостов российской части Интернет. Домены верхнего уровня дробятся на более мелкие домены, например, корпоративные.

В 80-е годы были определены первые домены первого уровня (top-level): gov, mil, edu, com, net. Позднее, когда сеть перешагнула национальные границы США появились национальные домены типа: uk, jp, au, ch, и т.п. Для СССР также был выделен домен su. После 1991 года, когда республики Союза стали суверенными, многие из них получили свои собственные домены: ua, ru, la, li, и т.п.

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

Если быть более точным, то новых имен с расширением su в настоящее время ни один провайдер не выделяет (делегирует). Однако у многих существует желание возобновить процесс делегирования доменов в зоне SU.

Со списком доменов первого уровня (top-level) и их типами можно ознакомиться, например, в материале «Общая информация о системе доменных имен» по адресу https://info.nic.ru/domains/review.html.

Как уже было сказано, вслед за доменами первого уровня(top-level) следуют домены, определяющие либо регионы (msk), либо организации (kiae). В настоящее время практически любая организация может получить свой собственный домен второго уровня. Для этого надо направить заявку провайдеру и получить уведомление о регистрации (см. «Как получить домен»).

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

Часть дерева доменного именования можно представить следующим образом:

Рис.1. Пример части дерева доменных имен.

Корень дерева не имеет имени метки. Поэтому его обозначают как «». Остальные узлы дерева метки имеют. Каждый из узлов соответствует либо домену, либо хосту. Под хостом в этом дереве понимают лист, т.е. такой узел ниже которого нет других узлов.

Именовать хост можно либо частичным именем, либо полным именем. Полное имя хоста — это имя, в котором перечисляются слева направо имена всех промежуточных узлов между листом и корнем дерева доменного именования, при этом начинают с имени листа, а кончают корнем, например:

Частичное имя — это имя, в котором перечислены не все, а только часть имен узлов, например:

polyn
apollo.polyn
quest.polyn.kiae

Обратите внимание на то, что в частичных (неполных именах) символ точки в конце имени не ставится. В реальной жизни программное обеспечение системы доменных имен расширяет неполные имена до полных прежде, чем обратиться к серверам доменных мен за IP-адресом.

Слово «Хост» не является в полном смысле синонимом имени компьютера, как это часто упрощенно представляется. Во-первых, у компьютера может быть множество IP-адресов, каждому из которых можно поставить в соответствие одно или несколько доменных имен. Во-вторых, одному доменному имени можно поставить в соответствие несколько разных IP-адресов, которые, в свою очередь могут быть закреплены за разными компьютерами.

Еще раз обратим внимание на то, что именование идет слева направо, от минимального имени хоста (от листа) к имени корневого домена. Разберем, например, полное доменное имя demin.polyn.kiae.su. Имя хоста — demin, имя домена, в который данный хост входит, — polyn, имя домена, который охватывает домен polyn, т.е. является более широким по отношению к polyn, — kiae, в свою очередь последний (kiae) входит в состав домена su.

Имя polyn.kiae.su — это уже имя домена. Под ним понимают имя множества хостов, у которых в их имени присутствует polyn.kiae.su. Вообще говоря, за именем polyn.kiae.su может быть закреплен и конкретный IP-адрес. В этом случае кроме имени домена данное имя будет обозначать и имя хоста. Такой прием довольно часто используется для обеспечения коротких и выразительных адресов в системе электронной почты.

Имена хоста и доменов отделяются друг от друга в этой нотации символом «.». Полное доменное имя должно оканчиваться символом «.», т.к. последняя точка отделяет пустое имя корневого домена от имени домена верхнего уровня. Часто в литературе и в приложениях эту точку при записи доменного имени опускают, используя нотацию неполного доменного имени даже в том случае, когда перечисляют все имена узлов от листа до корня доменного именования.

Следует иметь в виду, что доменные имена в реальной жизни достаточно причудливо отображаются на IP-адреса, а тем более на реальные физические объекты (компьютеры, маршрутизаторы, коммутаторы, принтеры и т.п.), которые подключены к сети.

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

Более того, один и тот же компьютер может иметь несколько доменных имен. Возможен вариант, когда за одним доменным именем может быть закреплено несколько IP-адресов, которые реально назначены различным серверам, обслуживающим однотипные запросы.
Таким образом, соответствие между доменными именами и IP-адресами в рамках системы доменных имен не является взаимно однозначным, а строится по схеме «многие к многим».

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

Следует также упомянуть о канонических доменных именах. Это понятие встречается в контексте описания конфигураций поддоменов и зон ответственности отдельных серверов доменных имен. С точки зрения дерева доменных имена не разделяют на канонические и неканонические, но с точки зрения администраторов, серверов и систем электронной почты такое разделение является существенным. Каноническое имя — это имя, которому в соответствие явно поставлен IP-адрес, и которое само явно поставлено в соответствие IP-адресу. Неканоническое имя — это синоним канонического имени. Более подробно см. «настройка BIND».

Наиболее популярной реализацией системы доменных имен является Berkeley Internet Name Domain (BIND). Но эта реализация не единственная. Так в системе Windows NT 4.0 есть свой сервер доменных имен, который поддерживает спецификацию DNS.

Тем не менее, даже администраторам Windows желательно знать принципы функционирования и правила настройки BIND, т.к. именно это программное обеспечение обслуживает систему доменных имен от корня до TLD (Top Level Domain).

Что такое доменное имя?

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

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

У каждого web-ресурса также есть свой IP Адрес. У официального сайта компании Яндекс IP Адрес 213.180.204.11 Это число трудно запоминать, однако если его написать в адресной строке, то браузер откроет сайт компании Яндекс. Доменное Имя у этого сайта www.yandex.ru соответствующее IP-адресу 213.180.204.11.

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

Доменное Имя (англ. domain name) — уникальный идентификатор, который присваивается определенному IP-адресу (двух одинаковых быть не может).

Доменные Имена обслуживается и централизованно администрируются набором серверов доменных имен DNS. DNS (Domain Name Service) — служба доменных имен. Наряду с цифровыми адресами, DNS позволяет использовать собственные имена компьютеров, так называемые Доменные Имена.

Вся информация о Доменных Именах хранится в центральной базе данных DNS, представляющей собой несколько мощных компьютеров, разбросанных по всему миру. В этой базе хранится информация о дате регистрации, о физическом или юридическом владельце Доменного Имени, а также путь к так называемому серверу имен — NAMESERVER, где содержится информация, на которую указывает Доменное Имя.

Единый каталог Internet, определяющий основу DNS, находится в государственной организации SRI International — Menlo Park, CA, US (Менло Парк, Калифорния, США).

Доменное Имя это буквенный адрес компьютера.

Доменное Имя или буквенный адрес компьютера может быть:

8. СЛУЖБА ДОМЕННЫХ ИМЕН (DNS)

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

В бытность существования ARPANET соответствия между IP-адресами и их текстовыми эквивалентами хранились в файле hosts.txt. Ежесуточно все хосты получали этот файл, что обеспечивало актуальность (авторитетность) хранящихся в нем записей, и пока к сети было подключено несколько сотен машин, это было вполне приемлемым решением.

Но когда сеть разрослась до нескольких тысяч компьютеров, стало ясно, что этому механизму надо искать какую-то замену. В самом деле, размер файла становился слишком большим, а главное, в результате децентрализации неизбежно должны были возникнуть конфликты имен. Эту проблему была призвана решить служба доменных имен (Domain Name System, DNS).

Идея DNS состоит в разбиении всего адресного пространства на несколько непересекающихся зон (доменов), которые делятся на подзоны (поддомены).

Весь Интернет разделен на 200 доменов верхнего уровня, число которых постоянно увеличивается. Доменом называют множество хостов, объединенных в логическую группу. Каждый домен верхнего уровня подразделяется на поддомены, которые так же могут состоять из других доменов и т. д. (рис. 13,а).

Рис. 13. Служба доменных имен (DNS)

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

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL