Настройка DNS сервера Bind9 (Создание локальной доменной зоны). Настройка собственных DNS серверов BIND

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

Основная цель: добиться автоматизации распространения обновленных данных на несколько DNS серверов: добавление, редактирование, удаление доменных зон.

Про то, как устанавливать bind, думаю, говорить не стоит. Перейдем непосредственно к автоматизации обмена между главным (master) и вторичным (slave) сервером. Все телодвижения будут выполняться на платформе Debian 6 с Bind9 и Rsync на борту.

Настройка bind на главном сервере.
1. Создаем директорию для размещения файлов доменов:
mkdir /etc/bind/zones
2. Создаем конфигурационный файл для всех зон в только что созданной директории
touch named.conf.zones
3. Подключаем конфигурационный файл в основной
Открываем на редактирование конфиг named.conf
nano named.conf
Вставляем в конец:
include "/etc/bind/zones/named.conf.zones";

Настройка доменных зон на главном сервере
Для заполнения named.conf.zones впоследствии используем шаблон для каждой из зон
zone "example.org" {
type master;
file "/etc/bind/zones/example.org.zone";
};
В соответствии с этим шаблоном файл зоны будет располагаться в директории «/etc/bind/zones/ » и называться example.org.zone

Структуру файла зоны для bind можно найти в интернете или же в самом дистрибутиве.

Настройка вторичного сервера имен DNS.
Делаем точно такие же настройки как и на master сервере.

Синхронизация master и slave серверов в автоматическом режиме.
Создадим BASH скрипт, назовем его, к примеру, get-dns
touch /opt/get-dns.sh
Содержимое скрипта:
#!/bin/bash

# Адрес master-сервера с указанием юзера, под которым будет производиться синхронизация.
MAINDNSSRV="[email protected]"

# Директории для синхронизации
SRCSYNCDIR="/etc/bind/zones"
DESTSYNCDIR="/etc/bind"

# Ключи для запуска rsync
RSYNCKEYS="-v -a -r"

# Путь до файла, при помощи которого будет блокироваться повторный запуск скрипта если он еще работает:
RSYNCWORKFILE="/opt/get-dns.work"

###
# Скрипт
###
read RSYNCWORK $RSYNCWORKFILE
rsync $RSYNCKEYS $MAINDNSSRV:$SRCSYNCDIR $DESTSYNCDIR;
/etc/init.d/bind9 reload
echo "0" > $RSYNCWORKFILE
fi

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

Данную схему можно применять не только в связке master slave, но и в среде с несколькими slave серверами.

Итог:
1. Необходимость в создании новых доменных зон на нескольких серверах отпадает. Они распространяются автоматически.
2. Редактирование зон не требует дополнительно вносить изменения на других серверах вручную.
3. При использовании лицензионного ПО для редактирования DNS нет нужны платить за slave сервера.

Экономия времени и денег.

Если не хотите заморачиваться с настройкой собственных DNS серверов, то можно воспользоваться услугами компании Stabline по Аренде DNS серверов .
1 домен — бесплатно. Больше — от 30 рублей в год!

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

Итак, планы на сегодня!

1. Настройка зоны мастер.
2. Подключение зон в слейве.
3. Каждому свое. Настраиваем параметры в зависимости от адреса клиента, с которого пришел запрос.
4. Подключаем внешний DNS-фильтр.

Интро

Когда я устроился на работу, количество сервисов в нашей сети можно было пересчитать по пальцам одной руки. Время шло, число сервисов росло. Обслуживающий DNS-сервер был один и выступал мастером для одной зоны (назовем ее xak.ru). Все остальные запросы он просто пересылал на DNS-сервер Google (8.8.8.8). А, чуть не забыл добавить: сервер этот был виртуальным. Потом в один прекрасный день сервер рухнул физически. После замены систему подняли, виртуализацию прикрутили. Поставили свежеустановленный Debian и к нему BIND 9. Присвоили тот же IP, что был у DNS-сервера до падения. Настройки восстановили из бэкапа. После успешного старта стали думать, как «закручивать болты».

