Теория

Как известно, протокол TCP/IP, которым пользуются в Интернете, может адресовать хосты лишь по IP-адресу. Человеку же не так-то просто сразу запомнить четыре числа, поэтому был изобретен механизм, позволяющий называть хосты прямо открытым текстом — например, «askbilly.microsoft.com.». Точка после com — вовсе не опечатка. Она должна там быть. Тем не менее, умные браузеры позволяют нам, простым смертным, ее опускать. Задача общемировой DNS — взять доменный адрес хоста и вычислить по нему его IP-адрес. Именно это и делают браузеры перед тем, как подключаются к затребованному вами сайту (обычно этот процесс занимает около секунды — от появления слов «Connecting» до «Connected, waiting for reply» в строке состояния браузера).

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

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

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

Все еще не понятно?.. Тогда давайте посмотрим с другой стороны. Пусть бы мы обращались не к microsoft.com., а к www.microsoft.com. В этом случае последний шаг приобретает вполне определенный смысл: он позволяет определить адрес домена www (вернее, www.microsoft.com.) внутри microsoft.com., все по той же самой схеме. Теперь я вернусь назад и скажу, что microsoft.com. с точки зрения симметрии и простоты должен выглядеть ничуть не лучше, чем ПУСТО.microsoft.com. Значит, IP-адрес сервера имен microsoft.com. вполне может не совпадать с IP-адресом конечного хоста microsoft.com. Более того: name-сервер microsoft.com. может передать полномочия обработки этого запроса какой-нибудь другой машине, и там все начнется с начала.

Конечно, если бы все происходило в точности таким образом, корневой сервер имен был бы просто завален запросами. Чтобы этого избежать, на каждом из name-серверов применяется технология кэширования запросов: если на какое-то доменное имя уже был выдан IP-адрес, то в течение нескольких часов при получении идентичного запроса он будет выдаваться снова — из кэша. Кроме того, я намеренно исказил схему, чтобы она казалась проще. В дальнейшем все должно встать на свои места.

Перейдем теперь к практической части. Предположим, вы поставили в Интернет машину с отдельным IP-адресом и хотите, чтобы ему соответствовал адрес myhost.ru. Вот шаги, которые необходимо для этого предпринять.

• Связаться с владельцами name-сервера первого уровня (ru.) и попросить у них связать доменное имя myhost.ru. с вашим IP-адресом. Обычно за это берутся какие-то деньги: в нашем примере это обойдется примерно в 20 долларов ежегодно.
• На своей машине с выделенным IP-адресом установить и настроить сервер имен — например, named. При обращении к этому серверу имен он должен для запроса myhost.ru. и *.myhost.ru. выдавать IP-адрес конечного хоста — то есть, той же самой машины. (Надеюсь, интуитивно ясно, что здесь обозначает звездочка?.. Если нет, то попробуйте догадаться, как отреагирует сконфигурированный named на адрес типа my.subdomain.myhost.ru.)

К сожалению, на этом дело не кончается. Дело в том, что из соображений надежности практически все владельцы доменов первого уровня требуют, чтобы у вас был не один name-сервер, а два, причем работающие синхронно (то есть, возвращающие одно и то же для запроса myhost.ru.). В идеале — это, конечно, две разных машины. Если вдруг одна из них выйдет из строя, другая сразу начнет выполнять ее работу по резолвингу доменных имен.

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

Если у вас нет возможности приобрести еще один IP-адрес в другой подсети класса C, не отчаивайтесь: существует несколько компаний, предоставляющих свой name-сервер для подобных нужд. Такой сервер будем называть вторичным сервером имен. Специально для поддержки вторичных серверов в named предусмотрена удобная опция, которая заключается в следующем: при изменении информации на первичном сервере вторичный скачивает ее к себе автоматически, так что синхронизация данных не должна вас заботить.

В качестве одного из самых удобных бесплатных вторичных серверов могу порекомендовать http://www.trifle.net. Все остальные подобные системы (в том числе и за рубежом) показались мне гораздо менее удобными, чем эта.

Необходимо еще разъяснить смысл термина «зона», который я до сих пор старался не применять. Итак, зона — это, грубо говоря, запись в базе данных named на той или иной машине. При резолвинге сервер имен вначале определяет, к какой зоне относится запрос, а затем уже начинает искать данные о доменном имени внутри нее. Например, доменные имена *.myhost.ru. на нашей машине будут принадлежать зоне с именем myhost.ru., и в этом смысле имя зоны всегда является общей частью всех доменов, которые в ней расположены. Итак, имя зоны — это как раз та строка, по которой происходит поиск при получении запроса на резолвинг. Еще пример: на корневом сервере имен существует зона с именем «.», хранящая список доменов первого уровня внутри нее. Именно в зоне хранятся данные о подчиненных ей доменах, и в этом смысле в начале наблы я немного схитрил, пытаясь избежать самого термина «зона». Кстати, вторичные серверы имен синхронизируют именно зоны, просто «выкачивая» их с первичного сервера.

