Серверы Linux. Часть III. Сервер DNS

Глава 5. Дополнительная информация о серверах DNS

5.4. Пример: использование механизма изменения ответов сервера DNS в зависимости от источников запросов

Представьте, что вам необходимо настроить сервер DNS таким образом, чтобы он отвечал на запросы в зависимости от того, кто отправляет эти запросы. К примеру, если кто-либо из сети 10.104.15.0/24 (обслуживаемой Джесс) отправляет запрос для получения ресурсной записи A домена www.paul.local, сервер DNS отправит ответ с IP-адресом 10.104.33.30. Но если аналогичный запрос для получения данных ресурсной записи A домена www.paul.local отправит кто-либо из сети 10.104.42.0/24 (обслуживаемой Кит), он получит ответ с IP-адресом 10.104.33.31.

Механизм изменения ответов сервера DNS в зависимости от источников запросов (split-horizon DNS) может использоваться для перенаправления пользователей на дублирующие локальные сервисы.

В данном примере мы попытаемся настроить сервер DNS для передачи определенных ответов клиентам из двух сетей (обслуживаемых Джесс и Кит) и предотвращения использования ими нашего сервера DNS для осуществления рекурсивных запросов с сохранением возможности разрешения имен из сети Интернет, а также имен из нашей зоны DNS paul.local локальной сети.

Начнем с создания трех условий (view clauses) в файле конфигурации named.conf.local.

root@debian7:/etc/bind# cat named.conf.local
view "paul" {
match-clients { 10.104.33.0; localhost; };
include "/etc/bind/named.conf.default-zones";
zone "paul.local" IN {
        type master;
        file "/etc/bind/db.paul.local";
        allow-update { none; };
        };
};      // окончание условия для внутренней сети

view "jesse" {
match-clients { 10.104.15/24; };
zone "paul.local" IN {
        type master;
        file "/etc/bind/db.paul.local.jesse";
        allow-update { none; };
        };
};      // окончание условия для сети Джесс

view "keith" {
match-clients { 10.104.42/24; };
zone "paul.local" IN {
        type master;
        file "/etc/bind/db.paul.local.keith";
        allow-update { none; };
        };
};      // окончание условия для сети Кит

Обратите внимание на то, что мы включили описания стандартных зон DNS (default-zones) в условие для внутренней сети. Размещение описаний всех зон DNS в рамках различных условий является обязательным требованием.

Файлы описания зон DNS являются идентичными копиями за исключением записи для поддомена www. Как вы можете убедиться, механизм изменения порядка передачи адресов серверов сервером DNS все также используется для пользователей из внутренней сети, причем компьютеры с адресами из диапазона 10.104.15.0/24 (находящиеся под управлением Джесс) всегда будут получать IP-адрес сервера 10.104.33.30, а компьютеры с адресами из диапазона 10.104.42.0/24 (находящиеся под управлением Кит) - IP-адрес сервера 10.104.33.31.

root@debian7:/etc/bind# grep www db.paul.local db.paul.local.[jk]*
db.paul.local:www               IN      A       10.104.33.30
db.paul.local:www               IN      A       10.104.33.31
db.paul.local.jesse:www         IN      A       10.104.33.30
db.paul.local.keith:www         IN      A       10.104.33.31

5.5. Старые советы по использованию и настройке серверов DNS

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

5.5.1. Пример: зона DNS для обратного разрешения доменных имен

1. Мы можем реализовать возможность получения IP-адреса, соответствующего доменному имени, с помощью нашего сервера DNS путем создания обратной зоны DNS.

2. Начнем работу с добавления описания зоны DNS .arpa в файл конфигурации /etc/bind/named.conf.local таким же образом, как показано ниже (мы используем значение no директивы notify для того, чтобы избежать отправки сообщений с уведомлениями другим серверам DNS):

root@ubu1010srv:/etc/bind# grep -A4 arpa named.conf.local 
zone "1.168.192.in-addr.arpa" {
        type master;
        notify no;
        file "/etc/bind/db.192";
};

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

