Амедиатека списывает деньги с номера МТСЗапустил группу вконтактеНовые технологии дают толчок к будущемуЗа последние выходные почти полноценно перешёл на LinuxУмение ходить по грани

настройка доменного имени

Устанавливаем
 

$ sudo apt-get install bind9 dnsutils


Настраиваем

Сначала зададим демону syslog, что он должен слушать и писать логи от DNS-сервера. Для этого открываем файл /etc/rsyslog.conf и в самый конец файла добавляем вот такую запись:


!named
*.* /var/log/named.log
!-named

чем указываем системе писать логи bind в файл /var/log/named.log

Перезапускаем демона логирования:

$ sudo /etc/init.d/rsyslog restart


Далее, свои настройки bind хранит по пути /etc/bind. Переходим в эту директорию - все действо отныне будет разворачиваться там.
 

$ cd /etc/bind

Предполагается, что это у нас мастер-сервер (т.е. primary, основной).

1) Создаем каталог, в котором будут хранится конфигурации наших DNS зон.
 

$ sudo mkdir master

2) Открываем на редактирование файл named.conf.options и приводим его к такому виду (все опции прокомментированы, Вам необходимо их значения указывать верными для себя, а не копировать примеры):
 

options {
 directory "/var/cache/bind"

 # Здесь указываются сервера DNS, к которым будет обращаться этот сервер в случае,
 # если он сам не является хозяином домена, который резолвит. Обычно указываются
 # DNS-сервера Вашего провайдера и/или DNS-сервера контроллеров домена.
 # ..Например, если этот сервер спросить - какой IP у yandex.ru - то он сам не
 # будет знать, зато сможет спросить у выше-стоящего сервера DNS провайдера.
 forwarders {
  99.77.55.33;
  99.77.55.34;
  192.168.0.1;
 };

 # Откуда принимать DNS запросы. "any" означает - со всех интерфейсов от любого
 # компьютера
 allow-query { any; };

 # Здесь указываются slave-сервера DNS, которым дозволено передавать информацию
 # при обновлении DNS-зон на текущем сервере.
 allow-transfer {
  11.22.33.45;
  192.168.0.2;
 };

 # Здесь указываются адреса или подсети, с которых допускаются рекурсивные запросы.
 allow-recursion {
  127.0.0.1;
  192.168.0.0/24;
 };

 # При включении этой опции и изменении какой-либо DNS-зоны на этом сервере - он
 # самостоятельно известит все slave-сервера о том, что зона поменялась и ее
 # необходимо перезагрузить.
 notify yes;

 # По-умолчанию извещается только тот сервер (сервера), которые указаны как slave-
 # сервера внутри описания самой зоны. Если у Вас slave-сервер(а) один и тот же -
 # то логично прописать его(их) как сервера, которые всегда стоит уведомлять об
 # изменении зон. При этом, даже если эти сервера не являются носителями этих зон -
 # ничего страшного не произойдет - они просто "пропустят мимо ушей" информацию об
 # изменении.
 # Данная опция и предоставляет такую возможность - указать slave-DNS-сервера,
 # которые всегда извещяются об изменениях зон.
 also-notify {
  11.22.33.45;
  192.168.0.2;
 };

 auth-nxdomain no;

 # Ожидать ли запросы по IPv6 протоколу и откуда? "none" означает - не ожидать и
 # игнорировать; "any" означает ожидать от всех компьютеров.
 listen-on-v6 { none; };
 
};

Сохраняем файл.

3) Теперь открываем файл named.conf и видим, что в нем указаны 3 ссылки на наши конфигурации:
 

...
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

Мы добавим еще одну ссылку - на файл с описаниями наших DNS-зон:
 

...
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
# Тут будут наши зоны:
include "/etc/bind/named.conf.zones";

И сохраним данный конфиг-файл.

4) Теперь создадим файл /etc/bind/named.conf.zones и запишем в него тестовую зону. Выглядеть этот файл будет как-то так:
 

zone "test.int" {
 type master;
 file "/etc/bind/master/test.int";
};

Мы видим здесь, что я указал заведомо несуществующую в интернете зону "test.int". Ее тип на данном сервере - мастер (т.е. она является master-зоной, соответственно, если ее обновление должно вестись на данном сервере) и ее описание надо брать из указанного файла.

5) Ну что-ж, давайте создадим такой файл:
 

$ cd /etc/bind/master
$ sudo touch test.int

И положим в него примерно такой конфиг (опять-же, правильные значения IP-адресов и имен зависят от Вашей сети):
 

