Имена Интернет

Печать статьи

Читать журнал

Скачать журнал

Автор статьи: Подстрешный Артем ©

Сайт Автора: нет

E-mail Автора: art@radio-msu.net

Дата публикации: 15.03.2006

Как настроить dns

Сама программа named в большинстве случаев входит в стандартный набор средств операционных систем unix. Если в вашем случае ее не оказалось, попробуйте сделать поиск программы named для вашей системы в поисковых серверах интернета (altavista, lycos и т.д.). Обычно главный файл с настройками named называется named.boot и лежит в директории /etc. Запускать демон named обязательно с привилегиями пользователя root.

В данном случае рассматривается freebsd версии 2.2.2 со стандартной named. Сама программа лежит в /usr/sbin/named, а заготовки для конфигурации в директории /etc/namedb.

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

Скопируем named.boot в нужную директорию:

% cp /etc/namedb/named.boot /etc

Комментарии в named.boot начинаются с ";" на первом месте в строке.

Рассмотрим различные директивы в named.boot:


directory       /etc/namedb

Это та директория, в которой будут храниться конфигурационные файлы для каждого из доменов, которые этот name-сервер будет держать.


cache    .   named.root

Эта специальная опция задает имя файла named.root в директории /etc/namedb, в котором содержатся ip-адреса компьютеров, которые "знают все" о доменных именах, то есть, содержат домен "точка". В этих серверах хранится информация обо всех доменах верхнего уровня, и если на dns-запрос ответ не был дан на более раннем этапе, то, добежав до одного из таких top-level серверов, запрос пойдет по необходимой ветке вниз. Вот кусок этого файла:


; formerly ns.internic.net
.                        3600000  in  ns    a.root-servers.net.
a.root-servers.net.      3600000      a     198.41.0.4

; formerly ns1.isi.edu

.                        3600000      ns    b.root-servers.net.
b.root-servers.net.      3600000      a     128.9.0.107

Файл named.root впоследствие нужно периодически забирать с ftp.rs.internic.net, так как ip-адреса top-level серверов через несколько месяцев могут и поменяться.

Следующая директива в конфигурационном файле говорит о том, что наш name-сервер является primary name-сервером для какой-то зоны, то есть, содержит всю информацию о ней. Синтаксис ее таков:

primary [имя.домена] [имя_файла]

Пример:


primary radio-msu.net db.radio-msu.net
primary math.msu.su db.math.msu.su

Это означает, что мы установили primary nameserver для доменов radio-msu.net (домен второго уровня) и math.msu.su (третьего уровня), но мы проделали только небольшую часть работы. После этого нужно будет описать эти домены в текстовых файлах, называющихся db.radio-msu.net и db.msu.su в директории /etc/namedb. Мы специально выбрали имена файлов похожими на имена соответствующих им доменов из соображений удобства. Имена конфигурационных файлов больше нигде роли не играют, и вы вправе их называть как угодно. Создавать и редактировать их можно при помощи обычного текстового редактора, находясь в директории /etc/namedb. Подробное описание db.* файлов будет дано чуть ниже.

Для того, чтобы стать вторичным nameserver'ом для других доменов, в named.boot нужно написать строчку такого плана:


secondary npi.msu.su    158.250.2.232 db.npi.msu.su
secondary rector.msu.su 193.232.112.1 db.rector.msu.su

Общий вид директивы таков:

