Добрый день, сегодня расскажу как настроить 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
Редактируем файл /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), должно быть первым в строке. Значение должно отделяться от ключевого слова пробелом.
Одним из важных сервисов, обеспечивающих функционирование современного интернета является сервис по преобразованию имени сайта в 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; };
| 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-сервер? Чтобы расшарить (сделать доступными) свои локальные сайты для всех пользователей сети.
Я создам сеть, где все устройства моей локальной сети смогут пользоваться ресурсами формата site.lan. В моем случае устройства локальной сети подключаются к интернету через роутер. Серверная машина - на Linux Mint (desktop), клиенты: ПК под управлением Windows, Linux, телевизор со Smart TV, а также смартфоны и планшет. Для начала убедитесь, что в роутере для сервера (машины, на которой будет установлен DNS сервер) зарезервирован статический внутренний IP адрес. Это очень важно, чтобы потом указать всем сетевым устройствам, где именно находится наш DNS сервер.
Установка DNS неймсервера:
Для начала необходимо установить пакет Bind:
Sudo apt-get install bind
Кроме того, для нормальной работы веб-сайтов нам потребуется LAMP (Linux Apache MySQL PHP). О том как установить LAMP в Ubuntu читайте в моей статье . А также по ссылке внизу статьи можете настроить локальный сайт. Единственное, что не прописывайте в /etc/hosts адрес сайта, т.к. этими вопросами будет заниматься неймсервер. На этом этап подготовки окончен.
Настройка Bind
Входим в директорию Bind и делаем резервные копии конфигурируемых файлов:
Cd /etc/bind/ cp named.conf.local named.conf.local.back cp named.conf.options named.conf.options.back
Создаём локальную доменную зону.lan:
Nano named.conf.local
И дописываем в конец файла следующие строки:
Zone "lan" { type master; file "/etc/bind/db.lan"; };
Теперь создаем соответствующий файл для доменной зоны.lan и открываем его на редактирование:
Touch db.lan nano db.lan
Наполняем его содержимым:
@ IN SOA lan. root.lan. (201605019 ;Serial 4h 1h 1w 1d @ IN NS ns1.lan. @ IN A 192.168.0.100 ns1 IN A 192.168.0.100 slicks IN A 192.168.0.100 site IN A 192.168.0.100 * IN CNAME @
Обратите внимание на Serial 201605019. Это значение нужно увеличивать каждый раз при редактировании файла доменной зоны. Я пишу YY-MM-DD + наращиваю порядковый номер на 1. 192.168.0.100 - IP адрес сервера. Запись формата "slicks IN A" означает, что в зоне.lan существует доменное имя slicks и что этот сайт расположен по IP адресу 192.168.0.100. В apache2 создан, соответственно веб-сайт с ServerName slicks.lan . Если бы сайт располагался на ином IP, чем DNS сервер, то запись бы имела вид slicks IN A _IP-ПК-с-сайтом_ Редактируем named.conf.options :
Nano named.conf.options
В него нужно дописать выделенные строки:
Acl "home" {192.168.0.0/24; 127.0.0.1;}; options { directory "/var/cache/bind"; dnssec-validation auto; allow-recursion {127.0.0.1/32; 192.168.0.0/24; 192.168.1.0/24; }; allow-transfer { none; }; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { none; }; allow-query {"home";}; };
Первая строка создаёт локальную DNS группу home, с диапазоном IP адресов от 192.168.0.0 до 192.168.0.255, а также 127.0.0.1. Вторая добавляемая строка содержит параметр allow-query (разрешить запросы) и мы указываем, что нужно разрешить запросы от группы home. С конфигурацией закончили, можем перезапустить сервер
Sudo /etc/init.d/bind9 restart
Указываем локальный DNS в роутере
Чтобы не было нужды редактировать сетевое подключение на каждом клиенте и вручную прописывать DNS-сервер, мы можем указать IP локального DNS в настройках маршрутизатора. И все запросы пользователей сети будут отправляться последним сперва на локальный DNS, а потом уже уходить в Интернет. У меня:
- Модель роутера: Dir-615;
- Internet Connection Type: Dynamic IP (DHCP);
Для указания локального DNS сервера в моем случае я вхожу в Setup -> Network Settings -> Manual Internet Connection Setup и в поле Primary DNS Address прописываю IP адрес сервера локальной доменной зоны 192.168.0.100, он же будет теперь выступать основным DNS сервером в локальной сети. А в качестве Secondary DNS адреса пишем 8.8.8.8. Это адреса DNS Google. На скрине у меня Primary и Secondary DNS адреса ведут на мой сервер. Почему-то вначале казалось, что роутер не перенаправлял запросы на мой DNS и прописал так. Вторым DNS лучше указать гугловский сервер, чтобы в случае если локальный сервер 192.168.0.100 будет выключен - не пропадал интернет у всех остальных устройств!
Проверка работоспособности
Запускаю клиентский ПК под управлением Windows Xp и тестирую подключение. Первым делом нужно очистить DNS кеш. Заходим в командндую строку виндовс и пишем:
Ipconfig /flushdns
1. Теперь уже проверяю видимость в сети сервера DNS, ping 192.168.0.100 :
C:\\Documents and Settings\\www>ping 192.168.0.100 Обмен пакетами с 192.168.0.100 по 32 байт: Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Статистика Ping для 192.168.0.100: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь), Приблизительное время приема-передачи в мс: Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек
Проверяю локальный сайт: nslookup slicks.lan :
C:\\Documents and Settings\\www>nslookup slicks.lan *** Can"t find server name for address 192.168.0.1: Non-existent domain *** Default servers are not available Server: UnKnown Address: 192.168.0.1 Name: slicks.lan Address: 192.168.0.100
ping slicks.lan :
C:\\Documents and Settings\\www>ping slicks.lan Обмен пакетами с slicks.lan по 32 байт: Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Ответ от 192.168.0.100: число байт=32 время<1мс TTL=64 Статистика Ping для 192.168.0.100: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь), Приблизительное время приема-передачи в мс: Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек
Наслаждаемся результатами!
Named – это демон, входящий в состав пакета bind9 и являющийся сервером доменных имен . Демон named может реализовывать функции серверов любого типа: master, slave, cache . На приведенной схеме я постарался максимально прозрачно отобразить основной принцип работы DNS сервера BIND . Бинарник, который выполняет основную работу, расположен в /usr/sbin/named . Он берет настройки из основного конфигурационного файла, который называется named.conf и расположен в каталоге /etc/bind . В основном конфиге описывается рабочий каталог асервера , зачастую это каталог /var/cache/bind , в котором лежат файлы описания зон и другие служебные файлы. Соответствие названия зоны и файла описания зоны задает раздел zone с параметром file . Раздел zone так же задает тип ответственности данного сервера за зону (master, slave и др.), а так же определяет особые параметры для текущей зоны (например, на каком интерфейсе обрабатывать запросы для текущей зоны). В файлах описания зон содержатся параметры зон и записи ресурсов (пути, указанные в данном абзаце могут отличаться, это зависит от дистрибутива Linux или параметров сборки сервера из исходников).
Эта общая схема работы, которая поможет в дальнейшем не запутаться, при рассмотрении конкретных конфигураций.
Формат файла конфигурации для 4-ой версии программы отличается от того, который применяется в восьмой и девятой версиях BIND . Учитывая, что я рассчитываю на установку нового DNS сервера, а старую версию смысла ставить не вижу, посему буду рассматривать конфиг новой версии.
Исходные данные
Для корректной работы DNS нем необходимо иметь настроенную сеть. DNS в текущей статье будет настроен на дистрибутиве FreeBSD, Конфиг сети стенда следующий:
Root@ns1:/usr/local/etc/namedb # cat /etc/rc.conf ... hostname="ns1.disnetern.lan" keymap="ru.koi8-r.win.kbd" ifconfig_em1="inet XXX.XXX.XXX.XXX netmask 255.255.255.240" defaultrouter="XXX.XXX.XXX.XXX" firewall_enable="YES" firewall_type="open" named_enable="YES" ....
где XXX.XXX.XXX.XXX – внешний интерфейс (подсеть, выделенная провайдером). Настраиваемая зона будет иметь имя disnetern.lan .
Установка BIND9
Для работы DNS сервера необходимо установить пакет bind9 (в некоторых дистрибутивах – bind ). Как отмечено на схеме – основным конфигурационным файлом BIND является файл named.conf (данный файл может быть размещен в каталоге /usr/local/etc/named/ ).
Параметры (синтаксис) named.conf
Синтаксис файла named.conf придерживается следующих правил:
IP-адреса – список IP должен быть разделен символом “;” , возможно указывать подсеть в формате 192.168.1.1/24 или 192.168.1.1/255.255.255.0, (для исключения IP перед ним нужно поставить знак!), возможно указывать имена “any”, “none”, “localhost” в двойных кавычках.
Комментарии – строки начинающиеся на #, // и заключенные в /* и */ считаются комментариями.
В файлах описания зон – символ @ является “переменной” хранящей имя зоны, указанной в конфигурационном файле named.conf или в директиве @ $ORIGIN текущего описания зоны.
Каждая завершенная строка параметров должна завершаться символом; .
Раздел Acl
Acl (access control list) – позволяет задать именованный список сетей. Формат раздела: acl “имя_сети” {ip; ip; ip; };
Раздел Options
Раздел Options задает глобальные параметры конфигурационного файла, управляющие всеми зонами. Данный раздел имеет формат: options {операторы_раздела_Options}; . Options может быть “вложен” в раздел Zone , при этом он переопределяет глобальные параметры. Часто используемые операторы options :
- allow-query {список_ip } – Разрешает ответы на запросы только из список_ip . При отсутствии – сервер отвечает на все запросы.
- allow-recursion {список_ip } – На запросы из список_ip будут выполняться рекурсивные запросы. Для остальных – итеративные. Если не задан параметр, то сервер выполняет рекурсивные запросы для всех сетей.
- allow-transfer {список_ip } – Указывает список серверов, которым разрешено брать зону с сервера (в основном тут указывают slave сервера)
- directory /path/to/work/dir – указывает абсолютный путь к рабочему каталогу сервера. Этот оператор допустим только в разделе options.
- forwarders {ip порт, ip порт.. .} – указывает адреса хостов и если нужно порты, куда переадресовывать запросы (обычно тут указываются DNS провайдеров ISP).
- forward ONLY или forward FIRST – параметр first указывает, DNS-серверу пытаться разрешать имена с помощью DNS-серверов, указанных в параметре forwarders, и лишь в случае, если разрешить имя с помощью данных серверов не удалось, то будет осуществлять попытки разрешения имени самостоятельно.
- notify YES|NO – YES – уведомлять slave сервера об изменениях в зоне, NO – не уведомлять.
- recursion YES|NO – YES – выполнять рекурсивные запросы, если просит клиент, NO – не выполнять (только итеративные запросы). Если ответ найден в кэше, то возвращается из кэша. (может использоваться только в разделе Options)
Раздел Zone
Определяет описание зон(ы). Формат раздела: zone {операторы_раздела_zone }; Операторы , которые наиболее часто используются:
- allow-update {список_ip } – указывает системы, которым разрешено динамически обновлять данную зону.
- file “имя_файла ” – указывает путь файла параметров зоны (должен быть расположен в каталоге, определенном в разделе options оператором directory)
- masters {список_ip } -указывает список мастер-серверов. (допустим только в подчиненных зонах)
- type “тип_зоны
” – указывает тип зоны, описываемой в текущем разделе,тип_зоны может принимать следующие значения:
- forward – указывает зону переадресации, которая переадресовывает запросы, пришедшие в эту зону.
- hint – указывает вспомогательную зону (данный тип содержит информацию о корневых серверах, к которым сервер будет обращаться в случае невозможности найти ответ в кэше)
- master – указывает работать в качестве мастер сервера для текущей зоны.
- slave – указывает работать в качестве подчиненного сервера для текущей зоны.
Дополнительные параметры конфигурации
Значения времени в файлах зон по умолчанию указывается в секундах, если за ними не стоит одна из следующих букв: S – секунды, M – минуты, H- часы, D – дни, W – недели. Соответственно, запись 2h20m5s будет иметь значение 2 часа 20 минут 5 секунд и соответствовать 8405 секунд.
Любое имя хоста/записи, не оканчивающиеся точкой считается неFQDN именем и будет дополнено именем текущей зоны. Например, запись domen в файле зоны examle.com будет развернуто в FQDN-имя domen.examle.com. .
В конфигурационных файлах BIND могут применяться следующие директивы :
- $TTL – определяет TTL по-умолчанию для всех записей в текущей зоне.
- $ORIGIN – изменяет имя зоны с указанного в файле named.conf. При этом, область действия данной директивы не распространяется “выше” (то есть если файл включен директивой $INCLUDE, то область действия$ORIGN не распространяется на родительский)
- $INCLUDE – включает указанный файл как часть файла зоны.
Для того чтобы локальный резолвер сервера тоже использовал локальный DNS, необходимо привести файл resolv.conf к следующему виду:
Dns:~# cat /etc/resolv.conf nameserver 127.0.0.1
Если в имени ресурсной записи встречается символ “*”, то это он означает что вместо него можно подразумевать любую разрешенную последовательность символов. Такую запись называют “wildcard запись “. Однако, символ “*” не может быть использован где угодно. Это может быть только первый символ в поле Name текущего домена, отделенный от остальных символом “.”
Настройка кэширующего DNS сервера
После установки bind, он полностью готов работать как кэширующий DNS сервер без дополнительной настройки. Единственный недостаток – он обрабатывает запросы на всех интерфейсах, что нам абсолютно не нужно, поэтому мы немного подредактируем настройки сервера.
Для того, чтобы BIND работал в качестве кэширующего сервера , необходимо иметь конфигурационные файлы заполненные необходимой информацией:
- named.conf ;
- описание серверов корневой зоны (зона типа hint);
- описание зоны 127.in-addr.arpa .
В данном примере приведен кэширующий DNS сервер , обрабатывающий запросы из списка сетей lan , в которую входит только одна локальная сеть 192.168.1.1/24 и петлевой интерфейс. При необходимости можно включить туда и другие сети. После определения списка сетей в директиве acl, в любом месте конфига можно будет ссылаться на этот список по имени (в нашем примере имя – lan), что, собственно и сделано в разделе options . Большинство параметров я прокомментировал, но отдельного внимания требует раздел, описывающий зону корневых серверов . В параметре file задан относительный путь к файлу описания корневых серверов (путь, относительно рабочего каталога сервера). За обновлениями данного файла необходимо следить, хотя он обновляется довольно редко (откуда брать обновленный файл я писал в теории DNS). Как вы заметили, имеется так же две записи для зоны localhost и две записи обратных зон для броадкаст доменов. Назначение этих зон состоит в том, чтобы избежать трансляции случайных запросов имен соответствующих IP-адресов на серверы, обслуживающие корневую зону.
Чтобы не вносить неразбериху в куче конфигурационных файлов, в статье я привожу примеры на основе единого конфигурационного файла. На самом деле, в последних версиях Debian (и других дистрибутивах Linux), файл named.conf выглядит следующим образом:
Root@master:~# cat /usr/local/etc/named/named.conf // This is the primary configuration file for the BIND DNS server named. // // Please read /usr/share/doc/bind9/README.Debian.gz for information on the // structure of BIND configuration files in Debian, *BEFORE* you customize // this configuration file. // // If you are just adding zones, please do that in /etc/bind/named.conf.local include "/usr/local/etc/named/named.conf.options"; include "/usr/local/etc/named/named.conf.local"; include "/usr/local/etc/named/named.conf.default-zones";
То есть основной файл не содержит конфигураций, а включает в себя более узко специализированные файлы, которые отвечают за свои задачи, например named.conf.options – содержит глобальные параметры конфигурации, named.conf.default-zones – содержит описание localhost и broadcast зон, а named.conf.local содержит описания зон, за которые отвечает данный сервер.
Первая строка задает параметр $TTL, который определяет время кеширования положительных ответов (ответ в виде найденного IP-адреса). Здесь и далее, время может задаваться в секундах или с помощью сокращений: m - минуты, h - часы, d - дни, w - недели.
В записи SOA указывается primary NS для домена и e-mail контактного лица. В скобках, по порядку:
- Serial - Серийный номер. Каждый раз при изменении каких-либо данных его нужно обязательно менять. Когда меняется серийный номер, зона обновляется на всех серверах. Используйте следующий формат: ГГГГММДДнн (год, месяц, день, нн - порядковый номер изменения за день). Если вы уже второй раз за день вносите измения в файл зоны, укажите “нн” равным 01, если третий - 02, и т.д.
- Refresh - интервал, через который slave сервера должны обращаться к primary серверу и проверять обновление зоны.
- Retry - если slave серверу не удалось обратится к primary серверу, через это время он должен повторить свой запрос.
- Expiry - если в течении этого времени slave сервер так и не смог обновить зону с primary сервера, то slave должен прекратить обслуживать эту зону.
- TTL - время кеширования отрицательных ответов (ответ “домен невозможно разрешить в IP адрес”)
В секции NS задаются NS сервера, которые обслуживают данный домен. Минимально их необходимо два, причем они должны находится в разных подсетях, а лучше - в географически разных местах. Первым указывайте primary сервер.
Секция MX описывает почтовые шлюзы (обычно один), на которые будет доставляться вся почта этого домена. Для каждого шлюза устанавливается приоритет (по умолчанию - 10). Обычно имя домена почтового шлюза выглядит так: mx.example.com .
В секции A указываются субдомены (A ) и синонимы (CNAME ). В примере домен example.com указывает на IP адрес 192.168.1.1, а домен www.example.com является синонимом example.com .
Обратите внимание:
- Если вы указываете полное имя домена, пишите в его конце точку.
- Записи NS, MX и A для основного домена (не субдомена) не должны начинаться с начала строки.
- Если почтовый шлюз принадлежит этому же домену, не забывайте указывать его в секции A.
Проверить файл зоны на ошибки можно с помощью команды:
$ named-checkzone example.com ./example.com zone example.com/IN: loaded serial 2007022600 OK
Далее, хочу обратить внимание на наличие файлов зон в каталоге, указанном в разделе options в параметре directory с именами, соответствующими параметрам file в разделах, описывающих зоны:
Dns:~# ls -l /var/cache/bind/ итого 24 -rw-r--r-- 1 root root 237 Май 28 01:28 0.in-addr.arpa -rw-r--r-- 1 root root 271 Май 28 01:28 127.in-addr.arpa -rw-r--r-- 1 root root 237 Май 28 01:28 255.in-addr.arpa -rw-r--r-- 1 root root 2994 Май 28 01:28 db.root -rw-r--r-- 1 root root 270 Май 28 01:28 localhost dns:~# cat /var/cache/bind/127.in-addr.arpa ; ; BIND reverse data file for local loopback interface ; $TTL 604800 @ IN SOA localhost. root.localhost. (1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800) ; Negative Cache TTL ; @ IN NS localhost. 1.0.0 IN PTR localhost.
Рассматривать файлы “петлевых” и бродкастовых зон не вижу смысла, т.к. после установки пакета bind настройки заданные по умолчанию в данных файлах вполне приемлемы. Далее, при организации мастер сервера мы рассмотрим пример описания файла зоны . Хочу обратить внимание, что мы настраиваем кэширующий сервер , а определяем мы его и как master для некоторых из зон. В нашем случае “кэширующий ” говорит о том, что наш сервер не поддерживает ни одну из реально существующих зон, т.е. ему не делегировано прав на такое обслуживание.
На этом настройка кэширующего DNS завершена. Все запросы, которые попадают в кэш DNS сервера он хранит в оперативной памяти компьютера и при перезапуске демона эти данные обнуляются. Для проверки работы кэша можно выполнить команду nslookup mail.ru example.com. , если в ответе содержится строка Non-authoritative answer , то адрес пришел из кэша, а так же если выполнить dig www.ru. (или другой домен, которого еще нет в кэше) и через некоторое время повторить команду, то время ответа должно быть гораздо меньше.
Главный (master) сервер зоны
Основной конфиг содержит следующие настройки:
Dns:~# cat /etc/bind/named.conf acl "lan" { 192.168.1.1/24; 127.0.0.1; }; options { directory "/var/cache/bind"; allow-query { any; }; // отвечать на зпросы со всех интерфейсов recursion no; // запретить рекурсивные запросы auth-nxdomain no; // для совместимости RFC1035 listen-on-v6 { none; }; // IPv6 нам не нужен version "unknown"; // не отображать версию DNS сервера при ответах /* * Раскомментируйте строки ниже, если * хотите разрешить рекрусивные запросы * из локальной сети. * (так же, необходимо закомментировать * recursion no;) */ # forwarders { // указываем DNS сервера для пересылки # 83.239.0.202; // предоставленные провайдером # 213.132.67.110; // ибо до них ближе чем до корневых # }; # allow-recursion { lan; }; // рекурсивные запросы тоже только из локальной }; // описание настроек корневых серверов zone "." { type hint; file "db.root"; }; // нижеописанные зоны определяют сервер авторитетным для петлевых // интерфейсов, а так же для броадкаст-зон (согласно RFC 1912) zone "localhost" { type master; file "localhost"; }; zone "127.in-addr.arpa" { type master; file "127.in-addr.arpa"; }; zone "0.in-addr.arpa" { type master; file "0.in-addr.arpa"; }; zone "255.in-addr.arpa" { type master; file "255.in-addr.arpa"; }; // описание основной зоны zone "example.com" { type master; file "example.com"; allow-transfer { 10.0.0.191; }; }; //описание обратных зон zone "0.0.10.in-addr.arpa" { type master; file "0.0.10.in-addr.arpa"; allow-transfer { 10.0.0.191; }; }; zone "1.168.192.in-addr.arpa" { type master; file "1.168.192.in-addr.arpa"; # allow-transfer { 10.0.0.191; }; // зона описывает локальную сеть поэтому ее не передаем }; // настройки логирования logging { channel "misc" { file "/var/log/bind/misc.log" versions 4 size 4m; print-time yes; print-severity yes; print-category yes; }; channel "query" { file "/var/log/bind/query.log" versions 4 size 4m; print-time yes; print-severity no; print-category no; }; category default { "misc"; }; category queries { "query"; }; };
Давайте кратко разберем конфигурационный файл и настройки master сервера : мы настраиваем мастер сервер для зоны example.com. . Согласно конфига, наш BIND имеет рабочий каталог /var/cache/bind, сервер отвечает на запросы со всех интерфейсов (allow-query {any ;}; ), рекурсивные запросы обрабатывает как итеративные (recursion no ), является мастер-сервером для зоны example.com и локальных служебных зон (type master ). При этом, если необходимо разрешить кэширование (то есть рекурсивные запросы) для локальной сети, то необходимо раскомментировать параметры forwarders и allow-recursion и закомментировать recursion no;.
Так же, для примера, я привел возможности BIND логировать все происходящее при работе сервера (можно для этой цели использовать syslog). В разделе logging задаются 2 параметра channel (можно и больше двух – на ваше усмотрение), эти параметры дословно можно назвать “канал” записи . Каждый канал определяет имя канала и настройки параметров записи (что записывать, а что – нет и куда писать). Директива category задает какую категорию сообщений в какой канал отправлять . Исходя из этого, мы имеем: запись стандартной информации в канал misc , а приходящие запросы посылаются в канал query . При этом, если файлы журнала достигают 4Мб (size 4m ), он переименовывается добавлением к имени .1 и начинается запись в новый журнал, числа в конце других журналов увеличиваются. Журналы с номером, более указанного в version (в нашем случае 4) удаляются (Управлять ротацией логов можно так же с помощью logrotate). Параметры print* определяют заносить ли в журнал время появления , важность и категорию информации. Более подробно про настройки раздела logging можно почитать в man (5) named.conf.
Отдельно хочется описать параметр allow-transfer { 10.0.0.191; }; . Данный параметр описывает серверы, которым разрешено скачивать копию зоны – т.н. slave серверА . В следующем примере мы разберем настройку slave DNS .
Для корректной работы логирования необходимо создать соответствующий каталог и присвоить необходимые права:
Dns:~# mkdir /var/log/bind/ dns:~# chmod 744 /var/log/bind/ dns:~# ps aux | grep named bind 4298 0.0 3.4 46792 13272 ? Ssl Jul05 0:00 /usr/sbin/named -u bind root 4815 0.0 0.1 3304 772 pts/4 S+ 18:19 0:00 grep named dns:~# chown bind /var/log/bind/ dns:~# ls -ld /var/log/bind/ drwxr--r-- 2 bind root 4096 Июл 6 18:18 /var/log/bind/
Dns:~# cat /var/cache/bind/example.com $TTL 3D @ IN SOA ns.example.com. root.example.com. (2011070601 ; serial 8H ; refresh 2H ; retry 2W ; expire 1D) ; minimum @ IN NS ns.example.com. @ IN NS ns2.example.com. @ IN A 10.0.0.152 @ IN MX 5 mx.example.com. ns IN A 10.0.0.152 ns2 IN A 10.0.0.191 mx IN A 10.0.0.152 www IN CNAME @
а так же в домене in-addr.arpa.
Dns:~# cat /var/cache/bind/0.0.10.in-addr.arpa $TTL 3600 @ IN SOA ns.examle.com. root.example.com. (2007042001 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600) ; Minimum IN NS ns.examle.com. IN NS ns2.example.com. 152 IN PTR examle.com. 191 IN PTR ns.example.com. * IN PTR examle.com. dns:~# cat /var/cache/bind/1.168.192.in-addr.arpa $TTL 3600 @ IN SOA ns.examle.com. root.example.com. (2007042001 ; Serial 3600 ; Refresh 900 ; Retry 3600000 ; Expire 3600) ; Minimum IN NS ns.examle.com. IN NS ns2.example.com. * IN PTR examle.com.
Наша сеть небольшая, предполагается, что в сети совсем мало машин. Все сервисы сети размещены на одном хосте example.com., поэтому и master DNS (ns.example.com.) и почтовый сервер (mx.example.com.) указывает на одну машину (10.0.0.152).
Вторичный (secondary, slave) авторитетный сервер зоны
Основная функция slave сервера – автоматическая синхронизация описания зоны с master сервером. Данная задача регламентируется документом RFC 1034 в разделе 4.3.5. Согласно данному документу обмен данными между серверами рекомендовано производить по протоколу TCP , посредством запроса AXFR. По этому запросу за одно TCP соединение должна передаваться вся зона целиком (RFC 1035).
Так же, slave DNS-сервер делит нагрузку с master сервером или принимает на себя всю нагрузку в случае аварии па первом сервере.
Прежде чем приступить к настройке slave DNS сервера , необходимо проверить возможность получения зоны вручную со вторичного сервера с помощью следующей команды:
Root@debian:~# dig @10.0.0.152 example.com. axfr ; <<>> DiG 9.7.3 <<>> @10.0.0.152 example.com. axfr ; (1 server found) ;; global options: +cmd example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 example.com. 259200 IN NS ns.example.com. example.com. 259200 IN NS ns2.example.com. example.com. 259200 IN A 10.0.0.152 example.com. 259200 IN MX 5 mx.example.com. mx.example.com. 259200 IN A 10.0.0.152 ns.example.com. 259200 IN A 10.0.0.152 ns2.example.com. 259200 IN A 10.0.0.191 www.example.com. 259200 IN CNAME example.com. example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 ;; Query time: 14 msec ;; SERVER: 10.0.0.152#53(10.0.0.152) ;; WHEN: Fri Jul 8 15:33:54 2011 ;; XFR size: 11 records (messages 1, bytes 258)
- Скопировать конфигурационный файл named.conf с master сервера;
- Заменить параметр type master на type slave
- Параметр allow-transfer { 10.0.0.191; }; заменить на masters { 10.0.0.152;}; в тех зонах, для которых он будет вторичным;
- Удалить зоны , которые не будет обслуживать текущий сервер , в том числе и корневую, если slave не будет отвечать на рекурсивные запросы;
- Создать каталоги для логов, как в предыдущем примере.
Итого, мы получаем конфиг slave сервера:
Root@debian:~# cat /etc/bind/named.conf options { directory "/var/cache/bind"; allow-query { any; }; // отвечать на запросы со всех интерфейсов recursion no; // запретить рекурсивные запросы auth-nxdomain no; // для совместимости RFC1035 listen-on-v6 { none; }; // IPv6 нам не нужен version "unknown"; // не отображать версию DNS сервера при ответах }; // нижеописанные зоны определяют сервер авторитетным для петлевых // интерфейсов, а так же для броадкаст-зон (согласно RFC 1912) zone "localhost" { type master; file "localhost"; }; zone "127.in-addr.arpa" { type master; file "127.in-addr.arpa"; }; zone "0.in-addr.arpa" { type master; file "0.in-addr.arpa"; }; zone "255.in-addr.arpa" { type master; file "255.in-addr.arpa"; }; // описание основной зоны zone "example.com" { type slave; file "example.com"; masters { 10.0.0.152; }; }; //описание обратной зоны zone "0.0.10.in-addr.arpa" { type slave; file "0.0.10.in-addr.arpa"; masters { 10.0.0.152; }; }; // настройки логирования logging { channel "misc" { file "/var/log/bind/misc.log" versions 4 size 4m; print-time YES; print-severity YES; print-category YES; }; channel "query" { file "/var/log/bind/query.log" versions 4 size 4m; print-time YES; print-severity NO; print-category NO; }; category default { "misc"; }; category queries { "query"; }; };
после перезапуска наш slave сервер благополучно скопирует необходимую ему информацию с главного сервера, о чем будет говорить наличие файлов в каталоге:
Root@debian:~# ls -la /var/cache/bind/ итого 28 drwxrwxr-x 2 root bind 4096 Июл 8 18:47 . drwxr-xr-x 10 root root 4096 Июл 8 15:17 .. -rw-r--r-- 1 bind bind 416 Июл 8 18:32 0.0.10.in-addr.arpa ...... -rw-r--r-- 1 bind bind 455 Июл 8 18:32 example.com ........
В принципе,/stroallow-transfer {pngp slave сервер может не хранить копию зоны у себя в файловой системе. Эта копия нужна только в момент старта DNS. Наличие копии зоны в файловой системе может избавить от сбоя при недоступности master сервера во время запуска slave DNS. Если не указать опцию file в разделе zone, то копия не создается.
Резюме
В текущей статье описана настройка основных конфигураций DNS сервера BIND. Целью статьи было – дать представление о работе сервера BIND в UNIX. Практически не затронуты вопросы безопасности ДНС и мало затронуты такие специфичные настройки, как работа сервера в пограничном режиме, когда в разные сети отдается разная информация о зоне(нах). Для более глубокого освоения ниже есть список дополнительных источников, в которых удастся получить нужную информацию.
Система доменных имен
: http://citforum.ru/internet/dns/khramtsov/
RFC 1034
- Domain Names - Concepts and Facilities: http://tools.ietf.org/html/rfc1034
RFC 1035
- Domain Names - Implementation and Specification: http://tools.ietf.org/html/rfc1035
RFC 1537
- Common DNS Data File Configuration Errors: http://tools.ietf.org/html/rfc1537
RFC 1591
- Domain Name System Structure and Delegation: http://tools.ietf.org/html/rfc1591
RFC 1713
- Tools for DNS Debugging: http://tools.ietf.org/html/rfc1713
RFC 2606
- Reserved Top Level DNS Names: http://tools.ietf.org/html/rfc2606
Безопасность DNS (DNSSEC):
http://book.itep.ru/4/4/dnssec.htm
BIND 9 Administrator Reference Manual
: http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.html
Secure BIND Template
: http://www.cymru.com/Documents/secure-bind-template.html
Хорошо расписаны параметры конфига на
русском
: http://www.bog.pp.ru/work/bind.html
Автоматическое создание файла зоны
: http://www.zonefile.org/?lang=en#zonefile
Вконтакте