Параллельно с этой работой был установлен хостинг, который держал на себе зону (например) xaker.ru. Само собой, центральный DNS должен о ней знать, а еще лучше быть slave DNS-сервером для этой зоны. Далее возникла необходимость перенаправлять DNS-запросы от центрального сервера к редиректору в зависимости от того, из какой сети пришел запрос. Делалось это ради подключения внешних DNS-фильтров, но не для всех. А только для тех, кому надо, а именно образовательных городских сетей - территории образовательных учреждений! Обо всем этом и пойдет речь ниже.

Немного теории

Если хочешь познакомиться с «новым» BIND, то рекомендую к чтению . В двух словах: версия 9 была последней, с 10-й версии права передают сообществу, и это ПО ныне известно как Bundy.

Быстрая установка, или еще раз об одном и том же

Итак, как установить BIND 9 в Debian/Ubuntu, в Сети очень и очень много материала. Так что быстро пройдемся по этому пункту, не вдаваясь в подробности. Для начала необходимо установить BIND 9 в систему. Для пользователей MS Windows есть версия BIND 9 под их платформу.

$ sudo apt install bind9

Для других дистрибутивов руководств по сборке из исходных кодов на просторах Сети предостаточно, забирай быстрее, переписывай в блокноты, пока новый «суперполезный» закон не накрыл весь интернет или пока тебя не отругали за то, что ты ходишь или ходил на сайт с запрещенной литературой. 😉

После установки переходим в каталог /etc/bind9/ и видим там основной файл конфигурации named.conf , внутри подключены остальные файлы named.conf.* . Как настраивать мастер-зону, опустим, поскольку в Сети информация изложена очень подробно. Добавим в файл named.conf строку

Include "/etc/bind/named.conf.acl";

чем подключим новый файл в конфиг для правил подсетей. Далее создаем файл /etc/bind/named.conf.acl и добавляем правила:

Acl "lan" { 192.168.181.0/24; }; acl "do" { 10.0.0.0/24; 192.168.253.0/24; }; acl "srv" { 192.168.254.0/24; }; acl "alls" { 10.10.0.0/16; }; acl "dou" { 192.168.201.0/24; 192.168.202.0/24; 192.168.203.0/24; 192.168.204.0/24; 192.168.205.0/24; }; acl "school" { 172.16.0.0/24; };

Здесь мы разделили сети на группы для дальнейшей обработки. Прежде чем продолжим, уточню один момент. Для корректной обработки зон необходимо в каждую группу правил добавлять все зоны. Можно это делать в одном файле или вынести настройки зоны в отдельный файл и потом просто подключать в нужных местах. Итак, в файл /etc/bind/named.conf.local вносим изменения:

View "edu" { match-clients { school; }; recursion yes; allow-query { school; }; forwarders { 77.88.8.7; }; zone "xaker.ru" { type master; file "/etc/bind/xaker.ru_loc"; }; zone "254.168.192.in-addr.arpa." { type master; file "/etc/bind/xaker.rev"; }; zone "zone2.ru" { type slave; file "/etc/bind/db.zone2.ru"; masters { 192.168.254.5; }; }; };

Здесь мы обозначаем группу, с которой будет работать BIND. Добавляем сюда клиенты из правил, которые мы определили выше. Назначаем вышестоящий сервер, на который будут пересылаться запросы, пришедшие из сетей, согласно описанным правилам. Здесь это единственная группа адресов School. В качестве вышестоящего DNS задал DNS-сервер Яндекс, который фильтрует «плохой» контент. Можно аналогично использовать другие DNS-сервисы, такие как SkyDNS.

Продолжение доступно только подписчикам

Вариант 1. Оформи подписку на «Хакер», чтобы читать все материалы на сайте

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов.

Сегодня продолжим цикл статей по настройке сервера и рассмотрим что же из себя представляет настройка DNS сервера Ubuntu. У нас уже есть сервер на базе ubuntu 14.04.1 LTS, на нем настроен DHCP сервер. Сегодня мы туда добавим еще и службу DNS.

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