$ORIGIN .
$TTL 3600;
test.int.               IN SOA ns1.mydomain.ru. webadmin.mydomain.ru. (
                               2011080901 ; serial
                               28800      ; refresh (8 hours)
                               7200       ; retry (2 hours)
                               604800     ; expire (1 week)
                               86400      ; minimum (1 day)
                        )
                        NS ns1.mydomain.ru.
                        NS ns2.mydomain.ru.
                        A  192.168.0.50
                        MX 10 mail.mydomain.ru.

$ORIGIN test.int.
ftp                     A       192.168.0.51
mail                    A       192.168.0.3
www                     CNAME   test.int.

Как видно, все значения я в этой зоне накидал совершенно от балды.

Теперь сохраняем наш файл.

6) Просим bind перечитать наши конфиги:
 

$ sudo rndc reload

7) Проверяем:
 

$ nslookup test.int 127.0.0.1

И смотрим результат. Сервер должен ответить, что test.int находится по адресу 192.168.0.50 (как указано в конфигурации зоны выше, или же другой адрес- какой ввели Вы).


Дальнейшая жизнь DNS-сервера

Аналогичным образом создаются все остальные зоны, уже с реальными реквизитами (например, из зон .ru, .com и т.д.) Файл named.conf.zones выглядит примерно так:
 

zone "mydomain.ru" {
 type master;
 file "/etc/bind/master/mydomain.ru";
};

zone "anothersite.com" {
 type master;
 file "/etc/bind/master/anothersite.com";
};


И для каждой зоны создаем файлик с ее конфигурацией в /etc/bind/master подобно пробной конфигурации test.int.


PS. Совет. НЕ забывайте ставить ";" в конфиге named везде, где это нужно! Отсутствие одной такой точки-с-запятой обломит запуск всего bind.

PPS. НЕ забывайте ставить конечную точку "." в конце зон, которые являются абсолютными (рекомендуется вообще везде). Т.е., например, если вместо "test.int." в конфиге зоны написать "test.int" - получите Вы совсем не то, что ожидали! Ну и, соответственно, работать нифига не будет.

PPPS. При изменении (любом) зоны - не забывайте увеличивать ее сервийный номер (serial). Причем не просто менять - а именно увеличивать. В данном случае запись виде YYYYMMDDNN, где YYYY - год 4 цифры, MM - месяц 2 цифры, DD - 2 цифры дня и NN - это "какой раз я за этот день меняю зону" - вполне удобна, т.к. по течению времени ее числовое значение будет только увеличиваться.



Сначала пара слов - для чего. Дело в том, что регистраторы требуют наличие минимум двух серверов DNS с различными IP-адресами и/или именами в интернете для регистрации зон DNS. Объяснение простое - один сервер должен быть основный, второй - на случай отказа первого. По этой причине с только одним сервером имен Вы можете работать с внутрисетью, но зарегистрировать зону в интернет не получится - с Вас спросят IP адрес еще одного такого "брата-собрата".


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

Общий вид схемы выглядит так: имеется мастер-сервер (главный) и один или несколько второстепенных (slave) серверов. Мастер-сервер (Master) хранит у себя информацию и именно на этом сервере администратор изменяет зоны DNS при необходимости. Дополнительные (Slave) сервера получают обновления данных по зонам от мастер-сервера и имеют полную актуальную картину "мира" тех зон, которые обслуживают.

При этом Slave сервера так-же имеют полную информацию о зонах DNS, которые они обслуживают. Поэтому при отказе мастер-сервера любую обслуживаемую зону можно получить с второстепенного - он так-же ответит на запрос.

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


Ну что-ж, хватит жевать теорию (тем более, что намного больше можно прочитать в специализированной литературе). У нас задача - показать, как установить и настроить второстепенный сервер DNS на машине под управлением Linux Debian.



Установка
 

$ sudo aptitude install bind9 dnsutils



Настройка

Свои настройки bind хранит по пути /etc/bind. Переходим в эту директорию - все действо отныне будет разворачиваться там.



$ cd /etc/bind


1) Создаем каталог, в котором будут хранится конфигурации наших DNS зон.
 

$ sudo mkdir slave

Заметка. Самостоятельно ничего в этот каталог записывать не надо! Служба DNS slave-сервера сама будет создавать здесь файлы зон во время синхронизации с мастер-сервером.


2) Открываем на редактирование файл named.conf.options и приводим его к такому виду (опции прокомментированы, Вам необходимо их значения указывать верными для себя, а не копировать примеры):



options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        auth-nxdomain no;    # conform to RFC1035

        // Раскомментируйте для включения поддержки IPv6
