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

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

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

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

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

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

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

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

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

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

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

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

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

Добрый день, сегодня расскажу как настроить DNS на сервере 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

Одним из важных сервисов, обеспечивающих функционирование современного интернета является сервис по преобразованию имени сайта в 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 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров. Проверьте себя на вступительном тесте и смотрите программу детальнее по.

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

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

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

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

Обзор

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

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

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

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

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

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

Forwarders { 1.2.3.4; 5.6.7.8; };

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

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

Sudo service bind9 restart

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

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

Sudo service bind9 restart

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

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

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

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

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

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

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

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

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

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

Sudo service bind9 restart

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

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

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

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

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

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

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

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

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

Sudo service bind9 restart

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

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

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

По умолчанию во FreeBSD используется одна из версий программы BIND (Berkeley Internet Name Domain), являющейся самой распространенной реализацией протокола DNS . DNS - это протокол, при помощи которого имена преобразуются в IP -адреса и наоборот. Например, в ответ на запрос о www.FreeBSD.org будет получен IP-адрес веб-сервера Проекта FreeBSD, а запрос о ftp.FreeBSD.org возвратит IP -адрес соответствующей машины с FTP -сервером. Точно также происходит и обратный процесс. Запрос, содержащий IP-адрес машины, возвратит имя хоста. Для выполнения запросов к DNS вовсе не обязательно иметь в системе работающий сервер имён.

FreeBSD в настоящее время поставляется с сервером DNS BIND 9, предоставляющим расширенные настройки безопасности, новую схему расположения файлов конфигурации и автоматические настройки для chroot (8) .

В сети Интернет DNS управляется через достаточно сложную систему авторизированных корневых серверов имён, серверов доменов первого уровня (Top Level Domain, TLD) и других менее крупных серверов имён, которые содержат и кэшируют информацию о конкретных доменах.

На данный момент пакет BIND поддерживается Internet Software Consortium http://www.isc.org/ .