Практика

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

Войдите в транс и внушите себе, что настраивать named просто, очень просто, проще некуда... Тогда у вас все получится.

options   { directory "/etc/named"; notify yes; };
zone "."          { type hint;   file "root.txt"; };
zone "myhost.ru." { type master; file "1.txt"; };

Здесь мы определяем две зоны, файлы данных которых будут располагаться в директории /etc/named.

Вообще-то, чаще всего используют путь /var/named, однако мне это категорически не нравится. Я предпочитаю размещать подобные вещи в /etc и включать ее целиком в ежедневный бэкап, чтобы случайно что-нибудь не потерялось.

Начнем со второй зоны, так как она наиболее интересна. Буквально тут записано, что данные зоны находятся в файле /etc/named/1.txt. Вот как выглядит этот файл (в предположении, что вы хотите получать письма о различных ошибках в работе DNS на адрес myhost@mail.ru):

$TTL  43200
; Символ @ при анализе файла заменяется named на 
; то, что указано в кавычках после слова "zone" 
; в named.conf - в нашем случае это myhost.ru. 
; Кстати, именно поэтому в E-mail адресе, который
; указан на следующей строке, нужно применять
; точку вместо @.

@     SOA @ myhost.mail.ru. (
        2000092940 ; serial
        3600       ; refresh
        900        ; retry
        1209600    ; expire
        86400      ; minimum TTL
      )
; Текущую зону можно выкачать с серверов myhost.ru.

@     NS     myhost.ru.
; ... и  ns2.trifle.net. Здесь я предположил, 
; что вы решились-таки воспользоваться trifle.net 
; для создания вторичного сервера имен.

@     NS     ns2.trifle.net.

; Домен, имя которого совпадает с именем текущей зоны,
; а также все его поддомены, имеют нужный IP-адрес.

@     A      ваш_IP_адрес
*     A      ваш_IP_адрес 

; Наконец, почта, приходящая на адрес 
; вида что-то@myhost.ru, будет попадать на 
; SMTP-сервер, запущенный на mail.myhost.ru, 
; то есть на текущую машину (вместо mail
; здесь можно было бы написать любое имя,
; ведь все поддомены имеют одинаковый IP-адрес).

@     MX 10  mail

Казалось бы, все просто. Так оно, в общем-то, и есть. Заметьте, что мы нигде не привязываемся непосредственно к имени myhost.ru., за исключением первой NS-строки. Это послужит нам в будущем. Теперь, если кто-то подключится к нашему name-серверу и попросит определить IP-адрес abc.myhost.ru., named мгновенно обнаружит, что этот домен принадлежит зоне myhost.ru. и вернет IP-адрес, тот самый, который указан во второй A-строке (где звездочка).

Строка с типом A обзначает: «Домен имеет IP-адрес ...». Строка с типом NS означает: «Зона хранится на name-сервере ...». Строка типа MX означает: «Для указанного домена после @ перенаправлять всю почту на ...». Все остальные строки (TTL, SOA) не так интересны, и вы можете почитать о них в документации.

Вернемся чуть назад, к рассмотрению файла named.conf. Зачем нужна первая, корневая, зона?.. Только для того, чтобы сама машина могла определить адрес общемирового корневого name-сервера. Именно в этой зоне он (точнее, они) и задается. Вот как обычно выглядит файл /etc/named/root.txt:

.                   3600000 IN NS  A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000     A  198.41.0.4
.                   3600000    NS  B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000     A  128.9.0.107
.                   3600000    NS  C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000     A  192.33.4.12
.                   3600000    NS  D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000     A  128.8.10.90
.                   3600000    NS  E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000     A  192.203.230.10
.                   3600000    NS  F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000     A  192.5.5.241
.                   3600000    NS  G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000     A  192.112.36.4
.                   3600000    NS  H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000     A  128.63.2.53
.                   3600000    NS  I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000     A  192.36.148.17
.                   3600000    NS  J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000     A  198.41.0.10
.                   3600000    NS  K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000     A  193.0.14.129 
.                   3600000    NS  L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000     A  198.32.64.12
.                   3600000    NS  M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000     A  202.12.27.33