По многочисленным просьбам читателей, я еще раз перепроверил все пункты и нашел некоторые ньюансы из-за которых сервер некорректно работал (изначально статья была написана для ubuntu server 11.04). Статья полностью переписана и проверена на Ubuntu Server 14.04.1

Существует много способов настроить BIND9. Наиболее распространенные конфигурации - это кэширующий сервер имен, первичный мастер и вторичный мастер.

Когда BIND9 настроен как кэширующий сервер, он ищет ответы на запросы имени и запоминает ответ на случай, если запрос придет повторно.

В качестве первичного мастера BIND9 читает данные зоны из локального файла и является ответственным за эту зону.

В качестве вторичного мастера BIND9 получает данные по зоне (целиком) с другого сервера имен, отвечающего за эту зону.

Обзор

Файлы настройки DNS сохраняются в каталоге /etc/bind. Основной файл конфигурации - это /etc/bind/named.conf.

Строки include определяют имена файлов, которые содержат DNS опции. Строка directory в файле /etc/bind/named.conf.options говорит DNS где искать файлы. Все файлы, используемые BIND, будут относительными к этому каталогу.

Файл с именем /etc/bind/db.root описывает корневые сервера имен в мире. Сервера со временем меняются, поэтому файл /etc/bind/db.root должен обслуживаться сейчас и потом. Обычно это происходит в качестве обновления к пакету bind9 . Секция zone определяет мастер сервер и она сохранена в файле, определяемой опцией file .

Существует возможность настроить один сервер как кэширующий сервер имен, первичный мастер и вторичный мастер одновременно. Сервер может быть началом авторизации (SOA) для одной зоны, при этом предоставляя вторичный сервис для другой. И при всем этом предоставлять кэширующий сервис в локальной сети (LAN).

Кэширующий сервер имен

По умолчанию конфигурация настраивается на работу кэширующим сервером. Все что для этого требуется - это добавить IP адреса DNS серверов вашего интернет провайдера. Просто раскомментируйте и исправьте следующее в /etc/bind/named.conf.options:

Forwarders { 1.2.3.4; 5.6.7.8; };

Замените 1.2.3.4 и 5.6.7.8 на актуальные IP адреса серверов имен.

Теперь перегружаем DNS сервер для применения новой конфигурации. Наберите в терминале:

Sudo service bind9 restart

Многие администраторы предпочитают использовать дату последнего редактирования в качестве Serial зоны в виде 2012010100, что соответствует формату yyyymmddss (где ss - Serial Number [за день]).

Как только вы произвели изменения в файле зоны, требуется перегрузить BIND9 для применения изменений:

Sudo service bind9 restart

Файл обратной зоны

Теперь, поскольку зона создана и разрешает имена в IP адреса, требуется создать также обратную зону. Обратная зона позволяет DNS определять имя по IP адресу.

Редактируем /etc/bind/named.conf.local и добавляем следующее:

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

Замените 1.168.192 на первые три октета адресов сети, которую вы используете. Также соответственно назовите файл зоны /etc/bind/db.192. В нем должен совпадать первый октет вашей сети.

Теперь создаем файл /etc/bind/db.192:

Sudo cp /etc/bind/db.127 /etc/bind/db.192

; ; BIND reverse data file for local 192.168.1.XXX net ; $TTL 604800 @ IN SOA ns.example.com. root.example.com. (2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800) ; Negative Cache TTL ; @ IN NS ns. 10 IN PTR ns.example.com.

Serial Number в обратной зоне также требуется увеличивать при каждом изменении. Для каждой A записи, которую вы настроите в /etc/bind/db.example.com на другой адрес, вы должны создать запись PTR в /etc/bind/db.192.

После создания файла обратной зоны перегрузите BIND9:

Sudo service bind9 restart

Вторичный мастер

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

Для начала на первичном мастере надо разрешить передачу зоны. Добавьте опцию allow-transfer к определениям прямой и обратной зон в /etc/bind/named.conf.local:

Zone "example.com" { type master; file "/etc/bind/db.example.com"; allow-transfer { 192.168.1.11; }; }; zone "1.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192"; allow-transfer { 192.168.1.11; }; };

