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

 

Итак, планы на сегодня!

  1. Настройка зоны мастер.
  2. Подключение зон в слейве.
  3. Каждому свое. Настраиваем параметры в зависимости от адреса клиента, с которого пришел запрос.
  4. Подключаем внешний DNS-фильтр.
Пример описания зоны DNS
Пример описания зоны DNS
 

Интро

Когда я устроился на работу, количество сервисов в нашей сети можно было пересчитать по пальцам одной руки. Время шло, число сервисов росло. Обслуживающий 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
apt-cache search bind9
apt-cache search 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; };
};

Эти правила можно отключить и прописать для каждой группы. Учти, что в таком случае параметры нужно прописывать в каждой секции, у нас их две. Файлы зон описываются при этом стандартно.

$TTL    86400
@       IN      SOA     xaker.ru. root.xaker.ru. (
    2015021902 ; Serial
    1d ; Refresh
    12h ; Retry
    1w ; Expire
    3h ; Minimum
);
        IN      A       192.168.0.6
*       IN      A       192.168.0.6
@       IN      NS      xaker.ru.
@       MX      5       192.168.0.3
mail    MX      10      192.168.0.3
mail    IN      A       192.168.0.3
pop     IN      A       192.168.0.3
smtp    IN      A       192.168.0.3
imap    IN      A       192.168.0.3
ns1     IN      A       192.168.0.3
www     IN      CNAME   @
jabber  IN      A       192.168.0.3

_xmpp-server._tcp.proxy.jabber.xaker.ru 86400 IN SRV 0 5 5222 jabber.xaker.ru

Здесь все стандартно. Описываем зону. Если нужно, 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. Всем удачи! Легкой настройки, бесперебойной работы и свободного канала связи 🙂

1 комментарий

  1. Аватар

    Vengel

    18.02.2019 в 10:30

    Значит так. Я купил доступ к этой ебаной статье, думая, что все то, что платно — лучше, чем бесплатное, так как за денежное вознаграждение работается лучше. Но! Видимо, Александр «Plus» Рак о таком не слышал и разместил в статье то, что и так можно найти в открытом доступе, так как это является первоначальной настройкой без каких либо тонкостей, но блять НЕЕЕЕТ, давайте за это возьмем деньги. Надеюсь эти ебаные 90 рублей пойдут на лечение твоей фамилии. Надеюсь ты блять от него и умрешь. Мне не жалко денег, но только в том случае, когда за это я получаю новую инфу, которая, как минимум, полезна. От этой же статьи я не получил ничего.

Оставить мнение