Доме­ны име­ют как мини­мум два DNS сер­ве­ра, один назы­ва­ет­ся пер­вич­ным сер­ве­ром имён (ns1), а дру­гой — вто­рич­ным сер­ве­ром имён (ns2). Вто­рич­ные сер­ве­ра обыч­но задей­ству­ют­ся при про­бле­мах с пер­вич­ным сер­ве­ром DNS: если один сер­вер недо­сту­пен, то вто­рой ста­но­вит­ся актив­ным. Воз­мож­ны и более слож­ные схе­мы с исполь­зо­ва­ни­ем балан­си­ров­ки нагруз­ки, фай­ер­во­лов и кластеров.

Thank you for reading this post, don't forget to subscribe! 

Все DNS запи­си опре­де­лён­но­го доме­на добав­ля­ют­ся в пер­вич­ный сер­вер имён. Вто­рич­ный сер­вер про­сто син­хро­ни­зи­ру­ет всю инфор­ма­цию, полу­чая её от пер­вич­но­го, на осно­ва­нии пара­мет­ров, задан­ных на пер­вич­ном сервере.

Эта инструк­ция опи­шет, как создать пер­вич­ный DNS сер­вер, рабо­та­ю­щий на CentOS. Пожа­луй­ста, обра­ти­те вни­ма­ние, что DNS сер­вер, пред­став­лен­ный в этой инструк­ции, будет пуб­лич­ным DNS, это озна­ча­ет, что сер­вер будет отве­чать на запро­сы от любо­го IP адре­са. Как огра­ни­чить доступ к сер­ве­ру, опи­са­но в этой инструкции.

Перед тем, как мы нач­нём, хоте­лось бы упо­мя­нуть, что DNS может быть уста­нов­лен с или без chroot jail окру­же­ни­ем. Окру­же­ние chroot jail огра­ни­чи­ва­ет DNS сер­вер опре­де­лён­ной дирек­то­ри­ей в систе­ме, в отли­чие от пол­но­го систем­но­го досту­па на сер­ве­ре. Таким обра­зом, любая уяз­ви­мость DNS сер­ве­ра не ском­про­ми­ти­ру­ет всю систе­му. Огра­ни­че­ние DNS сер­ве­ра в опре­де­лён­ной дирек­то­рии (про­цесс назы­ва­ет­ся chrooting) так­же полез­но в тесто­вых условиях.

Установка пакетов

Мы будем исполь­зо­вать bind для DNS, кото­рый с лёг­ко­стью может быть уста­нов­лен коман­дой yum.

Уста­нов­ка DNS без chroot:

yum install bind

Уста­нов­ка DNS с chroot:

yum install bind bind-chroot

Подготовка конфигурационных файлов

Как было упо­мя­ну­то ранее, bind может быть настро­ен с или без chroot. Пути немно­го раз­ли­ча­ют­ся, в зави­си­мо­сти от того, был ли уста­нов­лен chroot.

Путь до кон­фи­гу­ра­ци­он­но­го фай­ла    Путь до фай­лов зоны

Без chroot /etc/                           /var/named/

С chroot   /var/named/chroot/etc/          /var/named/chroot/var/named/

Мож­но исполь­зо­вать кон­фи­гу­ра­ци­он­ный файл named.conf, кото­рый постав­ля­ет­ся по умол­ча­нию. Тем не менее, мы будем исполь­зо­вать дру­гой при­мер­ный кон­фи­гу­ра­ци­он­ный файл для про­сто­ты использования.

Дела­ем резерв­ную копию фай­ла /etc/named.conf
cp /etc/named.conf /etc/named.conf.bak

Без chroot:

cp /usr/share/doc/bind-9.9.4/sample/etc/named.rfc1912.zones /etc/named.conf

С chroot:

cp /usr/share/doc/bind-9.9.4/sample/etc/named.rfc1912.zones /var/named/chroot/etc/named.conf

