|
Bog BOS: DNS сервер BIND |
|
Последние изменения: |
Последнее изменение файла: 2010.03.03
Скопировано с www.bog.pp.ru: 2024.11.21
Требуется предварительное знакомство с материалом по архитектуре DNS.
BIND является самой распространенной реализацией сервера DNS. Разработка ведется Internet Software Consortium (ISC). Текущие версии (на 28 марта 2007) - BIND 9.4.0, BIND 9.3.4 (FC6 - 9.3.2/9.3.4), BIND 9.2.8 (поддержка до 1 августа 2007, RHEL4 - 9.2.4), BIND 8.4.7, BIND 4.9.11. Лицензия собственная, позволяет использовать продукт бесплатно или за плату (контракт на поддержку).
В комплекте с сервером BIND 9 поставляются утилиты DNS, клиентская библиотека DNS resolver, облегченная клиентская библиотека lightweight resolver и соответствующий ей демон lwresd, UDP/921 (по-моему, это очень вредная идея консорциума ISC, нарушающая принцип совместимости ПО).
В статье описываются:
В статье не описываются (пока?):
Файл настройки BIND 9 обычно называется /etc/named.conf (можно изменить при установке). Формат файла зоны стандартен и приведен в описании архитектуры DNS. Утилита named-checkzone проверяет синтаксис файла зоны. В качестве параметра указываются имя зоны и имя файла. Утилита named-checkconf проверяет синтаксис файла настройки. В качестве параметра можно указать имя файла.
Комментарии в файле настройки могут записываться в стиле C, C++ или sh. Строки и идентификаторы, не являющиеся доменными именами, например, имена файлов, обязательно заключать в кавычки.
Во многих местах файла настройки используется такая синтаксическая конструкция, как список-шаблонов-адресов: список через точку с запятой шаблонов адресов, завершающийся точкой с запятой. Шаблон адреса - это либо IP-адрес, либо IP-адрес с указанием числа бит в маске адреса (например, 192.168.0.0/28), либо имя ACL (т.е. ссылка на ранее определенный утверждением acl список-шаблонов-адресов, либо список-шаблонов-адресов в фигурных скобках, либо ключевое слово key с последующим именем ключа (определяется утверждением key). Имена рекомендуется заключать в кавычки. Перед шаблоном адреса может стоять символ отрицания (восклицательный знак). Ключи попали в эту конструкцию, потому что они тоже определяют права доступа, хотя и не имеют отношения к адресам хостов. Исходный адрес сравнивается последовательно с элементами списка до первого успешного соответствия. Если перед этим элементом списка стоит символ отрицания, то процесс завершается и сравнение со всем списком-шаблонов-адресов считается неудачным. Предопределены следующие имена ACL:
Список-ключей - это список ключей через точку с запятой, завершающийся точкой с запятой.
Файл настройки состоит из утверждений, завершающихся точкой с запятой. Утверждение начинается с ключевого слова и может содержать блок предложений, заключенный в фигурные скобки. Предложение в блоке также завершается точкой с запятой, начинается с ключевого слова и может содержать блок. Утверждения обрабатываются последовательно. Предусматриваются следующие типы утверждений:
Утверждение options может содержать следующие предложения (не пугайтесь их количеству - большинство либо уже устарело, либо еще не реализовано :):
host -t txt -c CHAOS version.bind адрес-сервера
host -t txt -c CHAOS hostname.bind адрес-сервера
Утверждение server может использоваться на верхнем уровне файла настройки или быть вложено в утверждение view. Если утверждение view содержит хотя бы одно утвержение server, то для данного вида используются только они (глобальные утверждения server игнорируются), иначе глобальные утверждения server действуют и на данный вид. Утвержение server может содержать следующие предложения:
Утверждение zone устанавливает опции, специфические для указанной зоны. Формат утверждения следующий:
zone имя-зоны [ класс ] {
type тип-зоны;
[ опция; ... ]
};
Имя зоны - это доменное имя корневого узла зоны. Тип зоны определяет роль, которую сервер будет исполнять для этой зоны:
Опции зоны (большинство опций позволяют заменить глобальные значения, заданные в утверждении options или взятые по умолчанию; они имеют тот же самый синтаксис и семантику):
Утверждение view позволяет выдавать различные ответы на один и тот же запрос в зависимости от того, кто спрашивает. То есть вид доменного пространства будет зависеть от точки зрения. Берётся первый подходящий вид в зависимости от адреса клиента (match-clients) или сервера (match-destinations). Если не определено ни одного вида, то по умолчанию создаётся вид "default" в классе IN, в который попадают описания всех зон для всех клиентов. Если хотя бы один вид описывается явно, то все зоны должны быть внутри видов. Формат утверждения следующий:
view имя-вида [ класс ] {
match-clients { список-шаблонов-адресов };
match-destinations { список-шаблонов-адресов };
match-recursive-only { yes_or_no };
[ опция; ... ]
[ определение зоны; ... ]
};
Чтобы принять 2 вида зоны slave сервер должен иметь 2 адреса, на которые будут передаваться различные виды.
Похоже, что BIND 9 не обслуживает передачу зон, для которых он не является уполномоченным.
Утверждение logging позволяет задать произвольное число способов записи в журнал с помощью предложений channel и привязать различные категории сообщений к каналам с помощью предложений category. Описано в документации мутно (особенно про отладку) и точно так же работает (например, rndc reload не отключает часть отладочной печати).
В предложении channel задается имя канала, способ записи (в файл с ограничением его размера (можно использовать масштабирующие коэффициенты K, M и G) и числа версий, syslog, stderr, null), фильтр (минимальный уровень серьезности сообщений для вывода через этот канал) и формат вывода (выводить ли в каждое сообщение имя категории, уровень серьезности и метку времени; по умолчанию - нет):
channel имя-канала {
( file имя-файла
[ versions ( число | unlimited ) ]
[ size максимальный-размер ]
| syslog syslog_facility
| stderr
| null );
[ severity (critical | error | warning | notice |
info | debug [ уровень ] | dynamic ); ]
[ print-category yes-или-no; ]
[ print-severity yes-или-no; ]
[ print-time yes-или-no; ]
};
Версии файла (file, file.0, file.1 и т.д.) перенумеровываются при каждом открытии (кстати, а когда он открывается?), если максимальный размер файла не задан. Если задан и размер и число версий, то перенумеровывание при открытии происходит только при превышении этого размера. Если при записи в файл его максимальный размер будет превышен, то при указании числа версий происходит перенумерация файлов и открывается новый, если число версий не указано, то запись в файл просто прекращается.
Режим отладки задается либо при запуске (ключ -d), либо командой trace программы rndc (выключается командой rndc notrace). Команда trace позволяет указать уровень отладки (чем больше уровень, тем более подробная отладочная информация выдается, уровень 3 достаточно болтлив). При указании фильтра (severity) можно указать определенный уровень отладки (debug [ уровень ]) для включения отладочной печати данного уровня (и ниже) независимо от уровня отладки сервера (лишь бы ее включили) или указать ключевое слово dynamic для отладочной печати уровня, совпадающего с уровнем отладки сервера.
В предложении category задается имя категории и список ранее определенных каналов, через которые будут выводиться сообщения данной категории:
category имя-категории {
имя-канала ; [ имя-канала ; ... ]
};
Определены следующие категории:
Переопределять каналы (в т.ч. встроенные) нельзя, но можно привязать категории к новым каналам. Сообщения об ошибках синтаксиса файла настройки и о запуске сервера записываются как будто утверждение logging отсутствует (так что syslog:daemon тоже надо просматривать регулярно). По умолчанию принимается следующая настройка записи в журнал:
logging {
channel default_syslog {
syslog daemon;
severity info;
};
channel default_debug {
file "named.run";
severity dynamic;
};
channel default_stderr {
stderr;
severity info;
};
channel null {
null;
};
category default { default_syslog; default_debug; };
category unmatched { null; };
};
Количество статистической информации, собираемой BIND 9 сильно уменьшилось о сравнению с предыдущими версиями. Накопленная статистика добавляется командой rndc stats к файлу named.stats в рабочей директории (options, directory), очередной раздел обрамляется строками "Statistics Dump" с указанием времени в формате UNIX:
Общее число запросов к серверу равно success + referral + nxrrset + nxdomain + failure. Статистика может собираться отдельно по зонам и видам, в этом случае имена зоны и вида (опускается для вида default) приводятся в конце каждой строки.
Немного местной статистики (кеширующий сервер; большую часть нагрузки создают почтовые серверы из-за RBL ;): 4.4 запроса в секунду; средний размер пакета - 100 байт; устоявшийся размер процесса - 16 МБ; нагрузка на процессор - втрое меньше, чем squid, обслуживающий тот же контингент пользователей.
Рекомендуется создать специальную группу named и пользователя named для запуска сервера. Перед запуском необходимо отредактировать /etc/named.conf, файлы зон и установить соответствующие права доступа к ним и прочим файлам, имеющим отношение к серверу (простой пример). Если необходимо управление сервером с помощью программы rndc, то необходимо также отредактировать /etc/rndc.conf. Ключи запуска:
После отладки процесс запуска можно автоматизировать.
В то время как управление работающим сервером BIND 4 осуществлялось простой посылкой сигнала процессу (HUP - перезагрузить файл настройки и зоны; TERM - остановить; INT - сбросить базу данных в файл named_dump.db; ABRT - записать статистику в конец файла named.stats), управление сервером BIND 9 производится с помощью специальной утилиты rndc, которая соединяется с сервером (по умолчанию - TCP порт 953) и использует специальный протокол для передачи ему команд. Однако сигналы HUP, TERM пока действуют.
Настраивая сервер, необходимо обеспечить права доступа к управляющему порту (controls) и ключ (key), смотри ниже rndc-confgen.
Файл настройки rndc (/etc/rndc.conf) имеет такой же синтаксис, что и named.conf. Комментарии могут записываться в стиле C, C++ или sh. Файл настройки состоит из утверждений, завершающихся точкой с запятой. Утверждения содержат блок предложений, заключенный в фигурные скобки. Предложение в блоке также завершается точкой с запятой. Права на чтение этого файла должны быть только у того, кто имеет право запускать rndc. Предусматириваются следующие типы утверждений:
Утилита rndc-confgen позволяет сгенерировать /etc/rndc.conf со случайным ключом (и закоментаренные предложения controls и key для /etc/named.conf). Следующими ключами можно модифицировать получаемый файл:
Утилита rndc позволяет менять параметры соединения с сервером с помощью ключей:
Если запустить rndc без указания команды, то она выдаст список поддерживаемых команд:
Автоматизация запуска производится через стандартный в Linux механизм /etc/rc.d/. Кстати, можно позаимствовать скрипты из какого-нибудь дистрибутива. Для работы этих скриптов необходимо предварительно настроить сервер, включая управление через rndc, и создать пользователя и группу named.
Создается файл /etc/rc.d/init.d/named следующего вида (реальный файл из дистрибутива будет содержать множество проверок):
#!/bin/bash
# chkconfig: - 55 45
RETVAL=0
prog="named"
start() {
# Start daemons.
if [ -n "`/sbin/pidof named`" ]; then
echo -n $"$prog: already running"
return 1
fi
echo -n $"Starting $prog: "
base=$prog
/usr/local/sbin/named -u named
RETVAL=$?
usleep 100000
if [ -z "`/sbin/pidof named`" ]; then
# The child processes have died after fork()ing, e.g.
# because of a broken config file
RETVAL=1
fi
[ $RETVAL -ne 0 ] && failure $"$base startup"
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/named && success $"$base startup"
echo
return $RETVAL
}
stop() {
# Stop daemons.
echo -n $"Stopping $prog: "
/usr/local/sbin/rndc stop
RETVAL=$?
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named || {
killproc named
RETVAL=$?
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named
}
echo
return $RETVAL
}
status() {
/usr/local/sbin/rndc status
return $?
}
restart() {
stop
start
}
reload() {
/usr/local/sbin/rndc reload >/dev/null 2>&1
return $?
}
Не забудьте дать ему права на исполнение:
chmod 755 /etc/rc.d/init.d/named
Включение его при загрузке и пробный запуск:
chkconfig --add named chkconfig --level 2 named on chkconfig --level 3 named on chkconfig --level 4 named on chkconfig --level 5 named on /etc/rc.d/init.d/named start
Проверяем, запустился ли:
/etc/rc.d/init.d/named status
Простейшим случаем является настройка сервера DNS, который не является уполномоченным ни для какой зоны, а только обслуживает локальных клиентов. Предполагается, что новый DNS сервер создается внутри уже существующей инфраструктуры, т.е. проблемы с определением канонического доменного имени сервера, почтового адреса администратора и обратной зоны решены кем-то до нас.
/usr/sbin/useradd -c "Named" -u 25 -s /sbin/nologin -r -d /etc/named named
mkdir /etc/named chown root:named /etc/named chmod 770 /etc/named
$TTL 1d @ IN SOA каноническое-доменное-имя-сервера d-почтовый-адрес-администратора ( 2004012201 1d 1h 1w 1h ) IN NS каноническое-доменное-имя-сервера 1 IN PTR localhost.
chown root:named /etc/named/* chmod 640 /etc/named/*
acl "mynets" {
192.168.0.0/24;
...
};
options {
version "что-нибудь"; // скрыть номер версии, если Вы параноик
directory "/etc/named";
pid-file "named.pid";
zone-statistics yes;
// разрешить запросы только своим клиентам
allow-query { "mynets"; };
allow-recursion { "mynets"; };
allow-transfer { "mynets"; };
// укажем явно, на каких интерфейсах обслуживать запросы
listen-on { 127.0.0.1; адрес-сервера; };
interface-interval 0;
// с какого адреса выдавать запросы к другим серверам, AXFR/IXFR, NOTIFY
query-source address адрес-сервера;
transfer-source адрес-сервера;
notify-source адрес-сервера;
// увы, окружающие серверы в большинстве своем не понимают "модных штучек"
notify explicit;
transfer-format one-answer;
request-ixfr no;
// ограничения на потребление ресурсов
max-cache-size 100M;
};
// весь вывод, включая отладку, на syslog:local1
// позволяет включать/выключать querylog (уровень сообщений info)
// и trace с нужным уровнем отладки (debug)
logging {
channel debug_syslog {
syslog local1;
severity dynamic;
print-category yes;
};
category default { debug_syslog; };
// lame-server в отдельный файл, поверьте - они вас достанут!
// размер файла и число версий - дело вкуса, можно и "versions 2 size 10k"
channel lame-server {
file "lamers.log" versions 99 size 10M;
severity info;
print-time yes;
};
category lame-servers { lame-server; };
};
zone "." in {
type hint;
file "named.root";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "loopback";
};
key "rndc-key" {
algorithm hmac-md5;
secret "очень секретная строчка";
};
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
key "rndc-key" {
algorithm hmac-md5;
secret "очень секретная строчка";
};
controls { // доступ только через loopback
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
chown root:named /etc/rndc.conf /etc/named.conf chmod 0640 /etc/rndc.conf /etc/named.conf
host 127.0.0.1 127.0.0.1
host 127.0.0.1 адрес-сервера
host ya.ru адрес-сервера
Первичный уполномоченный сервер для домена (primary, master) |
Данный сервер в дополнение к обслуживанию своих клиентов будет первичным сервером для зоны company.ru. и отвечать на внешние запросы для данной зоны. Предполагается, что новый DNS сервер по-прежнему создается внутри уже существующей инфраструктуры, т.е. проблемы с определением почтового адреса администратора, почтовых серверов и обратной зоны решены кем-то до нас.
Договориваемся с кем-либо о вторичном уполномоченном сервере для нашей зоны. Не рекомендуется иметь только один уполномоченный сервер для зоны. Многие регистраторы просто не делегируют вам зону, пока не убедятся в наличии для нее двух работоспособных DNS серверов в различных сетях. В принципе, если есть второй канал выхода в интернет и возможность установить второй DNS сервер (на отдельном компьютере), то можно обойтись своими ресурсами. В этом случае, необходимо одновременно установить вторичный уполномоченный сервер.
$TTL 86400 ; 1 day
@ IN SOA ns d-почтовый-адрес-администратора (
2004012201 1d 1h 1w 1h )
NS ns
NS каноническое-доменное-имя-вторичного-сервера
; кто-то должен обрабатывать почту, приходящую на наш домен
MX 5 каноническое-имя-почтового-сервера
MX 10 каноническое-имя-запасного-почтового-сервера
; если мы хотим, чтобы к WWW-серверу можно было
; обратиться просто по имени домена
A адрес-HTTP-сервера
ns A адрес-нашего-сервера
; указание адреса вместо синонима ускорит доступ к сайту,
; но добавит забот при смене адреса
www CNAME каноническое-имя-HTTP-сервера
; прочие сведения о домене (FTP, почта и т.д.)
...
server адрес-вторичного-сервера {
transfer-format many-answers;
};
zone "company.ru" {
type master;
file "company.ru.master";
allow-query { any; };
// если нет паранойи, то можно и так: allow-transfer { any; };
allow-transfer { адрес-вторичного-сервера; };
// т.к. у нас в глобальных параметрах установлено: notify explicit,
// то необходимо явно указать список вторичных серверов, которые мы
// будем извещать об изменении зоны (если есть способные понять NOTIFY)
also-notify { адрес-вторичного-сервера; };
};
rndc reload
host -t ns домен-какого-нибудь-нежадного-провайдера host www.company.ru один-из-его-DNS-серверов
Вторичный уполномоченный сервер для домена (secondary, slave) |
Данный сервер в дополнение к обслуживанию своих клиентов будет вторичным сервером для обратной зоны 195.161.72.0 и отвечать на внешние запросы для данной зоны. Настройка первичного сервера описана выше.
server адрес-первичного-сервера {
request-ixfr yes;
transfers 20;
};
zone "72.161.195.in-addr.arpa" in {
type slave;
file "72.161.195.in-addr.arpa.slave";
// вместо первичного сервера можно брать зону
// с другого вторичного сервера
masters { адрес-уполномоченного-сервера; };
allow-query { any; };
// если нет паранойи, то можно и так: allow-transfer { any; };
allow-transfer { адреса-прочих-вторичных-серверов; };
};
}
rndc reload
host -t ns домен-какого-нибудь-нежадного-провайдера host -t ns 72.161.195.in-addr.arpa. один-из-его-DNS-серверов
Добавить поддомен без делегирования прав его администрирования (т.е. без создания новой зоны) очень просто. Для этого в наш файл, описывающий зону, company.ru.master необходимо добавить следующие строки и перезапустить сервер (rndc reload; не забудьте предварительно увеличить серийный номер в SOA!):
$ORIGIN otdel.company.ru.
; если мы хотим, чтобы к WWW-серверу можно было
; обратиться просто по имени домена
A адрес-HTTP-сервера
; кто-то должен обрабатывать почту, приходящую на наш домен
MX 5 каноническое-имя-почтового-сервера
MX 10 каноническое-имя-запасного-почтового-сервера
; указание адреса вместо синонима ускорит доступ к сайту,
; но добавит забот при смене адреса
www CNAME каноническое-имя-HTTP-сервера
; прочие сведения о домене (FTP и т.д.)
...
$ORIGIN company.ru.
При необходимости создать много одинаковых поддоменов (отдельный виртуальный www-сайт для каждого отдела) можно сделать общий include-файл с именем standard-www-server.include
; если мы хотим, чтобы к WWW-серверу можно было
; обратиться просто по имени домена
@ A адрес-HTTP-сервера
; кто-то должен обрабатывать почту, приходящую на наш домен
MX 5 каноническое-имя-почтового-сервера
MX 10 каноническое-имя-запасного-почтового-сервера
; указание адреса вместо синонима ускорит доступ к сайту,
; но добавит забот при смене адреса
www CNAME каноническое-имя-HTTP-сервера
; прочие сведения о домене (FTP и т.д.)
...
Теперь при необходимости создать поддомен для сайта очередного отдела достаточно добавить одну строку в наш файл, описывающий зону, company.ru.master и перезапустить сервер (rndc reload; не забудьте предварительно увеличить серийный номер в SOA!):
$INCLUDE standard-www-server.include otdelN.company.ru.
Предварительно необходимо настроить первичный и вторичные серверы, обслуживающие делегируемый поддомен, и убедиться, что они работают правильно. Вторичный и даже первичный сервер поддомена может совпадать с сервером базового домена.
Теперь в наш файл company.ru.master, описывающий базовую зону, добавляем строки, задающие первичный и вторичный серверы поддомена (здесь нет разницы между первичным и вторичным сервером):
superotdel NS каноническое-имя-сервера1-поддомена
NS каноническое-имя-сервера2-поддомена
Для каждого канонического имени сервера, лежащего внутри делегируемого поддомена, необходимо явно задать его адрес для того, чтобы избежать проблемы "курицы и яйца" (чтобы обратиться к серверу поддомена необходимо знать его адрес, а чтобы узнать его адрес необходимо обратиться к серверу домена и т.д.). Информация об адресе узла поддомена не принадлежит базовой зоне и называется связующими записями (glue records):
каноническое-имя-сервера1-поддомена A адрес-сервера1-поддомена каноническое-имя-сервера2-поддомена A адрес-сервера2-поддомена
Следует избегать лишних связующих записей (находящихся вне базовой зоны). В лучшем случае они будут проигнорированы. Необходимо следить за актуальностью связующих записей, иначе поддомен станет невидимым для внешнего мира.
При выделении небольшой подсети в ведение системного администратора филиала возникает задача делегирования ему прав администрирования небольшой части обратной зоны. Структура доменных имен обратной зоны не позволяет делегировать подзону из, например, 16 адресов так же легко и естественно, как в случае прямой зоны.
Первое решение. Не делегировать подзону и вести общую обратную зону самостоятельно.
Второе решение. На каждый IP адрес в своей зоне добавить NS запись (или несколько записей, если подзона будет иметь несколько уполномоченных серверов):
$ORIGIN 72.161.195.in-addr.arpa. 128 NS имя-сервера-филиала 129 NS имя-сервера-филиала ... 143 NS имя-сервера-филиала
Директива $GENERATE позволяет уменьшить объем записей до
$ORIGIN 72.161.195.in-addr.arpa. $GENERATE 128-143 $ NS имя-сервера-филиала
Файл /etc/named.conf сервера филиала должен иметь описание для каждой зоны вида:
zone "128.72.161.195.in-addr.arpa" {
type master;
file "128.72.161.195.in-addr.arpa.master";
}
zone "129.72.161.195.in-addr.arpa" {
type master;
file "129.72.161.195.in-addr.arpa.master";
}
...
zone "143.72.161.195.in-addr.arpa" {
type master;
file "143.72.161.195.in-addr.arpa.master";
}
При этом в каждом файле зоны 128.72.161.195.in-addr.arpa.master и остальных должна быть описана подзона для одного единственного адреса:
$TTL 86400 ; 1 day
@ IN SOA имя-сервера-филиала d-почтовый-адрес-администратора (
2004012201 1d 1h 1w 1h )
NS имя-сервера-филиала
PTR имя-хоста-с-адресом-195.161.72.128
Третье решение (RFC 2317, BCP 20). На каждый IP адрес в своей зоне добавить CNAME запись, указывающую на соответствующий адрес во вспомогательном домене и NS запись (или несколько записей) для вспомогательного домена:
$ORIGIN 72.161.195.in-addr.arpa. 128 CNAME 128.128-143 129 CNAME 129.128-143 ... 143 CNAME 143.128-143 128-143 NS имя-сервера-филиала
Директива $GENERATE позволяет уменьшить объем записей до
$ORIGIN 72.161.195.in-addr.arpa. $GENERATE 128-143 $ CNAME $.128-143 128-143 NS имя-сервера-филиала
Файл /etc/named.conf сервера филиала должен иметь описание зоны вида:
zone "128-143.72.161.195.in-addr.arpa" {
type master;
file "128-143.72.161.195.in-addr.arpa.master";
}
Файл зоны 128-143.72.161.195.in-addr.arpa.master при этом должен содержать записи PTR для соответствующего интервала адресов:
$TTL 86400 ; 1 day
@ IN SOA имя-сервера-филиала d-почтовый-адрес-администратора (
2004012201 1d 1h 1w 1h )
NS имя-сервера-филиала
128 PTR имя-хоста-с-адресом-195.161.72.128
129 PTR имя-хоста-с-адресом-195.161.72.129
...
143 PTR имя-хоста-с-адресом-195.161.72.143
Если необходимо обеспечить работу DNS в сети интернет, изолированной от Интернет, то надо создать файл named.own.root, описывающий "нашу" корневую зону на "основном" DNS сервере:
$TTL 1d
. IN SOA ns.company.ru. d-почтовый-адрес-администратора (
2004012201 1d 1h 1w 1h )
NS ns.company.ru.
; наш корневой сервер знает только о нашем домене и наших адресах
company.ru. NS ns.company.ru.
0.168.192.in-addr.arpa. NS ns.company.ru.
; адрес нашего корневого сервера
ns.company.ru. A 192.168.0.1
В /etc/named.conf необходимо заменить описание зоны корневых указателей (утверждение zone типа hint) на следующее:
zone "." {
type master;
file "named.own.root";
};
На остальных DNS серверах локальной сети необходимо заменить файл named.root следующим содержимым:
. 99999999 IN NS ns.company.ru. ns.company.ru. 99999999 IN A 192.168.0.1
Можно даже использовать файл named_dump.db, предусмотрительно созданный ранее с помощью rndc dumpdb, в качестве корневой зоны при временной потере доступа ко всем корневым серверам (например, в результате атаки хакеров на них или при падении основного канала связи, используемого для DNS запросов).
Для защиты от искажений и подделок ответов сервера, передачи зоны и обновлений зоны (update) поддерживается использование расширения TSIG протокола DNS. Для защиты обмена между каждой парой участников необходимо создать отдельный общий ключ. Имя ключа имеет синтаксис доменного имени. Секретное значение ключа записывается в кодировке Base64. Можно придумать его самостоятельно, но рекомендуется использовать случайную 128-битную последовательность, создаваемую утилитой dnssec-keygen:
dnssec-keygen -a HMAC-MD5 -b 128 -n HOST имя-ключа
В результате работы утилиты в текущей директории создаются файлы, содержащие публичный (файл с суффиксом .key) и частный (файл с суффиксом .private) ключи. Имена файлов образуются из основы (печатается утилитой на stdout) и соответствующего суффикса. Для такого симметричного алгоритма как HMAC-MD5 оба файла содержат эквивалентные значения ключа в различных форматах: последнее поле в файле .key и строка с заголовком "Key:" в файле .private.
Имя и значение ключа используется в утверждении key файла настройки bind для описания ключа.
Если при описании удалённого сервера в утверждении server использовать предложение keys, то наш сервер будет подписывать указанным ключом все направляемые данному серверу обычные запросы и запросы на передачу зоны, а также проверять, что ответ подписан (не обязательно тем же самым ключом).
Предложение allow-transfer утверждения zone с использованием ключа в ACL позволяет ограничивать передачу зоны только теми клиентами, кто использовал соответствующий ключ для подписи запроса.
Предложения allow-update и update-policy позволяют ограничить динамические обновления.
Содержимое файлов и их производных следует хранить в секрете от посторонних лиц (права доступа, передача по SSH). Не забудьте о синхронизации времени, по умолчанию подпись действительна в течении 300 секунд.
Расширение протокола DNS (динамические изменения зоны) позволяет клиентам отправлять запросы на изменение записей о ресурсах (RR) первичному уполномоченному серверу непосредственно или с помощью вторичного уполномоченного сервера (предложение allow-update-forwarding в утверждении options или zone). Авторы не рекомендуют использовать передачу изменений через вторичные сервера. Серийный номер в SOA увеличивается BIND 9.2.3 при каждом изменении.
Нельзя редактировать файл зоны вручную одновременно с использованием механизма динамических изменений. Динамические изменения записывается в отдельный журнал для каждой зоны (имя файла - имя зоны с добавлением суффикса .jnl). Журнал сливается с файлом зоны через какой-то (?) промежуток времени или при достижении максимального размера, задаваемого предложением max-journal-size в утверждении options или zone.
Сервер может проверять право клиента на изменение зоны по его IP адресу (не рекомендуется) или при помощи механизма TSIG - см. описание предложений allow-update и update-policy утверждения zone.
Утилита nsupdate позволяет сформировать пакет изменений и отослать его первичному уполномоченному серверу (имя сервера извлекается из SOA зоны). Пакет формируется на основе команд (см. описание динамических изменений), читаемых с stdin или из файла (имя файла задаётся в качестве параметра):
Ключи утилиты:
Установка bind 9.3.3 на CentOS 5.1 из пакетов внутри DMZ (2 канала, виды, slave) |
bind 9.3.3 в RHEL5/CentOS 5.1 разбит на пакеты:
Для примера рассмотрим установку сервера DNS в DMZ за сетевым экраном. Точнее говоря, перенос существующего DNS сервера с сетевого экрана внутрь DMZ. Необходимо учесть, что у меня 2 входных канала и необходимы специальные меры, чтобы ответ ушёл в правильный канал: на новом сервере для интервейса eth0 заведены два адреса (в понятиях ifconfig - eth0 и eth0:1). Пакеты с первым исходящим адресом шлюз переправляет в первый канал, со вторым - во второй. Для домена company.ru наш сервер является первичным сервером, для домена company.com - вторичным. Внешние клиенты обслуживаются по минимому: никаких рекурсий и запросов о чужих доменах. Внутренние клиенты получают любую информацию, кроме передачи полных зон. Вид нашей зоны для внутренних и внешних клиентов отличается (например, внешним клиентам не надо знать адрес нашего прокси-сервера).
Предварительно требуется установить пакеты bind и bind-chroot (всё в /var/named/chroot, включая /var/named/chroot/etc/named.conf) в дополнение к bind-libs и bind-utils и добавить в группу named администратора bind.
Описание локальной зоны в файле /var/named/chroot/var/named/localhost:
$TTL 1d
@ IN SOA @ noc.company.ru (
2007032901 1d 1h 1w 1h )
NS @
A 127.0.0.1
Описание обратной локальной зоны в файле /var/named/chroot/var/named/127.0.0.1:
$TTL 1d
@ IN SOA localhost. noc.company.ru (
2007032901 1d 1h 1w 1h )
NS localhost.
1 PTR localhost.
Описание зоны company.ru для внешнего потребления в файле /var/named/chroot/var/named/company.ru.external.master:
$TTL 1d @ IN SOA ns1 noc.company.ru ( 2007032901 1d 1h 1w 1h ) NS ns1 NS ns2 MX 10 mail1 MX 20 mail2 A адрес-www-сервера-для-чужих ; ns1 A исходящий-адрес-1 ns2 A исходящий-адрес-2 ; mail1 A исходящий-адрес-1 mail2 A исходящий-адрес-2 www A адрес-www-сервера-для-чужих
Описание зоны company.ru для внутреннего потребления в файле /var/named/chroot/var/named/company.ru.internal.master:
$TTL 1d @ IN SOA ns1 noc.company.ru ( 2007032901 1d 1h 1w 1h ) NS ns1 NS ns2 MX 10 mail1 MX 20 mail2 A адрес-www-сервера-для-своих ; ns1 A свой-адрес-1 ns2 A свой-адрес-1 ; $GENERATE 1-255 node$ A 192.168.0.$ mail A адрес-SMTP-сервера proxy A адрес-прокси-сервера inbox A адрес-POP/IMAP-сервера
Описание локальной обратной зоны 192.168.0.0/24 в файле /var/named/chroot/var/named/192.168.0.0.master:
$TTL 1d
@ IN SOA ns1.company.ru. noc.company.ru (
2007032901 1d 1h 1w 1h )
NS ns1.company.ru.
NS ns2.company.ru.
$GENERATE 1-255 $ PTR node$.company.ru.
Описание реальной обратной зоны 333.444.555.48/28 в файле /var/named/chroot/var/named/subnet-28.48.555.444.333.in-addr.arpa.master:
$TTL 1d
@ IN SOA ns1.company.ru. noc.company.ru (
2007032901 1d 1h 1w 1h )
NS ns1.company.ru.
NS ns2.company.ru.
NS ns1-провайдера
NS ns2-провайдера
$GENERATE 48-63 $ PTR enode$.company.ru.
Проверить синтаксис с помощью named-checkzone (очень слабая проверка):
named-checkzone -t /var/named/chroot company.ru. /var/named/company.ru.master
Конфигурация /var/named/chroot/etc/named.conf:
// от кого принимать запросы
acl "clients" {
127.0.0.1;
192.168.0.0/24;
...
};
// кому отдавать зону целиком и принимать извещения
// особо осторожные могут разбить по зонам
acl "siblings" {
адрес-вторичного-сервера;
};
options {
version "9.9.9";
directory "/var/named";
pid-file "/var/run/named/named.pid";
zone-statistics yes;
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
// query-source address * port 53;
query-source address свой-адрес-1;
notify-source свой-адрес-2;
};
logging {
channel debug_syslog {
syslog local1;
severity dynamic;
print-category yes;
};
category default { debug_syslog; };
channel lame-server {
file "/var/log/bind/lamers.log" versions 99 size 10M;
// для SELinux
// file "/var/named/data/lamers.log" versions 99 size 10M;
severity info;
print-time yes;
};
category lame-servers { lame-server; };
};
view internal {
match-clients { "clients"; };
allow-query { "clients"; "siblings"; };
allow-recursion { "clients"; };
// если нет внутренних вторичных серверов, иначе придётся разбивать по зонам
notify no;
allow-notify свой-адрес-2;
zone "localhost" IN {
type master;
file "localhost";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "127.0.0.1";
allow-update { none; };
};
zone "company.ru" IN {
type master;
file "company.ru.internal.master";
allow-query { any; };
allow-update { none; };
};
zone "company.com" IN {
type slave;
file "slaves/company.com";
masters { 555.555.555.555; свой-адрес-2; };
transfer-source свой-адрес-1;
allow-notify { свой-адрес-1; свой-адрес-2; };
allow-query { any; };
};
zone "0.168.192.in-addr.arpa" IN {
type master;
file "192.168.0.0.master";
allow-query { any; };
allow-update { none; };
};
zone "subnet-28.555.444.333.in-addr.arpa" {
type master;
file "subnet-28.48.555.444.333.in-addr.arpa.master";
allow-query { any; };
allow-update { none; };
};
};
view external {
allow-query { none; };
allow-recursion { none; };
allow-transfer { "siblings"; };
allow-notify { "siblings"; };
zone "company.ru" IN {
type master;
file "company.ru.external.master";
allow-query { any; };
allow-update { none; };
};
zone "company.com" IN {
type slave;
file "slaves/company.com";
masters { 555.555.555.555; };
transfer-source свой-адрес-2;
allow-transfer { "siblings"; свой-адрес-1; свой-адрес-2;};
allow-query { any; };
also-notify { свой-адрес-1; };
};
zone "subnet-28.555.444.333.in-addr.arpa" IN {
type master;
file "subnet-28.48.555.444.333.in-addr.arpa.master";
allow-query { any; };
allow-update { none; };
};
};
Проверить синтаксис с помощью named-checkconf -t /var/named/chroot.
Запускаем rndc-confgen и результат записываем в /var/named/chroot/etc/rndc.conf (проверить, что закрыт на чтение) и в /var/named/chroot/etc/named.conf (проверить, что закрыт на чтение).
Проверить синтаксис с помощью named-checkconf -t /var/named/chroot.
Тестовый запуск:
service named start
Заглядываем в журнал syslog, чтобы убедиться что все хорошо.
Проверяем работу rndc:
service named status
не работает, так как надо
rndc -c /var/named/chroot/etc/rndc.conf status
Правим /etc/rc.d/init.d/named.
Попробуем найти локальный адрес:
host 127.0.0.1 127.0.0.1
Попробуем найти реальный адрес:
host ya.ru 127.0.0.1
Открываем локальный сетевой экран.
Попробуем найти локальный и реальный адрес с соседнего компьютера:
host 127.0.0.1 адрес-сервера
host ya.ru адрес-сервера
Попытка передачи зоны (host -l) с произвольного компьютера изнутри (должна быть отвергнута).
Тестирование доступа снаружи:
Перевести локальные компьютеры на использование нового сервера (DHCP и статика отдельно).
Пробрасывать на входном сетевом экране порт 53 вместо временного 9953.
Остановить старый сервер.
Автоматический запуск сервера:
chkconfig --level 2345 named on
Тестирование изменения зоны, для которой наш сервер является первичным - получают ли вторичные сервера извещения и могут ли копировать зону.
Тестирование изменения зоны, для которой наш сервер является вторичных - получает ли наш сервер извещения, может ли скопировать зону и передать её в вид internal.
Установка bind 9.3.3 на CentOS 5.0 из пакетов в изолированной сети |
bind 9.3.3 в RHEL5/CentOS 5 разбит на пакеты:
Для примера рассмотрим установку сервера DNS в изолированной сети. Предварительно требуется установить пакет bind и bind-chroot в дополнение к bind-libs и bind-utils на сервер и добавить в группу named администратора bind.
Описание "нашей корневой зоны" в /var/named/chroot/var/named/named.own.root на первичном сервере
$TTL 1d
. IN SOA ns.company.ru. noc.company.ru (
2007061301 1d 1h 1w 1h )
NS ns.company.ru.
company.ru. NS ns.company.ru.
0.168.192.in-addr.arpa. NS ns.company.ru.
ns.company.ru. A 192.168.0.1
Описание локальной зоны в файле /var/named/chroot/var/named/localhost:
$TTL 1d
@ IN SOA @ noc.company.ru (
2007061301 1d 1h 1w 1h )
NS @
A 127.0.0.1
Описание обратной локальной зоны в файле /var/named/chroot/var/named/127.0.0.1:
$TTL 1d
@ IN SOA localhost. noc.company.ru (
2007061301 1d 1h 1w 1h )
NS localhost.
1 PTR localhost.
Описание зоны company.ru в файле /var/named/chroot/var/named/company.ru.master на первичном сервере:
$TTL 1d @ IN SOA ns noc.company.ru ( 2007061301 1d 1h 1w 1h ) NS ns MX 10 mail A 192.168.0.1 ; ns A 192.168.0.1 ; $GENERATE 1-255 node$ A 192.168.0.$ mail A 192.168.0.3
Описание обратной зоны 192.168.0.0/24 в файле /var/named/chroot/var/named/192.168.0.0.master:
$TTL 1d
@ IN SOA ns.company.ru. noc.company.ru (
2007032901 1d 1h 1w 1h )
NS ns.company.ru.
$GENERATE 1-255 $ PTR node$.company.ru.
Проверить синтаксис с помощью named-checkzone:
named-checkzone -t /var/named/chroot . /var/named/named.own.root ...
Cоздать каталог /var/named/chroot/var/log/bind
с правами 755 для named:named
(SELinux против - хочет контекст named_cache_t)
[Создать каталог /var/named/data с правами на запись для named.]
[Создать каталог /var/named/slaves с правами на запись для named на вторичном сервере.]
Конфигурация /var/named/chroot/etc/named.conf для первичного сервера:
acl "clients" {
127.0.0.1;
192.168.0.0/24;
...
};
acl "siblings" {
192.168.0.2;
};
options {
version "9.9.9";
directory "/var/named";
pid-file "/var/run/named/named.pid";
zone-statistics yes;
allow-query { "clients"; };
allow-recursion { "clients"; };
allow-transfer { "siblings"; };
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
};
logging {
channel debug_syslog {
syslog local1;
severity dynamic;
print-category yes;
};
category default { debug_syslog; };
channel lame-server {
file "/var/log/bind/lamers.log" versions 99 size 10M;
severity info;
print-time yes;
};
category lame-servers { lame-server; };
};
zone "." {
type master;
file "named.own.root";
};
zone "localhost" {
type master;
file "localhost";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.1";
};
zone "company.ru" {
type master;
file "company.ru.master";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "192.168.0.0.master";
};
Проверить синтаксис с помощью named-checkconf (не все ошибки ловятся).
Запускаем rndc-confgen и результат записываем в /etc/rndc.conf (проверить, что закрыт на чтение) и в /var/named/chroot/etc/named.conf (проверить, что права 640 для root:named).
Тестовый запуск:
service named start
Заглядываем в журнал syslog, чтобы убедиться что все хорошо.
Проверяем работу rndc:
service named status
Попробуем найти локальный адрес:
host 127.0.0.1 127.0.0.1
Попробуем найти реальный адрес:
host node111.company.ru 127.0.0.1
Открываем локальный сетевой экран на первичном сервере.
Попробуем найти локальный адрес с соседнего компьютера:
host 127.0.0.1 адрес-сервера
Попытка передачи зоны (host -l) с будущего вторичного сервера и с произвольного компьютера (должна быть отвергнута).
Автоматический запуск сервера:
chkconfig --level 2345 named on
Конфигурация /var/named/chroot/etc/named.conf для вторичного сервера:
acl "clients" {
127.0.0.1;
192.168.0.0/24;
...
};
acl "siblings" {
192.168.0.1;
};
options {
version "9.9.9";
directory "/var/named";
pid-file "/var/run/named/named.pid";
zone-statistics yes;
allow-query { "clients"; };
allow-recursion { "clients"; };
allow-transfer { "siblings"; };
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
};
logging {
channel debug_syslog {
syslog local1;
severity dynamic;
print-category yes;
};
category default { debug_syslog; };
channel lame-server {
file "/var/log/bind/lamers.log" versions 99 size 10M;
severity info;
print-time yes;
};
category lame-servers { lame-server; };
};
zone "." {
type slave;
file "slaves/named.own.root";
masters { 192.168.0.1; };
};
zone "localhost" {
type master;
file "localhost";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.1";
};
zone "company.ru" {
type slave;
file "slaves/company.ru";
masters { 192.168.0.1; };
};
zone "0.168.192.in-addr.arpa" {
type slave;
file "slaves/192.168.0.0";
masters { 192.168.0.1; };
};
Проверить синтаксис с помощью named-checkconf -t /var/named/chroot.
Запускаем rndc-confgen и результат записываем в /var/named/chroot/etc/rndc.conf (проверить, что закрыт на чтение), ссылку в /etc/rndc.conf и в /var/named/chroot/etc/named.conf (проверить, что закрыт на чтение).
Открываем локальный сетевой экран на вторичном сервере.
Тестовый запуск:
service named start
Заглядываем в журнал syslog, чтобы убедиться что все хорошо в файлы зон *.slave.
Проверяем работу rndc:
service named status
Попробуем найти локальный адрес:
host 127.0.0.1 127.0.0.1
Попробуем найти реальный адрес:
host node111.company.ru 127.0.0.1
Попробуем найти локальный адрес с соседнего компьютера:
host 127.0.0.1 адрес-сервера
Попытка передачи зоны (host -l) с первичного сервера и с произвольного компьютера (должна быть отвергнута).
Автоматический запуск сервера:
chkconfig --level 2345 named on
Настройки /etc/resolv.conf на всех участниках.
Настройка DHCP для раздачи адресов клиентам.
Установка bind 9.2.4 на CentOS 4.4 из пакетов в изолированной сети |
bind 9.2.4 в RHEL4.4/CentOS 4.4 разбит на пакеты:
Для примера рассмотрим установку двух серверов DNS в изолированной сети. Предварительно требуется установить пакет bind в дополнение к bind-libs и bind-utils на оба сервера (bind-chroot не используем в изолированной сети) и добавить в группу named администратора bind.
Описание "нашей корневой зоны" в /var/named/named.own.root на первичном сервере
$TTL 1d
. IN SOA ns.company.ru. noc.company.ru (
2007032901 1d 1h 1w 1h )
NS ns.company.ru.
NS ns2.company.ru.
company.ru. NS ns.company.ru.
NS ns2.company.ru.
0.168.192.in-addr.arpa. NS ns.company.ru.
NS ns2.company.ru.
ns.company.ru. A 192.168.0.1
ns2.company.ru. A 192.168.0.2
Описание локальной зоны в файле /var/named/localhost на обоих серверах:
$TTL 1d
@ IN SOA @ noc.company.ru (
2007032901 1d 1h 1w 1h )
NS @
A 127.0.0.1
Описание обратной локальной зоны в файле /var/named/127.0.0.1 на обоих серверах:
$TTL 1d
@ IN SOA localhost. noc.company.ru (
2007032901 1d 1h 1w 1h )
NS localhost.
1 PTR localhost.
Описание зоны company.ru в файле /var/named/company.ru.master на первичном сервере:
$TTL 1d @ IN SOA ns noc.company.ru ( 2007032901 1d 1h 1w 1h ) NS ns NS ns2 MX 10 mail A 192.168.0.1 ; ns A 192.168.0.1 ns2 A 192.168.0.2 ; $GENERATE 1-255 node$ A 192.168.0.$ mail A 192.168.0.3
Описание обратной зоны 192.168.0.0/24 в файле /var/named/192.168.0.0.master на первичном сервере:
$TTL 1d
@ IN SOA ns.company.ru. noc.company.ru (
2007032901 1d 1h 1w 1h )
NS ns.company.ru.
NS ns2.company.ru.
$GENERATE 1-255 $ PTR node$.company.ru.
Проверить синтаксис с помощью named-checkzone.
Cоздать каталог /var/log/bind с правами 755 для named:named на обоих серверах. Создать каталог /var/named/data с правами на запись для named на обоих серверах. Создать каталог /var/named/slaves с правами на запись для named на вторичном сервере.
Конфигурация /etc/named.conf для первичного сервера:
acl "clients" {
127.0.0.1;
192.168.0.0/24;
...
};
acl "siblings" {
192.168.0.2;
};
options {
version "9.9.9";
directory "/var/named";
pid-file "/var/run/named/named.pid";
zone-statistics yes;
allow-query { "clients"; };
allow-recursion { "clients"; };
allow-transfer { "siblings"; };
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
};
logging {
channel debug_syslog {
syslog local1;
severity dynamic;
print-category yes;
};
category default { debug_syslog; };
channel lame-server {
file "/var/log/bind/lamers.log" versions 99 size 10M;
severity info;
print-time yes;
};
category lame-servers { lame-server; };
};
zone "." {
type master;
file "named.own.root";
};
zone "localhost" {
type master;
file "localhost";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.1";
};
zone "company.ru" {
type master;
file "company.ru.master";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "192.168.0.0.master";
};
Проверить синтаксис с помощью named-checkconf.
Запускаем rndc-confgen и результат записываем в /etc/rndc.conf (проверить, что закрыт на чтение) и в /etc/named.conf (проверить, что закрыт на чтение).
Открываем локальный сетевой экран на первичном сервере.
Тестовый запуск:
service named start
Заглядываем в журнал syslog, чтобы убедиться что все хорошо.
Проверяем работу rndc:
service named status
Попробуем найти локальный адрес:
host 127.0.0.1 127.0.0.1
Попробуем найти реальный адрес:
host node111.company.ru 127.0.0.1
Попробуем найти локальный адрес с соседнего компьютера:
host 127.0.0.1 адрес-сервера
Попытка передачи зоны (host -l) с будущего вторичного сервера и с произвольного компьютера (должна быть отвергнута).
Автоматический запуск сервера:
chkconfig --level 2345 named on
Конфигурация /etc/named.conf для вторичного сервера:
acl "clients" {
127.0.0.1;
192.168.0.0/24;
...
};
acl "siblings" {
192.168.0.1;
};
options {
version "9.9.9";
directory "/var/named";
pid-file "/var/run/named/named.pid";
zone-statistics yes;
allow-query { "clients"; };
allow-recursion { "clients"; };
allow-transfer { "siblings"; };
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
};
logging {
channel debug_syslog {
syslog local1;
severity dynamic;
print-category yes;
};
category default { debug_syslog; };
channel lame-server {
file "/var/log/bind/lamers.log" versions 99 size 10M;
severity info;
print-time yes;
};
category lame-servers { lame-server; };
};
zone "." {
type slave;
file "slaves/named.own.root";
masters { 192.168.0.1; };
};
zone "localhost" {
type master;
file "localhost";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.1";
};
zone "company.ru" {
type slave;
file "slaves/company.ru";
masters { 192.168.0.1; };
};
zone "0.168.192.in-addr.arpa" {
type slave;
file "slaves/192.168.0.0";
masters { 192.168.0.1; };
};
Проверить синтаксис с помощью named-checkconf.
Запускаем rndc-confgen и результат записываем в /etc/rndc.conf (проверить, что закрыт на чтение) и в /etc/named.conf (проверить, что закрыт на чтение).
Открываем локальный сетевой экран на вторичном сервере.
Тестовый запуск:
service named start
Заглядываем в журнал syslog, чтобы убедиться что все хорошо в файлы зон *.slave.
Проверяем работу rndc:
service named status
Попробуем найти локальный адрес:
host 127.0.0.1 127.0.0.1
Попробуем найти реальный адрес:
host node111.company.ru 127.0.0.1
Попробуем найти локальный адрес с соседнего компьютера:
host 127.0.0.1 адрес-сервера
Попытка передачи зоны (host -l) с первичного сервера и с произвольного компьютера (должна быть отвергнута).
Автоматический запуск сервера:
chkconfig --level 2345 named on
Настройка DHCP для раздачи адресов клиентам.
bind 9.2.4 в RHEL4.4/CentOS 4.4 разбит на пакеты:
Для примера рассмотрим установку сервера DNS в DMZ с обеспечением различных видов для внешних и внутренних клиентов. Предварительно требуется установить пакеты bind и bind-chroot (всё в /var/named/chroot, включая /var/named/chroot/etc/named.conf) в дополнение к bind-libs и bind-utils и добавить в группу named администратора bind.
Описание локальной зоны в файле /var/named/chroot/var/named/localhost:
$TTL 1d
@ IN SOA @ noc.company.ru (
2007032901 1d 1h 1w 1h )
NS @
A 127.0.0.1
Описание обратной локальной зоны в файле /var/named/chroot/var/named/127.0.0.1:
$TTL 1d
@ IN SOA localhost. noc.company.ru (
2007032901 1d 1h 1w 1h )
NS localhost.
1 PTR localhost.
Описание зоны company.ru в файле /var/named/chroot/var/named/company.ru.master:
$TTL 1d @ IN SOA ns noc.company.ru ( 2007032901 1d 1h 1w 1h ) NS ns NS ns2 MX 10 mail A 192.168.0.1 ; ns A 192.168.0.1 ns2 A 192.168.0.2 ; $GENERATE 1-255 node$ A 192.168.0.$ mail A 192.168.0.3
Описание обратной зоны 192.168.0.0/24 в файле /var/named/chroot/var/named/192.168.0.0.master:
$TTL 1d
@ IN SOA ns.company.ru. noc.company.ru (
2007032901 1d 1h 1w 1h )
NS ns.company.ru.
NS ns2.company.ru.
$GENERATE 1-255 $ PTR node$.company.ru.
Cоздать каталог /var/named/chroot/var/log/bind с правами 755 для named:named.
Конфигурация /var/named/chroot/etc/named.conf:
acl "clients" {
127.0.0.1;
192.168.0.0/24;
...
};
acl "siblings" {
555.555.555.555;
};
options {
version "9.9.9";
directory "/var/named";
pid-file "/var/run/named/named.pid";
zone-statistics yes;
allow-query { "clients"; };
allow-recursion { "clients"; };
allow-transfer { "siblings"; };
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
};
logging {
channel debug_syslog {
syslog local1;
severity dynamic;
print-category yes;
};
category default { debug_syslog; };
channel lame-server {
file "/var/log/bind/lamers.log" versions 99 size 10M;
severity info;
print-time yes;
};
category lame-servers { lame-server; };
};
zone "localhost" {
type master;
file "localhost";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0.1";
allow-update { none; };
};
// zone "company.ru" {
// type master;
// file "company.ru.master";
// allow-query { any; };
//};
zone "0.168.192.in-addr.arpa" {
type master;
file "192.168.0.0.master";
};
Проверить синтаксис с помощью named-checkconf -t /var/named/chroot.
Запускаем rndc-confgen и результат записываем в /var/named/chroot/etc/rndc.conf (проверить, что закрыт на чтение) и в /var/named/chroot/etc/named.conf (проверить, что закрыт на чтение).
Проверить синтаксис с помощью named-checkconf -t /var/named/chroot.
Тестовый запуск:
service named start
Заглядываем в журнал syslog, чтобы убедиться что все хорошо.
Проверяем работу rndc:
service named status
не работает, так как надо
rndc -c /var/named/chroot/etc/rndc.conf status
Правим /etc/rc.d/init.d/named.
Попробуем найти локальный адрес:
host 127.0.0.1 127.0.0.1
Попробуем найти реальный адрес:
host ya.ru 127.0.0.1
Открываем локальный сетевой экран.
Попробуем найти локальный адрес с соседнего компьютера:
host 127.0.0.1 адрес-сервера
Попытка передачи зоны (host -l) с будущего вторичного сервера и с произвольного компьютера (должна быть отвергнута).
Автоматический запуск сервера:
chkconfig --level 2345 named on
Установка сервера под Red Hat Linux 7.2 (клиент оставлен стандартный):
|
Bog BOS: DNS сервер BIND |
|
Последние изменения: |