FreeBSD

Настройка DNS сервера в FreeBSD

В данной публикации я хочу раскрыть настройку DNS сервера на машине под управлением операционной системы FreeBSD, с помощью которого можно было бы осуществлять поддержку несколько (в теории, неограниченного) количества доменных зон: первичных (primary), вторичных (secondary), а также обратных или реверсивных (reverse). Но для начала изложу немного теории, для пояснения того, для чего нужны, какие бывают и чем отличаются между собой эти самые доменные зоны.

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

Вторичная (secondary) DNS зона является дублирующей и подчиненной первичной зоне. Она необходима для того, чтобы поддерживать и распространять записи для доменного имени, в том случае, если по каким-либо причинам первичный DNS сервер зоны станет недоступен в сети Интернет. Сервер, на котором прописана вторичная DNS зона для какого-либо доменного имени называют вторичным или альтернативным или secondary DNS сервером зоны. Вторичных DNS серверов для зоны может быть неограниченное количество. Единственное требование: все они должны быть настроены на получение информации об этой зоне с первичного DNS сервера. Соответственно, первичный DNS должен быть настроен так, чтобы отдавать данную информацию всем вторичным DNS серверам зоны. Обычно для поддержки доменных зон используется один DNS сервер и один-два — вторичных. В редких случаях возможна схема, когда для поддержки зоны использую два первичных DNS сервера, при этом настраивая их таким образом, чтобы информация на них всегда была синхронизирована.

Первичный и вторичные DNS для зоны должны находиться в разных сетях (автономных системах). И чем дальше они будут друг от друга в географическом отношении, тем лучше. Редко, но все же бывают в сети Интернет катаклизмы, при которых становятся «отрезанными от мира» целые страны. В этом случае, прописав зону на первичном DNS сервере в Украине, а в качестве вторичного использовав DNS в США можно не волноваться, что в случае проблем с магистральными каналами доменная зона «умрет».

Реверсная зона используется для указания так называемых обратных DNS записей. Применяются они для указания соответствия IP адресов определенным именам. Сложно для понимания? Приведу пример.

Имеется IP адрес 213.180.204.8. Это IP адрес сервера, на котором работает всем известный http://ya.ru/ При выполнении поиска соответствия имени ya.ru IP адресу машины к которой «привязано» данное имя, можно выполнить команду:

$ host ya.ru
 ya.ru has address 213.180.204.8
 ...

или в Windows

C:>nslookup ya.ru
  ...
 Name:    ya.ru
 Address:  213.180.204.8

Имеем сопоставление имени IP адресу, или «прямое преобразование имени в IP адрес» (с использованием A записи). Однако, со временем в сети Интернет назрела необходимость сопоставления также IP адреса имени (пожалуй, это произошло в пылу борьбы с нарастающими объемами спам-трафика). И тогда придумали, так называемую «IN-ADDR.ARPA» зону, к которой были привязаны все адреса в сети Интернет, перевернутые наоборот. Как это выглядит?

$ host 213.180.204.8
 8.204.180.213.in-addr.arpa domain name pointer ya.ru.

или в Windows

C:>nslookup -q=PTR 8.204.180.213.in-addr.arpa
 ...
 8.204.180.213.in-addr.arpa      name = ya.ru
 ...

Со всеми IP адресами в сети Интернет можно выполнить преобразование в вид XXX.XXX.XXX.XXX.in-addr.arpa Для этого нужно всего лишь написать сам адрес «задом-наперед» и дописать в конце «.in-addr.arpa». Так вот, зона, прописанная для обратного преобразования IP адреса называется реверсивной или обратной или reverse zone. Как видим из последнего примера, для 8.204.180.213.in-addr.arpa прописано имя ya.ru

С давних времен так повелось, что программы для работы в качестве основных сетевых служб включены по-умолчанию в код операционной системы FreeBSD. Служба DNS не исключение. В FreeBSD роль DNS сервера выполняет программа bind (или named). Со временем было написано масса различного программного обеспечения, которое запросто может заменить bind, однако, поскольку bind является «родным» для FreeBSD его и будем использовать. Даже несмотря на количество критических уязвимостей, которые были обнаружены в bind за всю историю его существования, он остается одним из самых популярных серверов DNS в сети Интернет. К слову сказать, самую последнюю, не критичную ошибку в bind разработчики FreeBSD исправили накануне выхода релиза системы 6.3

Итак, работаем с операционной системой FreeBSD 6.3 RELEASE. Последняя версия bind на сегодняшний день:

# named -version
 BIND 9.3.4-P1