Теперь, когда есть резерв­ная копия кон­фи­гу­ра­ци­он­но­го фай­ла, а сам ори­ги­нальн­вй файл изме­нён, дви­га­ем­ся дальше.

Без chroot:

# vim /etc/named.conf

С chroot:

# vim /var/named/chroot/etc/named.conf

Сле­ду­ю­щие стро­ки были добавлены/изменены.

options {
## путь до фай­лов зон ##
directory "/var/named";

## пене­ра­прав­ля­ем запро­сы на пуб­лич­ный DNS сер­вер Google для нело­каль­ных доменов ##
forwarders { 8.8.8.8; };
};

## объ­яв­ле­ние пря­мой зоны для example.tst ##
zone "example.tst" IN {
type master;
file "example-fz"; ## файл для пря­мой зоны раз­ме­щён в /var/named ##
allow-update { none; };
};

## объ­яв­ле­ние обрат­ной зоны для сети 172.16.1.0 ##
zone "1.16.172.in-addr.arpa" IN {
type master;
file "rz-172-16-1"; ## файл для обрат­ной зоны раз­ме­щён в /var/named ##
allow-update { none; };
};

 

Дирек­ти­ва listen-on долж­на быть заком­мен­ти­ро­ва­на для про­слу­ши­ва­ния доступ­ных интер­фей­сов. Дирек­ти­ва recursion долж­на иметь зна­че­ние off, что­бы предот­вра­тить reflection DDoS-ата­ки. Дирек­ти­ва allow-transfer добав­ля­ет в белый спи­сок IP-адрес вто­рич­но­го сер­ве­ра. кро­ме того, нуж­но изме­нить зна­че­ние дирек­ти­вы allow-query на any, что­бы предо­ста­вить поль­зо­ва­те­лям доступ к зонам.

 

Подготовка файлов зон

Дефолт­ные фай­лы зон авто­ма­ти­че­ски созда­ны в /var/named или /var/named/chroot/var/named (для chroot).

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

Без chroot:

# cp /usr/share/doc/bind-9.9.4/sample/var/named/named.* /var/named/

С chroot:

# cp /usr/share/doc/bind-9.9.4/sample/var/named/named.* /var/named/chroot/var/named

Отлич­но. Теперь дефолт­ные фай­лы зоны гото­вы, мы созда­ём наши соб­ствен­ные фай­лы зоны для example.tst и сети 172.16.1.0. Пока мы созда­ём фай­лы зоны, нуж­но пом­нить следующее.

• Сим­вол ‘@’ озна­ча­ет NULL в фай­лах зоны.
• Каж­дая запись пол­но­го домен­но­го име­ни (FQDN) закан­чи­ва­ет­ся точ­кой ‘.’ напри­мер. mail.example.tst. Без точ­ки, будут проблемы.

1. Прямая зона

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

Без chroot:

# vim /var/named/example-fz

С chroot:

# vim /var/named/chroot/var/named/example-fz

$TTL 1D
@ IN SOA ns1.example.tst. mial.example.tst. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
IN NS ns1.example.tst.
IN A 172.16.1.3
mail IN A 172.16.1.1
IN MX 10 mail.example.tst.
www IN A 172.16.1.2
ns1 IN A 172.16.1.3
ftp IN CNAME www.example.tst.

Объ­яс­не­ние: Внут­ри фай­ла зоны, SOA озна­ча­ет нача­ло авто­ри­за­ции. Это пол­ное домен­ное имя авто­ри­тет­но­го сер­ве­ра имен. После пол­но­го домен­но­го име­ни, идёт кон­такт­ный email адрес. Посколь­ку мы не можем исполь­зо­вать ‘@’ в mial@example.tst, мы пере­за­пи­сы­ва­ем email адрес как mial.example.tst.