Замените 192.168.1.11 на IP адрес вашего вторичного сервера имен.

Перезапустим BIND9 на первичном мастере:

Zone "example.com" { type slave; file "db.example.com"; masters { 192.168.1.10; }; }; zone "1.168.192.in-addr.arpa" { type slave; file "db.192"; masters { 192.168.1.10; }; };

Замените 192.168.1.10 на IP адрес вашего первичного сервера имен.

Перегружаем BIND9 на вторичном мастере:

Sudo service bind9 restart

В /var/log/syslog вы сможете увидеть нечто похожее на (некоторые строки разделены для соответствия формату документа):

Client 192.168.1.10#39448: received notify for zone "1.168.192.in-addr.arpa" zone 1.168.192.in-addr.arpa/IN: Transfer started. transfer of "100.18.172.in-addr.arpa/IN" from 192.168.1.10#53: connected using 192.168.1.11#37531 zone 1.168.192.in-addr.arpa/IN: transferred serial 5 transfer of "100.18.172.in-addr.arpa/IN" from 192.168.1.10#53: Transfer completed: 1 messages, 6 records, 212 bytes, 0.002 secs (106000 bytes/sec) zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 5) client 192.168.1.10#20329: received notify for zone "example.com" zone example.com/IN: Transfer started. transfer of "example.com/IN" from 192.168.1.10#53: connected using 192.168.1.11#38577 zone example.com/IN: transferred serial 5 transfer of "example.com/IN" from 192.168.1.10#53: Transfer completed: 1 messages, 8 records, 225 bytes, 0.002 secs (112500 bytes/sec)

Обратите внимание, что передача зоны произойдет только если Serial Number на первичном сервере больше значения на вторичном. Если вы хотите, чтобы первичный мастер DNS сообщал вторичному DNS серверу об изменении зоны, вы можете добавить also-notify { ipaddress; }; в /etc/bind/named.conf.local как показано в примере ниже: zone "example.com" { type master; file "/etc/bind/db.example.com"; allow-transfer { 192.168.1.11; }; also-notify { 192.168.1.11; }; }; zone "1.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192"; allow-transfer { 192.168.1.11; }; also-notify { 192.168.1.11; }; };

DNS – это протокол, при помощи которого имена преобразуются в IP-адреса и наоборот. FreeBSD в настоящее время поставляется с сервером DNS – BIND9, предоставляющим расширенные настройки безопасности, новую схему расположения файлов конфигурации и автоматические настройки для chroot(8). К тому же BIND9 считается наименее уязвимой для внешних атак (FreeBSD автоматически запускает named в ограниченном окружении (chroot(8))). Эта версия DNS -сервера поддерживает списки управления доступом для запросов, передачи зон подчиненным (вторичным) DNS -серверам, а также динамические обновления своих зон с вышестоящих (первичных) DNS -серверов. Этой версией поддерживается стандарт динамических обновлений и уведомления об изменениях зоны, а так же он использует механизм инкрементальной передачи зоны, позволяющий подчиненным DNS -серверам запрашивать у вышестоящих DNS -серверов только изменения зональных данных. Это позволяет намного ускорить передачу зон.

На момент написания статьи я настраивал BIND 9.6.1-P1 на сервере под управлением FreeBSD 7.2-RELEASE .

# cat /etc/namedb/named.conf // так выглядит комментарий acl self { 127.0.0.1; }; // задаем переменную self, в которой перечислим ip-адреса нашего сервера,\ на которых будет работать bind acl trust { self; }; // задаем переменную, в которой перечислим ip-адреса, с которых будет разрешено\ посылать запросы через наш DNS-сервер // секция глобальных параметров options { directory "/etc/namedb"; // рабочий каталог bind, относительно которого ниже мы будем обозначать\ остальные каталоги pid-file "/var/run/named/pid"; // pid-файл dump-file "/var/dump/named_dump.db"; // расположение dump-файла корневой зоны при временной потере\ доступа ко всем корневым серверам statistics-file "/var/stats/named.stats"; // расположение файла статистики listen-on { self; }; // указываем bind на каких интерфейсах работать listen-on-v6 { none; }; // запрещаем использовать IPv6 version "Hello, pal!"; // здесь вы можете указать версию вашего bind (для безопасности рекомендуют\ этого не делать) allow-query { self; }; // от кого разрешаем принимать запросы forwarders { 12.34.56.78; }; // для снижения нагрузки на свой сервер вы можете указать тут DNS-сервера\ своего провайдера }; ...

