Главная | Контакты



Главная > Программы

Настройка сервера named, или маленькие радости хостинг-провайдеров

Обычно настройка сервера доменных имен (named) в Unix кажется новичку довольно сложным занятием. И это несмотря на обилие статей в Интернете на эту тему! К сожалению, многие подобные статьи на практике оказываются излишне многословными и запутанными, перегруженными лишними деталями. Задача этой наблы - описать один частный случай настройки named, который может особенно пригодиться начинающим хостинг-провайдерам. Думаю, он подойдет и вам тоже.

Чайник 

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

Теория

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

Завершающая точка (в нашем примере после 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 просто, очень просто, проще некуда... Тогда у вас все получится.

У named есть всего один важный файл конфигурации, который нам необходимо исправить. Он называется /etc/named.conf. Вот как он будет выглядеть:
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 может послать пользователя к одному из корневых серверов за дальнейшей информацией. Не правда ли, удобно?..

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

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

Чайник 

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

Традиционно добавление новой зоны происходит по описанной выше схеме: создается файл, например, 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 не умеет обнаруживать модификации в файлах зон по их дате изменения, поэтому не забудьте изменять серийный номер зоны после ее правки.

Материал взят с сайта: http://dklab.ru/

Главная > Программы