• NS: Имя сервера
• A: A запись или запись адре­са — это IP адрес
• MX: Mail Exchanger запись. Здесь мы исполь­зу­ем толь­ко один MX с при­о­ри­те­том 10. В слу­чае мно­же­ства MX, мы можем исполь­зо­вать раз­лич­ные циф­ро­вые при­о­ри­те­ты. Ниж­ний номер выиг­ры­ва­ет. Напри­мер, MX 0 луч­ше чем MX 1.
• CNAME: имя в кано­ни­че­ском виде. Если на сер­ве­ре раз­ме­ще­но мно­же­ство служб, весь­ма веро­ят­но, что мно­же­ство имён будут пре­об­ра­зо­вы­вать­ся к одно­му сер­ве­ру. CNAME сиг­на­ли­зи­ру­ет, что дру­гие име­на сер­вер может иметь и отсы­ла­ет к име­ни, кото­рое содер­жит­ся в A записи.

2. Обратная зона

Обрат­ная зона содер­жит кар­ту пре­об­ра­зо­ва­ний из IP адре­сов в име­на. Здесь мы созда­ём обрат­ную зону для сети 172.16.1.0. В реаль­ном домене, DNS сер­вер вла­дель­ца пуб­лич­но­го IP бло­ка содер­жит­ся в фай­ле обрат­ной зоны.

Без chroot:

# vim /var/named/rz-172-16-1

С chroot

# vim /var/named/chroot/var/named/rz-172-16-1

$TTL 1D
@ IN SOA ns1.example.tst. sarmed.example.tst. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
IN NS ns1.example.tst.
1 IN PTR mail.example.tst.
2 IN PTR www.example.tst.
3 IN PTR ns1.example.tst.

Объ­яс­не­ние: Боль­шин­ство исполь­зу­е­мых пара­мет­ров в обрат­ной зоне иден­тич­ный пря­мой зоне, кро­ме одного.

• PTR: PTR или запись ука­за­те­ля, она ука­зы­ва­ет на пол­ное домен­ное имя

Завершение

Теперь, когда фай­лы зон гото­вы, мы настро­ем раз­ре­ше­ние фай­лов зоны.

Без chroot:

# chgrp named /var/named/*

С chroot:

# chgrp named /var/named/chroot/var/named/*

Сей­час мы зада­дим IP адрес DNS сервера.

# vim /etc/resolv.conf
nameserver 172.16.1.3

Нако­нец, мы можем запу­стить служ­бу DNS и убе­дить­ся, что она добав­ле­на в автозапуск.

# service named restart
# chkconfig named on

Когда DNS зара­бо­та­ет, реко­мен­ду­ет­ся погля­ды­вать в файл жур­на­ла /var/log/messages, посколь­ку он содер­жит полез­ную инфор­ма­цию о том, что про­ис­хо­дит «за сце­ной». Если там нет оши­бок, мы можем начать тести­ро­вать DNS сервер.

Тестирование DNS

Мы можем исполь­зо­вать dig или nslookup для тести­ро­ва­ния DNS. Вна­ча­ле, мы уста­но­вим необ­хо­ди­мые пакеты.

# yum install bind-utils

1. Тестирование прямой зоны с использованием dig

Когда вы исполь­зу­е­те для тести­ро­ва­ния dig, вам все­гда сле­ду­ет искать ста­тус "NOERROR". Любое дру­гое состо­я­ние озна­ча­ет, что что-то не так.

# dig example.tst

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31184

;; QUESTION SECTION:
;example.com. IN A

;; ANSWER SECTION:
example.com. 86400 IN A 172.16.1.3

;; AUTHORITY SECTION:
example.com. 86400 IN NS ns1.example.com.

;; ADDITIONAL SECTION:
ns1.example.com. 86400 IN A 172.16.1.3

2. Проверка PTR с помощью dig

Когда вы исполь­зу­е­те для тести­ро­ва­ния dig, вам все­гда сле­ду­ет искать ста­тус "NOERROR". Любое дру­гое состо­я­ние озна­ча­ет, что что-то не так.

# dig -x 172.16.1.1

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27415

