В этой статье мы рассмотрим один из вариантов развертывания DNS сервера для локальной сети на базе Ubuntu (у меня 14.04.3 LTS) и bind9. Для большинства других дистрибутивов отличия будут минимальны, для Debian-подобных их не будет совсем. Если вы уже ознакомились с предыдущей статьей по настройке DHCP сервера, то знаете, что изначально у меня был установлен неподдерживаемый дистрибутивом dnsmasq, который было решено заменить. Поскольку в прошлый раз я удалил dnsmasq (а он был как DHCP, так и DNS - сервером, который, кстати, не был должным образом сконфигурирован и не работал), то появилась потребность в DNS, чем я и решил на досуге заняться. Настройка DNS занимает немногим больше времени, но только из-за большего числа конфигурационных файлов.
И так, приступим. Первым делом актуализируем систему (обновим пакеты):
sudo apt-get update && sudo apt-get upgrade -y
Теперь установим DNS сервер bind9:
sudo apt-get install bind9
Теперь можно создать ключ для того, чтобы другие демоны могли обновлять DNS-записи этого сервера. Это могут быть как другие серверы в сети, так и другие сервисы этого же сервера. У меня это будет локально же установленный DHCP сервер. В теории, безопасности для, каждому сервису или серверу нужно сгенерировать свой ключ, тогда при компрометации одного из них, его можно просто заблокировать, а остальные продолжат работать. Но в моем случае обновлять записи будет только мой же DHCP сервер, так что я генерирую только один ключ:
dnssec-keygen -a HMAC-MD5 -b 128 -r /dev/urandom -n USER DHCP_UPDATER
В домашнем каталоге пользователя, от которого была запущена команда появится 2 файла:
-rw------- 1 user user 54 янв. 21 12:17 Kdhcp_updater.+157+55379.key-rw------- 1 user user 165 янв. 21 12:17 Kdhcp_updater.+157+55379.private
Файлы пусть так и лежат, они не потеряются. Чтобы посмотреть необходимый ключ, выполните:
tail Kdhcp_updater*.private
Вы увидите примерно такое содержимое, кде значение "Key" и есть требуемый ключ:
Для начала сделаем наш DNS сервер кэширующим сервером имен, то есть заставим его разрешать доменные имена, запрашивая их у вышестоящего сервера. При первом запросе доменного имени от клиента сервер будет пересылать запрос на вышестоящий сервер, а затем уже будет возвращать его из своего кэша, что несколько увеличит скорость обработки DNS-запросов для клиентов в нашей сети. Так же мы укажем серверу, на каких адресах наш DNS будет обслуживать клиентов. Для этого нужно отредактировать файл /etc/bind/named.conf.options:
sudo cp /etc/bind/named.conf.options /etc/bind/named.conf.options.dist && sudo nano /etc/bind/named.conf.options
Добавим туда следующие строки:
forwarders {212.120.160.130;8.8.8.8;};listen-on {127.0.0.1;192.168.0.231;};
Рассмотри эти секции:
- forwarders - тут указываем вышестоящие серверы имен. Их количество не ограничено, при недоступности одного из них запросы будут пересылаться на следующий в списке. Я указал DNS своего провайдера и Google Public DNS;
- lisnen-on - адреса локальных интерфейсов, на которые сервер будет принимать DNS-запросы клиентов.
В nano это выглядит примерно так:
Сохраняем конфигурацию. Теперь можно перезапустить DNS службу:
sudo service bind9 restart
Теперь наш сервер работает в качестве кэширующего DNS, что уже позволяет указать его в качестве DNS-сервера любому клиенту в нашей сети. Проверим его работу, для этого сгодится любой компьютер в сети или сам сервер. Я покажу на примере рабочей станции с Windows 7. Нажимаем Win+R, в появившемся окне пишем cmd, запустится командная оболочка windows. Пишем туда следующее:
nslookup - 192.168.0.231
Вы, естественно, пишете IP своего сервера. Запустится консольная утилита диагностики DNS для Windows - nslookup, а в качестве DNS сервера будет использован не системный DNS, а указанный в параметре. Nslookup хорош тем, что отсылает запросы на требуемый сервер минуя DNS-кэш Windows. Первым делом проверим работоспособность прямых DNS запросов:
> google.ru
Затем работоспособность обратных запросов:
> 212.120.160.130
В cmd.exe выглядит примерно так:
Если у Вас все точно так же, значит Ваш DNS уже отлично работает в качестве кэширующего сервера. В случае с google.ru мы так же можем видеть, что наш сервер способен разрешать и IPv6.
Теперь нам надо указать своему серверу использовать в качестве DNS самого себя. Делать это он будет по loopback-интерфейсу. Для этого нам надо изменить файл /etc/resolv.conf, но менять его самостоятельно смысла нет, поскольку перезагрузки его всеравно исправит network manager. Поэтому мы будем редактировать /etc/network/interfaces:
sudo nano /etc/network/interfaces
Находим там секцию с интерфейсом локальной сети (у меня это eth0) и добавляем или изменяем следующие строки:
dns-nameservers 127.0.0.1dns-search ordaupfin.local
*вместо ordaupfin.local Вы указываете свой домен или рабочую группу.
Должно получиться примерно как у меня:
Теперь, если Вы находитесь непосредственно за консолью сервера физически, достаточно перезапустить сервис networking командой:
sudo service networking restart
А если вы подключены к серверу по SSH (как я), то активная сессия не позволит сервису перезапуститься, поэтому сервер придется перезагрузить:
sudo reboot
Теперь можно проверить, действительно ли сервер направляет DNS-запросы самому себе, в терминал пишем:
dig google.ru
Если в последних строчках пишет SERVER: 127.0.0.1 - значит все настроено правильно. Вот как должен выглядеть выхлоп dig на google.ru:
Если вы выполните dig google.ru повторно, то увидите, что время выполнение запроса существенно сократилось. Это связано с тем, что все последующие запросы по тому же домену сервер будет брать из кэша, не пересылая запрос на вышестоящий сервер.
Наш DNS сервер хорошо справляется с разрешением имен на внешних адресах, но он абсолютно ничего не знает о клиентах в локальной сети. Для того, чтобы он мог разрешать имена локальных машин и устройств, нужно настроить его в качестве первичного мастера для своей сети. Более того, это необходимо для полноценного функционирования сети.
Создаем зону прямого просмотра. Сервер уже содержит типовые файлы настроек, поэтому их нужно лишь скопировать в рабочую директорию и изменить под себя. Я использую свои данные, Вы, само собой, должны подставить свои. Копируем файл конфигурации зоны прямого просмотра и открываем его на редактирование:
sudo cp /etc/bind/db.local /var/lib/bind/db.ordaupfin.local && sudo nano /var/lib/bind/db.ordaupfin.local
Приведем его к такому виду (не забываем указывать свои данные вместо исходных):
; BIND data file for local loopback interface;$TTL 604800@ IN SOA ubunturoute.ordaupfin.local. root.ubunturoute.ordaupfin.local. (20150122 ; Serial604800 ; Refresh86400 ; Retry2419200 ; Expire604800 ) ; Negative Cache TTL;@ IN NS ubunturoute.ordaupfin.local.@ IN A 192.168.0.231@ IN AAAA ::1ubunturoute IN A 192.168.0.231
Теперь подобным образом создаем и редактируем файл зоны обратного просмотра:
sudo cp /etc/bind/db.127 /var/lib/bind/db.192 && sudo nano /var/lib/bind/db.192
И приводим его к следующему виду:
; BIND reverse data file for local loopback interface;$TTL 604800@ IN SOA ubunturoute.ordaupfin.local. root.ubunturoute.ordaupfin.local. (20150122 ; Serial604800 ; Refresh86400 ; Retry2419200 ; Expire604800 ) ; Negative Cache TTL;@ IN NS ubunturoute.231 IN PTR ubunturoute.ordaupfin.local.
Обратите, пожалуйста, внимание на то, что "231", с которого начинается последняя строка - это последняя секция в IP-адресе моего сервера, В вашем случае, она, скорей всего, будет иной.
Теперь эти зоны нужно прописать в основную конфигурацию сервера, чтобы при последующем запуске он знал об их существовании. Для этого открываем на редактирование /etc/bind/named.conf.local
sudo cp /etc/bind/named.conf.local /etc/bind/named.conf.local.dist && sudo nano /etc/bind/named.conf.local
И добавляем туда такое содержимое:
key DHCP_UPDATER {algorithm HMAC-MD5.SIG-ALG.REG.INT;secret "s5Efp/-/-/-/wQtvg9rR7Q==";};
zone "ordaupfin.local" {type master;file "/var/lib/bind/db.ordaupfin.local";allow-update { key DHCP_UPDATER; };};
zone "0.168.192.in-addr.arpa" {type master;file "/var/lib/bind/db.192";allow-update { key DHCP_UPDATER; };};
Где:
- key DHCP_UPDATER - информация для обновления записей, сюда Вы вписываете сгенерированный ранее свой ключ;
- zone "ordaupfin.local" - зона прямого просмотра;
- zone "0.168.192.in-addr.arpa" - зона обратного просмотра.
Выглядеть будет примерно так:
Сохраняем и перезапускаем сервер:
sudo service bind9 restart
Проверяем работу сервера:
nslookup ubunturoute.ordaupfin.local
Выхлоп должен быть таким:
Server: 127.0.0.1Address: 127.0.0.1#53
Name: ubunturoute.ordaupfin.localAddress: 192.168.0.231
Подобным образом проверяем работоспособность зоны обратного просмотра:
nslookup 192.168.0.231
И получаем:
Server: 127.0.0.1Address: 127.0.0.1#53
231.0.168.192.in-addr.arpa name = ubunturoute.ordaupfin.local.
Если у Вас все точно так, дело почти сделано. Почти, потому что теперь нам надо, чтобы наш DHCP сервер мог обновлять DNS-записи при появлении новых клиентов. Я буду рассматривать настройку на примере установленного у меня isc-dhcp-server. Редактируем /etc/dhcp/dhcpd.conf:
sudo nano /etc/dhcp/dhcpd.conf
И вставляем туда следующее содержимое:
ddns-update-style interim;update-static-leases on;key DHCP_UPDATER {algorithm hmac-md5;secret "s5EfpF53BBE9/-/tvg9rR7Q==";}zone ordaupfin.local. {primary 127.0.0.1;key DHCP_UPDATER;}zone 0.168.192.in-addr.arpa. {primary 127.0.0.1;key DHCP_UPDATER;}
Вы, конечно, должны подставить свои значения. После этого перезапустим DNS и DHCP сервер. Если сервер запустился без ошибок - все отличено. Если сервер не запускается - внимательно смотрим в конфиги, кроме того в диагностике ошибок Вам очень поможет syslog:
tail -f /var/log/syslog
Спасибо за внимание!
Если статья показалась полезной, поделитесь ей в соц сетях, кнопки которых расположены ниже
Предложения и обсуждения данной статьи ведется в комментариях
Комментарии к статье:
ВКонтакте