Теперь предлагаю немного отвлечься от настройки файла named.conf . Предлагаю вам рассмотреть интересный способ удаленного администрирования вашим DNS -сервером – утилита rndc . Для того, чтобы начать ей пользоваться, вам необходимо создать для нее конфигурационный файл и секретный ключ, с помощью которых она будет взаимодействовать с вашим bind. Для это задачи существует команда rndc-confgen .
Выполняя команду:

# rndc-confgen

вы получите на стандартном выводе что-то вроде:

# Start of rndc.conf key "rndc-key" { algorithm hmac-md5; secret "34f88008d07deabbe65bd01f1d233d47"; }; options { default-key "rndc-key"; default-server 127.0.0.1; default-port 953; }; # End of rndc.conf # # Use with the following in named.conf, adjusting the allow list as needed: # key "rndc-key" { # algorithm hmac-md5; # secret "34f88008d07deabbe65bd01f1d233d47"; # }; # # controls { # inet 127.0.0.1 port 953 # allow { 127.0.0.1; } keys { "rndc-key"; }; # }; # End of named.conf

Незакомментированную часть вывода помещаете в файл /etc/namedb/rndc.conf

# cat /etc/namedb/rndc.conf key "rndc-key" { algorithm hmac-md5; secret "34f88008d07deabbe65bd01f1d233d47"; }; options { default-key "rndc-key"; default-server 127.0.0.1; default-port 953; };

Закомментированную часть вывода команды rndc-confgen помещаете в конфигурационный файл /etc/namedb/named.conf :

Key "rndc-key" { algorithm hmac-md5; secret "34f88008d07deabbe65bd01f1d233d47"; }; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; }; ...

В результате работы команды rndc-confgen в каталоге /etc/namedb/ должен появиться файл rndc.key , со следующим содержимым:

# cat /etc/namedb/rndc.key key "rndc-key" { algorithm hmac-md5; secret "34f88008d07deabbe65bd01f1d233d47"; };

Если у вас уже существовал там ключ, удалите его и замените новым.
Во всех случаях строчка secret “34f88008d07deabbe65bd01f1d233d47”; у вас должна быть одинаковой! Значение secret сгенерировала команда rndc-confgen .
Проверить сделанную вами работу вы сможете, когда полностью настроите свой DNS -сервер и запустите его. Тогда, при выполнении команды:

# rndc status

если вы увидите что-то похожее на:

Version: 9.6.1-P1 (Hello, pal!) CPUs found: 2 worker threads: 2 number of zones: 14 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 0/0/1000 tcp clients: 0/100 server is up and running

— значит утилита rndc успешно подключилась к вашему bind, авторизовалась с помощью ключа, который мы только что создали, и запросила у bind статус DNS -сервера, что вам и показали.

Существует множество полезных ключей, с помощью которых данная утилита позволит вам мониторить и управлять вашим DNS -сервером. Достаточно запустить ее без аргументов и вы увидите доступные команды и помощь по ним. (Советую сразу же создать дамп-файл командой rndc dumpdb ).

Продолжим пояснения по конфигурационному файлу /etc/namedb/named.conf :