Все конфигурационные файлы нашего DNS располагаются в каталоге /etc/namedb/ который является ссылкой на каталог /var/named/etc/namedb Каталог /var/named/ является chroot окружением, в котором происходит запуск bind. В данном каталоге могут располагаться такие файлы:

# ls /etc/namedb/
   dump -> /var/named/var/dump
   master/
   named.conf
   named.root
   reverse/
   rndc.key
   slave/
   stats -> /var/named/var/stats
   zones.master
   zones.slave
   zones.reverse

здесь:

  • named.conf — основной конфигурационный файл bind
  • zones.master, zones.slave, zones.reverse — конфигурационные файлы в которых прописаны поддерживаемые DNS зоны
  • slave/, master/, reverse/ — каталоги, в которых располагают конфигурационные файлы DNS зон
  • named.root — системный конфигурационный файл, содержащий информацию о всех корневых DNS серверах сети Интернет
  • rndc.key — файл ключом, который необходим для управления работой bind посредством утилиты rndc

От нашего будущего DNS сервера требуется:

  • Раздавать актуальную информацию о нашей зоне zone1.com, тоесть быть для нее первичным DNS.
  • Осуществлять поддержку зоны friends.com и быть для нее вторичным DNS.
  • Поскольку в локальной сети имеем энное количество машин, требуется прописать для каждой машины обратную DNS запись. Это нам нужно для того, чтобы в логи, например, Apache (который будет запущен на этом же сервере), записывались уже не IP адреса, а имена компьютеров нашей локальной сети.
  • Выполнять рекурсивный поиск в системе DNS для зон (имен), которых нет в настоящий момент в кеше и которые не прописаны на нашем DNS сервере.

Начнем с правки конфигурационного файла /etc/namedb/named.conf. Между прочим, man named.conf — отличное пособие для конфигурирования bind.

Рабочий пример, написанный по этому мануалу приведен ниже. Строки начинающиеся с // являются комментариями.

//////////////////////////////////////
// Bind configuration file by Daemony
//////////////////////////////////////
// 1. Глобальные настройки
//
// Создадим список доступа. Назовем
// его IN_NET. Ниже пригодится.
   acl "IN_NET" {
             127.0.0.1;
             172.17.17.0/24;
   };
//
// Далее следуют основные опции сервера
   options {
// - имя хоста, в принципе оно и не нужно
          hostname "ns.mydns.net";
// - директория с конфигурационными файлами
          directory "/etc/namedb";
// БУДЬТЕ ВНИМАТЕЛЬНЫ! Дальше пути к файлам и каталогам
// указываются в chroot'овом окружении /var/named
// - где будет располагаться pid файл демона
          pid-file "/var/run/named/pid";
// - здесь мы можем (хотя и необязательно) указать файл
// в который свалится кеш DNS после выполнения команды
// rndc dumbdb
          dump-file "/var/dump/named_dump.db";
// - а в этот файл (тоже необязательно) свалится
// статистика сервера, если исполнить rndc stats
          statistics-file "/var/stats/named.stats";
//
// На каких интерфейсах слушать 53-й порт.
// Если параметр не задан, то слушает все.
          listen-on {
             127.0.0.1;
             192.168.0.1;
             XXX.XXX.XXX.XXX;
             };
// Интересная опция. Расскажу в конце конфига,
// где она может выручить.
          interface-interval 10;
// Разрешать рекурсивные запросы? Да.
          recursion yes;
// Определим, от каких сетей обрабатывать
// рекурсивные запросы. Используем здесь,
// созданный нами ранее Access Control
// List по имени IN_NET
          allow-recursion { "IN_NET"; };
// Если в кеше нет записи о зоне, которая нам нужна,
// что делать? Сразу начинать поиск имени начиная
// от корневых DNS серверов, или же попробовать
// "уточнить" эту информацию у ближайших DNS (обычно
// своего провайдера), перенаправив запрос?
// Да, перенаправить.
          forward first;
// Чтобы перенаправить, надо знать,
// кому перенаправлять. Укажем здесь DNS'ы
// своего провайдера (можно несколько).
          forwarders {
             XXX.XXX.XXX.XXX;
             YYY.YYY.YYY.YYY;
             };
// О тех зонах, что мы поддерживаем
// (и первичные и вторичные) кому будем
// отдавать информацию? Всем. Данный параметр
// можно переопределить для каждой конкретной
// зоны в конфигурационном файле зоны.
          allow-query { any; };
// Параметр для указания версии сервера.
// Зачем только не понятно.

          version "SuperPuper DNS";
   };