//      listen-on-v6 { any; };

        // Серверы пересылки. При запросе у этого slave-сервера информации о
        // зоне, которая не входит в состав его списка обслуживания - у каких
        // серверов выше спросить про нее (например, если у сервера спрашивают
        // про зону google.com - у какого сервера спросить про эту зону - ведь
        // сам сервер ее не хостит).
        forwarders {
                11.22.33.33;
                192.168.1.1;
                99.88.77.66;
        };

        // Каким компьютерам или сетям позволять делать запросы к этому серверу
        // (any - всем). Для серверов, используемых для хостинга интернет-зон -
        // необходимо ставить "any", чтобы любой компьютер из интернета имел
        // возможность спросить его.
        allow-query             { any; };

        // Перечисление серверов DNS, с которыми разрешен обмен информацией о
        // зонах (синхронизация). ОЧЕНЬ не рекомендуется использоваться any здесь.
        allow-transfer  {
                        11.22.33.33;
                        192.168.1.1;
                        };

        // Принимать рекурсивные запросы от следующих компьютеров или сетей.
        allow-recursion {
                        127.0.0.1;
                        10.0.0.0/8;
                        192.168.0.0/16;
                        };

        // Извещать останльные сервера DNS из связки (мастер-вторые) при изменении
        // зоны DNS на этом сервере (если он по-совместительству является мастером
        // для каких-то зон).
        notify          yes;

        // Извещать следующие сервера об изменениях в зонах DNS.
        also-notify     {
                        11.22.33.33;
                        192.168.1.1;
                        192.168.0.1;
                        };

        // Принимать запросы только на интерфейсах с перечисленными IP-адресами.
        listen-on       {
                        127.0.0.1;
                        11.22.33.44;
                        192.168.1.2;
                        };
};

Здесь:


Как видно - все адреса - только для примера. В Вашем конкретном случае они будут своими.

Сохраняем файл.


3) Теперь открываем файл named.conf и видим, что в нем указаны 3 ссылки на наши конфигурации:
 

...
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

Мы добавим еще одну ссылку - на файл с описаниями наших DNS-зон:
 

...
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
# Тут будут описания наших slave-зон:
include "/etc/bind/named.conf.zones";

И сохраним данный конфиг-файл.


4) Теперь создадим файл /etc/bind/named.conf.zones и запишем в него тестовую зону. Выглядеть этот файл будет как-то так:
 

zone "test.int" {
type slave;
file "/etc/bind/slave/test.int";
masters { 11.22.33.33; };
};

Мы видим здесь, что я указал заведомо несуществующую в интернете зону "test.int". Ее тип на данном сервере - ведомая (slave), поэтому мы добавили опцию "masters", внутри которой указали - с какого сервера получать и запрашивать обновления.

Таким образом, на slave-сервере тоже нужно объявлять зоны DNS, которыми он будет владеть и указывать - с какого именно сервера получать информацию по этим зонам. Отличие заключается в том, что сами зоны прописывать не надо (т.е. НЕ нужно создавать файлы с конфигурациями зон) - BIND самостоятельно свяжется с мастер-сервером и получит все необходимые данные.


Заметка. Для того, чтобы тест прошел успешно - зона test.int должна быть объявлена на мастер-сервере. В данном случае - на сервере 11.22.33.44 (кстати, не забудте изменить этот фиктивный IP-адрес на адрес Вашего мастер-сервера!)
При уже запущенном и работающем мастер-сервере можно вместо test.int использовать существующую "боевую" зону.




Проверка

Попросим наш второстепенный сервер перечитать информацию:
 

$ sudo rndc reload

Если на стороне мастер-сервера все настроено правильно - то slave-сервер скопирует к себе DNS-зону test.int и начнет отвечать на запросы касательно нее.

Проверяем. В каталоге /etc/bind/slave должен появиться файл test.int с содержимым, идентичным зоне на стороне master-сервера. Именно так - нам не нужно было самим забивать зону на стороне ведомого сервера - он сам ее прочитал с мастер-сервера.

Теперь проверим, что slave-сервер отвечает на запросы по зоне test.int:
 

$ nslookup test.int 127.0.0.1

В случае успеха - ответ должен Вам предоставить информацию о IP адресе зоны.

На этом настройка сервера заканчивается.



Еще немного

Первое. Чтобы slave-сервера копировали измененные зоны с мастер-серверов - параметр "Serial " (т.е. серийный номер) редактируемой зоны администратор должен увеличивать. Причем именно увеличивать - а не просто менять.

Логика тут такая: slave-сервер при синхронизации не получает каждый раз весь набор данных по каждой зоне. Он смотрит только на серийный номер зон - и только в случае, если серийный номер увеличился (не остался таким-же и не уменьшился) - только в таком случае ведомый запрашивает всю информацию с мастер-сервера по данной зоне.


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

$ sudo rndc retransfer test.int


Где вместо test.int - указывайте имя зоны, которую необходимо передать на slave-сервер в принудительном порядке.