Zone "." { type hint; file "named.root"; //как получить актуальный файл корневой зоны написано ниже }; zone "0.0.127.in-addr.arpa" { type master; file "master/localhost.rev"; notify no; }; ...

Файл localhost.rev выглядит примерно так:

# cat /etc/namedb/master/localhost.rev $TTL 3600 @ IN SOA host.your_domain.ru. root.host.your_domain.ru. (2009110601 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600) ; Minimum IN NS host.your_domain.ru. 1 IN PTR localhost.your_domain.ru.

Следующими настройками мы будем собирать и записывать логи bind в различные фалы. Формат секции записи логов по каналам имеет вид:

Channel имя-канала { (file имя-файла [ versions (число | unlimited) ] [ size максимальный-размер ] | syslog syslog_facility | stderr | null); // мы тут будем указывать имя файла, в который будем писать логи этого канала (относительно\ рабочего каталога); количество версий файлов логов; размер файла, при котором\ происходит перенумерация файла лога. если количество версий указано не будет, логирование\ прекратиться по достижению указанного размера файла. [ severity (critical | error | warning | notice | info | debug [ уровень ] | dynamic); ] // фильтр логов, кукую именно информацию мы будем заносить\ в этот канал [ print-category yes-или-no; ] // заносим или нет в лог тип категории события [ print-severity yes-или-no; ] // заносим или нет в лог тип "серьезности" собфтия [ print-time yes-или-no; ] // заносим или нет в лог время события };

Итак – это мои настройки в файле /etc/namedb/named.conf :

Logging { // параметры логирования channel default_ch { // обозначаем канал логирования default_ch file "/var/log/named.log" versions 3 size 800k; severity info; print-time yes; print-category yes; }; channel security_ch { // обозначаем канал логирования security_ch file "/var/log/security.log" versions 3 size 800k; severity info; print-time yes; print-category yes; }; channel transfer_ch { // обозначаем канал логирования transfer_ch file "/var/log/transfer.log" versions 3 size 800k; severity info; print-time yes; print-category yes; }; channel lame-ch { // обозначаем канал логирования lame-ch file "/var/log/lamers.log" versions 3 size 800k; severity info; print-time yes; print-category yes; }; category lame-servers { lame-ch; }; // пишем в канал lame-ch события от "кривых" DNS-серверов category default { default_ch; }; // пишем в канал default_ch все, для чего нет собственного канала category security { security_ch; }; // пишем в канал security_ch о событиях безопасности category xfer-in { transfer_ch; }; // пишем в канал transfer_ch об отдаче зон category xfer-out { transfer_ch; }; // пишем в канал transfer_ch о приеме зон category notify { transfer_ch; }; // пишем в канал transfer_ch уведомления и факты регистрации };

Теперь, после окончания настройки bind, вам осталось только с помощью команды wget или fetch получить актуальный файл корневой зоны (named.root) с сервера:

# fetch ftp://ftp.internic.net/domain/named.root

и положить его в каталог /etc/namedb/ с заменой существующего. Желательно периодически повторять эту процедуру, или настроить эту операцию через cron.

Теперь настало время запустить наш DNS -сервер:

/etc/rc.d/named start

Проверяем работу утилитой rndc , как было описано выше.

Для начала выполните команду:

# ps -ax | grep named 476 ?? Is 0:01,19 /usr/sbin/syslogd -l /var/run/log -l /var/named/var/run/log -s 704 ?? Is 0:00,04 /usr/sbin/named -t /var/named -u bind 1022 p0 R+ 0:00,00 grep named

Если вы видите примерно это же – то процесс запущен.
Для пущей уверенности можно выполнить следующую команду (если она у вас есть):

# lsof -i tcp | grep LISTEN | grep named named 704 bind 20u IPv4 0xc845a000 0t0 TCP localhost:domain (LISTEN) named 704 bind 21u IPv4 0xc449a740 0t0 TCP localhost:rndc (LISTEN) named 704 bind 20u IPv4 0xc845a000 0t0 TCP localhost:domain (LISTEN) named 704 bind 21u IPv4 0xc449a740 0t0 TCP localhost:rndc (LISTEN) named 704 bind 20u IPv4 0xc845a000 0t0 TCP localhost:domain (LISTEN) named 704 bind 21u IPv4 0xc449a740 0t0 TCP localhost:rndc (LISTEN) named 704 bind 20u IPv4 0xc845a000 0t0 TCP localhost:domain (LISTEN) named 704 bind 21u IPv4 0xc449a740 0t0 TCP localhost:rndc (LISTEN) named 704 bind 20u IPv4 0xc845a000 0t0 TCP localhost:domain (LISTEN) named 704 bind 21u IPv4 0xc449a740 0t0 TCP localhost:rndc (LISTEN)

Теперь надо настроить наш сервер на работу с только что установленным DNS -сервером. Для этого вам необходимо внести изменения в файл /etc/resolv.conf . Приведите его к следующему виду:

# cat /etc/resolv.conf domain your_domain.ru nameserver 127.0.0.1

В комплекте с сервером BIND9 поставляются утилиты DNS dig , host и nslookup для исследования доменного пространства. С их помощью мы проверим, как работает только что настроенный и запущенный вами DNS -сервер.

Утилита host позволяет получать значения RR указанного типа для указанного доменного имени. Формат вызова:
host [ -управляющие-ключи ] [ -ключи-запроса ] доменное-имя-или-адрес [ опрашиваемый-сервер ] .

По умолчанию, используется сервер, описанный при настройке клиентской библиотеки. Доменные имена считаются абсолютными и список поиска не используется. Более подробная информация на man host .

Утилита dig позволяет получать значения RR указанного типа для указанного доменного имени в формате файла зоны. В виде комментариев выдается масса вспомогательной информации, в т.ч. интерпретация пакета, полученного в ответ на запрос. Формат вызова:
dig [ @опрашиваемый-сервер ] [ -опции-dig ] доменное-имя [ тип-записи ] [ класс-записи ] [ +опции-запроса ]

По умолчанию, используется сервер, описанный при настройке клиентской библиотеки. Доменные имена считаются абсолютными и список поиска не используется. В качестве требуемого типа записи можно использовать также псевдотипы AXFR (зона передается только от уполномоченного сервера), ixfr=опорный-номер-версии и ANY , по умолчанию: A. В одной командной строке можно сделать несколько запросов.

Утилита nslookup объявлена устаревшей и навязчиво напоминает об этом при каждом запуске (даже документация не поставляется, отсутствует команда help и некоторые другие). Формат вызова:
nslookup [ -ключи ] доменное-имя [ опрашиваемый-сервер ]

Выполните команду:

# dig @127.0.0.1 ya.ru ; <<>> DiG 9.6.1-P1 <<>> @127.0.0.1 ya.ru ; (1 server found) ;; global options: +cmd ;; Got answer: ;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 51090 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;ya.ru. IN A ;; ANSWER SECTION: ya.ru. 2843 IN A 213.180.204.8 ya.ru. 2843 IN A 77.88.21.8 ya.ru. 2843 IN A 93.158.134.8 ;; AUTHORITY SECTION: ya.ru. 2843 IN NS ns1.yandex.ru. ya.ru. 2843 IN NS ns5.yandex.ru. ;; ADDITIONAL SECTION: ns1.yandex.ru. 79700 IN A 213.180.193.1 ns5.yandex.ru. 79701 IN A 213.180.204.1 ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Dec 4 14:04:11 2009 ;; MSG SIZE rcvd: 146

Если в результате ее работы вы видите примерно тоже самое – значит вам DNS -сервер отработал команду правильно.

Теперь выполните команду:

# host ya.ru ya.ru has address 77.88.21.8 ya.ru has address 93.158.134.8 ya.ru has address 213.180.204.8 ya.ru mail is handled by 10 mx.yandex.ru.

Если ваш DNS -сервер ответил примерно таким образом – значит он работает правильно!

Если данные команды не вернули никаких результатов, надо смотреть лог /var/log/messages на предмет ошибок, которые заносит туда ваш bind. Анализируя их, постарайтесь понять, с чем связана некорректная работа DNS -севера. Основным недосмотром является неправильная настройка сетевых файерволов.

В заключении хочу сказать о некоторых встроенных в bind командах диагностики.

• named-checkzone – проверяет синтаксис и целостность файлов зон. Такие же проверки выполняются каждый раз перед их загрузкой bind’ом. Но считаю полезным все-таки это делать перед их загрузкой сервером имен.
• named-compilezone – выполняет более строгие проверки, чем named-checkzone, т.к. в результате ее работы сформируется дамп актуальных зон, который в свою очередь будут использоваться named.
• named-checkconf – утилита проверки файла-конфигурации named.conf