// Глобальные настройки закончились.
// Дальше идут необязательные параметры
// ведения логов. Можно писать, а можно
// не писать.
   logging {
          channel syslog {
          syslog daemon;
          severity info;
          print-category yes;
          print-severity yes;
       };
   category xfer-in { syslog; };
   category xfer-out { syslog; };
   category config { syslog; };
   category default { null; };
   };
//
// А здесь пропишем настройки "удаленного"
// управления DNS сервером утилитой rndc.
// Удаленное в кавычки взял, потому что управлять
// нашим DNS мы будем только с локалхоста.

// Хотя можно сделать так, чтобы bind открыл
// "command chanel" на внешнем интерфейсе
// и принимал команды от удаленных узлов.
// Но я считаю это "дырой", а потому нефиг.
// Пусть слушает только localhost и принимает
// команды только с него. В данной секции нам
// нужно прописать только лишь ключ, который
// будет использоваться при работе с rndc.
   key "Daemony" {
   algorithm hmac-md5;
   secret "pPSvUGU4mRoD0vTuwpzvUg==";
   };
//
// Собственно, с конфигурацией сервера на этом
// все. Далее идут настройки только DNS зон.
//
//////////////////////////////////////////////
// Эту секцию я условно обозвал "SYSTEM" zones
//////////////////////////////////////////////
//
///// Корневая зона. Или зона "точка".
//    У Д А Л Я Т Ь     Н Е Л Ь З Я !
//    Иначе Ваш DNS работать не будет.

//
zone "." {
// - здесь описывается тип зоны
          type hint;
// - здесь указан конфигурационный файл зоны.
          file "named.root";
   };
//
///// Прямая зона для localhost
zone "localhost" {
// - следущий параметр указывает, что наш DNS
// сервер для этой зоны является авторитативным
          type master;
// - кому можно об этой зоне рассказывать -
// понятное дело, что только самому себе
          allow-query { 127.0.0.1; };
// - файл с конфигурацией зоны
          file "master/localhost";
   };
//
///// Обратная зона для localhost
zone "0.0.127.IN-ADDR.ARPA" {
          type master;
          allow-query { 127.0.0.1; };
          file "reverse/localhost.rev";
   };
// Все аналогично предыдущему случаю.
//
// В конце named.conf мы с помощью конструкции include
// подключим чтение остальных частей конфигурации
// DNS, а именно информацию о поддерживаемых зонах,
// которая содержится в следующих файлах.
//
          include "/etc/namedb/zones.master";
          include "/etc/namedb/zones.slave";
          include "/etc/namedb/zones.reverse";
/// End of bind configuration

Что касается опции «interface-interval» она может пригодиться на серверах, где внешний интерфейс динамический, например, tun0. Если у Вас подключение к поставщику услуг сети Интернет посредством PPP или PPPoE при старте системы bind может стартовать быстрее, чем будет поднято PPP/PPPoE соединение. В купе с «listen-on» это будет чревато тем, что bind не сможет слушать интерфейс, который появился после его запуска. Как это лечить, не знаю. Если кто-то подскажет, скажу спасибо. Но знаю, что с помощью «interface-interval N;» можно заставить bind после запуска выждать N секунд до того, как он «прибиндится» на интерфейсы. При старте системы за 10 секунд, PPPoE интерфейс например, поднимается обычно без проблем и bind продолжает нормальную работу.

Идем дальше. Расскажем нашему bind’у какие же зоны он он будет поддерживать.

Файл zones.reverse подключается в конфиге named.conf и содержит информацию о реверсивных зонах. У нас она одна. Нам нужны PTR записи для машин в локальной сети, а в локальной сети у нас только одна подсеть 192.168.0.0/24

// - имя зоны
zone "0.168.192.IN-ADDR.ARPA" {
// - тип зоны - она у нас "первичная" но прописана для реверса
          type master;
// - кому можно отвечать за запросы получения
// информации об именах в этой зоне? Только нашей локальной сети.
          allow-query {
               127.0.0.1;
               192.168.0.0/24;
           };
// - путь к файлу конфигурации зоны
          file "reverse/in.0.168.192.rev";
   };

Файл zones.master также подключается в конфиге named.conf и содержит информацию о том, какие праймэри (primary) зоны мы будем поддерживать. Для примера, она у нас будет только одна. Зона zone1.com

// - имя зоны
zone "zone1.com" {
// - тип зоны - она у нас "мастер" - первичная
          type master;
// - путь к файлу конфигурации зоны
          file "master/zone1.com";
// - кому можно отвечать за запросы получения
// информации об именах в этой зоне? Всем.
          allow-query { any; };
// - кому можно отдавать полностью конфигурацию зоны
// (осуществлять трансфер). Здесь укажем только IP
// адреса наших вторичных DNS серверов для зоны zone1.com
          allow-transfer {
                100.200.0.1;
                200.100.0.2;
                };
   };