secondary [имя.домена] [ip-адрес primary nameserver'а] [имя_файла]

Первый параметр здесь - имя домена, для которого мы устанавливаем secondary. Для него обязательно должен существовать первичный name-сервер, с которого демон будет периодически считывать данные об этом домене. Вместо одного ip-адреса primary nameserver'а может идти и список адресов, откуда еще можно узнать информацию о домене. Это используется в том случае, если мы создаем многоуровневую систему nameserver'ов с различными приоритетами, и т.д. В большинстве случаев в это поле заносится только адрес primary. Последний параметр - имя временного файла, выбранное нами произвольным образом, в котором демон named будет хранить информацию о домене, полученную от primary name-сервера. Как и в первом случае, имена файлов лучше назначать созвучными с именем домена. Кстати, для того, чтобы установить вторичный nameserver для домена, нужно только добавить одну такую строчку named.boot, и все.

Чтобы правильно настроить primary name-сервер, нам осталось рассмотреть конфигурационные файлы db.* (эти файлы также называются файлами зоны). Общий вид записи в этом файле:

[domain] [opt_ttl] [opt_class] [type] [resource_record_data]

где domain есть "." для описания домена верхнего уровня, "@" для текущего домена или обычное доменное имя (в частности, просто имя машины (hostname)).

opt_ttl - необязательное поле, целое число, которое означает время жизни (time-to-live) этой записи в секундах. По истечении этого срока содержимое записи должно автоматически обновиться.

opt_class - тип адреса объекта. Такой тип существует только один, который, собственно, и указывается ("in").

type - тип записи (рассмариваются ниже)

resource_record_data - данные этого типа

Рассмотрим пример primary nameserver'а и соответствующего ему файлу зоны для домена radio-msu.net. В случае, если вы будете использовать эти примеры как руководство, не забудьте, пожайлуста, поменять все записи соответственно структуре вашей сети.

В named.boot мы должны прописать такую строчку:


primary  radio-msu.net  db.radio-msu.net

И в директории /etc/namedb создаем файл с названием db.radio-msu.net примерно такого содержания:


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;     bind configuration for the primary nameserver
;             radio-msu.net host table
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
@               in      soa  ns.radio-msu.net.  art.radio-msu.net. (
                        1998022300      ; serial
                        28800           ; refresh
                        7200            ; retry
                        604800          ; expire
                        86400 ) ; minimum ttl
;----------------------------------------------------------------
                in      ns              ns.radio-msu.net.
                        ns              mskws.desy.de.
localhost       in      a               127.0.0.1
;----------------------------------------------------------------
@               in      mx      20      mpr
                        mx      40      mskws.desy.de.
;----------------------------------------------------------------
ns              in      a               193.124.134.1
                in      mx      10      ns
                in      mx      50      relay
;----------------------------------------------------------------
telion                  in      a       193.124.134.2
                        mx      10      telion
                        mx      20      relay.radio-msu.net.
                        mx      50      mskws.desy.de.
www                     in      cname   telion
;----------------------------------------------------------------
noc                     in      a       193.124.134.101
                        in      mx      10 noc
                        in      mx      20 relay
;----------------------------------------------------------------
mpr                     in      a       193.124.134.3
                        mx      10      mpr
                        mx      50      mskws.desy.de.
pop                     in      a       193.124.134.3
uucp                    in      a       193.124.134.3
relay                   in      a       193.124.134.3
mail                    in      a       193.124.134.3
vika                    in      a       193.124.134.5
                        mx      10      vika
                        mx      50      relay
;----------------------------------------------------------------
brusun                  in      a       193.124.134.20
diana                   in      a       193.124.134.7
sftgames                in      cname   telion
chat                    in      cname   brusun
;------------------------  the  end  ----------------------------

Заметим, что все строки, начинающиеся с ";", являются комментариями и используются для улучшения читабельности текста.

Теперь рассмотрим типы записей, встречающиеся в нашей конфигурации:

Самая первая запись в любом таком файле выглядит следующим образом:


@               in      soa  ns.radio-msu.net.  art.radio-msu.net. (

Символ "@" означает, что дальнейшие директивы относятся к текущему домену (то есть, к домену radio-msu.net). Поле "in" можнно считать несущественым, а после него идет описание типа записи:

soa - (start of authorizing) - зона ответственности. Дальнейшие параметры определяют, кто отвечает за этот домен, как часто обновлять информацию об этой зоне на secondary-серверах, а также другую служебную информацию. Первое поле параметров этой записи - имя primary name-сервера, содержащего зону. После него следует адрес технического контактного лица, отвечающего за домен. Обратите особое внимание на точки в конце этих адресов! Точка в конце означает, что этот адрес является обычным доменным именем, и его не нужно дополнять справа доменом, которому соответствует наш конфигурационный файл. То есть, если вместо ns.radio-msu.net. написать ns.serv, то будет иметься ввиду компьютер ns.serv.radio-msu.net

Точку в конце символьных имен нужно не забывать ставить и в других полях зоны. Это одна из самых распространенных ошибок. Написать "ns.radio-msu.net" - значит, иметь ввиду сервер "ns.radio-msu.net.radio-msu.net", которого просто не существует.

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

Первое число ("1998022300" у нас) - сериальный номер (serial number) записи. По изменению сериального номера secondary name-сервера определяют, было ли изменено содержимое домена или нет, и соответственно, нужно ли считывать весь домен с primary-сервера. Сериальный номер должен состоять из десяти цифр и обязательно должен быть заменен вручную на какой-либо больший при любом измеении любой записи в файле домена. Для этих целей идеально подходит такой вариант: первые четыре цифры serial'а - год, затем две на месяц и число. Последние две - порядковый номер (начиная с 00) редакции в течение дня. Если мы меняем конфигурацию домена, то заодно мы должны увеличить и сериальный номер. А при таком задании serial'а увеличение происходит автоматом.

После сериального номера идет поле refresh, которое указывает время в секундах, по истечении которого secondary name-сервер проверяет не изменилась ли данная зона на primary-сервере, и если изменения были, то происходит передача файла с зоной.

Если при этом у него не получилось по каким-либо причинам соединиться с сервером, то следующую попытку secondary сделает по истечении retry секунд (третий параметр).

В том случае, если и последующие попытки подключиться к primary и узнать информацию о зоне оканчиваются неудачей, вторичный name-сервер по прошествии expire секунд забудет всю информацию по этой зоне.

Последнее поле ('minimum ttl') указывает на минимальное время жизни (time to live) записей в файле зоны, если только в какой-то записи не будет указано другое значение в необязательном поле opt_ttl.

Рекомендуемые значения для этих величин таковы:


 28800  ; refresh     8 hours
 7200   ; retry       2 hours
 604800 ; expire      7 days
 86400  ; minimum ttl 1 day

Однако вам никто не вправе помешать поставить свои значения. Только не ставьте слишком маленькие величины (меньше часа) - иначе вы просто забьете сеть бесполезной информацией, непрерывно пересылаемой от primary к secondary.

Теперь рассмотри записи следующего типа:

ns - (name server) - перечисляет name-сервера (и primary, и secondary), которые держат эту зону. Не забывайте про точку в конце имени!


                in      ns              ns.radio-msu.net.
                        ns              mskws.desy.de.

Здесь мы для зоны .radio-msu.net указали два name-сервера (первый из них - primary, второй - secondary), на которых содержится вся информация о домене.

Далее идет одна из наиболее часто встречающихся записей dns:

a - (address) - адрес хоста. На первом месте в такой строке будет стоять символьное имя компьютера в текущем домене, после этого "in a", а затем - числовой ip-адрес, соответствующий этой машине. Рекомендуется внести, например, такую строку в файл зоны:


localhost       in      a               127.0.0.1

Это позволит обращаться с любого компьютера в сети к самому себе, используя зарезервированное имя localhost. Для того, чтобы как-нибудь назвать новый компьютер в сети, вам нужно просто добавить такую строчку в файл зоны (не забудьте только после этого подправить сериальный номер в записи soa и после всех изменений перезапустить демон named (сделать ему kill -1)).

В рассмотренном примере мы видим такие строки:


ns              in      a               193.124.134.1
telion          in      a               193.124.134.2
diana           in      a               193.124.134.7

Значит, мы назвали компьютеры с соответствующими ip-адресами именами ns,telion и diana. Очень часто используется имя www, которое позволяет обращаться к web-серверу домена. Если бы мы изменили здесь слово 'telion' на 'www', то по адресу http://www.radio-msu.net/ откликнулась машина с ip-адресом 193.124.134.2. В нашем случае, можно поступить более хитрым образом, используя запись типа cname.

cname - (canonical name) - в транслитерации с латинского, на компьютерном жаргоне такая запись называется алиас (alias). Вы как бы добавляете компьютеру еще одно имя, которое при разрешении превратится в тот же ip-адрес, что и основное имя.


www             in      cname   telion

Теперь имя www.radio-msu.net будет аналогично telion.radio-msu.net. Алиасов для одного ip-адреса может быть сколько угодно, но на них накладывается единственное условие: то имя (каноническое), которое стоит после cname, должно также где-либо быть описанным. Допускается использовать в качестве канонического имени и alias, лишь бы такая цепочка алиасов не замыкалась. В качестве cname может выступать любой именной адрес в сети, не обязательно из текущего домена, например:


other           in      cname   www.sun.com.

И пойдя теперь по адресу other.radio-msu.net, мы попадем на сервер sun microsystems.

Заметим еще один момент. Второе имя компьютеру можно дать и так:


mail                    in      a       193.124.134.3
relay                   in      a       193.124.134.3

При этом у нас будет несколько записей типа 'a', соответствующих одному ip-адресу. Это ничему не противоречит, но так делать - плохой стиль.

Следующий важный тип записей - записи типа mx.

mx - (mail exchange) - пересылка почтовых сообщений. Они обычно следуют за записями типа 'a' или 'soa'. Используются они обычно так:

[domain] in mx [pref_value] [mail_server]

где domain - необязательное поле. Если оно есть, то запись онтосится к этому домену, если нет - то к предыдущему с типом 'a'. В том случае, если на месте [domain] стоит символ '@' или это поле отсутствует, но сама запись находится в самом начале файла зоны (сразу же после soa), то такое поле mx будет относиться к домену, которому соответствует текущий db-файл.

'in' также можно указывать, а можно опускать. mail_server - доменное имя почтового сервера, которому достанется вся почта, приходящая на этот домен. На этом сервере должны стоять программы, поддерживающие почтовый протокол smtp. Для повышения надежности пересылки почты, вы можете указать подряд несколько почтовых серверов. В том случае, если один из них перестанет работать, вся почта на домен будет отправляться на эти "запасные" mail-сервера, которые при первой же возможности отправят все накопившиеся у них электронные письма на основной почтовый сервер. Чтобы регулировать такую систему, и вводится параметр pref_value (приоритет соответствующего почтового сервера), который может меняться от 0 (самый большой приоритет) до 32767 (почта на mail-сервер с таким значением pref_value будет приходить в совсем крайнем случае). Если у вас запись mx единственная для какого-то домена, то значение этого поля не играет роли. Но при использовании только одного mail-сервера в те моменты, когда он по каким-либо причинам недоступен, почта будет теряться. Поэтому обыкновенно ставят две-три mx-записи, а приоритеты у них устанавливают круглыми числами от 10 до 100. Пример:


mpr                     in      a       193.124.134.3
                        mx      10      mpr
                        mx      50      mskws.desy.de.

Итак, почта, идущая на mpr (например, на [email protected]), прежде всего попытается лечь на сам mpr, а в том случае, если у нее это не получится, то будет использован второй вариант (50 больше, чем 10) - mskws.desy.de, где почта пролежит до того момента, пока mpr опять не заработает. Зачастую нужно использовать более короткие почтовые адреса, вроде [email protected]. Делается это таким образом:


@               in      mx      20      mpr
                        mx      40      mskws.desy.de.

Ситуация в точности та же. Почта на [email protected] перенаправляется на mpr (или на mskws), а на этих компьютерах уже должны быть корректно настроены почтовые программы, понимающие, на какой домен приходит почта и что с ней надо делать дальше. Для этого вам, к несчастью, придется ознакомиться с соответствующей документацией к почтовому серверу.

Следующие типы записей используются реже, тем не менее, приведем их тут:

null - пустая запись. Скорее всего, должна использоваться для резервирования доменного имени, но на практике применяется только в том случае, если необходимо убрать на некоторое время из dns'а запись о какой-то машине. Хотя проще такие строчки просто закомментарить.

rp - (responsible person) - ответственное за этот домен лицо:


xerox		in	rp	ivanov ivan

hinfo - (host information) - информация о компьютере (тип процессора, операционная система и т.д.). Используется крайне редко.

Нам осталось рассмотреть последний особый тип записи 'ptr' (domain name pointer), эта запись используется в db.* файлах так называемой "обратной зоны" (reverse-dns).

Список похожих статей