====== Основные понятия Domain Name System ======

===== 1. Общие понятия =====

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

{{ :rias:рисун1.jpg?600 |}}

Доменная структура DNS представляет собой древовидную иерархию, состоящую из узлов, зон, доменов, поддоменов и других элементов, о которых ниже пойдет речь. «Вершиной» доменной структуры является корневая зона. Настройки корневой зоны расположены на множестве серверов/зеркал, размещенных по всему миру, и содержат информацию о всех серверах корневой зоны, а также отвечающих за **домены первого уровня** (ru, net, org и др.).\\

Информация о серверах корневой зоны расположена на данном [[http://www.root-servers.org/|сайте корневых серверов]]. Настройки корневой зоны всегда доступны по ссылке [[ftp://ftp.internic.net/domain/named.root|named.root]]. Серверы корневой зоны обрабатывают и отвечают на запросы, выдавая информацию только о доменах первого уровня, то есть отвечают на любые запросы как на нерекурсивные.\\

**//Зона//** — это любая часть дерева системы доменных имен, размещаемая как единое целое на некотором **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 отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе — //слэш//, а в DNS — //точка//. А также **DNS адрес** читается справа налево (от корневого домена к имени хоста) в отличие от пути в файловой системе Linux. **Доменное имя начинается с точки** (//корневого домена//) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.о. доменное имя полностью отражает //структуру иерархии DNS//. Часто, последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.name., а k-max.name).

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

{{ :rias:рисун2.jpg?600 |}}

Различие между **FQDN** и обычным доменным (**неFQDN**), именем появляется при именовании доменов второго, третьего и последующих уровней. Для **получения FQDN** требуется обязательно указать в доменном имени домены более высокого уровня (например, mail является доменным именем, однако FQDN-имя выглядит как mail.k-max.name.). Максимальный размер FQDN — 255 байт, с ограничением в 63 байта на каждое имя домена.\\

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

Итак, на схеме выше рассмотрен **корневой домен**, следующим в иерархии идут **домены первого/верхнего уровня**, они же **TLD**, они же **TopLevel Domain**. К данным доменам относятся **//национальные домены//** (//ru., ua. и др//) и **общие домены** (//com., net., и др//). Существуют также **специализированные домены**, которые не опубликованы в системе DNS, но используются программами (домен .onion используется анонимной сетью Tor для перехвата и последующей маршрутизации обращений к скрытым сервисам этой сети). Еще есть т.н. **зарезервированные доменные имена**, определенные в RFC 2606 (**Reserved Top Level DNS Names** — Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. К таким именам относятся например example.com, example.org и example.net, а также test, invalid и др. Ниже по иерархии, как видно, идут домены третьего уровня и т.д. Заканчивается доменная иерархия — **именами хостов**, которые задаются соответствующими **ресурсными записями** или **хостовыми записями**.\\

===== 2. Ресурсные записи =====

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

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

  * **имя (NAME)** — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись, либо IP адрес. При отсутствии данного поля, запись ресурса наследуется от предыдущей записи.

  * **Time To Live (TTL)** — дословно «время жизни» записи, время хранения записи в кэше DNS (после указанного времени запись удаляется), данное поле может не указываться в индивидуальных записях ресурсов, но тогда оно должно быть указано в начале файла зоны и будет наследоваться всеми записями.

  * **класс (CLASS)** — определяет тип сети, (в 99,99% случаях используется IN (что обозначает — Internet). Данное поле было создано из предположения, что DNS может работать и в других типах сетей, кроме TCP/IP)

  * **тип (TYPE)** — тип записи синтаксис и назначение записи

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

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

  * **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//):

{{ :rias:рисун3.jpg?600 |}}

  * **AAAA** (//IPv6 address record//) аналогична записи A, но для IPv6.

  * **CNAME** (//canonical name record/каноническая запись имени (псевдоним)//) — отображает алиас на реальное имя (для перенаправления на другое имя), например, следующая запись задает алиас ftp для хоста www.k-max.name.:

{{ :rias:рисун4.jpg?600 |}}

  * **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-записи:

{{ :rias:рисун5.jpg?600 |}}

  * **NS** (//name server/сервер имён//) указывает на DNS-сервер, обслуживающий данный домен. Вернее будет сказать — указывают сервера, на которые делегирован данный домен. Если записи NS относятся к серверам имен для текущей зоны, доменная система имен их практически не использует. Они просто поясняют, как организована зона и какие машины играют ключевую роль в обеспечении сервиса имен. Например, зону name. обслуживают следующие NS:

{{ :rias:рисун6.jpg?600 |}}

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

{{ :rias:рисун7.jpg?600 |}}

  * **PTR** (//pointer//) — отображает IP-адрес в доменное имя (о данном типе записи поговорим ниже в разделе обратного преобразования имен).

  * **SOA** (//Start of Authority/начальная запись зоны//) — описывает основные/начальные настройки зоны, можно сказать, //определяет зону// //ответственности данного сервера//. Для каждой зоны должна существовать только одна запись SOA и она должна быть первая. **//Поле Name//** содержит //имя// //домена/зоны//, **//поля TTL//**, **//CLASS//** — стандартное значение, **//поле TYPE//** принимает значение SOA, а **//поле DATA//** состоит из нескольких значений, разделенных пробелами: //имя главного DNS (Primary Name Server), адрес// //администратора зоны, далее в скобках — серийный номер файла зоны (Serial// //number)//. При каждом внесении изменений в файл зоны данное значение необходимо увеличивать, это указывает вторичным серверам, что зона изменена, и что им необходимо обновить у себя зону. Далее — **//значения//** **//таймеров//** (//Refresh// — указывает, как часто вторичные серверы должны опрашивать первичный, чтобы узнать, не увеличился ли серийный номер зоны, //Retry// — время ожидания после неудачной попытки опроса, //Expire// — максимальное время, в течение которого вторичный сервер может использовать информацию о полученной зоне, //Minimum TTL// — минимальное время, в течение которого данные остаются в кэше вторичного сервера). Ниже в примере приведено 2 одинаковые записи SOA (хотя вторая и записана в несколько строк), но они одинаковы по значению и формат записи второй более понятен в силу его структурированности:\\

{{ :rias:рисун8.jpg?600 |}}

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

Рассмотрим, что такое **Делегирование**. **Делегирование** (корректнее сказать **делегирование ответственности**) — это операция //передачи// //ответственности за часть дерева доменных имен (зону)// другому лицу или организации. За счет делегирования, в DNS обеспечивается распределенность администрирования и хранения зон. Технически, делегирование заключается в выделении какой-либо части дерева в отдельную зону, и размещении этой зоны на DNS-сервере, принадлежащем другому лицу или организации. При этом, в родительскую зону включаются «склеивающие» ресурсные записи (NS и А), содержащие указатели на авторитативные DNS-сервера дочерней зоны, а вся остальная информация, относящаяся к дочерней зоне, хранится уже на DNS- серверах дочерней зоны. Например, на иллюстрации **корневой домен** делегирует полномочия серверам отвечающим за TLD, TLD же в свою очередь, делегируют полномочия управления зонами — серверам второго уровня, иногда на этом цепочка заканчивается, но бывает, что делегирование простирается до 4 и даже 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-серверов, которые обладают соответствующей информацией.\\

===== 3. Серверы DNS =====

Выше, при рассмотрении типов ресурсных записей упоминалось о **первичном** и **вторичном** сервере. Кроме данных типов, существует еще один тип — **кэширующий**.\\

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

**Вторичный сервер** — тоже является **//авторитетным//**, но он копирует главный файл зоны с //первичного сервера//. **Отличие**//главного// от //вторичного// лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный — загружает (получает) настройки зон — с главного сервера. **Вторичный DN** S может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). //Вторичных// серверов может быть сколько угодно много. В зависимости от настроек, **главный сервер** может посылать вторичному сигнал о изменении зоны, при этом **вторичный**, получив сигнал производит копирование. Данное действие называется **трансфер зоны** (**zone** **transfer**). Существует два механизма **копирования зоны**: //полное копирование// //(AXFR)// и //инкрементальное (incremental) копирование зоны (IXFR)//.\\

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

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

===== 4. Клиенты DNS (resolver) =====

//Как же программы на конечных машинах знают, куда и в каком виде посылать запросы DNS?// Они этого не знают. Для разрешения имен и IP адресов клиентскими приложениями используется **библиотека Resolver**. Это не какое- то специальное приложение, это функциональность системы (ядра). Т.о. приложения посылают //системные вызовы// gethostbyname и gethostbyaddr, а ядро уже на основании настроек в файле /etc/nsswitch.conf определяет по какому пути ему далее действовать. Данный файл определяет, какие сервисы (будь то файл ///etc/hosts// или //DNS//) и в каком порядке использовать. В ранних версиях библиотеки Linux — //libc//, использовался **файл /etc/host.conf**. Вот фрагмент файла, который нас интересует:\\

{{ :rias:рисун9.jpg?600 |}}

Две строки данного фрагмента указывают ядру производить преобразование имен хостов в 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:\\

{{ :rias:рисун10.jpg?600 |}}

Директива **nameserver** определяет адрес **сервера доменных имен**, который будет выполнять рекурсивные запросы resolver. В данном файле указано **использовать север имен** сначала 192.168.1.1 затем, если первый не смог обработать запрос, 192.168.1.2. Рекомендуется не использовать более 3х **параметров** **//nameserver//**. Если //опция nameserver// не задана, то резолвер попытается соединиться с сервером на локальном хосте. **Параметр domain** определяет заданное по умолчанию имя домена, которое будет подставлено, когда DNS не удастся найти имя хоста. Существует также **опция search**, которая задает дополнительные домены, в которых необходимо произвести поиск и разрешение имени хоста. Опции search и domain нельзя использовать совместно.\\

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

{{ :rias:рисун11.jpg?600 |}}

===== 5. Запросы DNS =====

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

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

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

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

Любой **DNS-server** должен отвечать на **итеративные запросы**. Возможно настроить DNS отвечать и на **рекурсивные запросы**. //Если DNS не настроен// //отвечать на рекурсивные запросы, он обрабатывает их как//**//итеративные//**.\\

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

{{ :rias:рисун12.jpg?600 |}}

Давайте разберем, что тут нарисовано по шагам: 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** гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.\\

===== 6. Ответы DNS сервера =====

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

  * **Авторитативный ответ (authoritative response)** приходит от серверов, являющихся ответственными за зону.

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

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

  * **Запись заголовка** — служебную информацию о запросе.

  * **Запись запроса** — повторяет отправленный запрос.

  * **Запись ответа** — собственно, сам ответ.

  * **Записи авторитетных серверов** — информацию об авторитетных серверах, хранящих информацию по текущему запросу.

  * **Дополнительную информацию** — дополнительные записи, например адреса NS-серверов.

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

{{ :rias:рисун13.jpg?500 |}}

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

**DNS** используется, в первую очередь, для преобразования доменных имён в IP-адреса, но он также может выполнять обратный процесс, называемый **//Обратное преобразование имен//** или **обратным отображением**. Т.к. записи в прямой базе DNS структурированы иерархически по доменным именам, **DNS** не может эффективно выполнять поиск по IP адресу в такой базе. **Для** **обратного преобразования в DNS используется специальный домен in-** **addr.arpa**. Ресурсные записи в данном домене в **поле Name** содержат //IP-адреса//, в **поле Type** — //PTR//, а в **поле Data** — //FQDN-имя// соответствующее данному IP.\\

На схеме представлена **структура домена arpa**. **Домен** **arpa.** имеет два поддомена **in-add** r и **ip6**, отвечающие за //IPv4// и //IPv6// адреса соответственно. **Домен in-addr.arpa.** имеет от *.0.in-addr.arpa. до *.255.in-addr.arpa. поддоменов, каждый из которых также имеет по 256 поддоменов.\\

{{ :rias:рисун14.jpg?500 |}}

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

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

{{ :rias:рисун15.jpg?600 |}}

При этом, команду 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. будет иметь такой вид:\\

{{ :rias:рисун16.jpg?600 |}}

Имя 50.0.87.194 не заканчивается точкой и поэтому является относительным. Вопрос: относительным относительно чего? Ни в коем случае не относительно "www.ru". Для того чтобы эта запись была FQDN, домен по умолчанию должен называться «IN-ADDR.ARPA.». Этого можно добиться либо поместив записи PTR в отдельный файл, в котором доменное имя зоны по умолчанию — **IN-ADDR.ARPA**. (заданный в файле начальной загрузки демона named), либо изменив этот домен с помощью директивы $ORIGIN. Если домен по умолчанию определен как 0.87.194.IN-ADDR.ARPA., то запись можно представить так:\\

{{ :rias:рисун17.jpg?600 |}}

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

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

**Регистрация доменов** — это действие, посредством которого клиент сообщает регистратору, каким 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) регистратор не единственный. При наличии нескольких регистраторов все они должны использовать единую (централизованную или распределённую) базу данных для исключения конфликтов и обеспечения уникальности доменного имени.\\

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