Bind9 ubuntu настройка внутренней и внешней зоны. Проверка настроек и перезапуск Bind

Добрый день, сегодня расскажу как настроить DNS на сервере Ubuntu 14.04 LTS. Для начало теория: DNS это служба сервера, которая преобразует доменное имя в IP-адрес. Например www.example.com будет преобразовано в 93.184.216.34. Записи в DNS имеют несколько типов (Основные: A -address record, AAAA -IPv6 address record, CNAME -canonical name record, MX -mail exchange, NS -name server, PTR -pointer, SOA -Start of Authority).

И так приступим к самой настройке DNS. Прежде всего, я полагаю что у Вас установлен сервер Ubuntu 14.04 LTS, выполнено его обновление. Для обновления, выполните в командной строке две команды:

Apt-get update

Sudo apt-get upgrade

После выполнения обновления выполним установку службы Bind9.

Sudo apt-get install bind9

Bind9 установлен, но не настроен. Произведем его настройку. Остановим службу:

Sudo service bind9 stop

Укажем адреса, на которых Bind9 будет слушать запросы и куда перенаправлять в случае если он не отвечает за эту зону. Для этого открываем файл /etc/bind/named.conf.options

Sudo nano /etc/bind/named.conf.options

в графу forwarders указываем сервера для пересылки запросов, а в графу listen-on указываем на каких адресах он должен отвечать. Должно получится что-то вроде этого:

