HPUNIX Сайт о ОС и не только!

Работа DNS-сервера BIND

25 февраля 2009 - unix

#image.jpgНеплохого времени, уважаемые читатели. На данный момент в блоге желаю рассмотреть работу Domain Name System - сервера на Linux.

Разбираясь с работой SAMBA попробовал поднять свой реальный контроллер домена Active Directory и сообразил, что не хватает знаний до реального понимания DNS. Итак, основная цель DNS - это отображение доменных имен в IP адреса и напротив - IP в DNS.

В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав хоть какого дистрибутива UNIX. Базу BIND составляет бес named, который для своей работы употребляет порт UDP/53 и для некоторых запросов TCP/53.

Главные понятия Domain Name System

Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP делал файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В конечном итоге придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:

#image.jpgДоменная структура DNS представляет собой древовидную иерархию, состоящую из узлов, зон, доменов, поддоменов и др. частей, о которых ниже пойдет речь. "Вершиной" доменной структуры является корневая зона. Функции корневой зоны расположены на неограниченном количестве серверов/зеркал, размещенных по всему миру и содержат информацию о всех серверах корневой зоны, а так же  отвечающих за домены первого уровня (ru, net, org и др).

Информация о серверах корневой зоны расположена на данном сайте корневых серверов. Функции корневой зоны всегда доступны тут.

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

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

Целью выделения части дерева в отдельную зону является передача ответственности (Делегирование) за эту ветвь другому лицу или организации. На иллюстрации, примеры зон выделены голубым градиентом (зона name., зона k-max.name. со всем подчиненными ресурсами, www.openoffice.org. со всем подчиненными поддоменами и ресурсами).

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

Домен - это именованная ветвь или поддерево в дереве имен DNS, другими словами это определенный  узел, включающий в себя все подчиненные узлы. Следующая цитата из книги Linux Network Administrators Guide отлично проясняет картину относительно различия меж зоной и доменом:

Таким образом, место имен раздроблено на зоны ( zones), неважно какая из которых управляется своим доменом. Обратите внимание на различие меж зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в институте Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а непосредственно physics.groucho.edu.

Работа DNS-сервера BIND

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

А так же DNS адрес читается справа на лево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux. Доменное имя начинается с точки (корневого домена) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именованием хоста.

Т.о. доменное имя полностью отражает структуру иерархии DNS. Часто (я бы произнес - всегда в каждодневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (другими словами в браузере мы вводим не k-max.name.

rhel 6 bind primary dns server in redhat linux in hindi part 1

, а k-max.name). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию FQDN.

FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) - это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Обычный аналог абсолютного пути в файловой системе. Давайте разберем вышесказанное на примере имени домена mail.k-max.name:

mail.k-max.name. |     |  |  | | |     |  |  | +-корневой домен |     |  |  +---домен первого уровня |     |  +------точка, разделяющая домены/части FQDN |     +---------домен второго уровня +---------------поддомен/домен третьего уровня, может быть - имя хоста

Различие меж FQDN и обыденным доменным (неFQDN) именованием появляется при именовании доменов второго, третьего (и т. д.) уровня.

Для получения FQDN требуется обязательно указать в доменном имени домены более высокого уровня (например, mail является доменным именованием, но FQDN имя смотрится как mail.k-max.name.). Больший размер FQDN — Двести 50 5 б, с ограничением в Шестьдесят три б на каждое имя домена.

Поддомены, коротко говоря, это - подчиненные домены. На самом деле, все домены в интернете являются подчиненными не считая корневого. Например домен k-max является поддоменом домена name, а name, в свою очередь - поддоменом корневого домена.

Итак, на схеме выше мы рассмотрели корневой домен, следующим в иерархии идут домены первого/верхнего уровня, они же TLD, они же Top-Level Domain. К данным доменам относятся национальные домены (ru., ua. и др) и общие домены (com., net., и др).

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

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

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

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

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

Запись ресурса состоит из следующих полей:

name.             TTL   CLASS      TYPE       DATA
  • имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись, либо IP адрес. При отсутствии данного поля, запись ресурса наследуется от предыдущей записи.
  • Работа DNS-сервера BIND
  • Time To Live (TTL) — дословно "время жизни" записи, время хранения записи в кэше DNS (после обозначенного времени запись удаляется), данное поле может не указываться в личных записях ресурсов, но тогда оно должно быть обозначено поначалу файла зоны и будет наследоваться всеми записями.
  • класс (CLASS) - определяет тип сети, (в 99,99% случаях употребляется IN (что обозначает - Internet).

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

  • тип (TYPE) — тип записи синтаксис и назначение записи
  • данные (DATA) - различная информация, формат и синтаксис которой определяется типом.

При всем этом, может быть использовать следующие знаки:

  • ;   -  Вводит комментарий
  • #  -  Также вводит комменты (только в версии BIND 4.9)
  • @  - Имя текущего домена
  • ( )    - Позволяют данным занимать несколько строк
  • *    - Метасимвол (только в поле имя)

Со всем набором ресурсных записей можно ознакомиться в wikipedia. Более часто применяемые ресурсные записи следующими (далее, мы обязательно рассмотрим их на практике):

  • A - (address record/запись адреса) демонстрируют имя хоста (доменное имя) на адрес IPv4. Для каждого сетевого интерфейса машины должна быть сделана одна A-запись. Например, следующая запись указывает доменное имя k-max.name. в IPv4 адрес хоста 81.177.139.65 (поле NAME - k-max.name., поле TTL - 86400, поле CLASS - IN, поле DATA - 81.177.139.65):[plain]k-max.name.             Восемьдесят 6 тыщ четыреста   IN      A       81.177.139.65[/plain]
  • AAAA (IPv6 address record) подобна записи A, но для IPv6.
  • CNAME (canonical name record/каноническая запись имени (псевдоним)) - указывает алиас на реальное имя (для перенаправления на другое имя), например, следующая запись задает алиас ftp для хоста .:[plain]ftp             Восемьдесят 6 тыщ четыреста   IN      CNAME       .[/plain]
  • MX (mail exchange) - указывает хосты для доставки почты, адресованной домену. При всем этом поле NAME указывает домен назначения, поля TTL, CLASS - стандартное значение, поле TYPE принимает значение MX, а поле DATA указывает ценность и через пробел - доменное имя хоста, ответственного за прием почты. Например, следующая запись показывает, что для домена k-max.name направлять почту сначала на mx.k-max.name, позже на mx2.k-max.name, если с mx.k-max.name появились какие-то трудности. При всем этом, для обоих MX хостов должны быть соответствующие A-записи:
  •      k-max.name.             Семнадцать тыщ семьсот девяносто   IN      MX      10 mx.k-max.name. k-max.name.             Семнадцать тыщ семьсот девяносто   IN      MX      20 mx2.k-max.name.
  • NS (name server/сервер имён) указывает на DNS-сервер, обслуживающий данный домен.

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

    Они просто разъясняют, как организована зона и какие машины играют главную роль в обеспечении сервиса имен. Например, зону name. обслуживают следующие NS:

  •    name.                   5 тыщ семьсот 70 два    IN      NS      l6.nstld.com. name.

                       5 тыщ семьсот 70 два    IN      NS      m6.nstld.com. name.                   5 тыщ семьсот 70 два    IN      NS      c6.nstld.com. name.                   5 тыщ семьсот 70 два    IN      NS      j6.nstld.com. ......

    зону k-max.name обслуживают:

       k-max.name.             Одна тыща 500 70 семь    IN      NS      ns2.jino.ru. k-max.name.             Одна тыща 500 70 семь    IN      NS      ns1.jino.ru.

  • PTR (pointer) - указывает Ip-адрес в доменное имя (о данном типе записи побеседуем ниже в разделе обратного преобразования имен).
  • SOA (Start of Authority/начальная запись зоны) - обрисовывает главные/начальные функции зоны, можно сказать, определяет зону ответственности данного сервера. Для каждой зоны должна существовать только одна запись SOA и она должна быть 1-ая (дополнение: Первой она быть не должна.

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

    Тоже самое касается и директивы $TTL (полагаю, что и $ORIGIN, хотя и не проверял). (с)). Поле Name содержит имя домена/зоны, поля TTL, CLASS - стандартное значение, поле TYPE принимает значение SOA, а поле DATA состоит из нескольких значений, разбитых пробелами: имя головного DNS (Primary Name Server), адрес администратора зоны, далее в скобках - серийный номер файла зоны (Serial number).

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

    Ниже в примере приведено Два одинаковые записи SOA (хотя 2-ая и записана в несколько строк), но они идентичны по значению и формат записи 2-ой более понятен в силу его структурированности:

       k-max.name.             Восемьдесят 6 тыщ четыреста   IN      SOA     ns1.jino.ru. hostmaster.jino.ru.

    Два млрд одиннадцать миллионов 30 две тыщи три 28800 Семь тыщ двести 604800 Восемьдесят 6 тыщ четыреста k-max.name.             Восемьдесят 6 тыщ четыреста   IN      SOA     ns1.jino.ru. hostmaster.jino.ru. ( Два млрд одиннадцать миллионов 30 две тыщи три ; serial (серийный номер) 20 восемь тыщ восемьсот ; refresh (обновление) Семь тыщ двести ; retry (повторная попытка) 600 четыре тыщи восемьсот ; expire (срок годности) 86400) ; minimum TTL (минимум)

  • SRV (server selection) - указывают на сервера, обеспечивающие работу тех или других служб в данном домене (например  Jabber и Active Directory).

Давайте рассмотрим, что есть Делегирование.

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

Технически, делегирование заключается в выделении какой-либо части дерева в отдельную зону, и размещении этой зоны на DNS-сервере, принадлежащем другому лицу или организации. При всем этом, в родительскую зону врубаются «склеивающие» ресурсные записи (NS и А), содержащие указатели на авторитативные DNS-сервера дочерней зоны, а вся остальная информация, относящаяся к дочерней зоне, хранится уже на DNS-серверах дочерней зоны. Например, на иллюстрации корневой домен делегирует способности серверам отвечающим за TLD, TLD же в свою очередь, делегируют способности управления зонами - серверам второго уровня, временами на этом цепочка заканчивается, но бывает, что делегирование простирается до Четыре и даже 5 уровней.

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

Зона k-max.name после делегирования способностей на данный момент не зависит от name. и может содержать все (поточнее сказать - любые имена, которые я захочу) доменные имена, которые заканчиваются на *.k-max.name. С другой стороны, зона name.

содержит только доменные имена, оканчивающиеся на *.name., но не входящие в делегированные этой зоны, такие, например, как k-max.name или a-lab.name или непринципиально какая другая. k-max.name может быть поделен на поддомены с именами вроде mail.k-max.name, ftp.k-max.name и некоторые из этих поддоменов могут быть выделены в самостоятельные зоны, и ответственность за данные зоны может так же быть делегирована. Если ftp.k-max.name будет являться самостоятельной зоной, то зона k-max.name не будет содержать доменные записи, которые заканчиваются на *.ftp.k-max.name.

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

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

Серверы DNS

Выше, при рассмотрении типов ресурсных записей я упоминал о первичном и вторичном сервере. Не считая данных типов, существует очередной тип - кэширующий.

Главный сервер DNS (он же первичный, он же master, он же primary) - это авторитетный сервер (временами называют - авторитативный, как точнее называть - не знаю #image.jpg ), который хранит главную копию файла данных зоны, сопровождаемую администратором системы.

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

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

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

Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).

Кэширующие серверы НЕ АВТОРИТЕТНЫ, данные серверы хранят в памяти (кэше), ответы на прошлые запросы, если данный сервер получил запрос, то он сначала просматривает информацию в кэше, и если в кэше не оказалось подходящего ответа, то отправляет запрос вышестоящему серверу DNS.

Может быть так же настроить DNS в режиме stels (т.н. невидимый), информацию о данном сервере нереально получить используя прямые запросы. Это может быть полезно для организации primary сервера в защищенной среде и тем оградить зону от атак на зону.

Клиенты DNS (resolver)

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

Т.о. приложения посылают системные вызовы gethostbyname(2) и gethostbyaddr(2), а ядро уже на основании опций в файле /etc/nsswitch.conf определяет по какому пути ему далее действовать. Данный файл определяет какие сервисы (будь то файл /etc/hosts или DNS) и в каком порядке использовать.

В ранних версиях библиотеки Linux - libc, употреблялся файл /etc/host.conf. Ранее, в статьях о сети в Linux я упоминал о nsswitch. Вот кусочек файла, который нас интересует:

root@DNS:~# cat /etc/nsswitch.conf ...... hosts:          files dns networks:       files

Две строки данного кусочка указывают ядру создавать преобразование имен хостов в IP (строка hosts: files dns) сначала из файла hosts, позже силами DNS, а так же преобразование имен сетей в IP (строка networks: files) с помощью файла /etc/network.Возможны так же свойства nis или nisplu, определяющие использовать Network Information System (NIS) чтобы найти адрес. Порядок, в каком перечислены сервисы, определяет последовательность их опроса.

Если согласно /etc/nsswitch.conf запрос отправляется DNS, то употребляются функции из файла /etc/resolv.conf, который определяет какие серверы DNS использовать. Вот обыденный пример файла /etc/resolv.conf:

root@DNS:~# cat /etc/resolv.conf nameserver 192.168.1.1 nameserver 192.168.1.2 domain  examle.com

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

В данном файле обозначено использовать север имен сначала 192.168.1.1 позже, если 1-ый не смог обработать запрос, 192.168.1.2. Рекомендуется не использовать более 3х черт nameserver.

Если функция nameserver не задана, то резолвер попробует слиться с сервером на локальном хосте. Параметр domain определяет данное по умолчанию имя домена, которое будет подставлено, когда DNS не получится найти имя хоста.

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

Не считая кэша на ДНС сервере, есть кэши интернет-браузеров, кэши резолверов. Довольно прозрачную картину предоставляет Wikipedia:

#image.jpg

Запросы DNS

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

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

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

Обратный запрос отправляет IP  и просит вернуть доменное имя.

Хоть какой DNS-server должен отвечать на итеративные запросы. Может быть настроить DNS отвечать и на рекурсивные запросы. Если DNS не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.

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

#image.jpgДавайте разберем, что тут нарисовано по шагам:

  1. Клиент (браузер, почтовая программа, либо хоть какое другое приложение) отправляет запрос резолверу, резолвер на основании обозначенных конфигов определяет адрес настроенного сервера имен.
  2. Резолвер посылает запрос обозначенному серверу имен.
  3. Сервер имен принимает данный рекурсивный запрос и, т.к. не имеет инфы ни о домене, ни, может быть, даже о зоне name., отправляет рекурсивный (или нерекурсивный зависимо от опций) запрос серверу, отвечающему за корневую зону.
  4. Сервер корневой зоны не обрабатывает рекурсивные запросы, в конечном итоге обрабатывает данный запрос как итеративный и возвращает имя и адрес сервера, авторитетного за зону name.
  5. Сервер попеременно продолжает опрашивать авторитативные сервера для последующих зон, в порядке убывания уровня зон в имени
  6. пока не получает удовлетворительный ответ, данных шагов может быть больше, зависимо от длины доменного имени
  7. и "вложенности" доменных имен.
  8. В итоге, сервер получает подходящий ответ от сервера имен, хранящего подходящую ресурсную запись о хосте.
  9. Сервер провайдера локальной сети возвращает резолверу клиента запрошенные данные.

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

Для решения данного вопроса DNS-серверы BIND употребляют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера.

Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из числа тех авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.

До того как BIND впервой послал запрос какому-либо серверу и получил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все другие, обретенные на основании замеров. Таким образом, DNS BIND гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, до того как начнет выбирать предпочтительный на основании метрики.

Ответы DNS сервера

Ответы DNS бывают следующего типа:

  1. Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.
  2. Неавторитативный ответ (non authoritative response) приходит от серверов, которые не отвечают за зону (от кэширующих).

Ответ DNS обычно содержит следующую информацию:

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

Вышенаписанное наглядно подтверждается утилитой dig:

root@DNS:~# dig ya.ru
; <<>> DiG 9.7.3 <<>> ya.ru (раздел заголовка) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50 три тыщи четыреста девяносто девять ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 2, ADDITIONAL: Три ;; QUESTION SECTION: (раздел запроса) ;ya.ru.                         IN      A
;; ANSWER SECTION: (раздел ответа) ya.ru.

                  Четыре тыщи восемьсот тринадцать    IN      A       87.250.250.203 ya.ru.                  Четыре тыщи восемьсот тринадцать    IN      A       87.250.251.3 ya.ru.                  Четыре тыщи восемьсот тринадцать    IN      A       93.158.134.3 ya.ru.

                  Четыре тыщи восемьсот тринадцать    IN      A       93.158.134.203 ya.ru.                  Четыре тыщи восемьсот тринадцать    IN      A       213.180.204.3 ya.ru.                  Четыре тыщи восемьсот тринадцать    IN      A       77.88.21.3 ya.ru.

                  Четыре тыщи восемьсот тринадцать    IN      A       87.250.250.3 ;; AUTHORITY SECTION: (авторитативные сервера) ya.ru.                  Четыре тыщи восемьсот тринадцать    IN      NS      ns1.yandex.ru. ya.ru.

                  Четыре тыщи восемьсот тринадцать    IN      NS      ns5.yandex.ru. ;; ADDITIONAL SECTION: (дополнительная информация - адреса авторитативных name servers) ns5.yandex.ru.          Триста 40 5 тыщ 500 шестьдесят 5 IN      A       213.180.204.1 ns1.yandex.ru.  имя головного DNS (Primary Name Server)        Триста 40 5 тыщ 500 шестьдесят 5 IN      A       213.180.193.1 ns1.yandex.ru.

          Три тыщи 500 шестьдесят 5    IN      AAAA    2a0ua.em2:6emb8::1 ;; Query time: Семь msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sat Jul  Два 23:02:45 Две тыщи одиннадцать ;; MSG SIZE  rcvd: 238

Обратное преобразование имен

#image.jpgDNS употребляется поначалу для преобразования доменных имён в Ip-адреса, но он также может делать обратный процесс, называемый Обратное преобразование имен или обратным отображением. Т.к. записи в прямой базе DNS структурированы иерархически по доменным именам, DNS не может отлично делать поиск по IP адресу в такой базе.

Для обратного преобразования в DNS употребляется особенный домен in-addr.arpa. Ресурсные записи в данном домене в поле Name содержат Ip-адреса, в поле Type - PTR, а в поле Data - FQDN-имя соответствующее данному IP.

На схеме представлена структура домена arpa. Думаю, что тут все довольно наглядно. Домен arpa. имеет Два поддомена in-addr и ip6, отвечающие за IPv4 и IPv6 адреса соответственно. Домен in-addr.arpa.

имеет от *.0.in-addr.arpa. до *.255.in-addr.arpa. поддоменов, хоть какой из которых так же имеет по Двести 50 6 поддоменов.

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

Наглядно приведенную схему можно представить командами:

[root@DNS~]# dig www.ru. ... ;; QUESTION SECTION: ;www.ru.                                IN      A
;; ANSWER SECTION: www.ru.                 50 две тыщи 100 девятнадцать   IN      A       194.87.0.50 ... [root@DNS~]# dig -x 194.87.0.50 ... ;; QUESTION SECTION: ;50.0.87.194.in-addr.arpa.      IN      PTR
;; ANSWER SECTION: 50.0.87.194.in-addr.arpa.

30 тыщ триста восемьдесят 5 IN      PTR     www.ru. ....

При всем этом, команду dig -x 194.87.0.50 точнее будет представить как dig 50.0.87.194.in-addr.arpa., другими словами записи в поддоменах *.in-addr.arpa. представлены в так называемой обратной нотации (или reverse форме), другими словами хосту с IP 194.87.0.50 будет соответствовать PTR-запись, имеющая FQDN 50.0.87.194.in-addr.arpa., которая в свою очередь указывает на домен www.ru..  Хочется отметить, что почти всегда за обратную зону и ее редактирование отвечает поставщик интернета.

Как и обещал, описываю ресурсную запись PTR в домене IN-ADDR.ARPA, соответствующая приведенной выше записи А для машины www.ru., будет иметь такой вид:

50.0.87.194 IN PTR www.ru.

Имя 50.0.87.194 не заканчивается точкой и поэтому является относительным. Вопрос: относительным относительно чего? Ни в коем случае не относительно "www.ru.". Для того чтобы эта запись была FQDN, домен по умолчанию должен называться "IN-ADDR.ARPA.".

Этого можно добиться либо поместив записи PTR в отдельный файл, в каком доменное имя зоны по умолчанию — IN-ADDR.ARPA. (данный в файле начальной загрузки беса named), либо изменив этот домен с помощью директивы $ORIGIN. Если домен по умолчанию определен как 0.87.194.IN-ADDR.ARPA., то запись можно представить так:

50 IN PTR www.ru.

Регистрация доменных имен

В 2-ух словах вожделел бы затронуть вопрос регистрации доменных имен.

Регистрация доменов — это действие, средством которого клиент докладывает регистратору, каким DNS-серверам следует делегировать поддомен, и также снабжает регистратора контактной и платежной информацией. Регистратор передает информацию в соответствующий реестр. Почти всегда, это процесс внесения в реестр зоны первого уровня (другими словами в TLD зоны ru, com или др.), записи о новом доменном подимени.

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

Уровни доменов, для которых нужна неотклонимая регистрация лица, ответственного за домен, следующие:

  • корневой домен
  • все домены первого уровня (TLD)
  • некоторые домены второго уровня (например, com.ru или co.uk)

Регистратором для корневого домена является организация ICANN. Чтобы стать регистратором доменов в зонах второго уровня (.com .net .org .biz .info .name .mobi .asia .aero .tel .travel .jobs ...), необходимо получить аккредитацию ICANN.

Правила регистрации в международных (gTLD - com., org, и др.) доменах инсталлируются ICANN. Правила регистрации в муниципальных (ccTLD - ru, us и др.) доменах инсталлируются их регистраторами и/или органами власти соответствующих стран, например единые правила для всех регистраторов в доменах .ru, и .рф задаются Координационным центром муниципального домена сети Интернет.

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

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

В окончание статьи желаю отметить так же о таком маркетинговом нюансе, что временами домены второго уровня называют именами доменов ПЕРВОГО уровня, тем "опуская" значение корневого домена и принимая за корневой домен - домены TLD.

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

Резюме

Итак, в сегодняшней статье я постарался как можно понятней описать работы доменной системы имен. Надеюсь, это у меня вышло.

Мы рассмотрели иерархическую структуру базы данных DNS, а так же рассмотрели процессы взаимодействия клиентов и серверов DNS, а так же разновидности серверов DNS. В следующей статье я рассмотрю практические вопросы установки и функции DNS сервера BIND на Linux. Буду рад Вашим комментариям.

Что еще почитать:

man (5) resolver: http://www.opennet.ru/man.shtml?topic=resolver&category=5&russian=0
man (3) gethostbyname:  http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=gethostbyname&category=3
Linux Network Administrators Guide v2 Russian: скачать.
RFC882, 1035, 1183
Статья DNS сервер bind - практика

Upd 2013.01.28: обновил информацию по SOA-записи (спасибо комментатору feedbee на хабре)

Похожие статьи

  • Постоянные выражения, базы для работы в Linux

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

  • Управление бесом syslogd и журналированием в Linux

    На данный момент на речь пойдет о журналировании в Linux. Функция системного журналирования (т.н. "логи" или логирование) - это основной источник инфы о работе системы и ошибках. Журналирование может осущ...

  • Композиции кнопок для работы в интерпретаторе Bash

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

  • Сервер точного времени своими руками (на базе беса ntpd)

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

  • Сервер печати CUPS

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

Теги:
Рейтинг: +19 Голосов: 241 2440 просмотров
Комментарии (0)

Нет комментариев. Ваш будет первым!

Найти на сайте: параметры поиска

Windows 7

Среда Windows 7 на первых порах кажется весьма непривычной для многих.

Windows 8

Если резюмировать все выступления Microsoft на конференции Build 2013.

Windows XP

Если Windows не может корректно завершить работу, в большинстве случаев это

Windows Vista

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