Split DNS: заставим BIND работать на два фронта!::Журнал СА 5.2007
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Информация для ВАК
Звезды «СА»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Игры
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
13.03.2019г.
Просмотров: 69
Комментарии: 0
DevOps для ИТ-менеджеров

 Читать далее...

13.03.2019г.
Просмотров: 74
Комментарии: 0
Запуск и масштабирование DevOps на предприятии

 Читать далее...

13.03.2019г.
Просмотров: 57
Комментарии: 0
Kubernetes в действии

 Читать далее...

13.03.2019г.
Просмотров: 53
Комментарии: 0
Внедрение Splunk 7

 Читать далее...

24.12.2018г.
Просмотров: 1111
Комментарии: 0
Python. Разработка на основе тестирования

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Split DNS: заставим BIND работать на два фронта!

Архив номеров / 2007 / Выпуск №5 (54) / Split DNS: заставим BIND работать на два фронта!

Рубрика: Администрирование /  Продукты и решения

Яков Коваленко

Split DNS: заставим BIND работать на два фронта!

Вы системный администратор организации, которая использует много внешних адресов и свои DNS-серверы? У вас единое адресное пространство для внешних и внутренних серверов? Вы используете разные DNS-серверы для внутренней и внешней сети? Не стоит так усложнять себе жизнь. Есть способ заставить BIND работать на два фронта!

BIND – DNS-сервер для UNIX. Для воплощения в жизнь информации из этой статьи вам потребуются знания UNIX и BIND на уровне продвинутого пользования.

Что такое Split DNS-конфигурация? Конфигурация BIND, позволяющая использовать различные настройки DNS в зависимости от адреса источника запроса.

Для чего это может быть полезно? Допустим, ваша организация называется «Horns And Hooves inc.» и соответственно доменное имя hornsandhooves.ru. Вероятно, системному администратору покажется удобным назвать логичными и понятными именами все свои серверы и рабочие компьютеры.

Например, сервер разработки dev.hornsandhooves.ru, почтовые серверы – mx1.hornsandhooves.ru и mx2.hornsandhooves.ru, компьютеры сотрудников тоже захочется назвать понятными именами, например bender.hornsandhooves.ru, panikovsky.hornsandhooves.ru и так далее.

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

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

Рисунок 1. Модель обычной расстановки DNS-серверов без использования Split DNS

Рисунок 1. Модель обычной расстановки DNS-серверов без использования Split DNS

За брандмауэром расположены DNS-серверы для обслуживания зоны hornsandhooves.ru.

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

Давайте попробуем разобраться, каким образом, используя всего одну пару DNS-серверов, отдавать в Интернет только то, что положено – www-сервер с внешним адресом, DNS-сервер, почтовые серверы, а внутренним клиентам – адреса внутренних серверов и клиентских компьютеров, так называемое «затененное пространство имен», которое показывать в Интернете минимум опасно.

Расщепление пространства имен. Виды

Нам потребуется создать 2 разных файла зоны hornsandhooves.ru: один из них будет содержать информацию для Интернета, второй будет содержать информацию для внутренних клиентов.

Примечание: все доменные имена и IP-адреса вымышлены, совпадения случайны.

В файле зоны ext.hornsandhooves.ru указан минимальный набор серверов, необходимых для того, чтобы компания нормально работала, разрешала свои интернет-имена и принимала почту. При условии, что у регистратора зоны прописаны ваши DNS-серверы как ответственные за зону (см листинг 1).

Листинг 1. Файл ext.hornsandhooves.ru

$TTL 86400

hornsandhooves.ru.      IN     SOA ns1.hornsandhooves.ru. noc.hornsandhooves.ru.

                        (

                        2007032900          ; serial

                        21600               ; refresh (6 hours)

                        1200                ; retry (20 minutes)

                        86400               ; expire (1 day)

                        432000              ; minimum (5 days)

                        )

                        IN     NS           ns1.hornsandhooves.ru.

                        IN     NS           ns2.hornsandhooves.ru.

                        IN     MX     5      mx1.hornsandhooves.ru.

                        IN     MX     10     mx2.hornsandhooves.ru.

                        IN     A            194.0.1.1

