![]() |
![]() |
![]() |
![]() |
![]() |
![]() ![]() ![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
|
[30 декабря 2001 г.] |
Не так страшен черт, как его малютка Народная мудрость |
Обычно настройка сервера доменных имен (named) в Unix кажется новичку довольно сложным занятием. И это несмотря на обилие статей в Интернете на эту тему! К сожалению, многие подобные статьи на практике оказываются излишне многословными и запутанными, перегруженными лишними деталями. Задача этой
![]() |
Для |
Как известно, протокол TCP/IP, которым пользуются в Интернете, может адресовать хосты лишь по 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-сервер, а два, причем работающие синхронно (то есть, возвращающие одно и то же для запроса 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 и
включать ее целиком в ежедневный бэкап, чтобы случайно что-нибудь не потерялось.
|
Начнем со второй зоны, так как она наиболее интересна. Буквально тут записано, что данные зоны находятся в файле
$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
Казалось бы, все просто. Так оно, в общем-то, и есть. Заметьте, что мы нигде не привязываемся непосредственно к имени
![]() |
Строка с типом |
Вернемся чуть назад, к рассмотрению файла
. 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
Думаю, нет смысла разбираться, что все это
Раньше мы рассматривали пример, когда кто-то подключается к named и запрашивает у него резолвинг домена
Вот здесь вы можете посмотреть на все файлы, которые затронула настройка named.
Но что, если мы захотим добавить к нашей системе еще несколько доменов (
![]() |
Благодаря протоколу HTTP/1.1, который используют все браузеры и Web-серверы, сервер способен определить, к какому хосту пришел запрос, даже если все хосты «висят» на одном и том же IP-адресе. Подробнее об этом можно прочитать, например, в статье об установке Apache. |
Традиционно добавление новой зоны происходит по описанной выше схеме: создается файл, например,
Однако не стоит отчаиваться. Думаю, решение находится на поверхности, и вы сейчас сами догадаетесь, в чем оно заключается. Просто создайте вторую
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"; };
И тут вы заметите поразительную вещь: оказывается, файлы
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-адрес вам будет достаточно лишь поменять запись в
Напоследок несколько слов о том, как самостоятельно создавать вторичные зоны (до этого описывалось создание первичных), чтобы они автоматически синхронизировались с первичными. Это может понадобиться, если вы поставили еще одну машину в другой подсети класса C. Создать вторичную зону очень просто: достаточно добавить в
zone "myhost.ru." { type slave; file "sec/myhost.ru."; masters { IP_адрес; }; };
Здесь
![]() |
Кстати, master-сервер не обязательно должен поддерживать именно первичный вариант зоны. Если уж на то пошло, то концептуально «снаружи» вообще не видно, какая зона первична, а |
Чудес не бывает, и вам также придется создать директорию
![]() |
Еще несколько замечаний. Во-первых, в |
![]() |
|
Дмитрий Котеров |
30 декабря 2001 г.
©1999-2019
|
|
Вернуться к оглавлению |