Думаю, нет смысла разбираться, что все это означает — просто скопируйте в /etc/named/root.txt, и все (можете даже назвать root.txt как-нибудь по-другому, но тогда не забудьте поправить и named.conf). Скажу только, что все эти name-серверы совместно обслуживают корневую зону, и все они являются как бы вторичными серверами друг для друга.

Раньше мы рассматривали пример, когда кто-то подключается к named и запрашивает у него резолвинг домена abc.myhost.ru. Что произойдет, если он запросит, например, адрес microsoft.com.? Если бы не запись о корневой зоне в нашем named.conf, сервер имен ответил бы, что не смог найти зону для такого запроса. Но, так как такая запись присутствует в named.conf, умный named может послать пользователя к одному из корневых серверов за дальнейшей информацией. Не правда ли, удобно?..

Вот здесь вы можете посмотреть на все файлы, которые затронула настройка named.

Массовое создание зон

Но что, если мы захотим добавить к нашей системе еще несколько доменов (читайте — несколько зон), привязанных к тому же самому IP-адресу?..

Благодаря протоколу HTTP/1.1, который используют все браузеры и Web-серверы, сервер способен определить, к какому хосту пришел запрос, даже если все хосты «висят» на одном и том же IP-адресе. Подробнее об этом можно прочитать, например, в статье об установке Apache.

Традиционно добавление новой зоны происходит по описанной выше схеме: создается файл, например, 2.txt, и в нем прописываются данные второй зоны, также обновляется и named.conf. Вообразите теперь, что у вас 100 различных зон, и вы решили переехать на другой выделенный канал, поменяв при этом IP-адрес. Вам придется править 100 файлов зон! Если вы — хостинг-провайдер, то вам несдобровать.

Однако не стоит отчаиваться. Думаю, решение находится на поверхности, и вы сейчас сами догадаетесь, в чем оно заключается. Просто создайте вторую зону — файл 2.txt для зоны otherhost.ru. Отлично. Пропишите этот файл в named.conf, который будет выглядеть после этого вот так:

options   { directory "/etc/named"; notify yes; };
zone "."          { type hint;   file "root.txt"; };
zone "myhost.ru."    { type master; file "1.txt"; };
zone "otherhost.ru." { type master; file "2.txt"; };

И тут вы заметите поразительную вещь: оказывается, файлы 1.txt и 2.txt идентичны! Как говорится, если не видно разницы, зачем платить больше?.. Так что смело удаляйте 2.txt и изменяйте named.conf, чтобы он выглядел, например, вот так:

options  { directory "/etc/named"; notify yes; };
zone "." { type hint; file "root.txt"; };
zone "myhost.ru."      { type master; file "1.txt"; };
zone "otherhost.ru."   { type master; file "1.txt"; };
zone "microsoft.com."  { type master; file "1.txt"; };
zone "dklab.ru."       { type master; file "1.txt"; };

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

Создание вторичных зон

Напоследок несколько слов о том, как самостоятельно создавать вторичные зоны (до этого описывалось создание первичных), чтобы они автоматически синхронизировались с первичными. Это может понадобиться, если вы поставили еще одну машину в другой подсети класса C. Создать вторичную зону очень просто: достаточно добавить в named.conf такую строку:

zone "myhost.ru." { type slave; file "sec/myhost.ru."; masters { IP_адрес; }; };

Здесь IP_адрес — IP-адрес, по которому можно найти name-сервер, поддерживающий зону myhost.ru.

Кстати, master-сервер не обязательно должен поддерживать именно первичный вариант зоны. Если уж на то пошло, то концептуально «снаружи» вообще не видно, какая зона первична, а какая — вторична. Главное, чтобы с master-машины можно было скачать данные зоны — то есть, чтобы зона была прописана в его named.conf.

Чудес не бывает, и вам также придется создать директорию sec в /etc/named, чтобы туда named выкачивал данные вторичных зон. Он будет создавать там обычные текстовые файлы с именами, которые вы укажете в предложении file.

Еще несколько замечаний. Во-первых, в named.conf можно сочетать записи о первичных и вторичных зонах, и в этом смысле сервер может выступать в «смешанном варианте» — и первичным, и вторичным. Во-вторых, предложение notify yes, которое я с завидным постоянством приводил в примерах named.conf выше, означает, что при изменении зоны все вторичные сервера (грубо говоря) должны об этом информироваться. В-третьих, под «изменением зоны» здесь понимается изменение serial-номера в файле зоны и перезапуск named. К сожалению, named не умеет обнаруживать модификации в файлах зон по их дате изменения, поэтому не забудьте изменять серийный номер зоны после ее правки.