root@ubu1010srv:/etc/bind# cat db.192 
;
; BIND reverse data file for 192.168.1.0/24 network
;
$TTL    604800
@       IN      SOA     ns.cobbaut.paul root.cobbaut.paul. (
                        20110516        ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns.
37      IN      PTR     ns.cobbaut.paul.
1       IN      PTR     anya.cobbaut.paul.
30      IN      PTR     mac.cobbaut.paul.
root@ubu1010srv:/etc/bind# 

4. Протестируем работоспособность механизма обратного разрешения доменных имен с помощью утилиты nslookup или dig:

root@ubu1010srv:/etc/bind# dig 1.168.192.in-addr.arpa AXFR

5.5.2. Балансировка нагрузки на серверы DNS

Данный метод отличается от описанного выше. В том случае, если вы используете более одного сервера DNS, авторитативного для зоны DNS, вы можете распределять запросы между всеми имеющимися серверами DNS. Один из методов подобного распределения заключается в создании ресурсных записей NS для всех серверов DNS, которые будут использоваться для балансировки нагрузки в процессе обработки запросов от клиентов из внешней сети.

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

5.5.3. Уведомления серверов DNS

Оригинальная спецификация протокола DNS, приведенная в стандартах RFC 1034 и RFC 1035, предусматривает наличие специального поля refresh в ресурсной записи SOA, предназначенного для указания длительности промежутка времени, по истечении которого ведомые серверы должны запрашивать отправку данных зон DNS у ведущего сервера DNS. Использование подобного механизма может привести к генерации множества запросов отправки данных зон DNS или к значительному замедлению процесса обновления данных зон DNS.

По этой причине была разработана спецификация уведомлений серверов DNS (описанная в стандарте RFC 1996). Теперь сервер DNS может уведомлять ведомые серверы DNS при каждом обновлении данных зон DNS. Данная возможность активирована по умолчанию в сервере DNS bind.

Описанный механизм уведомлений может быть деактивирован таким же образом, как показано в следующем примере:

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

5.5.4. Тестирование работоспособности протоколов IXFR и AXFR

Операции полных передач данных зон DNS (осуществляющиеся по протоколу AXFR) инициируются в момент перезапуска службы сервера DNS bind или при ручном обновлении файла базы данных зоны DNS. С помощью утилиты nsupdate вы можете обновить данные файла базы данных зоны DNS и инициировать операцию частичной передачи данных зоны DNS.

Для корректного использования утилиты nsupdate необходимо активировать поддержку технологии динамического DNS (DDNS).

root@ubu1010srv:/etc/bind# nsupdate
> server 127.0.0.1
> update add mac14.linux-training.be 86400 A 192.168.1.23
> send
update failed: REFUSED

5.5.5. Интеграция серверов DDNS и DHCP

В некоторых организациях принято использовать сервер DNS для закрепления доменных имен за всеми клиентскими компьютерами. Такая конфигурация может оказаться достаточно сложной в плане обслуживания. К счастью, стандарт RFC 2136 описывает аспекты интеграции серверов DHCP с серверами DNS. В любой момент, когда сервер DHCP подтверждает IP-адрес клиента, он может отправить уведомление серверу DNS с информацией об IP-адресе и имени соответствующего клиентского компьютера. Данный механизм называется механизмом динамических обновлений (dynamic updates) или DDNS.

5.5.6. Обратное разрешение доменных имен является обычным разрешением доменных имен с использованием домена in-addr.arpa

Обратное разрешение доменных имен на самом деле реализовано как обычное разрешение доменных имен с использованием домена in-addr.arpa. Данный домен имеет 256 дочерних доменов (начиная с домена 0.in-addr.arpa и заканчивая доменом 255.in-addr.arpa), причем каждый дочерний домен также имеет 256 дочерних доменов. Описанное ветвление доменов повторяется еще дважды, образуя структуру из более чем четырех миллиардов (2 в степени 32) доменов.

5.5.7. Протокол IPv6

После выпуска стандарта RFC 3596 стали известны подробности реализации расширений протокола DNS для работы с сетевым протоколом IPv6. В стандарте описывается ресурсная запись AAAA, предназначенная для указания адресов IPv6 для использующих их узлов в сети, а также домен ip6.int, предназначенный для осуществления обратного разрешения доменных имен (имеющий 16 дочерних доменов от 0.ip6.int до f.ip6.int, каждый из которых имеет также 16 дочерних доменов и так 16 раз).

5.5.8. Безопасное использование сервера DNS: повреждение файлов

Для того, чтобы избежать повреждения файлов зон DNS, а также файла конфигурации сервера DNS bind следует защищать их от несанкционированного доступа с помощью системы прав доступа UNIX и регулярно создавать их резервные копии.

5.5.9. Безопасное использование сервера DNS: операции передачи данных зон DNS

Ограничьте операции передачи данных зон DNS определенными IP-адресами серверов вместо использования параметра any. Не думайте о возможной подмене IP-адреса сервера в пакетах (спуфинге), а просто используйте описанную возможность.

5.5.10. Безопасное использование сервера DNS: операции передачи данных зон DNS и спуфинг

Для защиты от атак подмены IP-адресов (спуфинга) в процессе передачи данных зон DNS вы можете либо задействовать технологию DNSSEC (при этом следует помнить о том, что данная технология является не самой простой в плане настройки и поддержки работоспособности сервера), либо использовать технологии, описанные в стандартах RFC 2845 (TSIG) и RFC 2930 (TKEY, подвержена атаке перебора ключей), или же вы можете полностью отключить механизм передачи данных зон DNS и использовать сценарий для самостоятельного копирования этих данных с использованием протокола SSH.

5.5.11. Безопасное использование сервера DNS: запросы

Разрешайте инициировать рекурсивные запросы лишь клиентам из локальной сети, а итеративные запросы - клиентам из внешних сетей лишь в случае необходимости. Данные ограничения могут быть установлены на уровне ведущих и ведомых серверов.

view "internal" {
match-clients { 192.168.42/24; };
recursion yes;
...

};

view "external" {
match-clients { any; };
recursion no;
...

};

Или же разрешайте инициировать запросы лишь клиентам из локальной сети.

options {
      allow-query { 192.168.42.0/24; localhost; };
};

zone "cobbaut.paul" {
      allow-query { any; };
};

Еще одним вариантом является разрешение инициирования рекурсивных запросов только для клиентов из внутренней сети.

options {
        allow-recursion { 192.168.42.0/24; localhost; };
};

5.5.12. Безопасное использование сервера DNS: сервер DNS bind в окружении chroot

Во многих дистрибутивах Linux имеется возможность запуска сервера DNS bind в окружении chroot, которой следует пользоваться.

5.5.13. Безопасное использование сервера DNS: технология DNSSEC

В случае использования технологии DNSSEC для безопасного обмена данными между серверами DNS используются публичные и закрытые ключи; сама технология описана в стандартах RFC 4033, RFC 4034 и RFC 4035.

5.5.14. Безопасное использование сервера DNS: привилегии пользователя root

Не запускайте сервер DNS bind с привилегиями пользователя root. Более того, вообще не следует самостоятельно запускать какие-либо демоны с привилегиями пользователя root.