www                     IN     A            194.0.1.1

ns1                     IN     A            194.0.1.3

ns2                     IN     A            194.0.1.4

mx1                     IN     A            194.0.1.3

mx2                     IN     A            194.0.1.4

А в файле int.hornsandhooves.ru, кроме внешних интернет-сервисов, но с внутренними адресами, мы видим еще несколько адресов, а именно адреса внутренних сервисов, о которых незачем знать внешнему Интернету, плюс адреса рабочих станций, о которых Интернету знать тоже незачем (см. листинг 2).

Листинг 2. Файл int.hornsandhooves.ru

$TTL 86400

hornsandhooves.ru.      IN     SOA ns1.hornsandhooves.ru. noc.hornsandhooves.ru.

                        (

                        2007032900          ; serial

                        21600               ; refresh (6 hours)

                        1200                ; retry (20 minutes)

                        86400               ; expire (1 day)

                        432000              ; minimum (5 days)

                        )

                        IN     NS           ns1.hornsandhooves.ru.

                        IN     NS           ns2.hornsandhooves.ru.

                        IN     MX     5      mx1.hornsandhooves.ru.

                        IN     MX     10     mx2.hornsandhooves.ru.

                        IN     A            192.168.1.1

www                     IN     A            192.168.1.1

ns1                     IN     A            192.168.1.3

ns2                     IN     A            192.168.1.4

mx1                     IN     A            192.168.1.3

mx2                     IN     A            192.168.1.4

dev                     IN     A            192.168.1.10

gate                    IN     A            192.168.1.11

filesrv                 IN     A            192.168.1.12

dhcp                    IN     A            192.168.1.13

bender                  IN     A            192.168.1.20

panikovsky              IN     A            192.168.1.21

funt                    IN     A            192.168.1.22

shura                   IN     A            192.168.1.23

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

Конфигурирование named.conf

Для начала разберемся с конфигурацией наших DNS-серверов.

У нас 2 сервера, master и slave. Ns1 и ns2 соответственно. Они по совместительству являются почтовыми серверами, ничто им не мешает заниматься еще и почтой.

В каждом сервере по два сетевых интерфейса. Один имеет внешний IP-адрес (194.0.1.3 для ns1 и 194.0.1.4 для ns2), второй интерфейс имеет адрес из внутренней сети (192.168.1.3 и 192.168.1.4 соответственно).

О конфигурации с одним интерфейсом с внутренним адресом (например, если у вас DMZ) будет сказано в конце статьи.

В BIND 9 есть замечательная возможность создавать Views (виды). В одном View мы расположим зону для Интернета, а в другом – зону для внутренней сети. Назовем их external и internal.

Файл конфигурации named.conf для master-сервера:

options {

        directory "/var/named";

        notify yes;

        pid-file "/var/run/named/named.pid";

        statistics-file "named.stats"; 

};

controls {

        inet 127.0.0.1 allow { localhost; } keys { rndckey; };

};

// Создадим ACL, в котором укажем, что внутренние адреса – подсеть 192.168.1

acl "internals" {192.168.1.0/24; 127.0.0.1/32;};

// Объявляем вид – internal зоны для внутренней сети

view "internal" {

        // Этот вид разрешено просматривать только внутренним клиентам

        match-clients { "internals"; };

        // Обозначим slave-сервер. Только ему разрешим скачивать зону

        allow-transfer {192.168.1.4;};

        // Наш сервер рекурсивен для внутренних клиентов, сам будет узнавать адрес для клиента

        recursion yes;

        //ROOT zone

        zone "." IN {

        type hint;

        file "named.ca";

        };

        //Forward zones

        zone "hornsandhooves.ru" in {

        type master;

        file "forward/int.hornsandhooves.ru";

        };

        //Reverse zone

        zone "1.168.192.in-addr.arpa" in {

        type master;

        file "reverse/1.168.192";

        };

        zone "localhost" IN {

        type master;

        file "localhost.zone";

        allow-update { none; };

        };

        zone "0.0.127.in-addr.arpa" IN {

        type master;

        file "named.local";

        allow-update { none; };

        };

};