Options { directory "/var/cache/bind"; // If there is a firewall between you and nameservers you want // to talk to, you may need to fix the firewall to allow multiple // ports to talk. See http://www.kb.cert.org/vuls/id/800113 // If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders. // Uncomment the following block, and insert the addresses replacing // the all-0"s placeholder. // forwarders { // 0.0.0.0; // }; //======================================================================== // If BIND logs error messages about the root key being expired, // you will need to update your keys. See https://www.isc.org/bind-keys //======================================================================== dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; forwarders { 8.8.8.8; 8.8.4.4; }; listen-on { 127.0.0.1; 192.168.0.1; }; };

Обратите внимание на строку listen-on-v6 { any; }; если у Вас включен IPv6, то Bind9 будет слушать на всех адресах IPv6. Если необходимо этого избежать, то за комментируйте эту строку или укажите конкретный адрес. Не рекомендуется слушать на всех адресах, особенно которые на прямую смотрят в интернет, так как существует масса атак на DNS сервера.

Теперь настроим зоны, которыми будет управлять наш Bind9. Для этого открываем файл /etc/bind/named.conf.local

Sudo nano /etc/bind/named.conf.local

Прописываем согласно примера:

Zone "example.com" { //Домен которой будем управлять type master; //Тип. Bind9 главный он и будет управлять file "/etc/bind/db.example.com"; //Файл с содержанием домена }; zone "0.168.192.in-addr.arpa" { //Обратная запись для домена type master; //Тип. Bind9 главный он и будет управлять file "/etc/bind/db.0.168.192"; //Файл с обратными записями домена };

Теперь создадим файл зон:

Sudo touch /etc/bind/db.example.com

Sudo touch /etc/bind/db.0.168.192

В файл /etc/bind/db.example.com мы должны прописать зоны прямого просмотра и указать NS сервера, по сколько мы будем являться для данного домена NS сервером, то необходимо указать имя нашего хоста. У меня имя хоста сервера, заданное при установке, srv-bind9. Заполняем по примеру:

; BIND data file for local loopback interface ; $TTL 604800 @ IN SOA srv-bind9.example.com. root.srv-bind9.example.com. (//обратите внимание в конце стоит точка 20150120 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800) ; Negative Cache TTL ; @ IN NS srv-bind9.example.com. @ IN A 192.168.0.1 //указываем адрес нашего сервера @ IN AAAA::1 //указываем IPv6 адрес нашего сервера, если есть. srv-bind9 IN A 192.168.0.1 //указываем адрес нашего сервера

Прямую зону настроили, теперь настроим обратную. Открываем файл: /etc/bind/db.0.168.192 и настраиваем по примеру:

; BIND reverse data file for local loopback interface ; $TTL 604800 @ IN SOA srv-bind9.example.com. root.srv-bind9.example.com. (//обратите внимание в конце стоит точка 20141126 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800) ; Negative Cache TTL ; @ IN NS srv-bind9. //обратите внимание в конце стоит точка 1 IN PTR srv-bind9.example.com. //В первой колонке указывается последняя цифра IP-адреса. //Обратите внимание в конце стоит точка

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

Named-checkconf

Если она ничего не сообщила, то всё сделано правильно. И можно запускать Bind9:

Sudo service bind9 start

Вот мы и закончили установку и настройку Bind9

Рассмотрим примерный конфигурационный файл кеширующего 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

DNS (Domain Name System) – важный и довольно сложный в настройке компонент, необходимый для работы веб-сайтов и серверов. Многие пользователи обращаются к DNS-серверам, которые предоставляет их хостинг-провайдер, однако собственные DNS-серверы имеют некоторые преимущества.

В данном мануале вы узнаете, как установить Bind9 и настроить его как кэширующий или перенаправляющий DNS-сервер на сервере Ubuntu 14.04.

Требования

Понимание базовых типов DNS-серверов. Ознакомиться с подробностями можно в .
Две машины, из которых хотя бы одна работает на Ubuntu 14.04. Первая машина будет настроена как клиент (IP-адрес 192.0.2.100), а вторая – как DNS-сервер (192.0.2.1).

Вы научитесь настраивать клиентскую машину для отправки запросов через DNS-сервер.

Кэширующий DNS-сервер

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

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

Почти все DNS-серверы в вашей сетевой конфигурации будут кэширующими. Кэширующий DNS-сервер – хороший выбор для многих ситуаций. Если вы не хотите полагаться на DNS-серверы вашего хостинг-провайдера или другие общедоступные DNS-серверы, настройте собственный кэширующий DNS-сервер. Чем меньше расстояние от DNS-сервера к клиентским машинам, тем меньше время обслуживания запросов DNS.

Перенаправляющий DNS-сервер

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

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

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

1: Установка Bind на DNS-сервер

Пакет Bind можно найти в официальном репозитории Ubuntu. Обновите индекс пакетов и установите Bind с помощью менеджера apt. Также нужно установить пару зависимостей.

sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc

После этого можно начать настройку сервера. Конфигурацию кэширующего сервера можно использовать в качестве шаблона для настройки перенаправляющего сервера, поэтому сначала нужно настроить кэширующий DNS-сервер.

2: Настройка кэширующего DNS-сервера

Сначала нужно настроить Bind в качестве кэширующего DNS-сервера. Такая конфигурация заставит сервер рекурсивно искать ответы на клиентские запросы на других DNS-серверах. Он будет последовательно опрашивать все соответствующие DNS-сервера, пока не найдет ответ.

Конфигурационные файлы Bind хранятся в каталоге /etc/bind.

Большую часть файлов редактировать не нужно. Главный конфигурационный файл называется named.conf (named и bind – два названия одного приложения). Этот файл ссылается на файлы named.conf.options, named.conf.local и named.conf.default-zones.

Для настройки кэширующего DNS-сервера нужно отредактировать только named.conf.options.

sudo nano named.conf.options

Этот файл выглядит так (комментарии опущены для простоты):

options {
directory "/var/cache/bind";
dnssec-validation auto;

listen-on-v6 { any; };
};

Чтобы настроить кэширующий сервер, нужно создать список контроля доступа, или ACL.

Нужно защитить DNS-сервер, обрабатывающий рекурсивные запросы, от злоумышленников. Атаки DNS-усиления особенно опасны, поскольку могут вовлечь сервер в распределенные атаки на отказ в обслуживании.

Атаки DNS-усиления – это один из способов прекращения работы серверов и сайтов. Для этого злоумышленники пытаются найти общедоступные DNS-серверы, которые обрабатывают рекурсивные запросы. Они подделывают IP-адрес жертвы и отправляют запрос, который вернет DNS-серверу очень объемный ответ. При этом DNS-сервер возвращает на сервер жертвы слишком много данных в ответ на небольшой запрос, увеличивая доступную пропускную способность злоумышленника.

Для размещения общедоступного рекурсивного DNS-сервера требуется тщательная настройка и администрирование. Чтобы предотвратить возможность взлома сервера, настройте список IP-адресов или диапазонов сети, которым сервер сможет доверять.

Перед блоком options добавьте блок acl. Создайте метку для группы ACL (в данном мануале группа называется goodclients).

acl goodclients {
};
options {
. . .

В этом блоке перечислите IP-адреса или сети, у которых будет доступ к этому DNS-серверу. Поскольку сервер и клиент работают в подсети /24, можно ограничить доступ по этой подсети. Также нужно разблокировать localhost и localnets, которые подключаются автоматически.

acl goodclients {
192.0.2.0/24;
localhost;
localnets;
};
options {
. . .

Теперь у вас есть ACL безопасных клиентов. Можно приступать к настройке разрешения запросов в блоке options. Добавьте в него такие строки:

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

. . .

Блок options явно включает рекурсию, а затем настраивает параметр allow-query для использования списка ACL. Для ссылки на группу ACL можно также использовать другой параметр, например allow-recursion. При включенной рекурсии allow-recursion определит список клиентов, которые могут использовать рекурсивные сервисы.

Однако если параметр allow-recursion не установлен, Bind возвращается к списку allow-query-cache, затем к списку allow-query и, наконец, к спискам по умолчанию localnets и localhost. Поскольку мы настраиваем только кэширующий сервер (он не имеет собственных зон и не пересылает запросы), список allow-query всегда будет применяться только к рекурсии. Это самый общий способ определения ACL.

Сохраните и закройте файл.

Это все настройки, которые нужно добавить в конфигурационный файл кэширующего DNS-сервера.

Примечание : Если вы хотите использовать только этот тип DNS, переходите к проверке конфигураций, перезапустите сервис и настройте свой клиент.

3: Настройка перенаправляющего DNS-сервера

Если вашей инфраструктуре больше подходит перенаправляющий DNS-сервер, вы можете немного откорректировать настройку.

На данный момент файл named.conf.options выглядит так:

acl goodclients {
192.0.2.0/24;
localhost;
localnets;
};
options {
directory "/var/cache/bind";
recursion yes;
allow-query { goodclients; };
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};

Можно использовать тот же список ACL, чтобы ограничивать DNS-сервер конкретным списком клиентов. Однако при этом необходимо немного изменить конфигурацию, чтобы сервер больше не пытался выполнять рекурсивные запросы.

Не меняйте значение recursion на no. Перенаправляющий сервер все-таки поддерживает рекурсивные сервисы. Чтобы настроить перенаправляющий сервер, нужно создать список кэширующих серверов, на которые он будет перенаправлять запросы.

Это делается в блоке options {}. Сначала нужно создать в нем новый блок forwarders, где будут храниться IP-адреса рекурсивных серверов имен, на которые нужно перенаправлять запросы. В данном случае это будут DNS-серверы Google (8.8.8.8 и 8.8.4.4):

. . .
options {
directory "/var/cache/bind";
recursion yes;
allow-query { goodclients; };
forwarders {

8.8.8.8;

8.8.4.4;

};
. . .

В результате конфигурация выглядит так:

acl goodclients {
192.0.2.0/24;
localhost;
localnets;
};
options {
directory "/var/cache/bind";
recursion yes;
allow-query { goodclients; };
forwarders {
8.8.8.8;
8.8.4.4;
};
forward only;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};

Последнее изменение касается параметра dnssec. При текущей конфигурации и в зависимости от настройки DNS-серверов, на которые перенаправляются запросы, в логах могут появиться такие ошибки:

Jun 25 15:03:29 cache named: error (chase DS servers) resolving "in-addr.arpa/DS/IN": 8.8.8.8#53
Jun 25 15:03:29 cache named: error (no valid DS) resolving "111.111.111.111.in-addr.arpa/PTR/IN": 8.8.4.4#53

Чтобы избежать их, нужно изменить значение параметра dnssec-validation на yes и явно разрешить dnssec.

. . .
forward only;
dnssec-enable yes;
dnssec-validation yes;
auth-nxdomain no; # conform to RFC1035
. . .

Сохраните и закройте файл. Настройка перенаправляющего DNS-сервера завершена.

4: Проверка настроек и перезапуск Bind

Теперь нужно убедиться, что настройки работают должным образом.

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

sudo named-checkconf

Если в файлах нет ошибок, командная строка не отобразит никакого вывода.

Если вы получили сообщение об ошибке, исправьте ее и повторите проверку.

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

sudo service bind9 restart

После нужно проверить логи сервера. Запустите на сервер команду:

sudo tail -f /var/log/syslog

Теперь откройте новый терминал и приступайте к настройке клиентской машины.

5: Настройка клиента

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

Отредактируйте файл /etc/resolv.conf, чтобы направить сервер на сервер имен.

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

Откройте файл с помощью sudo в текстовом редакторе:

sudo nano /etc/resolv.conf

В файле нужно перечислить DNS-серверы, которые будут использоваться для разрешения запросов. Для этого используйте директиву nameserver. Закомментируйте все текущие записи и добавьте строку nameserver, указывающую на ваш DNS-сервер:

nameserver 192.0.2.1
# nameserver 8.8.4.4
# nameserver 8.8.8.8
# nameserver 209.244.0.3

Сохраните и закройте файл.

Теперь можно отправить тестовый запрос, чтобы убедиться, что он разрешается правильно.

Для этого можно использовать ping:

ping -c 1 google.com
PING google.com (173.194.33.1) 56(84) bytes of data.
64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63.8 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000 ms

Одним из важных сервисов, обеспечивающих функционирование современного интернета является сервис по преобразованию имени сайта в ip адрес. Настройкой реализации сервиса DNS мы займемся в этой статье на примере настройки Bind 9 (named) на сервере под управлением CentOS 7. Мы подготовим минимально необходимый базовый функционал и заглянем немного глубже в настройки логирования.

Bind — самая распространенная на текущий день реализация ДНС сервера, которая обеспечивает преобразование IP адресов в dns-имена и наоборот. Его также называют named, например в Freebsd. Судя по информации из Википедии, сейчас 10 из 13 корневых ДНС серверов интернета работают на bind. Он установлен из коробки практически во всех linux дистрибутивах. Я рассмотрю его установку на сервер CentOS 7.

Устанавливаем Bind 9 (named) в CentOS 7

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

# rpm -qa bind* bind-libs-lite-9.9.4-14.el7.x86_64 bind-license-9.9.4-14.el7.noarch

У меня не установлен, так как во время выбрал минимальный пакет программ. Сервер имен у нас будет работать в chroot окружении, так что устанавливаем соответствующие пакеты:

# yum - y install bind bind - utils bind - chroot

Еще раз обращаю внимание, что мы будем использовать bind в chroot среде для увеличения безопасности. Это накладывает определенные особенности в настройке и управлении сервером. Нужно быть внимательным в этих мелочах. Итак, запускаем bind :

# systemctl start named-chroot # systemctl enable named-chroot ln -s "/usr/lib/systemd/system/named-chroot.service" "/etc/systemd/system/multi-user.target.wants/named-chroot.service"

Проверяем содержимое chroot каталога:

# ls -l /var/named/chroot/etc

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

Настраиваем DNS сервер в CentOS 7

Файл конфигурации нашего сервера располагается по адресу /var/named/chroot/etc/named.conf . Открываем его и приводим к следующему виду:

# mcedit /var/named/chroot/etc/named.conf options { listen-on port 53 { any; }; listen-on-v6 port 53 { none; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; allow-query { 127.0.0.1; 192.168.7.0/24; }; recursion yes; allow-recursion { 127.0.0.1; 192.168.7.0/24; }; forwarders { 8.8.8.8; }; version "DNS Server"; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; dnssec-enable no; dnssec-validation no; }; zone "." IN { type hint; file "named.ca"; }; include "/etc/named.rfc1912.zones"; include "/etc/named.root.key"; logging { channel default_file { file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; }; category default { default_file; }; };

Эта конфигурация обеспечит работу обычного кэширующего сервера в локальной сети. Комментарии к некоторым параметрам:

Не забудьте отредактировать правила фаервола для корректной работы DNS сервера — открыть 53 порт UDP для работы кэширующего сервера, который мы сейчас настроили, и 53 порт TCP для пересылки зон, о которых речь пойдет дальше

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

# cd /var/named/chroot/var/log && mkdir named && chown named. named

Поддержка собственной зоны

Допустим, нам необходимо в нашем named разместить собственную зону site1.ru. Первым делом создаем файл зоны, которую будет обслуживать dns сервер:

# mcedit /var/named/chroot/var/named/site1.ru.zone $TTL 86400 @ IN SOA site1.ru. site1.ru.local. (2015092502 43200 3600 3600000 2592000) IN NS ns1.site1.ru. IN NS ns2.site1.ru. IN A 192.168.7.254 IN MX 10 mx.site1.ru. gate IN A 192.168.7.254 mx IN A 192.168.7.250 ns1 IN A 192.168.7.235 ns2 IN A 192.168.7.231

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

Выставляем необходимые права:

# chown root:named /var/named/chroot/var/named/site1.ru.zone # chmod 0640 /var/named/chroot/var/named/site1.ru.zone

Zone "site1.ru" { type master; file "site1.ru.zone"; };

Перечитываем конфигурацию named с помощью rndc :

# rndc reconfig

Добавление в bind slave zone

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

Zone "site.ru" IN { type slave; masters { 10.1.3.4; }; file "site.ru.zone"; };

10.1.3.4 — ip адрес dns сервера, с которого мы берем зону. Не забудьте на нем разрешить передачу зоны на ваш dns сервер.

Нужно добавить группе named разрешение на запись, чтобы стало вот так:

После этого можно перезапустить bind и проверить, что создался файл слейв зоны. С указанными выше настройками, он будет располагаться по адресу /var/named/chroot/var/named/site.ru.zone . Если у bind не будет прав для создания файла, в логе вы получите ошибку:

Dumping master file: tmp-7Swr6EZpcd: open: permission denied

Гораздо интереснее и полезнее разобраться с подробным логированием работы сервера. Я долгое время поверхностно хватался за всякие рекомендации и куски примерных конфигов в интернете, пока в не решил разобраться сам с этой темой и не полез в оригинальный мануал .

Bind дает широкие возможности для ведения логов. Можно фиксировать практически все, что связано с работой сервера. Я сейчас на простых примерах покажу, как это работает.

Первым делом в конфигурации мы задаем канал, куда будут складываться логи по тем или иным событиям. Вот пример подобного канала:

Channel general { file "/var/log/named/general.log" versions 3 size 5m; severity dynamic; print-time yes;

Здесь указано название канала, которые мы придумываем сами — general, указан путь до файла, сказано, что хранить будем 3 версии лога размером не более 5 мегабайт. Параметр severity может принимать следующие значения:

Параметр print-time указывает на то, что в лог необходимо записывать время события. Помимо указанных мной настроек, в конфигурации канала могут быть добавлены следующие параметры:

print-severity yes | no — указывает, писать или нет параметр severity в лог
print-category yes | no — указывает писать или нет название категории логов

Я эти параметры не указал, так как по-умолчанию устанавливается значение no , которое лично меня устраивает.

Category general { general; };

Описание категорий логов в bind (named)

default	Сюда будут попадать события всех категорий из этой таблицы, если они не определены отдельно, за исключением категории queries, которую нужно включать специально. То есть если обозначить только категорию default, то в нее будут сыпаться события всех категорий.
general	Эта категория для всех логов, которые не включены ни в одну из перечисленных категорий.
database	Сообщения, относящиеся к хранению зон и кэшированию.
security	Подтверждение и отказ в выполнении запросов.
config	Все, что относится к чтению и выполнению файла конфигурация.
resolver	Разрешение имен, включая информацию о рекурсивных запросах, выполняемых от имени клиента кэширующим сервером.
xfer-in	Информация о получении зон.
xfer-out	Информация о передаче зон.
notify	Логирование операций протокола NOTIFY.
client	Выполнение клиентских запросов.
unmatched	Сообщения, которые named не смог отнести ни к одному классу или для которых не определено отображение.
network	Логирование сетевых операций.
update	Динамические апдейты.
update-security	Подтверждение или отклонение запросов на апдейт.
queries	Логирование запросов к ДНС серверу. Для включения этой категории необходимо отдельно задать параметр в конфигурации сервера. Это связано с тем, что эта категория генерирует очень много записей в лог файл, что может сказаться на производительности сервера.
query-errors	Ошибки запросов к серверу.
dispatch	Перенаправление входящих пакетов модулям сервера на обработку.
dnssec	Работа протоколов DNSSEC и TSIG.
lame-servers	Фиксируются ошибки, которые получает bind при обращении к удаленным серверам в попытке выполнить запрос на разрешение имени.
delegation-only	Логирование запросов, вернувших NXDOMAIN.
edns-disabled	Запросы, которые вынуждены использовать plain DNS из-за превышения timeouts.
RPZ	Все операции, связанные с выполнение Response Policy Zone (RPZ).
rate-limit	Операции связанные с одним или несколькими rate-limit statements в options или view.

Таким образом, чтобы вывести все категории логов в отдельные файлы, необходимо в конфиг named добавить следующую конструкцию:

Logging { channel default { file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel general { file "/var/log/named/general.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel database { file "/var/log/named/database.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel security { file "/var/log/named/security.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel config { file "/var/log/named/config.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel resolver { file "/var/log/named/resolver.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel xfer-in { file "/var/log/named/xfer-in.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel xfer-out { file "/var/log/named/xfer-out.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel notify { file "/var/log/named/notify.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel client { file "/var/log/named/client.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel unmatched { file "/var/log/named/unmatched.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel network { file "/var/log/named/network.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel update { file "/var/log/named/update.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel update-security { file "/var/log/named/update-security.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel queries { file "/var/log/named/queries.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel query-errors { file "/var/log/named/query-errors.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel dispatch { file "/var/log/named/dispatch.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel dnssec { file "/var/log/named/dnssec.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel lame-servers { file "/var/log/named/lame-servers.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel delegation-only { file "/var/log/named/delegation-only.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel edns-disabled { file "/var/log/named/edns-disabled.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel rpz { file "/var/log/named/rpz.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel rate-limit { file "/var/log/named/rate-limit.log" versions 3 size 5m; severity dynamic; print-time yes; }; category default { default; }; category general { general; }; category database { database; }; category security { security; }; category config { config; }; category resolver { resolver; }; category xfer-in { xfer-in; }; category xfer-out { xfer-out; }; category notify { notify; }; category client { client; }; category unmatched { unmatched; }; category network { network; }; category update { update; }; category update-security { update-security; }; category queries { queries; }; category query-errors { query-errors; }; category dispatch { dispatch; }; category dnssec { dnssec; }; category lame-servers { lame-servers; }; category delegation-only { delegation-only; }; category edns-disabled { edns-disabled; }; category rpz { rpz; }; category rate-limit { rate-limit; }; };

Если мы хотим собирать все логи запросов из категории queries , то в раздел options файла конфигурации необходимо добавить параметр, который это разрешает:

Querylog yes;

Перезапускаем bind :

# systemctl restart named-chroot.service

Проверка работы DNS Server

Первым делом пойдем в каталог с логами и проверим, что там у нас:

# cd /var/named/chroot/var/log/named # ls -l

Все файлы журнала созданы и начали наполняться. Можно проверить один из них. Например, посмотрим, как наш сервер centos (192.168.7.246) логирует запросы пользователей. Попробуем с компьютера 192.168.7.254 (windows) выполнить nslookup yandex.ru и посмотрим как это отразится в лог файле:

26-Sep-2015 19:25:30.923 client 192.168.7.254#56374 (yandex.ru): query: yandex.ru IN A + (192.168.7.246) 26-Sep-2015 19:25:31.013 client 192.168.7.254#56375 (yandex.ru): query: yandex.ru IN AAAA + (192.168.7.246)

Теперь выполним ping site1.ru, чтобы проверить, как сервер поддерживает нашу зону:

Смотрим, что в логах:

26-Sep-2015 19:28:01.660 client 192.168.7.254#49816 (site1.ru): query: site1.ru IN A + (192.168.7.246)

Таким образом очень удобно отследить, куда лезет компьютер. Например, можно поднять временно dns сервер, включить лог запросов. В клиенте указать единственный днс сервер, который мы настроили. Дальше можно отслеживать, к примеру, куда лезет винда после загрузки без нашего ведома. Или откуда грузится реклама в скайпе. Все запросы будут аккуратно складываться в файл, который потом можно спокойно анализировать, а затем, к примеру, .

Это все, что я хотел в данном материале рассказать. Тема настройки bind (named) достаточно обширная. Возможно я еще вернусь к ней.

Онлайн курс "Администратор Linux"

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Администратор Linux» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров. Проверьте себя на вступительном тесте и смотрите программу детальнее по.

В сети очень много статей на тему установки и настройки DNS-сервера Bind9. Они разные. Некоторые написаны просто и доступно, но нет пояснений зачем и почему. В других материал подан очень подробно, но новичкам такой материал осилить сложно. Я же попытаюсь совместить достоинства способов подачи материала, нащупать ту золотую середину, которая подойден большинству. Но опять таки, я не претендую на истину в последней инстанции и готов принять конструктивную критику.

Итак, вступление закончено, приступим к самой статье. Я как приверженнец Debian, буду описывать процесс установки и настройки именно на этой ОС. Дано Debian 8 «Jessie» установленный вот с такими параметрами (Ну разве кроме пункта web server , он пригодится тем, кто в дальнейшем будет работать с веб-сервером Apache):

Настройки сети:

Теперь необходимо настроить файл конфигурации Bind9:

Расшифровка:
acl - создает ACL (Access control list ) - так называемый список контроля доступа, с помощью которого мы ограничиваем диапазон адресов которые могут запрашивать зоны с нашего сервера. В данном примере это разрешено подсети 192.168.1.0/24 . и локальному хосту .
allow-query { mynetwork; }; - список тех, кто имеет право запрашивать информацию. Можно ограничить с помошью acl либо установить allow-query { any; }; - что будет означать, что запросы разрешенмы всем.
forwarders {192.168.1.1; 8.8.8.8; }; - это DNS провайдера, или любые другие, у которых можно получить информацию о доменах неизвестных вашему серверу.
listen-on-v6 { none; } - запрещает работать с IPv6.

Настройка зон

Для начала покорректируем файл локальной конфигурации Bind9:

1	vim /etc/bind/named.conf.local

Этот файл содержит локальную конфигурацию DNS-сервера, в нем объявляются зоны, связанные с доменами этого сервера. Добавляем в него файлы наших зон (зону прямого просмотра и зону обратного просмотра):

Со следующим содержимым:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

; ; Зона прямого просмотра ; $TTL 30 $ORIGIN nixway.loc. @ IN SOA ns1.nixway.loc. admin.nixway.loc. ( 2015050101 ; Serial 1d ; Refresh 1h ; Retry 1w ; Expire 2h ; Negative Cache TTL ) @ IN NS ns1.nixway.loc. @ IN NS ns.provider.org. @ IN A 192.168.1.10 ns1 IN A 192.168.1.10 nixway.loc IN A 192.168.1.10 www IN CNAME nixway.loc.

В конце этого файла нужно обязательно оставить пустую строку!

Расшифровка:
$ORIGIN - оригинальное имя зоны
ns1.nixway.loc. - Наш DNS-сервер (точка в конце обязательна).
admin.nixway.loc. - email администратора сервера, где вместо символа @ используется точка.
Serial - серийный номер зоны в формате ГГГГММДД и номер текущего изменения за этот день. (Важно, при каждом изменении, нужно редактировать этот номер увеличивая его в большую сторону) Пример: 2015020301.
Refresh - период времени с которым вторичный сервер днс обращается к основному.
Retry - период с которым вторичный сервер будет повторять попытки при неудачном обновлении.
Expire - максимальное время использования данных на вторичном сервере, после которого делается обязательное обновление.
Negative Cache TTL - время актуальности данных в кэше запросов.

Зона обратного просмотра

Зона обратного просмотра, выполняет преобразование IP-адреса в доменное имя. Создадим файл для зоны обратного просмотра:

В этом файле должны быть только записи типа PTR . В конце этого файла так же должна быть пустая строка. Число 10 - это последний октет в IP адресе нашего сервера.

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

Тогда по адресу router.nixway.loc в браузере будет открываться web-интерфейс роутера (эквивалентно 192.168.1.1 ), но только внутри локальной сети.