DNS (Domain Name System, система доменных имён) — система, в которой все доменные имена серверов находятся в определённой иерархии. Для чего она нужна?
Представим, что нам нужно обратиться к устройству с IP-адресом 92.53.116.191. Чтобы это сделать мы можем ввести адрес в командной строке и получить нужную информацию. Но запомнить много таких комбинаций цифр очень трудно. Поэтому были придуманы специальные серверы, которые позволяют преобразовывать доменные имена в IP-адреса.
Так, когда вы вводите в поисковой строке браузера cloud.timeweb.com, данные запроса отправляются на DNS-сервер, который ищет совпадения в своей базе. Затем DNS-сервер посылает на устройство нужный IP-адрес и только тогда браузер обращается непосредственно к ресурсу.
Настройка собственной DNS позволяет более гибко и точно конфигурировать систему и не зависеть от третьих лиц. В этой статье мы рассмотрим, как настроить DNS с помощью сервера имён BIND на Ubuntu.
Термины
Зона — часть иерархии доменных имён, которая размещается на DNS-сервере. Она нужна для того, чтобы установить рамки, в пределах которых распространяется ответственность конкретного сервера или группы серверов.
Топ вопросы на собеседовании по JavaScript: 4) Методы call, apply, bind.
Корневые серверы — это DNS-серверы, которые содержат информацию о доменах первого уровня (.ru, .com и так далее).
Доменом называют именованную часть в иерархии DNS. Это определённый узел, который включает в себя другие узлы. DNS-адреса читаются справа налево и начинаются с точки, точкой также отделяются домены.То есть домен cloud.timeweb.com правильно читать так: .com.timeweb.cloud. Чаще всего доменное имя отражает структуру иерархии DNS, но последняя точка опускается.
FQDN — это имя полное имя домена, которое включает в себя имена всех родительских доменов.
Ресурсная запись — это единица хранения информации. Проще говоря, это запись, которая содержит связь имени с какой-либо служебной информацией. Ресурсная запись состоит из следующих элементов:
- Имя (NAME) — имя или IP-адрес, которому принадлежит зона.
- Время жизни (Time to Live, TTL) — время хранения записи в кэше DNS, по прошествии которого запись удаляется.
- Класс (CLASS) — тип сети, чаще всего IN — Internet.
- Тип (TYPE) — назначение записи
- Различная информация (DATA)
Самые частые ресурсные записи
A-запись. Имя хоста на адрес IPv4. Для каждого сетевого интерфейса можно сделать только одну A-запись.
timeweb.com. 86400 IN A 185.114.246.105
AAAA-запись. Это то же самое, что А-запись, только справедливо для IPv6.
CNAME. Каноническая запись. Содержит псевдоним реального имени для перенаправления.
ftp 86400 IN CNAME store.cloud.timweb.com.
MX. Указывает хосты для доставки почты, адресованной домену. Поле NAME содержит домен назначения, а поле DATA — приоритет и хост для приёма почты.
website.ru. 17790 IN MX 10 mx.website.ru.
website.ru. 17790 IN MX 20 mx2.website.ru.
NS. Указывает на DNS-сервер, которым обслуживается домен.
Как работает метод bind? 30 вопросов собеседования JavaScript
PTR. IP-адрес в доменное имя. Необходимо для обратного преобразования имён.
SOA. Описывает основные настройки зоны.
SRV. Содержит адреса серверов, которые обеспечивают работу внутренних служб домена. Например, Jabber.
Инфраструктура
Для того, чтобы следовать всем инструкциям в статье, вам необходимо иметь как минимум два сервера Ubuntu в одном ЦОД. Любой из этих серверов вы можете заказать на cloud.timeweb.com .
Нам понадобится два сервера на Ubuntu 18.04, они будут использоваться в качестве первичного и вторичного DNS-серверов — ns1 и ns2 соответственно. А также дополнительные серверы, которые будут использовать наши настроенные серверы.
Вы должны иметь права суперпользователя на каждом из серверов. Чтобы узнать, как это получить административные доступ, воспользуйтесь статьёй в нашем блоге — Редактирование файла sudoers .
Установка BIND на DNS-серверах
В этой статье мы будем использовать bind в качестве DNS-сервера . Установим пакет bind9 из репозитория Linux:
sudo apt update sudo apt upgrade -y
sudo apt install bind9
Кроме этого рекомендуем установить сразу инструменты мониторинга сети:
sudo apt install dnsutils
После установки запускаем службу bind9:
sudo service bind9 start
Основной конфигурационный файл сервера — /etc/bind/named.conf. Он описывает общие настройки и обычно разбивается на несколько других для удобства. С работы с параметрами внутри этого файла начинается настройка DNS .
named.conf.options. Этот файл содержит общие параметры сервера. В нём укажем данные для конфигурации DNS.
options dnssec-validation auto;
auth-nxdomain no;
directory «/var/cache/bind»;
recursion no; # запрещаем рекурсивные запросы на сервер имён
listen-on 172.16.0.0/16;
127.0.0.0/8; >;
forwarders <
172.16.0.1;
8.8.8.8;
>;
>;
Чтобы проверить, что всё внесено верно, нужно воспользоваться одной из утилит демона named — named-checkconf .
sudo named-checkconf
Если всё написано верно, bind-сервер начал работать.
Первичный DNS-сервер
Первичный DNS-сервер — сервер, который хранит главную копию файла данных зоны. Все зоны будем хранить в каталоге /etc/bind/master-zones основного DNS-сервера . Создадим директорию:
sudo mkdir /etc/bind/master-zones
В ней создадим файл для описания зоны:
sudo touch /etc/bind/master-zones/test.example.com.loсal.zone
… и добавим в него SOA-, NS- и A-записи:
После этого необходимо запустить проверку утилитой named-checkzone .
sudo named-checkzone test.example.com. /etc/bind/master-zones/test.example.com.loсal.zone
named.conf.local. Это ещё один файл, который включается в общий конфиг сервера. В нём мы укажем локальные зоны:
zone «test.example.com.» type master;
file «/etc/bind/master-zones/test.example.com.local.zone»;
>;
После того, как пропишем нужные данные, проверим конфиг и перезагрузим bind9 (флаг -z проверяет файлы зон):
sudo named-checkconf
sudo named-checkconf -z
sudo service bind9 restart
sudo service bind9 status
Настройка представлений
Настройка представлений позволяет гибко управлять разрешением имён из разных подсетей. В файле /etc/bind/named.conf укажем:
include «/etc/bind/named.conf.options»;
acl «local» < 172.16.0.0/16; >;
view «local» include «/etc/bind/named.conf.local»;
match-clients < local; >;
>;
В этом же файле можно прописать директивы для указания тех узлов и адресов сетей, от которых нужно принимать или отклонять запросы.
Затем нужно заново перезагрузить bind9:
sudo service bind9 restart
После перезагрузки сервера с другого компьютера локальной сети можно запросить наличие у сервера 172.16.0.5 SOA-записи:
На этом этапе настройка основного DNS-сервера завершена. Далее в статье — вторичный сервер, настройка почтового сервера и обратная зона.
Вторичный сервер
Первые шаги абсолютно такие же, что и в случае с первичным сервером — установка bind9 и сетевых утилит.
sudo apt update sudo apt upgrade -y
sudo apt install bind9
sudo apt install dnsutils
sudo service bind9 start
Далее для того, чтобы хранить файлы зон, создадим каталог /etc/bind/slave и снабдим его необходимыми правами:
sudo mkdir slave
sudo chmod g+w slave
Приступаем к настройке зоны на вторичном сервере. В файл /etc/bind/named.conf.local добавляем зону
zone «test.example.com.» type slave;
file «/etc/bind/slave/test.example.com.local.zone»;
masters < 172.16.0.5; >;
>;
… и в основном конфигурационном файле named.conf настраиваем представления
include «/etc/bind/named.conf.options»;
acl «local» < 172.16.0.0/16; >;
view «local» match-clients < local; >;
include «/etc/bind/named.conf.local»;
>;
После добавления настроек нужно проверить синтаксис, а затем перезагрузить bind9:
sudo named-checkconf
sudo named-checkconf -z
sudo service bind9 restart
Если нет ошибок, нужно выполнить трансфер зоны:
sudo rndc retransfer test.example.com
Если номер уменьшился, то трансфер этой зоны будет прекращён. Поэтому каждый раз при редактировании зоны критически важно увеличивать серийный номер . В качестве номера рекомендуем использовать текущую дату и некий инкремент.
Как только настроили сервер и выполнили трансфер зоны, в конфиге named.conf на первичном сервере нужно ограничить передачу адресом вторичного сервера. Для этого в named.conf нужно добавить директиву allow-transfer с указанием IP-адреса вторичного DNS-сервера.
И перезагружаем сервер:
sudo service bind9 restart
Далее все операции будем проводить на первичном сервере.
Добавление MX-записи
В этом примере мы используем mx в качестве имени хоста, поскольку это общепринятое обозначение. Тогда FQDN — mx.test.example.com.
В файл зоны /etc/bind/master-zones/test.example.com.loсal.zone добавляем ресурсные записи почты и обновляем серийный номер.
Проверим синтаксис и перезапустим bind9:
sudo named-checkzone test.example.com. /etc/bind/master-zones/test.example.com.local.zone
sudo service bind9 reload
Обратная зона
Обратная зона DNS — это особая доменная зона, которая предназначена для того, чтобы определять имя узла по его IP адресу. Например, адрес узла 192.168.1.10 в обратной нотации превращается в 10.1.168.192.in-addr.arpa. Благодаря тому, что используется иерархическая модель, можно делегировать управление зоной владельцу диапазона IP-адресов.
По своей сути, PTR-запись определяет домен по адресу, а значит это практически то же самое, что и A-запись. Она используется в основном для проверки почтовых серверов.
Для настройки зоны обратного просмотра создадим новый файл зоны:
sudo nano /etc/bind/master-zones/16.172/in-addr.arpa.zone
и поместим в него следующее содержимое:
$TTL 3600
16.172.in-addr.arpa. IN SOA (
ns.test.example.com.
admin.test.example.com.
2022041202
10800
1200
604800
3600 )
IN NS ns.test.example.com.
IN NS ns2.test.example.com.
3.101.16.172.in-addr.arpa. IN PTR test.example.com.
5.0.16.172.in-addr.arpa. IN PTR ns.test.example.com.
6.0.16.172.in-addr.arpa. IN PTR ns2.test.example.com.
2.101.16.172.in-addr.arpa. IN PTR mail.test.example.com.
Проверим зону и убедимся в корректности конфигурации:
sudo named-checkzone 16.172.in-addr.arpa /etc/bind/master-zones/16.172.in-addr.arpa.zone
Теперь эту зону нужно добавить в конфигурационный файл named.conf :
sudo nano /etc/bind/named.conf.local
zone «16.172.in-addr.arpa.» type master;
file «/etc/bind/master-zones/16.172.in-addr.arpa.zone»;
allow-transfer < 172.16.0.6; >;
>;
После этого проверяем синтаксис и перезагружаем bind9.
Можно приступать к аналогичной настройке на вторичном сервере. В named.conf.local добавьте следующую конфигурацию:
zone «16.172.in-addr.arpa.» <
type slave;
file «/etc/bind/slave/16.172.in-addr.arpa.zone»;
masters < 172.16.0.5; >;
>;
На этом этапе мы завершили работу с локальными доменными зонами. Можно приступать к конфигурации внешней доменной зоны.
Внешняя доменная зона
Во-первых, для того, чтобы запросы из внешней сети обрабатывались нашим сервером нужно в файле конфигурации named.conf.options добавить внешний адрес в директиву listen-on :
.
listen-on aaa.bbb.ccc.ddd/32; # наш внешний IP
172.16.0.0;
127.0.0.0/8
>
…
Далее создадим файл зоны (не забудьте изменить серийный номер!) и добавим в него внешние IP-адреса.
sudo nano /etc/bind/master-zones/test.example.com.zone
Затем создадим для зон внешнего просмотра отдельный файл, чтобы раздавать разные доменные зоны клиентам из разных подсетей.
sudo nano /etc/bind/named.conf.external
И добавим в него следующее содержимое:
zone «test.example.com.» <
type master;
file «/etc/bind/master-zones/test.example.com.zone»;
allow-transfer < 172.16.0.6; >;
>;
После этого подключим файл в named.conf , добавив такой блок:
acl «external-view» aaa.bbb.ccc.ddd; >;
view «external-view» recursion no;
match-clients < external-view; >;
include «/etc/bind/named.conf.external»;
>;
Осталось проверить эту зону и перезагрузить bind9:
sudo named-checkconf -z
sudo named-checkzone test.example.com. /etc/bind/master-zones/test.example.com.zone
sudo service bind9 restart
sudo service bind9 status
На вторичном DNS-сервере в named.conf.options нам нужно указать внешний адрес сервера:
sudo nano /etc/bind/named.conf.options
options dnssec-validation auto;
auth-nxdomain no;
recursion no;
directory «/var/cache/bind»;
listen-on eee.fff.ggg.hhh/24;
172.16.0.0/16;
127.0.0.0/8;
>;
>;
И точно так же, как на первой машине, создаём новый файл named.conf.external:
sudo nano /etc/bind/named.conf.external
Со следующим содержимым:
zone «test.example.com.» type slave;
file «/etc/bind/slave/test.example.com.zone»;
masters < 172.16.0.5; >;
>;
Далее в named.conf добавляем следующий блок:
acl «external-view» eee.fff.ggg.hhh; >;
view «external-view» <
recursion no;
match-clients < external-view; >;
include «/etc/bind/named.conf.external»;
>;
И выполняем трансфер:
sudo rndc retransfer test.example.com IN external-view
Отладка
При настройке DNS-сервера очень важно внимательно отнестись к журналированию запросов. Это поможет при отладке на начальных стадиях, а во время полноценной работы сервера вы сможете в полной мере контролировать работу служб.
Bind9 позволяет полноценно настраивать правила журналирования — писать в один файл, разные категории помещать в разные журнал и так далее.
Для того, чтобы записать отладочную информацию в один файл, нужно создать правила журналирования и подключить их в основной конфиг. Для этого создадим файл log.conf :
sudo nano /etc/bind/log.conf
И поместим в него содержимое:
logging channel bind.log file «/var/lib/bind/bind.log» versions 10 size 20m;
severity debug;
print-category yes;
print-severity yes;
print-time yes;
>;
category queries < bind.log; >;
category default < bind.log; >;
category config < bind.log; >;
>;
После этого подключим файл в основной конфиг:
include «/etc/bind/log.conf»
И перезагрузим bind9:
sudo service bind9 restart
Можно создать несколько таких файлов с разными настройками и подключать их в зависимости от стадии разработки или нагрузки на сервер.
Заключение
Теперь вы сможете самостоятельно сконфигурировать систему так, чтобы обращаться к реусрсам по имени, а не по IP-адресу. Для этого в качестве примера мы настроили на сервере с OS Ubuntu dns с помощью пакета bind9.
Однако теперь вы должны внимательно следить за основным и вторичным серверами, поскольку они обрабатывают DNS-запросы внутри системы.
Источник: timeweb.cloud
DNS сервер BIND (теория)
Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.
Основные понятия Domain Name System
Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:
Доменная структура DNS представляет собой древовидную иерархию, состоящую из узлов, зон, доменов, поддоменов и др. элементов, о которых ниже пойдет речь. «Вершиной» доменной структуры является корневая зона. Настройки корневой зоны расположены на множестве серверов/зеркал, размещенных по всему миру и содержат информацию о всех серверах корневой зоны, а так же отвечающих за домены первого уровня (ru, net, org и др).
Информация о серверах корневой зоны расположена на данном сайте корневых серверов. Настройки корневой зоны всегда доступны тут. Серверы корневой зоны обрабатывают и отвечают на запросы, выдавая информацию только о доменах первого уровня (то есть отвечают на любые запросы, как на нерекурсивные)! Итак, уже много раз повторилось слово зона. Пора этот термин объяснить.
Зона — это любая часть дерева системы доменных имен, размещаемая как единое целое на некотором DNS-сервере. Зону, для бОльшего понимания, можно назвать «зоной ответственности». Целью выделения части дерева в отдельную зону является передача ответственности (Делегирование) за эту ветвь другому лицу или организации.
На иллюстрации, примеры зон выделены синим градиентом (зона name., зона k-max.name. со всем подчиненными ресурсами, www.openoffice.org со всем подчиненными поддоменами и ресурсами). На иллюстрации выделены не все зоны, а лишь некоторые для общего понимания и представления. В каждой зоне имеется, по крайней мере, один авторитетный сервер DNS, который хранит ВСЮ информацию о зоне, за которую он отвечает.
Домен — это именованная ветвь или поддерево в дереве имен DNS, то есть это определенный узел, включающий в себя все подчиненные узлы. Следующая цитата из книги Linux Network Administrators Guide хорошо проясняет картину относительно разницы между зоной и доменом:
Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.
Каждый узел в иерархии DNS отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе — слэш, а в DNS — точка. А так же DNS адрес читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux.
Доменное имя начинается с точки (корневого домена) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.о. доменное имя полностью отражает структуру иерархии DNS.
Часто (я бы сказал — всегда в повседневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.name., а k-max.name). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию FQDN.
FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) — это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Своеобразный аналог абсолютного пути в файловой системе. Давайте разберем вышесказанное на примере имени домена mail.k-max.name:
mail.k-max.name. | | | | | | | | | +-корневой домен | | | +—домен первого уровня | | +——точка, разделяющая домены/части FQDN | +———домен второго уровня +—————поддомен/домен третьего уровня, возможно — имя хоста
Различие между FQDN и обычным доменным (неFQDN) именем появляется при именовании доменов второго, третьего (и т. д.) уровня. Для получения FQDN требуется обязательно указать в доменном имени домены более высокого уровня (например, mail является доменным именем, однако FQDN имя выглядит как mail.k-max.name.). Максимальный размер FQDN — 255 байт, с ограничением в 63 байта на каждое имя домена.
Поддомены, коротко говоря, это — подчиненные домены. По большому счету, все домены в интернете являются подчиненными за исключением корневого. Например домен k-max является поддоменом домена name, а name, в свою очередь — поддоменом корневого домена.
Итак, на схеме выше мы рассмотрели корневой домен, следующим в иерархии идут домены первого/верхнего уровня, они же TLD, они же Top-Level Domain. К данным доменам относятся национальные домены (ru., ua. и др) и общие домены (com., net., и др).
Существуют так же специализированные домены, которые не опубликованы в системе DNS, но используются программами (домен .onion используется анонимной сетью Tor для перехвата и последующей маршрутизации обращений к скрытым сервисам этой сети). Еще есть т.н.
зарезервированные доменные имена, определенные в RFC 2606 (Reserved Top Level DNS Names — Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. К таким именам относятся например example.com, example.org и example.net, а также test, invalid и др. Ниже по иерархии, как видно, идут домены третьего уровня и т.д. Заканчивается доменная иерархия — именами хостов, которые задаются соответствующими ресурсными записями или хостовыми записями.
Ресурсные записи
Ресурсная запись — это то, собственно ради чего в конечном счете и существует DNS. Ресурсная запись — это единица хранения и передачи информации в DNS. Каждая такая запись несет в себе информацию соответствия какого-то имени и служебной информации в DNS, например соответствие имени домена — IP адреса.
Запись ресурса состоит из следующих полей:
k-max.name. 86400 IN A 81.177.139.65
ftp 86400 IN CNAME www.k-max.name.
Источник: habr.com
BIND 9: опыт настройки и эксплуатации DNS-сервера
Сегодня невозможно представить себе интернет без DNS. Однако многие администраторы не уделяют время настройке этой службы на своих серверах, поэтому не используют всю ее мощь даже на треть.
Итак, планы на сегодня!
- Настройка зоны мастер.
- Подключение зон в слейве.
- Каждому свое. Настраиваем параметры в зависимости от адреса клиента, с которого пришел запрос.
- Подключаем внешний DNS-фильтр.
Другие статьи в выпуске:
Xakep #211. Когда «Окна» смотрят в тебя
- Содержание выпуска
- Подписка на «Хакер» -60%
Интро
Когда я устроился на работу, количество сервисов в нашей сети можно было пересчитать по пальцам одной руки. Время шло, число сервисов росло. Обслуживающий DNS-сервер был один и выступал мастером для одной зоны (назовем ее xak.ru). Все остальные запросы он просто пересылал на DNS-сервер Google (8.8.8.8). А, чуть не забыл добавить: сервер этот был виртуальным.
Потом в один прекрасный день сервер рухнул физически. После замены систему подняли, виртуализацию прикрутили. Поставили свежеустановленный Debian и к нему BIND 9. Присвоили тот же IP, что был у DNS-сервера до падения. Настройки восстановили из бэкапа. После успешного старта стали думать, как «закручивать болты».
Параллельно с этой работой был установлен хостинг, который держал на себе зону (например) xaker.ru. Само собой, центральный DNS должен о ней знать, а еще лучше быть slave DNS-сервером для этой зоны. Далее возникла необходимость перенаправлять DNS-запросы от центрального сервера к редиректору в зависимости от того, из какой сети пришел запрос.
Делалось это ради подключения внешних DNS-фильтров, но не для всех. А только для тех, кому надо, а именно образовательных городских сетей — территории образовательных учреждений! Обо всем этом и пойдет речь ниже.
Немного теории
Основная цель DNS — это отображение доменных имен в IP-адреса и наоборот — IP в DNS. Решено было рассмотреть BIND (Berkeley Internet Name Domain, ранее Berkeley Internet Name Daemon), как самый распространенный софт для решения задачи DNS. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для части запросов TCP/53. Очень подробно о нем рассказано в статье на Хабре.
Если хочешь познакомиться с «новым» BIND, то рекомендую к чтению вот эту статью. В двух словах: версия 9 была последней, с 10-й версии права передают сообществу, и это ПО ныне известно как Bundy.
Быстрая установка, или еще раз об одном и том же
Итак, как установить BIND 9 в Debian/Ubuntu, в Сети очень и очень много материала. Так что быстро пройдемся по этому пункту, не вдаваясь в подробности. Для начала необходимо установить BIND 9 в систему. Для пользователей MS Windows есть версия BIND 9 под их платформу.
$ sudo apt install bind9
INFO
Подробно о версии для Windows 2008 можно почитать тут: «Установка BIND 9 в Windows Server 2008».
Для других дистрибутивов руководств по сборке из исходных кодов на просторах Сети предостаточно, забирай быстрее, переписывай в блокноты, пока новый «суперполезный» закон не накрыл весь интернет или пока тебя не отругали за то, что ты ходишь или ходил на сайт с запрещенной литературой.
После установки переходим в каталог /etc/bind9/ и видим там основной файл конфигурации named.conf , внутри подключены остальные файлы named.conf.* . Как настраивать мастер-зону, опустим, поскольку в Сети информация изложена очень подробно. Добавим в файл named.conf строку
include «/etc/bind/named.conf.acl»;
чем подключим новый файл в конфиг для правил подсетей. Далее создаем файл /etc/bind/named.conf.acl и добавляем правила:
acl «lan» < 192.168.181.0/24; >; acl «do» < 10.0.0.0/24; 192.168.253.0/24; >; acl «srv» < 192.168.254.0/24; >; acl «alls» < 10.10.0.0/16; >; acl «dou» < 192.168.201.0/24; 192.168.202.0/24; 192.168.203.0/24; 192.168.204.0/24; 192.168.205.0/24; >; acl «school» < 172.16.0.0/24; >;
Здесь мы разделили сети на группы для дальнейшей обработки. Прежде чем продолжим, уточню один момент. Для корректной обработки зон необходимо в каждую группу правил добавлять все зоны. Можно это делать в одном файле или вынести настройки зоны в отдельный файл и потом просто подключать в нужных местах. Итак, в файл /etc/bind/named.conf.local вносим изменения:
view «edu» < match-clients < school; >; recursion yes; allow-query < school; >; forwarders < 77.88.8.7; >; zone «xaker.ru» < type master; file «/etc/bind/xaker.ru_loc»; >; zone «254.168.192.in-addr.arpa.» < type master; file «/etc/bind/xaker.rev»; >; zone «zone2.ru» < type slave; file «/etc/bind/db.zone2.ru»; masters < 192.168.254.5; >; >; >;
Здесь мы обозначаем группу, с которой будет работать BIND. Добавляем сюда клиенты из правил, которые мы определили выше.
Назначаем вышестоящий сервер, на который будут пересылаться запросы, пришедшие из сетей, согласно описанным правилам. Здесь это единственная группа адресов School. В качестве вышестоящего DNS задал DNS-сервер Яндекс, который фильтрует «плохой» контент. Можно аналогично использовать другие DNS-сервисы, такие как SkyDNS.
Далее в этот же файл ниже добавляем вторую или остальные группы клиентов. Зона zone2.ru подключена как slave-зона, указан DNS-мастер-сервер и файл — путь к базе.
view «any» < match-clients < any; >; notify yes; recursion yes; allow-query < do; lan; srv; dou; >; forwarders < 8.8.8.8; >; zone «xaker.ru» < type master; file «/etc/bind/xaker.ru_loc»; >; zone «254.168.192.in-addr.arpa.» < type master; file «/etc/bind/xaker.rev»; >; zone «zone2.ru» < type slave; file «/etc/bind/db.zone2.ru»; masters < 192.168.254.5; >; >; zone «server.local» < type master; file «/etc/bind/server.local_loc»; >; >;
Здесь мы снова перечисляем, какие группы входят в эту секцию правил или, говоря иначе, каким сетям отвечать.
Настройки зон могут быть различными. Если необходимо обеспечить доступ в зону xaker.ru, то эту секцию нужно описывать в обеих секциях. Зона server.local описана только во второй части. Это говорит о том, что доступ к ней есть только у группы адресов, описанных в этой секции конфига.
Это полезно использовать для обеспечения доступа, например, к зоне серверов или закрытых внутренних сервисов, порталов и прочего только необходимых клиентов. Как видно из конфига, вышестоящий DNS-сервер здесь другой. Таким образом, можно подключать внешние DNS-фильтры для избранных.
В общем файле настроек /etc/bind/named.conf.options описываем только недостающие параметры.
options < directory «/var/cache/bind»; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 < any; >; version «Xaker DNS Master Server»; listen-on-v6 < none; >; notify yes; forward first; listen-on port 53 < 127.0.0.1; 192.168.254.2; >; >;
Эти правила можно отключить и прописать для каждой группы. Учти, что в таком случае параметры нужно прописывать в каждой секции, у нас их две. Файлы зон описываются при этом стандартно.
Здесь все стандартно. Описываем зону. Если нужно, MX-записями задаем узлы для работы с почтой. Последней строчкой мы описываем XMPP-сервер для передачи файлов с поддержкой Jabber-прокси. Без этого файлы между сетями, находящимися за шлюзом, передавались нестабильно.
Для того чтобы не описывать одинаковые зоны по несколько раз, можно вынести их в файл, например, zone-share.conf . Внутри описать общие зоны, которые будут использоваться во всех группах:
zone «xaker.ru» < type master; file «/etc/bind/xaker.ru_loc»; >; zone «254.168.192.in-addr.arpa.» < type master; file «/etc/bind/xaker.rev»; >; zone «zone2.ru» < type slave; file «/etc/bind/db.zone2.ru»; masters < 192.168.254.5; >; >; zone «server.local» < type master; file «/etc/bind/server.local_loc»; >;
А в файле /etc/bind/named.conf.local после описания параметров и перед подключением настроек зон подключить файл с настройками:
include «/etc/bind/zone-share.conf»;
А уже потом описывать зоны, которые будут обрабатываться только для этих клиентов, описанных в данной секции конфига.
Итог
Как видно, совсем не сложно разбить клиенты DNS на группы сетей или отдельные узлы и обрабатывать их запросы или перенаправлять вышестоящему DNS-серверу в зависимости от адреса, с которого пришел запрос. Чтобы наши клиенты НЕ СМОГЛИ использовать внешние DNS-серверы на выходном шлюзе, добавляем правило «Разрешить DNS-запросы в интернет от ваших DNS-серверов и запретить для всех остальных». Делается это из-за того, что есть знающие пользователи, которые меняют настройки на своих устройствах. Или просто заворачиваем все запросы на наш DNS. Следует отметить, что если используется прокси, то для его клиентов запросы будет обрабатывать прокси-сервер, это нужно учитывать.
Служба DNS не менее важна, чем DHCP и другие. При правильном подходе она помогает решить довольно большой круг задач. Игнорируя этот сервис, перекладывая все заботы на публичные DNS-серверы, администраторы лишают себя очень гибкого инструмента для работы с сетью. Так, например, можно снизить нагрузку на канал, если описать зоны с сервисами, находящимися в локальной сети и имеющими доступ из сети Интернет, чтобы внутренние клиенты ходили только по локальной сети, а клиенты внешние — через внешний канал соответственно. Когда число клиентов переваливает за сотню, это особенно ощутимо.
P. S. Всем удачи! Легкой настройки, бесперебойной работы и свободного канала связи
Александр «Plus» Рак
Участник сообщества OmskLUG. Заместитель начальника отдела сопровождения информационных систем ГКУ «Ресурсы Ямала».
Источник: xakep.ru