Файл zones.slave опять таки подключается в конфиге named.conf и содержит информацию о том, какие вторичные (secondary) зоны должен поддерживать наш DNS сервер. В данном примере, мы осуществляем поддержку одной зоны friends.com

// - указываем имя зоны
zone "friends.com" {
// - указываем, что зона эта вторичная (slave)
          type slave;
// - в каком файле сохранить информацию об этой зоне
          file "slave/friends.com";
// - указываем IP адрес(а) первичного(ых) DNS сервера(ов)
// Напомню, что первичных серверов может быть больше одного
          masters { 210.220.230.240; };
   };

С конфигурацией зон покончили. Если необходимо добавить какую-то еще зону, правим соответствующий файл и даем указание bind’у перечитать настройки. Теперь опишем собственно сами зоны в соответствующих файлах. Начнем с локалхоста.

# cat /etc/namedb/master/localhost
$TTL 1D
localhost.  IN  SOA  ns.mydns.net. root.ns.mydns.net. (
             2007042001  ;serial number
             86400       ;refresh
             3600        ;retry
             3888000     ;expire
             3600        ;minimum
             )
localhost.   IN  NS   ns.mydns.net.
localhost.   IN  A    127.0.0.1

В этом примере второй строкой идут следующие параметры: «имя зоны» — localhost, «тип записи» — IN SOA — Start Of Authority — «Начало авторитативной зоны«, за которую отвечает авторитативный DNS сервер ns.mydns.net, а с администратором этого сервера можно связаться по e-mail root@ns.mydns.net (точка заменяется «собакой»). Дальше следуют серийный номер зоны (serial number), который всегда следует изменять при внесении изменений в зону, период обновления зоны (refresh) вторичными DNS серверами (в секундах), период между попытками обновить зону вторичным DNS сервером (retry), если предыдущая попытка оказалась безуспешной, срок жизни зоны (expire) на вторичном DNS сервере, если первичный недоступен. Что означает параметр «minimum» я, честно говоря, непомню.

Дальше следуют описания DNS записей зоны. Из примера видно, что для имени localhost прописана одна А запись и указывает она на IP адрес 127.0.0.1 За поддержку зоны отвечает сервер ns.mydns.net, тоесть наш локальный bind.

Пример конфигурации обратной DNS зоны для localhost

# cat /etc/namedb/reverse/localhost.rev
$TTL 3600
@  IN  SOA  ns.mydns.net.  root.ns.mydns.net. (
             2007042001 ; Serial
             3600       ; Refresh
             900        ; Retry
             3600000    ; Expire
             3600 )     ; Minimum
    IN NS  ns.mydns.net.
1   IN PTR localhost.

Теперь наш bind будет знать, что для 127.0.0.1 прописана следующая PTR запись:

# host 127.0.0.1
  1.0.0.127.in-addr.arpa domain name pointer localhost.

Теперь нам необходимо создать файл обратной DNS зоны /etc/namedb/reverse/in.0.168.192.rev в котором укажем PTR записи для машин в нашей локальной сети. Пример будет таким:

$TTL 3600
@  IN  SOA  ns.mydns.net.  root.ns.mydns.net. (
             2007042001 ; Serial
             3600       ; Refresh
             900        ; Retry
             3600000    ; Expire
             3600 )     ; Minimum
        IN      NS      ns.mydns.net.
1       IN      PTR     router.
2       IN      PTR     mail-server.
3       IN      PTR     web-server.
4       IN      PTR     boss.
5       IN      PTR     buhgalter.
// и так далее...

После того, как наш DNS перечитает такую конфигурацию, в локальной сети IP адреса начнут резолвиться приблизительно в таком виде:

$ host 192.168.100.1
1.0.168.192.in-addr.arpa domain name pointer router.

$ host 192.168.100.2
2.0.168.192.in-addr.arpa domain name pointer mail-server.

$ host 192.168.100.3
3.0.168.192.in-addr.arpa domain name pointer web-server.

$ host 192.168.100.4
4.0.168.192.in-addr.arpa domain name pointer boss.

$ host 192.168.100.5
5.0.168.192.in-addr.arpa domain name pointer buhgalter.

Честно скажу, при разборе логов (и не только во FreeBSD) имена гораздо удобнее, чем IP адреса.

Наконец, нам осталось создать файл поддерживаемой нами первичной DNS зоны zone1.com Для этого в каталоге /etc/namedb/master создаем файл, например, такой конфигурации:

$TTL 7200
@       IN      SOA     ns.mydns.net. hostmaster.ns.mydns.net. (
             2008020601 ; Serial
             28800      ; Refresh
             7200       ; Retry
             2419200    ; Expire
             86400)     ; Negative Cache TTL
;
@      IN      NS   ns.mydns.net.
@      IN      NS   ns1.somedns.net.
@      IN      NS   ns2.somedns.net.
@      IN      A    212.212.212.212
@      IN      MX   1   ASPMX.L.GOOGLE.COM.
@      IN      MX   5   ALT1.ASPMX.L.GOOGLE.COM.
@      IN      MX   5   ALT2.ASPMX.L.GOOGLE.COM.
@      IN      MX   10  ASPMX2.GOOGLEMAIL.COM.
@      IN      MX   10  ASPMX3.GOOGLEMAIL.COM.
@      IN      MX   10  ASPMX4.GOOGLEMAIL.COM.
@      IN      MX   10  ASPMX5.GOOGLEMAIL.COM.
www    IN      CNAME    zone1.com.
ftp    IN      A        213.213.213.213

В данном примере приведены записи (выдуманные, естественно) для зоны zone1.com: почту для этой зоны принимают сервера Google (семь MX записей — семь серверов для приема почты на этот домен); само имя zone1.com привязано A записью к хосту с IP адресом 212.212.212.212, а www.zone1.com является синонимом имени zone1.com; при этом за зону отвечают DNS сервера ns.mydns.net, ns1.somedns.net и ns2.somedns.net. А по адресу 213.213.213.213 возможно находится FTP сервер ftp.zone1.com. По крайней мере, для этого имени есть соответствующая А запись.

Учтите, что сервера ns1.somedns.net и ns2.somedns.net, а точнее их IP адреса должны быть обязательно указаны в файле /etc/namedb/zones.master в «allow-transfer» для этой зоны.

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

Конфигурирование DNS сервера окончено. Чтобы он начал работать следует в /etc/rc.conf добавить:

  named_enable="YES"

Все остальное что нам нужно, прописано по-умолчанию в файле /etc/defaults/rc.conf

# cat /etc/defaults/rc.conf | grep named_uid
 named_uid="bind"     # User to run named as

Именно так. Неймд должен стартовать только от имени пользователя bind и ни в коем случае не от root’а. Иначе, рискуете стать жертвой глупости.

Bind можно запустить «родным» стартовым скриптом:

# /etc/rc.d/named start
Starting named.

При этом в /var/log/messages он напишет:

 named[33696]: starting BIND 9.3.4-P1 -t /var/named -u bind
 named[33696]: command channel listening on 127.0.0.1#953

Для пущей уверенности, что все работает:

# sockstat | grep named
bind  named   33696 3  dgram  -> /var/run/logpriv
bind  named   33696 20 udp4   192.168.0.1:53      *:*
bind  named   33696 21 tcp4   192.168.0.1:53      *:*
bind  named   33696 22 udp4   127.0.0.1:53        *:*
bind  named   33696 23 tcp4   127.0.0.1:53        *:*
bind  named   33696 24 udp4   XXX.XXX.XXX.XXX:53  *:*
bind  named   33696 25 tcp4   XXX.XXX.XXX.XXX:53  *:*
bind  named   33696 26 udp4   *:53                *:*
bind  named   33696 27 tcp4   127.0.0.1:953       *:*
root  syslogd 462   7  dgram  /var/named/var/run/log

Bind работает и готов принимать запросы на всех интерфейсах. Если у Вас он их не обрабатывает, проверьте разрешили ли Вы доступ к своему DNS на фаерволле. На порт 53 и с него должны беспрепятственно бегать пакеты как по TCP так и по UDP.

И напоследок немного о том, как можно управлять bind’ом посредством rndc.

Примеры:

  • rndc reload — перезагрузит конфигурацию (если нет ошибок в конфигурации named.conf)
  • rndc stop — остановит DNS сервер
  • rndc stats — выведет статистику того, что накешировал Ваш DNS
  • rndc dump — выбросит свой кеш в дамп файл, прописанный в конфиге named.conf
  • rndc flush — сбросит свой кеш в ноль
  • rndc flushname zona.com — удалит у себя из кеша информацию о зоне zona.com
  • rndc halt — убиение named’а без сохранения всего того, что он хотел сохранить в этот момент
  • rndc reconfig — приведет к перезагрузке основной конфигурации файла, а также конфигурации новых зон и еще масса приятных и удобных вещей.

Как видите, в конфигурировании DNS сервера абсолютно ничего сложного. Хотя, многим по началу кажется наоборот.

Оставить комментарий