;; QUESTION SECTION:
;1.1.17.172.in-addr.arpa. IN PTR

;; ANSWER SECTION:
1.1.16.172.in-addr.arpa. 86400 IN PTR mail.example.tst.

;; AUTHORITY SECTION:
1.16.172.in-addr.arpa. 86400 IN NS ns1.example.tst.

;; ADDITIONAL SECTION:
ns1.example.tst. 86400 IN A 172.16.1.3

3. Проверка MX с помощью dig

# dig example.tst mx

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35405

;; QUESTION SECTION:
;example.tst. IN MX

;; ANSWER SECTION:
example.tst. 14366 IN MX 10 mail.example.tst.

Подсказки при решении проблем

1. У меня отклю­чён SELinux.
2. Убе­ди­тесь, что ваш фай­ер­вол не бло­ки­ру­ет UDP порт 53
3. /var/log/messages дол­жен содер­жать полез­ную инфор­ма­цию в слу­чае, если что-то не так
4. Убе­ди­тесь, что вла­дель­цев фай­лов зон явля­ет­ся поль­зо­ва­тель ‘named’
5. Убе­ди­тесь, что IP адрес DNS сер­ве­ра сто­ит на пер­вом месте в /etc/resolv.conf
6. Если вы исполь­зу­е­те example.tst в лабо­ра­тор­ных усло­ви­ях, убе­ди­тесь, что отсо­еди­ни­ли сер­вер от Интер­не­та, посколь­ку example.tst — это несу­ще­ству­ю­щий домен.

 

 

 

 

В дан­ной ста­тье мы рас­смот­рим про­стой при­мер уста­нов­ки BIND на CentOS 6-вер­сии. BIND – одна из попу­ляр­ных реа­ли­за­ций DNS-сер­ве­ра, с откры­тым исход­ным кодом. DNS – сер­ве­ра выпол­ня­ют пре­об­ра­зо­ва­ние DNS-име­ни в IP-адрес и наоборот.
Перед нача­лом уста­нов­ки хоте­лось бы отме­тить, что реко­мен­ду­ет­ся иметь хотя бы два сер­ве­ра в обла­ке, что­бы обес­пе­чить луч­шую рабо­то­спо­соб­ность в слу­чае отка­за рабо­ты одно­го из сер­ве­ров. В нашем при­ме­ре мы пред­по­ла­га­ем настрой­ку как пер­вич­но­го, так и вто­рич­но­го сер­ве­ра DNS.

Обра­ти­те вни­ма­ние, что если вы реши­ли исполь­зо­вать боль­шое коли­че­ство домен­ных имен, то кон­фи­гу­ри­ро­ва­ние настро­ек подоб­ным обра­зом может ока­зать­ся не очень удобным.
Исполь­зо­ва­ние сво­е­го сер­ве­ра DNS поз­во­ля­ет иметь более пря­мой кон­троль над инфра­струк­ту­рой ваше­го хостин­га, а так же DNS запи­ся­ми. Пожа­луй, мож­но при­сту­пать к установке.

Пер­вое что сле­ду­ет сде­лать, про­ве­рить акту­аль­ность систе­мы, и обно­вить в слу­чае необ­хо­ди­мо­сти. Про­ве­рить нали­чие обнов­ле­ний вы може­те посред­ством коман­ды yum.

После это­го мож­но при­сту­пить в пер­вич­ной уста­нов­ке BIND на сервер.

Пер­вич­ная уста­нов­ка BIND на сервер

После уста­нов­ки сер­ве­ра необ­хо­ди­мо открыть кон­фи­гу­ра­ци­он­ный файл для настрой­ки конфигурации.

В кон­фи­гу­ра­ции «options» вме­сто IP адре­са 2.2.2.2 сле­ду­ет про­пи­сать адрес ваше­го вто­ро­го сервера.