// Объявляем вид для внешних запросов

view "external" {

        // К этому виду имеют доступ все

        match-clients {"any"; };

        // Наш сервер не рекурсивен для Интернета

        allow-recursion { localhost; };

        // Укажем внешний адрес slave-сервера

        allow-transfer { 194.0.1.4;};

        //ROOT zone

        zone "." IN {

        type hint;

        file "named.ca";

        };

        //Forward zones

        zone "hornsandhooves.ru" in {

        type master;

        file "forward/ext.hornsandhooves.ru";

        };

        //Reverse zone

        zone "1.0.194.in-addr.arpa" in {

        type master;

        file "reverse/1.0.194";

        };

};

include "/etc/rndc.key";

// Файл можно сгенерировать командой rndc-confgen -a -c /etc/rndc.key

Теперь, если с компьютера из внутренней сети сделать запрос на разрешение имени www.hornsandhooves.ru, то в ответ получим 192.168.1.1, если из Интернета, то получим 194.0.1.1. Если из внутренней сети дать запрос на разрешение имени bender.hornsandhooves.ru, то получим 192.168.1.20, а если из Интернета, то ничего не получим. Вот так наш сервер стал работать на два фронта.

Теперь давайте разберемся со slave-сервером.

Я не буду рассказывать, зачем нужен slave-сервер, но расскажу, как нужно его настроить специальным образом, для того чтобы он правильно синхронизировал зоны.

Специальная настройка заключается в указании серверу, с какого интерфейса надо запрашивать каждый вид. Делается это для того, чтобы сервер не перепутал виды и не скачал внутреннюю зону во внешний View.

Конфигурационный файл named.conf для slave-сервера:

options {

        directory "/var/named";

        notify yes;

        pid-file "/var/run/named/named.pid";

        statistics-file "named.stats"; 

};

controls {

        inet 127.0.0.1 allow { localhost; } keys { rndckey; };

        };

//ACLs

acl "internals" {192.168.1.0/24; 127.0.0.1/32; };

view "internal" {

        match-clients { "internals"; };

        query-source address 192.168.1.4 port 43303;

        recursion yes;

        // Здесь мы как раз указываем, с какого интерфейса запрашиваем передачу зоны.

        // В данном случае – с внутреннего, так как на внутреннем виде, на мастере,

        // трансфер разрешен для внутреннего интерфейса

        transfer-source 192.168.1.4;

        //ROOT zone

        zone "." IN {

        type hint;

        file "named.ca";

        };

        zone "hornsandhooves.ru" in {

        type slave;

        file "slave/int.hornsandhooves.ru";

        masters { 192.168.1.3; };

        };

        zone "localhost" IN {

        type master;

        file "localhost.zone";

        allow-update { none; };

        };

        zone "0.0.127.in-addr.arpa" IN {

        type master;

        file "named.local";

        allow-update { none; };

        };

        //Reverse zone

        zone "1.168.192.in-addr.arpa" in {

        type slave;

        file "reverse/1.168.192";

        masters { 192.168.1.3; };

        };

};

view "external" {

        match-clients {"any"; };

        query-source address 194.0.1.4 port 43303;

        allow-recursion { localhost; };   

        // Здесь мы указываем, что забираем зону с внешнего интерфейса –

        // только для него на мастере внешняя зона отдается

        transfer-source 194.0.1.4;

        //ROOT zone

        zone "." IN {

        type hint;

        file "named.ca";

        };

        //Forward zones

        zone "hornsandhooves.ru" in {

        type slave;

        file "slave/ext.hornsandhooves.ru";

        masters { 194.0.1.3; };

        };

        //Reverse zone

        zone "1.0.194.in-addr.arpa" in {

        type slave;

        file "reverse/1.0.194";

        masters { 194.0.1.3; };

        };

};

include "/etc/rndc.key";

Что получилось в результате?

На рис. 2 схематично представлено, что примерно должно получиться.

Рисунок 2. Модель расстановки DNS-серверов при использовании Split DNS

