Раздел: Админство

Настройка BIND на linux

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

Инсталлируем BIND.

$ sudo apt-get install bind9

Первое, что нужно — это понять архитектуру конфигов бинда.
Все файлы настроек лежат в директории /etc/bind/.
BIND

Файл named.conf является конечным файлом настроек bind, но в него ничего писать не нужно: в него инклудятся другие файлы настроек, которые мы и будем править.
Собственно, содержание named.conf таково (здесь и далее буду писать файлы без родных комментариев в них):

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

Таково содержимое файла по умолчанию и трогать ничего не нужно.

Переходим к файлу named.conf.options:

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

forward first; 
forwarders {
	8.8.8.8;
};

dnssec-validation auto;

auth-nxdomain no;    # conform to RFC1035
listen-on-v6 { any; };

allow-query {
any; 
};

recursion yes;
allow-recursion {
any;
};

notify no;
};

Здесь: directory «/var/cache/bind» — директория для хранения кешей бинда по умолчанию;
forward — настройка, указывающая, как работать DNS серверу. Если будет указано forward first, то в случае невозможности разрешить запрос сервером (т.е. если запрос не входит в его зону), он будет опрашивать серверы из списка forwarders (чуть ниже), и выдаст клиенту ответ. Именно так у сервера будет происходить наращивание кешей. Если же будет указано forward only, то сервер, не найдя в своей зоне нужных записей, просто отправит клиента к DNS-серверам из списка forwarders.
forwarders {
8.8.8.8;
};

Список DNS серверов, к которым следует обращаться, если bind не разрешил запрос самостоятельно. В данном случае, указан DNS-сервер гугла.
auth-nxdomain no; — не позволяет серверу отвечать авторитетно, если запрошенный домен не существует. Настройка по-умолчанию, оставляем.
recursion yes; — включает выполнение рекурсивных запросов.
allow-recursion {any;}; — указывает на резрешение рекурсивных запросов, поданных кем угодно. Лучше, конечно, вместо any там следует указать 192.168.1.0/24; (вашу подсеть).
notify отвечат за уведомление других dns серверов при изменениях в зоне ответственности данного сервера. Поскольку мы сами себе в локалке хозяева и у нас только один сервер, эта опция должна быть выключена.

Файл named.conf.local изначально пустой (не считая «заводских» комментариев). В этот файл необходимо записать названия зон прямого просмотра (forward zone), которые мы хотим создать и пути к настройкам самих файлов зон. Пусть у нас будет две зоны: xxx и yyy.

zone "xxx" {
	type master;
	file "/etc/bind/db.xxx";
};

zone "yyy" {
	type master;
	file "/etc/bind/db.yyy";
};

type master; означает, что наш сервер будет являться мастером для этой зоны.
Понятно, что файлов зон /etc/bind/db.xxx и /etc/bind/db.yyy ещё нет, вот мы сейчас их и создадим.

Файл /etc/bind/db.xxx

$TTL 3h
xxx. IN SOA nameserver.xxx. admin.xxx. (
1	; Serial number
3h	; Refresh time
1h	; Retry time
1w	; Expire time
1h )	; Negative Cache TTL
;
xxx.	IN NS nameserver
;
localhost	IN A	127.0.0.1
nameserver	IN A	192.168.1.9
webserver	IN A	192.168.1.10
test1.nameserver	IN CNAME nameserver
test2.nameserver	IN CNAME nameserver
test1.webserver 	IN CNAME webserver
test2.webserver 	IN CNAME webserver

В данном примере, имена nameserver.xxx сопоставлен с ip адресом 192.168.1.9, wbserver.xxx — с адресом 192.168.1.10. test1.nameserver.xxx, test2.nameserver.xxx так же будут сопоставлены с 192.168.1.9 как канонические, и test1.webserver.xxx, test2.webserver.xxx с 192.168.1.10 соответственно.

Файл /etc/bind/db.yyy у нас будет сделан по аналогии, но для адресов ipv6

$TTL 3h
yyy. IN SOA nameserver.yyy. admin.yyy. (
1	; Serial number
3h	; Refresh time
1h	; Retry time
1w	; Expire time
1h )	; Negative Cache TTL
;
yyy.	IN NS nameserver
;
localhost	IN AAAA	::1
nameserver	IN AAAA	FD00::9
webserver	IN AAAA	FD00::10
test1.nameserver	IN CNAME nameserver
test2.nameserver	IN CNAME nameserver
test1.webserver 	IN CNAME webserver
test2.webserver 	IN CNAME webserver

В этом файле задаётся сопоставление имён nameserver.yyy ipv6-адресу FD00::9, и webserver.yyy адресу FD00::10; для всего остального — аналогично.

ВАЖНО! nameserver — это имя нашей машины BIND.

Файл named.conf.default-zones служит для описания файлов зон обратного просмотра. Вот как он выглядит (внизу мы добавили описание для двух наших зон):

zone "." {
	type hint;
	file "/etc/bind/db.root";
};

zone "localhost" {
	type master;
	file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
	type master;
	file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
	type master;
	file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
	type master;
	file "/etc/bind/db.255";
};

zone "1.168.192.in-addr.arpa" {
	type master;
	file "/etc/bind/db.1.168.192";
};

zone "D.F.ip6.arpa" {
	type master;
	file "/etc/bind/db.D.F.ip6.arpa";
};

Файл с описанием зоны обратного просмотра для нашей сети будет иметь имя db.1.168.192
Логика составления настроек та же самая:

$TTL 3h
1.168.192.in-addr.arpa. IN SOA nameserver.xxx admin.xxx. (
1	; Serial number
3h	; Refresh time
1h	; Retry time
1w	; Expire time
1h )	; Negative Cache TTL

1.168.192.in-addr.arpa. IN NS nameserver.xxx.

9 IN PTR nameserver.xxx.
10	IN PTR	webserver.xxx.

9 и 10 — это как раз последний(то есть, в реверсном лучае, первый) октет ip-адресов.

В случае с ipv6 файл db.D.F.ip6.arpa для реверсной зоны будет выглядеть так:

$TTL 3h
0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa. IN SOA nameserver.yyy. admin.yyy. (
1	; Serial number
3h	; Refresh time
1h	; Retry time
1w	; Expire time
1h )	; Negative Cache TTL

0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa. IN NS nameserver.yyy.

9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR nameserver.yyy.
10.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR webserver.yyy.

Здесь в развёрнутом виде (и обратном, разумеется) записывается сопоставление айпишников FD00::9 и FD00::10 именам nameserver.yyy и webserver.yyy соответственно (здесь следует сказать, что наша ipv6 сеть имеет маску /64).

Пару слов по отладке.
BIND пишет логи в /var/log/syslog
Поэтому перед стартом бинда (ну, или при отладке) рекомендую очищать лог, чтобы не копаться в старой рухляди.
Лог удалять нельзя, но в него можно из-под рута записать пустоту:

cat /dev/null > /var/log/syslog

Наиболее частая ошибка в конфигурировании зон: отсутствие (или ненужное присутсвие) точек в конце доменных имён.
Из-за этого в сислоге может вылезать ошибка: SOA record not at top of zone — точно смотрите файлы зон.

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

[info] Usage: /etc/init.d/bind {start|stop|reload|restart|force-reload}

Однако, замечена следующая особенность (возможно, эта неудача постигла только меня, но всё же): на linux-клиентах DNS при перезапуске службы изменения происходят достаточно быстро, но не всегда полностью (!), на windows — я не дождался вообще. Так что рекомендую перезагрузить и саму машину с BIND сервером и клиенты сети для корректной работы.

Где искать проблему, если клиент нормально резолвит ipv6 адрес, а браузер не открывает?
Верно, в браузере. У меня, например, на windows корректно открываются сайты из ipv6 зоны (nameserver.yyy и webserver.yyy) только в браузерах firefox и IE. В Chrome и Opera не открываются. А вот в Linux mint 17 не открываются вообще ни в каком браузере. Хотя, для Firefox, оказывается, ipv6 был выключен в настройках браузера. Чтобы включить эту опцию, нужно в адресной строке набрать about:config, в поиске набрать network.dns.disableIPv6. Значение этого параметра у меня было по умолчанию установлено в true. После смены на false — сайты из зоны ipv6 стали открываться. Для других браузеров решение пока не нашёл.

Как проверить кеширование bind?
Поскольку в параметре directory указано»/var/cache/bind», то bind сохраняет кеши именно туда. Для того, чтобы посмотреть, что бинд накешировал, следует выполнить команду:

rndc dumpdb -cache

после этого создастся файл /var/cache/bind/named_dumb.db, который можно открыть для просмотра.
Вообще, чтобы удостовериться, что параметр forward first функционирует и сервер кеширует клиентские запросы, можно сделать вот что:
Сначала очистить кэш bind (лучше не делать на продакшене, только при настройке):

rndc flush

Затем с клиентской машины резолвим что-нибудь, например мой блог

dig itinrussian.ru

Затем дампим кэш

rndc dumpdb -cache

и, смотрим результат:

cat /var/cache/bind/named_dump.db | grep itinrussian.ru

Вот и все дела.

P.S. вот здесь нагуглено не самое свежее, но более-менее вменяемое описание настроек параметров BIND.

Комментировать

Комментарии

5 × 1 =