Из сооб­ра­же­ний без­опас­но­сти мы заком­мен­ти­ро­ва­ли зна­че­ние дирек­ти­вы «listen-on». Пара­метр обо­зна­ча­ет, что сер­вер будет при­ни­мать обра­ще­ния со всех доступ­ных интер­фей­сов. Так же выстав­ля­ем дирек­ти­ву в «recursion» в «no», так как это может послу­жить уяз­ви­мо­стью для DDOS-атак на сер­вер. В дирек­ти­ве «allow-transfer» ука­зы­ва­ем сер­ве­ра, кото­рым мы «дове­ря­ем», это наш вто­рой сер­вер. Выстав­ля­ем для дирек­ти­вы «allow-query» зна­че­ние «any», это поз­во­лит полу­чать над­ле­жа­щий доступ к раз­ме­ща­е­мым домен­ным зонам.

Сле­ду­ю­щим шагом мы доба­вим запись для пер­во­го доме­на, в фай­ле кон­фи­гу­ра­ции named.conf

После сохра­не­ния фай­ла, мы можем при­сту­пить к созда­нию пер­во­го фай­ла домен­ной зоны. Созда­ем файл, исполь­зуя домен­ное имя исполь­зо­ван­ное выше, т.е. mydomain.com.zone:

Файл мы созда­ем, поэто­му нам в нем сле­ду­ет ука­зать кое-какие пара­мет­ры. Подоб­но при­ме­ру, пока­зан­но­му ниже, вы долж­ны заме­нить адре­са 1.1.1.1 – это адрес ваше­го пер­во­го сер­ве­ра (NS1), 2.2.2.2 – это адрес ваше­го вто­ро­го сер­ве­ра (NS2), и 3.3.3.3 – адрес, на кото­ром нахо­дит­ся веб-сер­вер. Допол­ни­тель­ные запи­си домен­ных имен вы може­те добав­лять в том же формате.

Теперь мы пер­вич­но запус­ка­ем сер­вер named. Это может занять неко­то­рое вре­мя, пока named сге­не­ри­ру­ет файл rndc.key, созда­ва­е­мый толь­ко при пер­вом запуске.

Выклю­чать DNS сер­вер при рабо­те не реко­мен­ду­ет­ся, но быва­ет слу­чаи, когда без это­го не обой­тись. Поэто­му добав­ля­ем сер­вер в автозагрузку.

После преды­ду­щих шагов настро­ек на дан­ный момент мы уже долж­ны иметь пол­но­стью рабо­то­спо­соб­ный пер­вич­ный DNS сер­вер. Что­бы про­ве­рить, что это дело рабо­та­ет, сле­ду­ет выпол­нить коман­ду ука­зан­ную ниже, а так же заме­нить адрес 1.1.1.1 на адрес ваше­го пер­вич­но­го сервера.

Если вы уви­ди­те харак­тер­ную запись, с обо­зна­че­ни­ем пол­но­мо­чий, то ваш сер­вер имен настро­ен правильно.

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

После это­го уста­нав­ли­ва­ем BIND сер­вер, а так же его ком­по­нен­ты на вто­рич­ный сер­вер, ана­ло­гич­ным обра­зом, как это дела­ли ранее.

Далее, так же как и на пер­вом сер­ве­ре имен, созда­ем файл named.conf и про­пи­сы­ва­ем в нем всё то же, за исклю­че­ни­ем дирек­ти­вы «allow transfer». Эта дирек­ти­ва не нуж­на, т.к. это вто­рич­ный сервер.

Добав­ля­ем запись зоны, ана­ло­гич­но пер­вич­но­му сер­ве­ру, за исклю­че­ни­ем того, что в дирек­ти­ве type нуж­но ука­зать slave, а так же поме­нять 1.1.1.1 на адрес пер­вич­но­го сервера.

После кон­фи­гу­ри­ро­ва­ния вто­рич­ной зоны, сле­ду­ет пере­за­пу­стить сер­вер named. Как и гово­ри­лось ранее, на этом сер­ве­ре так же будет создан файл rndc.key, это зай­мет немно­го времени.

Добав­ля­ем файл сер­вер в автозагрузку:

Про­ве­ря­ем, что всё рабо­та­ет, заме­ня­ем 2.2.2.2 на адрес ваше­го вто­рич­но­го сервера.

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

 

Формат файла зоны

Пер­вая стро­ка зада­ет пара­метр $TTL, кото­рый опре­де­ля­ет вре­мя кеши­ро­ва­ния поло­жи­тель­ных отве­тов (ответ в виде най­ден­но­го IP-адре­са). Здесь и далее, вре­мя может зада­вать­ся в секун­дах или с помо­щью сокра­ще­ний: m — мину­ты, h — часы, d — дни, w — недели.

В запи­си SOA ука­зы­ва­ет­ся primary NS для доме­на и e-mail кон­такт­но­го лица. В скоб­ках, по порядку:

1. Serial — Серий­ный номер. Каж­дый раз при изме­не­нии каких-либо дан­ных его нуж­но обя­за­тель­но менять. Когда меня­ет­ся серий­ный номер, зона обнов­ля­ет­ся на всех сер­ве­рах. Исполь­зуй­те сле­ду­ю­щий фор­мат: ГГГГ­ММДДнн (год, месяц, день, нн — поряд­ко­вый номер изме­не­ния за день). Если вы уже вто­рой раз за день вно­си­те изме­ния в файл зоны, ука­жи­те "нн" рав­ным 01, если тре­тий — 02, и т.д.
2. Refresh — интер­вал, через кото­рый slave сер­ве­ра долж­ны обра­щать­ся к primary сер­ве­ру и про­ве­рять обнов­ле­ние зоны.
3. Retry — если slave сер­ве­ру не уда­лось обра­тит­ся к primary сер­ве­ру, через это вре­мя он дол­жен повто­рить свой запрос.
4. Expiry — если в тече­нии это­го вре­ме­ни slave сер­вер так и не смог обно­вить зону с primary сер­ве­ра, то slave дол­жен пре­кра­тить обслу­жи­вать эту зону.
5. TTL — вре­мя кеши­ро­ва­ния отри­ца­тель­ных отве­тов (ответ "домен невоз­мож­но раз­ре­шить в IP адрес")

В сек­ции NS зада­ют­ся NS сер­ве­ра, кото­рые обслу­жи­ва­ют дан­ный домен. Мини­маль­но их необ­хо­ди­мо два, при­чем они долж­ны нахо­дит­ся в раз­ных под­се­тях, а луч­ше — в гео­гра­фи­че­ски раз­ных местах. Пер­вым ука­зы­вай­те primary сервер.

Сек­ция MX опи­сы­ва­ет поч­то­вые шлю­зы (обыч­но один), на кото­рые будет достав­лять­ся вся поч­та это­го доме­на. Для каж­до­го шлю­за уста­нав­ли­ва­ет­ся при­о­ри­тет (по умол­ча­нию — 10). Обыч­но имя доме­на поч­то­во­го шлю­за выгля­дит так: mx.example.com.

В сек­ции A ука­зы­ва­ют­ся суб­до­ме­ны (A) и сино­ни­мы (CNAME). В при­ме­ре домен example.com ука­зы­ва­ет на IP адрес 192.168.1.1, а домен www.example.com явля­ет­ся сино­ни­мом example.com.

Обра­ти­те внимание:

• Если вы ука­зы­ва­е­те пол­ное имя доме­на, пиши­те в его кон­це точку.
• Запи­си NS, MX и A для основ­но­го доме­на (не суб­до­ме­на) не долж­ны начи­нать­ся с нача­ла строки.
• Если поч­то­вый шлюз при­над­ле­жит это­му же доме­ну, не забы­вай­те ука­зы­вать его в сек­ции A.

Про­ве­рить файл зоны на ошиб­ки мож­но с помо­щью команды: