Установка и настройка DNS в Ubuntu. Настройка собственных DNS серверов BIND

Электроника 10.04.2019
Электроника

Сегодня невозможно представить себе интернет без 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 представляет собой систему доменных имён, которая служит для преобразования имени в IP-адрес ПК и обратно. Таким образом, когда вы вводите адрес веб-страницы в браузере, система доменных имён преобразует его в IP-адрес хостинга , на котором располагается конкретный домен. В этой статье детально разберём, как установить и настроить DNS-сервер Ubuntu. Давайте же начнём. Поехали!

Перезапуск bind9

sudo service bind9 restart

Теперь укажите зоны прямого и обратного просмотра, а также введите их в конфигурации bind9. Исходные данные следующие:

Доменное имя - dom
IP-адрес сервера - 192.168.0.1
Имя сервера - ns.dom

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

sudo cp /etc/bind/db.local /var/lib/bind/db.dom

sudo nano /var/lib/bind/db.dom

и отредактируйте следующим образом:

$ORIGIN .
$TTL 604800 ; 1 week
dom IN SOA ns.dom. root.ns.dom. (
201605277 ; serial
604800 ; refresh (1 week)
86400 ; retry (1 day)
2419200 ; expire (4 weeks)
604800 ; minimum (1 week)
@ IN NS ns.dom.
@ IN A 192.168.0.1
@ IN AAAA::1
$ORIGIN dom.
$TTL 604800 ; 1 week
ns IN A 192.168.0.1

sudo cp /var/lib/bind/db.dom /var/lib/bind/db.192.dom

открываете его командой:

sudo nano /var/lib/bind/db.192.dom

и также редактируете:

$ORIGIN .
$TTL 604800 ; 1 week
0.168.192.in-addr.arpa IN SOA ns.dom. root.ns.dom. (
2016052655 ; serial
604800 ; refresh (1 week)
86400 ; retry (1 day)
2419200 ; expire (4 weeks)
604800 ; minimum (1 week)
@ IN NS ns.
$ORIGIN 0.168.192.in-addr.arpa.
$TTL 604800 ; 1 week
1 IN PTR ns.dom.

Чтобы настроить зоны в конфигурации bind9, нужно открыть файл конфигурации командой:

sudo nano /etc/bind/named.conf.local,

key DHCP_UPDATER {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret «9DxMmNw7J813qviXajG7rQ==»;
};

// зона прямого просмотра

zone «dom»{
type master;
file «/var/lib/bind/db.dom»;

};

// зона обратного просмотра

zone «0.168.192.in-addr.arpa»{
type master;
file «/var/lib/bind/db.192»;
allow-update { key DHCP_UPDATER; };
};

key DHCP_UPDATER - информация о secret key, который вы записывали в самом начале (его необходимо прописывать в кавычках). Если ранее, вы воспользовались вторым способом, введите:

// зона прямого просмотра

zone «dom»{
type master;
file «/var/lib/bind/db.dom»;

};

// зона обратного просмотра

zone «3.168.192.in-addr.arpa»{
type master;
file «/var/lib/bind/db.192»;
allow-update { key rndc-key; };
};

где key rndc-key - данные ключа, взятые из системы, а zone «dom» - данные о зоне применения системы доменных имён. Остаётся сохранить всё это дело, затем закрыть и перезапустить bind9, введя:

sudo /etc/init.d/bind9 restart

Проверка работы системы доменных имён

Теперь проверьте работу системы доменных имён:

в результате вы должны получить нечто вроде:

Server: 127.0.0.1
Address: 127.0.0.1#53
Name: ns.dom
Address: 192.168.0.1

Как вы можете убедиться, зона прямого просмотра работает. Теперь удостоверьтесь, что также работает и обратная:

В результате вы должны увидеть:

Server: 127.0.0.1
Address: 127.0.0.1#53
1.0.168.192.in-addr.arpa name = ns.dom.

В итоге вы должны получить имя сервера, введя его IP. Если у вас всё отображается подобным образом, значит, настройка была произведена верно. Если же нет, значит, ранее была допущена ошибка.

Настройка динамического обновления

Чтобы настроить динамическое обновление , откройте /etc/dhcp/dhcpd.conf, выполнив команду:

sudo nano /etc/dhcp/dhcpd.conf

Строку ddns-update-style none нужно заменить на ddns-update-style interim. Далее добавьте строку update-static-leases on, которая отвечает за создание зон для клиентов со статичным IP. Убедитесь, что в option domain-name содержится название домена «dom». В строке «key» должно быть название вашего ключа (если вы ранее выбирали первый способ, пропишите DHCP_UPDATER, если второй, то rndc-key), содержит ваш секретный ключ. Чтобы посмотреть rndc-key выполните:

cat /etc/bind/rndc.key |grep secret

в результате должно получиться нечто подобное:

secret «2mu11eRajAdm4KV0x0Pmcg==»;

На этом с настройками DHCP всё. Теперь необходимо перезапустить bind9 и dhcp. Для этого пропишите:

sudo service bind9 restart
sudo service isc-dhcp-server restart

Остаётся проверить как всё работает. Запустите клиентскую машину, находящуюся в сети с сервером. После запуска машина получит IP от DHCP, а он, в свою очередь, создаст запись типа client-pc.dom. По запросу «nslookup имя_клиентской_машины», вы должны получить ответ. Перезапустив server, можно будет посмотреть файлы прямого и обратного просмотра. Если на предыдущих этапах вы всё настроили правильно , там вы увидите информацию о новых машинах. Готово. Настройка завершена.

Итоги

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

Редактируем файл /etc/resolv.conf: первый DNS сервер это закольцовывание на ваш локальный сервер DNS (127.0.0.1), вторым ближайший к вам DNS сервер (обычно предоставляется вашим провайдером интернета), список остальных DNS на ваше усмотрение (они не являются обязательными). Файл resolv.conf, говорит нам о том, что в случае неудачного DNS запроса к вашему серверу (127.0.0.1), запрос будет автоматически переадресован ко второму по списку DNS серверу и т.д..

> ee /etc/resolv.conf domain your.domen nameserver 127.0.0.1 #DNS your ISP nameserver x.x.x.x nameserver x.x.x.x

Резолвер(resolver) - это набор подпрограмм в библиотеке C, которые предоставляют доступ к Internel Что такое DNS (Domain Name System) (Системе Доменных Имен Интернет) (прим. пер. – DNS обеспечивает возможность преобразования символьных имен машин в IP-адреса и наоборот, IP-адресов в символьные имена). Файл с настройками /etc/resolv.conf для резолвера содержит информацию, которую первым делом читают подпрограммы резолвера, вызванные каким-либо процессом. Данный файл устроен так, чтобы его мог читать человек и содержит список ключевых слов и значений, которые предоставляют резолверу различную информацию.

В нормально настроенной системе данный файл не нужен: запросы будут обрабатываться сервером на локальном хосте, имя домена определяется из имени машины, а путь поиска машины по домену конструируется из имени домена.

Параметры конфигурации:

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

Локальное имя домена. Большинство запросов на имена машин в этом домене смогут использовать лишь краткие имена, без указания имени домена. Если записей domain нет, то домен определяется из имени локальной машины, которое возвращается функцией gethostname(); доменной частью имени считается все, что следует после первой точки `.". Наконец, если имя машины не содержит доменной части, назначается корневой домен.

Список для поиска имен машин. Список обычно определяется из локального имени домена; по умолчанию он содержит только имя локального домена. В списке может быть задано несколько доменов, которые должны следовать за ключевым словом search и отделяться друг от друга пробелами или табуляциями. В большинстве случаев, если в запросе к резолверу задано короткое имя машины (без доменной части), то к нему будет поочередно добавляться каждый домен из заданного списка, пока не будет найдено полное совпадающее имя машины. Заметим, что данный процесс может быть медленным, и станет генерировать ощутимый сетевой траффик, если серверы, обслуживающие перечисленные в списке домены, не являются локальными, а также что запросы вернут ошибку тайм-аута, если сервер для одного из доменов недоступен. Список в данный момент ограничен шестью доменами, общая длина имен которых не должна превышать 256 символов.

Разрешает сортировку адресов, которые возвращаются вызовом gethostbyname(). Опция sortlist задается с помощью пары: IP адрес/маска сети. Маска сети является необязательной, по умолчанию используется текущая маска сети. Пары из IP-адреса и необязательной маски сети разделяются прямой косой чертой. Может быть задано до 10 пар. пример: sortlist 130.155.160.0/255.255.240.0 130.155.0.0

Данная опция разрешает изменение определенных переменных резолвера. Синтаксис такой:

Options опция... где опция может принимать одно из следующих значений: debug --- устанавливает RES_DEBUG в _res.options. ndots:n --- устанавливает порог для количества точек, которое должно быть в имени, заданном в res_query (см. resolver(@LIB_NETWORK_EXT@)) перед тем как будет создан начальный абсолютный запрос (initial absolute query). По умолчанию, n ``1"", означает, что если в имени есть хоть одна точка, будет попытка считать это имя абсолютным перед добавлением к нему элементов из списка search.

Ключевые слова domain и search являются взаимно исключающими. Если эти слова заданы оба, то будет работать то, которое задано последним.

Ключевое слово и значение должны быть в одной строке, и кроме того, ключевое слово (например, nameserver), должно быть первым в строке. Значение должно отделяться от ключевого слова пробелом.

Рассмотрим примерный конфигурационный файл кеширующего DNS -сервера для отдельно стоящего сервера. Кэширующий сервер имён – это сервер имён, не отвечающий ни за какую зону. Он просто выполняет запросы от своего имени и сохраняет результаты для своего последующего использования.
О сетевом сервисе DNS и настройке BIND9 еще можно почитать в Главе 25 Руководства FreeBSD . По умолчанию во FreeBSD используется одна из версий программы BIND (Berkeley Internet Name Domain), являющейся самой распространенной реализацией протокола DNS .

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


Рекомендуем почитать

Наверх