Рисунок 2. Модель расстановки DNS-серверов при использовании Split DNS

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

Во-первых, вместо четырех серверов у нас всего два.

Во-вторых, изменения нужно вносить только в master-сервер, на slave будут корректно синхронизироваться зоны.

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

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

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

Крупным компаниям рекомендуется использовать DMZ для интернет-серверов. С DMZ схема будет немного другая, так как не будет внешнего и внутреннего интерфейса, будет всего один.

Конфигурация с DMZ

Если ваши серверы находятся в DMZ, то у них используются только внутренние DMZ-IP-адреса, которые DMZ-маршрутизатором транслируются во внешние. Как решить проблему скачивания зон на slave-сервере?

Очень просто – поднимите дополнительный интерфейс на slave-сервере (можно alias, например eth0:1) и укажите его как transfer-source для одного из видов. На master-сервере для выбранного вида поставьте разрешение на скачивание, а для второго вида поставьте отказ в доступе. Делается это через acl.

Например:

acl "internals" {!192.168.1.5; 192.168.1.0/24;};

Здесь 192.168.1.5 – дополнительный интерфейс, которым мы будем скачивать external view. Ему не разрешено скачивать internal view (перед адресом стоит восклицательный знак).

Вот такое решение.

Послесловие

Если отбросить UNIX и BIND составляющую прочитанной вами статьи, кстати, спасибо, что дочитали, то информацию можно применить к любому DNS-серверу на любой платформе.

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

Удачи!


Комментарии
 
  19.11.2009 - 03:09 |  Игорь

Здравствуйте... у меня к вам такой вопрос (немного туповатый) но если я хочу использовать DNS только в локальной сети без віхода в интернет то мне надо регить доменное имя или я могу использовать любое ?

  05.12.2009 - 09:06 |  SlipKo

Любое использовать не стоит, могут быть проблемы. Обычно используется домен local, т.е. компьютеры будут называться vasya.local, petya.local и т.д. Регистрировать ничего не нада.

  28.04.2015 - 07:41 |  sergey.sav

Доброго времени!
Наткнулся на данную статью после того как реализовал подобную схему, а так же получил интересный косяк в придачу. Решения пока не вижу.
На серваке есть 2 одноимённые зоны (для внешней и внутренней сети).
Задача: Заставить сервер (localhost) разрешать имена в двух зонах
в named.conf сделано всё на view
view "internal" { match-clients { 192.168.1/24; 10/8; 127/8; localhost; };
...
}
view "external" { match-clients { 195.0.1/24; 127/8; localhost; };
...
}
named-checkconf -z
zone localhost.localdomain/IN: loaded serial 0
zone localhost/IN: loaded serial 0
zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
zone free-adm.ru/IN: loaded serial 2015042401
zone 1.168.192.IN-ADDR.ARPA/IN: loaded serial 2015042400
zone free-adm.ru/IN: loaded serial 2015042302
zone 1.0.195.IN-ADDR.ARPA/IN: loaded serial 2015042300

cat /etc/resolv.conf
search free-adm.ru
nameserver 127.0.0.1
А так же пробовал
cat /etc/resolv.conf
search free-adm.ru
nameserver 192.168.1.254
nameserver 195.0.1.15
192.168.1.254 и 195.0.1.15 – 2 интерфейса на сервере
С разноимёнными зонами понятно. Работать будет. А как быть с одноимёнными? Проблема только в том что до второй зоны дело не доходит. Пробовал с другого хоста nslookup натравливать на 195.0.1.15. Все разрешается как нужно
==================
Логику всё равно не понимаю до конца. Почему второй сервер не участвует
gate.free-adm.ru
Server: 195.0.1.15
Address: 195.0.1.15#53

** server can't find gate.free-adm.ru: NXDOMAIN

  14.02.2016 - 08:18 |  jsn

Сергей, привет -) Я понимаю год почти прошел с твоего письма. Да и статья уже 9 лет назад как вышла. Пиши если вопрос вдруг еще актуален :)

yakov.kovalenko@gmail.com

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru