Freebsd dns server настройка
DHCP, или Dynamic Host Configuration Protocol (Протокол Динамической Конфигурации Хостов), описывает порядок, по которому система может подключиться к сети и получить необходимую информацию для работы в ней. Во FreeBSD используется реализация DHCP от ISC (Internet Software Consortium), так что вся информация, описывающая особенности, зависящие от реализации, относится к дистрибутиву ISC.
В этом разделе делается попытка описать только те части системы DHCP, которые интегрированы с FreeBSD; таким образом, серверная часть не описывается. Справочные страницы по DHCP, кроме ссылок, дающихся ниже, будут вам весьма полезны.
Когда на клиентской машине выполняется программа dhclient , являющаяся клиентом DHCP, она начинает широковещательную рассылку запросов на получение настроечной информации. По умолчанию эти запросы делаются на 68 порт UDP. Сервер отвечает на UDP 67, выдавая клиенту адрес IP и другую необходимую информацию, такую, как сетевую маску, маршрутизатор и серверы DNS. Вся эта информация даётся в форме "аренды" DHCP и верна только определенное время (что настраивается администратором сервера DHCP). При таком подходе устаревшие адреса IP тех клиентов, которые больше не подключены к сети, могут автоматически использоваться повторно.
Клиенты DHCP могут получить от сервера очень много информации. Подробный список находится в странице Справочника dhcp-options (5) .
Клиент DHCP от ISC, dhclient , полностью интегрирован во FreeBSD. Поддержка клиента DHCP есть как в программе установки, так и в самой системе, что исключает необходимость в знании подробностей конфигурации сети в любой сети, имеющей сервер DHCP. Утилита dhclient включена во все версии FreeBSD, начиная с 3.2.
DHCP поддерживается утилитой sysinstall . При настройке сетевого интерфейса из программы sysinstall первый вопрос, который вам задается, это "Do you want to try DHCP configuration of this interface?" ( "Хотите ли вы попробовать настроить этот интерфейс через DHCP?" ). Утвердительный ответ приведёт к запуску программы dhclient , и при удачном его выполнении к автоматическому заданию информации для настройки интерфейса.
Есть две вещи, которые вы должны сделать для того, чтобы ваша система использовала DHCP при загрузке:
Убедитесь, что устройство bpf включено в компиляцию вашего ядра. Чтобы это сделать, добавьте строчку pseudo-device bpf в конфигурационный файл ядра и перестройте ядро. Более подробная информация о построении ядер имеется в разделе Chapter 9 .
Устройство bpf уже является частью ядра GENERIC , которое поставляется вместе с FreeBSD, так что, если вы не используете другое ядро, то вам и не нужно его делать для того, чтобы работал DHCP.
Note: Те, кто беспокоится о безопасности, должны иметь в виду, что устройство bpf является также тем самым устройством, которое позволяет работать программам-снифферам пакетов (хотя для этого они должны быть запущены пользователем root ). Наличие устройства bpf необходимо для использования DHCP, но если вы чересчур беспокоитесь о безопасности, то вам нельзя добавлять устройство bpf в ядро только для того, чтобы в неопределённом будущем использовать DHCP.
Отредактируйте ваш файл /etc/rc.conf , включив в него следующее:
Note: Обязательно замените fxp0 именем интерфейса, который вы хотите настроить динамически.
Если dhclient в вашей системе находится в другом месте или если вы хотите задать дополнительные параметры для dhclient , то также укажите следующее (изменив так, как вам нужно):
dhclient требует наличия конфигурационного файла, /etc/dhclient.conf . Как правило, файл содержит только комментарии, а настройки по умолчанию достаточно хороши. Этот настроечный файл описан на страницах справочной системы по dhclient.conf (5) .
dhclient скомпонован статически и находится в каталоге /sbin . На страница Справочника dhclient (8) дается более подробная информация о dhclient .
dhclient-script является специфичным для FreeBSD скриптом настройки клиента DHCP. Он описан в dhclient-script (8) , но для нормального функционирования никаких модификаций со стороны пользователя не требуется.
В этом файле клиент DHCP хранит базу данных выданных к использованию адресов в виде журнала. На странице dhclient.leases (5) дается гораздо более подробное описание.
Этот раздел даёт информацию о том, как настроить систему FreeBSD для работы в качестве сервера DHCP на основе реализации пакета DHCP от ISC (Internet Software Consortium).
Для того, чтобы настроить систему FreeBSD на работу в качестве сервера DHCP, вам необходимо обеспечить присутствие устройства bpf (4) , вкомпилированного в ядро. Для этого добавьте строку pseudo-device bpf в файл конфигурации вашего ядра. Для получения более полной информации о построении ядер, обратитесь к Chapter 9 .
Устройство bpf уже входит в состав ядра GENERIC , поставляемого с FreeBSD, так что вам не нужно создавать собственное ядро для обеспечения работы DHCP.
Note: Те, кто обращает особое внимание на вопросы безопасности, должны заметить, что bpf является тем устройством, что позволяет нормально работать снифферам пакетов (хотя таким программам требуются привилегированный доступ). Наличие устройства bpf обязательно для использования DHCP, но если вы очень обеспокоены безопасностью, наверное, вам не нужно включать bpf в ваше ядро только потому, что в отдалённом будущем вы собираетесь использовать DHCP.
dhcpd.conf состоит из деклараций относительно подсетей и хостов, и проще всего описывается на примере:
Как только вы закончите составлять свой dhcpd.conf , вы можете продолжить работу запуском сервера при помощи следующей команды:
Если в будущем вам понадобится сделать изменения в настройке вашего сервера, то важно заметить, что посылка сигнала SIGHUP приложению dhcpd не приведёт к перезагрузке настроек, как это бывает для большинства даемонов. Вам нужно послать сигнал SIGTERM для остановки процесса, а затем перезапустить его при помощи вышеприведённой команды.
dhcpd требует наличия конфигурационного файла, /usr/local/etc/dhcpd.conf , до того, как он будет запущен и начнёт предоставлять сервис клиентам. Необходимо, чтобы этот файл содержал все данные, которая будет выдаваться обслуживаемым клиентам, а также информацию о работе сервера. Этот конфигурационный файл описывается на страницах справочной системы dhcpd.conf(5), которые устанавливаются портом.
dhcrelay используется в сложных ситуациях, когда сервер DHCP пересылает запросы от клиента другому серверу DHCP в отдельной сети. На страницах справочной системы dhcrelay(8), которые устанавливаются с портом, даётся более полное описание.
Довольно часто возникает вопрос о внедрении своего ДНС сервера, который мог бы не только обслуживать запросы внешних пользователей к приобретенным ДНС именам, но и обслуживать запросы пользователей в локальной сети. Такая задача относительно просто решается средствами ОС FreeBSD.
Настроить DNS сервер Bind под управлением FreeBSD для обслуживания запросов клиентов внутренней сети и обслуживания прямой и обратной зон DNS с функцией их пересылки на вторичный DNS сервер. Тип всех зон на сервере — Master, то есть данный сервер предоставляет авторитетные ответы за все зоны.
1. Внутренний IP адрес DNS сервера — 192.168.0.1/24
2. Внешний IP адрес DNS сервера — 10.10.10.1/24
3. IP адрес вторичного сервера — 10.10.10.2/24
4. Прямая DNS зона — test.dom
5. Обратная DNS зона — 10.10.10.in-addr.arpa
1. В файле /etc/rc.conf прописываем запуск DNS сервера при старте системы
2. Приводим конфигурационный файл /etc/namedb/named.conf к следующему виду:
options directory "/etc/namedb";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
listen-on < 127.0.0.1; 10.10.10.1; >;
allow-recursion < ACCESS; >;
allow-transfer < 10.10.10.2; >;
transfer-source 10.10.10.1;
version "Bind DNS Server";
>;
logging category lame-servers < null; >;
>;
zone "." type hint;
file "named.root";
>;
zone "localhost" type master;
file "master/localhost";
>;
zone "0.0.127.in-addr.arpa" type master;
file "master/0.0.127.in-addr.arpa";
>;
zone "test.dom" type master;
file "master/test.dom";
allow-query < any; >;
>;
zone "10.10.10.in-addr.arpa" type master;
file "master/10.10.10.in-addr.arpa";
allow-query < any; >;
>;
acl — список доступа с именем ACCESS и описанием в нем сетей, которым разрешено использовать наш DNS сервер.
directory – Рабочая директория Bind
pid-file — Место размещения PID файла
dump-file – Место размещения DUMP файла
statistics-file – Место размещения файла статистики
listen-on – Указываем IP адреса интерфейсов, на которых Bind будет «слушать» запросы
allow-recursion – Указываем списки доступа, кому разрешены рекурсивные запросы к серверу
allow-transfer – Указываем IP адрес вторичного DNS сервера, которому будем пересылать наши зоны
transfer-source – Указываем IP интерфейса, через который будет разрешено проведение трансфера зон
version – Указываем свою версию DNS сервера
logging – Указываем ограничение журналирования
zone "." — Зона, описывающая корневые DNS сервера, необходима для работы. Хранится в файле /etc/namedb/named.root
zone «localhost» — Прямая зона, описывающая локальный сервер, необходима для работы. Хранится в файле /etc/namedb/master/localhost
zone «0.0.127.in-addr.arpa» — Обратная зона, описывающая локальный сервер, необходима для работы. Хранится в файле /etc/namedb/master/0.0.127.in-addr.arpa
zone «test.dom» — Наша прямая зона. Хранится в файле /etc/namedb/master/test.dom Так как на нашем сервере хранится мастер копия зоны, при помощи allow-query, разрешаем всем ее опрос.
zone «10.10.10.in-addr.arpa» — наша обратная зона. Хранится в файле /etc/namedb/master/10.10.10.in-addr.arpa. Так как на нашем сервере хранится мастер копия зоны, при помощи allow-query, разрешаем всем ее опрос.
3. Настраиваем файлы зон
3.1. Зона "." — оставляем по умолчанию
3.2. Зона «localhost». Конфигурационный файл /etc/namedb/master/localhost приводим к следующему виду:
@ IN SOA localhost. root.localhost. (
2009070601 ; Serial
3600 ; Refresh
600 ; Retry
2419200 ; Expire
86400 ) ; Minimum
IN NS localhost.
3.3. Зона «0.0.127.in-addr.arpa». Конфигурационный файл /etc/namedb/master/0.0.127.in-addr.arpa приводим к следующему виду:
@ IN SOA localhost. root.localhost. (
2009070601 ; Serial
3600 ; Refresh
600 ; Retry
2419200 ; Expire
86400 ) ; Minimum
IN NS localhost.
1 IN PTR localhost.
3.4. Зона «test.dom». Конфигурационный файл /etc/namedb/master/test.dom приводим к следующему виду:
$TTL 3600
@ IN SOA ns1.test.dom. hostmaster.test.dom. (
2009082801 ; Serial
3600 ; Refresh
600 ; Retry
2419200 ; Expire
86400 ) ; Minimum
IN NS ns1.test.dom.
IN NS ns2.test.dom.
ns1 IN A 10.10.10.1
ns2 IN A 10.10.10.2
3.5. Зона «10.10.10.in-addr.arpa». Конфигурационный файл /etc/namedb/master/10.10.10.in-addr.arpa приводим к следующему виду:
$TTL 3600
@ IN SOA ns1.test.dom. hostmaster.test.dom. (
2009082801 ; Serial
3600 ; Refresh
600 ; Retry
2419200 ; Expire
86400 ) ; Minimum
IN NS ns1.test.dom.
IN NS ns2.test.dom.
1 IN PTR ns1.test.dom.
2 IN PTR ns2.test.dom.
Где, например, для зоны test.dom сверху вниз:
— Время, указывающее длительность в секундах, сколько запись должна быть сохранена в кеше.
— @ — имя зоны — заменяющий символ, IN – класс записи INTERNET — значение по умолчанию, SOA – описание глобальных переменных зоны, ns1.test.dom. — имя DNS сервера для этой зоны, hostmaster.test.dom. — почтовый адрес администратора DNS сервера для этой зоны. Вместо знака @, в качестве разделителя используется знак «.»
— Серийный номер изменения записи. Для перечитывания зоны вторичным сервером, при каждом изменении, необходимо последнюю цифру увеличивать на 1
— Время через которое вторичный DNS сервер попытается перечитать зону
— Время через, которое вторичный сервер будет пытаться перечитать зону если ему не удалось связаться с первичным DNS сервером в период указанный в Refresh
— Указывает через какое время данные зоны больше не авторитетны для этого сервера. Используется вторичными серверами.
— Устаревший атрибут, указывающий на время жизни сохранения данных зоны в кеше.
— Указание DNS основного DNS сервера для данной зоны
— Указание вторичного DNS сервера для данной зоны
— Описание узлов в данной зоне
4. Управляем DNS сервером при помощи следующих команд:
Дополнительно:
Наиболее часто используемые типы записей в DNS:
A – запись на IP адрес узла в сети
NS — запись на DNS сервер
CNAME – запись на каноническое имя для узла
PTR – запись указатель на доменное имя, используется в обратных зонах
MX — запись для определения маршрутизации почты
Для проверки работоспособности можно использовать такие средства как dig или nslookup
Пример использования dig:
Команда означает — вывести записи типа ANY в зоне test.dom, используя сервер localhost
; > DiG 9.4.3-P2 > @localhost test.dom ANY
; (2 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 2
;; QUESTION SECTION:
;test.dom. IN ANY
;; ANSWER SECTION:
test.dom. 3600 IN A 10.10.10.1
test.dom. 3600 IN SOA ns1.test.dom. hostmaster.test.dom. 2009082801 3600 600 2419200 86400
test.dom. 3600 IN NS ns1.test.dom.
test.dom. 3600 IN NS ns2.test.dom.
;; ADDITIONAL SECTION:
ns1.test.dom. 3600 IN A 10.10.10.1
ns2.test.dom. 54886 IN A 10.10.10.2
Пример использования nslookup:
Name: test.dom
Address: 10.10.10.1
>
На мой взгляд использование dig для диагностики более гибко, хотя те кто знает полностью как использовать nslookup, скажут то же самое про него. Также рекомендую замечательное пособие по настройке DNS.
Что такое и для чего OpenDNSSEC есть информация в сети. Подробной информации на эту тему немного и в основном на английском. Попробую восполнить пробел. Сам не являюсь специалистом в этой области, было интересно, захотел, сделал.
Статья писалась одновременно с установкой/настройкой OpenDNSSEC. В общей сумме ушло около месяца. Процедура выполнялась дважды. Сначала был установлен OpenDNSSEC 1.3. Зоны подписаны, якоря у регистратора домена(РД) прописаны, цепочка доверия выстроена, о чём сообщалось в личном кабинете регистратора домена(РД), в общем всё получилось. Спустя полгода, в результате очередного ручного обновления портов, порт OpenDNSSEC 1.3.x был автоматически обновлён на 1.4.1, а там много чего по другому. Но всё, разумеется, продолжало работать без каких-либо намёков на проблему. Обнаружил случайно, когда в DNS зону потребовалось внести изменения. И началось…
Предполагаем, что NSD DNS сервер настроен, несколько лет работает, всё в порядке.
Версию 1.4 долго не получалось настроить, не появлялись ключи, зоны не подписывались. Пакет устанавливался с поддержкой MySql55. На официальном сайте, при перечислении официально поддерживаемых OS для 1.4 была заявлена FreeBSD 9.0. Вряд ли в этом была причина(причина и была не в этом), но на всякий обновился с FreeBSD 8.2 до 9.1. От незнания нюансов даже предположил, что мешала уже выстроенная цепочка доверия. Поэтому в личном кабинете РД разорвал цепочку доверия. И настроил NSD на работу с неподписанными зонами. Пробовать конвертировать существующую базу SQLite2 в SQLite3 не стал. Решено было всё заново сделать и использовать MySql55, как было рекомендовано.
Забегая вперёд: c MySql OpenDNSSEC настроить не удалось. Точно выяснил, что проблема связана с базой данных, или с взаимодействием между базой данных и OpenDNSSEC. OpenDNSSEC может работать как с SQLite, так и с MySql. Вернулся на SQLite3 там всё пошло сразу и без вопросов. На официальном сайте SQLite3 рекомендуется только для тестовых применений. Предположу, что MySql рекомендуется, если файлов зон и записей в них много, тысячи. Для случая тестового сервера решил использовать SQLite. Таким образом, всё нижеописанное, относящееся к MySql не используем. Но на всякий эту информацию оставил. Ниже приводится схематичная картинка, описывающая происходящее. Картинка взята с официального сайта документации OpenDNSSEC.
Вторичные сервера DNS не требуют над собой никаких действий, однако нужно убедиться, что вторичный сервер также поддерживает DNSSEC. У РД, у которого в своё время было заказано два вторичных DNS, всё поддерживается.
Предусмотрено 2 пары ключей:
Первая пара – ZSK используется для подписи зонного файла.
Вторая пара – KSK используется для подписи ключа ZSK и формирования DS-записей, которые передаются администратору родительской зоны (в текущем случае РД). Менять KSK рекомендуется раз в год, ZSK вплоть до раза в месяц.
Перекликается установка как 1.3, так и 1.4 версии OpenDNSSEC. При использовании SQLite2 и 3 баз данных проблем не было. С MySql55 настроить не получилось. После того, как всё заработало с SQLite3, поиск причин, почему же возникли проблемы с MySql, был отложен до следующего раза. Повторюсь, SQLite рекомендуется только для тестирования.
Привожу всё, как было, поэтому сначала желательно посмотреть, чем закончилось, а потом повторять. Да, при установке только OpenDNSSEC 1.4.1 статья получилась бы раза в два короче. Но считаю, что избыточность информации лучше поможет разобраться, если возникнут нюансы. Как говориться, подарок рерайтерам. Если у Вас автоматически было обновление OpenDNSSEC со старой до 1.4.1 версии, то желательно OpenDNSSEC перенести в резервную папку и заново установить. Файлы конфигураций будут отличаться. А старые новыми, по понятным причинам, не затираются.
При установке порта opendnssec не делаем make clean, понадобятся некоторые файлы для настройки.
В OpenDNSSEC 1.4.1 этой проблемы не возникает, там больше не используется AUDITOR, который использовал ruby. Ruby вообще не используется. Из 2х опций предлагаемых при установке выбрана одна MySql. Повторюсь, что с MySql не завелось, для OpenDNSSEC 1.4.1 выберем соответственно вторую галку из двух.
В файле /usr/local/etc/nsd/nsd.conf меняем:
zonesdir: “/usr/local/var/opendnssec/signed”
и все записи zonefile:
zonefile: "/usr/local/var/opendnssec/signed/zone1.ru"
zonefile: "/usr/local/var/opendnssec/signed/zone2.ru"
…
zonefile: "/usr/local/var/opendnssec/signed/zoneN.ru"
Пин код будем вводить вручную. Или оставляем, пин код будет подставляться автоматически.
Должно получиться так:
Для 1.4.1 Устанавливаем MySql55 server и client. SQLite3 рекомендуется использовать только в тестовых целях.
После установки MySql55 необходимо, в зависимости от предполагаемой нагрузки на сервер, выбрать один из конфигурационных файлов, находящихся в /usr/local/share/mysql, и скопировать его в /var/db/mysql. И соответственно в /etc/rc.conf должно быть:
nsd_enable=«YES»
opendnssec_enable=«YES»
mysql_enable=«YES»
Для автоматического создания нужной структуры базы данных используем файл:
/usr/ports/dns/opendnssec/work/opendnssec-1.4.1/enforcer/utils/database_create.mysql
В /usr/local/etc/opendnssec будут дефолтные конфигурационные файлы, созданные при установке.
В /usr/local/etc/opendnssec/conf.xml правим:
В /usr/local/etc/opendnssec/conf.xml должно быть:
Проверяем, чтобы было так:
Для секурности пин код тут не прописан. Будет вводиться вручную, хотя проще оставить его на месте.
Обращаем внимание на запись:
Судя по всему, всё, что делает эта команда –это добавление текстовой информации о путях размещения файлов зон в файл /usr/local/etc/opendnssec/zonelist.xml. Вводимое имя зоны должно совпадать с именем файла зоны, который будет скопирован в /usr/local/var/opendnssec/unsigned. В общем чтобы руками не редактировать zonelist.xml
Всё, что касается политики работы с зонами можно посмотреть в официальной документации. Использовал дефолтную политику. С зонами закончили.
Собственно формируем ключи:
Back up ключей можно делать только при остановленном OpenDNSSEC. Иначе есть вероятность генерации нового ключа в течении выполнения операции back up. Ключи помечаются как bsck up. На всякий пока убрал опцию
Переустанавливал, после резервного перемещения всего, что связано с OpenDNSSEC в другую папку.
Здесь в /usr/local/etc/opendnssec будут дефолтные конфигурационные файлы, созданные при установке. В общем в папке должны быть файлы: conf.xml, kasp.xml, zonefetch.xml, zonelist.xml. Если их нет, то нужно переименовать файлы с расширением sample в этой-же директории.
При установке OpenDNSSEC с MySql путь уже исправлен.
Появится файл /usr/local/var/opendnssec/kasp.db
В /etc/rc.conf добавляем opendnssec_enable=«YES»
На версию 1.3.13 не обращаем внимания, у Вас будет 1.4.1
И т.д. добавляем все Ваши файлы зон.
Если видим такой вывод, значит всё настроено правильно.
SQLite база данных: /usr/local/var/opendnssec/kasp.db
;; QUESTION SECTION:
;dig. IN A
;; Got answer:
;; ->>HEADER ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;xx.yy.zz.ss. IN ANY
;; Got answer:
;; ->>HEADER ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
Всё в порядке. DNS по прежнему, и спустя некоторое время работает. Но DNSSEC пока не функционирует, в выводе нет строк с ключами.
Теперь нужно сообщить провайдеру о вашем открытом ключе и DS записях для каждой из зон. У провайдера на сайте в личном кабинете есть/должна быть форма заполнения с примером. У моего была.
При экспорте после ключа –e нужно установить текущее состояние (state) ключа KSK publish, active…
для размещения DNSKEY у РД, прямо всё, полученное через ods-ksmutil key export что есть копируем в текстовое поле ввода на сайте в личном кабинете, через некоторое время введённые данные автоматически будут подправлены до вида как в примере. Имеется в виду пример заполнения на веб странице личного кабинета РД. Т.е. всё, что после ;publish KSK DNSKEY record: прописываем в поле DNS Key: в личном кабинете РД.
Соответственно копируем полученные DS записи в соответствующее поле ввода в личном кабинете xxx. Проделываем соответствующую операцию для всех доменов.
И последний штрих –автоматический перезапуск NSD сервера, при перегенерации ключей:
В файле /usr/local/etc/opendnssec/conf.xml нужно рас комментировать или добавить строку в секции
Или копируем соответствующий файл из папки установки OpenDNSSEC.
;; QUESTION SECTION:
;xxx.yyy.zzz.aaa. IN A
;; Got answer:
;; ->>HEADER ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3
В приведённом выводе видим наличие ключей.
И последняя проверка, поскольку всё делалось для регистратора xxx, заходим в личный кабинет, и производим онлайн-тестирование DNS.
Всё в порядке, осталось убедиться, что по истечению установленного срока действия ключей, зоны будут пере подписаны автоматически. Видим запись, в личном кабинете РД “Выстроена цепочка доверия”.
Если кто укажет на возможные нюансы настройки c MySql, опробую и подкорректирую статью.
Много информации есть на официальном сайте.
Статью планируется корректировать, для правки настроек, связанных с MySql.
В сети Интернет DNS управляется через достаточно сложную систему авторизированных корневых серверов имён, и других менее крупных серверов имён, которые содержат и кэшируют информацию о конкретных доменах.
В этом документа рассматривается BIND 8.x, так как это стабильная версия, используемая во FreeBSD. BIND 9.x может быть установлен как порт net/bind9 .
Протокол DNS стандартизован в RFC1034 и RFC1035.
Для понимания этого документа нужно понимать значения некоторых терминов, связанных с работой DNS.
Термин | Определение |
---|---|
прямой запрос к DNS (forward DNS) | преобразование имён хостов в адреса IP |
ориджин (origin) | обозначает домен, покрываемый конкретным файлом зоны |
named, bind, сервер имён | общеупотребительные названия для обозначения пакета BIND, обеспечивающего работу сервера имён во FreeBSD. |
ресолвер | системный процесс, посредством которого машина обращается к серверу имён для получения информации о зоне |
обратный DNS (reverse DNS) | операция, обратная прямому запросу к DNS, преобразование адресов IP в имена хостов |
корневая зона | более точно, "." , служит для обозначения корня, или начала зоны. Все зоны находятся под ней, так же, как все файлы располагаются ниже корневого каталога. Это начало иерархии зон Интернет. |
зона | любой отдельный домен, поддомен или область, контролируемые в DNS. |
. является корневой зоной
org. является зоной ниже корневой зоны
1.2.3.in-addr.arpa является зоной, в которую включены все IP-адреса, формирующие пространство адресов 3.2.1.*.
Сервера имён обычно используются в двух видах: авторитетный сервер имён и кэширующий сервер имён.
Авторитетный сервер имён нужен, когда:
нужно предоставлять информацию о DNS остальному миру, отвечая на запросы авторизированно.
блоку адресов IP требуется обратные записи DNS (IP в имена хостов).
резервный (slave) сервер имён должен отвечать на запросы о домене, когда основной не работает или не доступен.
Кэширующий сервер имён нужен, когда:
локальный сервер DNS может кэшировать информацию и отвечать на запросы быстрее, чем это происходит при прямом опросе внешнего сервера имён.
требуется уменьшение общего сетевого трафика (DNS составляет около 5% всего трафика Интернет, или чуть больше).
Во FreeBSD даемон BIND, по очевидным причинам, называется named .
Файл | Описание |
---|---|
named | даемон BIND |
ndc | программа управления даемоном сервера имён |
/etc/namedb | каталог, в котором располагается вся информация о зонах BIND |
/etc/namedb/named.conf | конфигурационный файл для даемона |
Файлы зон обычно располагаются в каталоге /etc/namedb и содержат информацию о зоне DNS, за которую отвечает сервер имён.
Так как сервер имён BIND устанавливается по умолчанию, его настройка сравнительно проста.
Чтобы даемон named запускался во время загрузки, сделайте следующие изменения в файле /etc/rc.conf
Для запуска даемона вручную (после его настройки)
Обязательно выполните следующие команды:
для того, чтобы правильно создать файл /etc/namedb/localhost.rev локальной обратной зоны для loopback-интерфейса.
Как и говорится в комментариях, если вы хотите получить эффект от использования кэша провайдера, то можно включить раздел forwarders . В обычном случае сервер имён будет рекурсивно опрашивать определённые серверы имён Интернет до тех пор, пока не получит ответ на свой запрос. При включении этого раздела он будет автоматически опрашивать сервер имён вашего провайдера (или тот, который здесь указан), используя преимущества его кэша. наличия нужной информации. Если соответствующий сервер имён провайдера работает быстро и имеет хороший канал связи, то в результате такой настройки вы можете получить хороший результат.
Warning 127.0.0.1 здесь работать не будет . Измените его на IP-адрес сервера имён провайдера.
/* * If there is a firewall between you and name servers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default. */ // query-source address * port 53; /* * If running in a sandbox, you may have to specify a different * location for the dumpfile. */ // dump-file "s/named_dump.db"; >; // Note: the following will be supported in a future release. /* host < any; >< topology < 127.0.0.0/8; >; >; */ // Setting up secondaries is way easier and the rough picture for this // is explained below. // // If you enable a local name server, don't forget to enter 127.0.0.1 // into your /etc/resolv.conf so this server will be queried first. // Also, make sure to enable it in /etc/rc.conf. zone "." < type hint; file "named.root"; >; zone "0.0.127.IN-ADDR.ARPA" < type master; file "localhost.rev"; >; zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" < type master; file "localhost.rev"; >; // NB: Do not use the IP addresses below, they are faked, and only // serve demonstration/documentation purposes! // // Example secondary config entries. It can be convenient to become // a secondary at least for the zone where your own domain is in. Ask // your network administrator for the IP address of the responsible // primary. // // Never forget to include the reverse lookup (IN-ADDR.ARPA) zone! // (This is the first bytes of the respective IP address, in reverse // order, with ".IN-ADDR.ARPA" appended.) // // Before starting to setup a primary zone, better make sure you fully // understand how DNS and BIND works, however. There are sometimes // unobvious pitfalls. Setting up a secondary is comparably simpler. // // NB: Don't blindly enable the examples below. :-) Use actual names // and addresses instead. // // NOTE. FreeBSD runs bind in a sandbox (see named_flags in rc.conf). // The directory containing the secondary zones must be write accessible // to bind. The following sequence is suggested: // // mkdir /etc/namedb/s // chown bind:bind /etc/namedb/s // chmod 750 /etc/namedb/s
Дополнительная информация о запуске BIND в ограниченном окружении находится в соответствующем разделе .
Это примеры описаний прямой и обратной зон из файла named.conf для вторичных серверов.
Для каждого новой зоны, которую будет обслуживать сервер имён, в файл named.conf должна быть добавлена запись
В случае вторичной зоны информация о ней передается с основного сервера имён для заданной зоны и сохраняется в указанном файле. Если и когда основной сервер имён выходит и строя или недосягаем, то скачанная информация о зоне будет находиться на вторичных серверах и они смогут обслуживать эту зону.
Файл зоны имеет следующий формат:
recordname IN recordtype value
Наиболее часто используемые записи DNS:
начало зоны ответственности
авторитативный сервер имен
каноническое имя для алиаса
указатель на доменное имя (используется в обратных зонах DNS)
имя домена, а также ориджин для этого файла зоны.
основной/авторитативный сервер имён для этой зоны
последовательный номер файла. При каждом изменении файла зоны это число должно увеличиваться. В настоящее время для нумерации многие администраторы предпочитают формат ггггммддвв . 2001041002 будет означать, что файл последний раз изменялся 10.04.2001, а последнее число 02 означает, что это была вторая модификация файла за день. Последовательный номер важен, так как он служит для того, чтобы вторичные серверы узнавали об обновлении зоны.
localhost IN A 127.0.0.1 ns1 IN A 3.2.1.2 ns2 IN A 3.2.1.3 mail IN A 3.2.1.10 @ IN A 3.2.1.30
Для файлов зон in-addr.arpa (обратные записи DNS) используется тот же самый формат, отличающийся только использованием записей PTR вместо A или CNAME .
В этом файле дается полное соответствие имён хостов IP-адресам в нашем описанном ранее вымышленном домене.
Кэширующий сервер имён - это сервер имён, не отвечающий ни за какую зону. Он просто выполняет запросы от своего имени и сохраняет результаты для последующего использования. Для настройки такого сервера достаточно исключить все описания зон из стандартной конфигурации сервера имён.
Для дополнительной безопасности вам может потребоваться запускать named (8) с правами непривилегированного пользователя и настроить его на выполнение chroot (8) в каталог-песочницу. Это позволит сделать недоступным для даемона named все, что расположено вне песочницы. Если named будет взломан, то это поможет уменьшить возможный ущерб. По умолчанию во FreeBSD имеются пользователь и группа с именами bind , которые предназначены именно для такого использования.
Note: Многие рекомендуют вместо настройки named на использование chroot , запускать named внутри jail (8) . В этом разделе такой подход не рассматривается.
Так как named не сможет обратиться ни к чему вне песочницы (например, совместно используемым библиотекам, сокетам протоколов и так далее), то нужно выполнить несколько шагов, чтобы named смог работать нормально. В следующем списке предполагается, что каталогом песочницы является /etc/namedb и что вы не делали никаких изменений в содержимом этого каталога. Выполните следующие шаги, работая как пользователь root .
Создайте все каталоги, которые ожидает увидеть named :
Измените и создайте базовые файлы зоны и настроек:
Постройте статистически скомпонованную копию named-xfer и скопируйте ее в песочницу:
При этом из вашего дерева исходных текстов будет удалён весь "мусор" , и повторение вышеописанных шагов должно выполниться успешно.
Создайте файл устройства dev/null , который named может видеть и писать в него:
Создайте символическую ссылку /var/run/ndc на /etc/namedb/var/run/ndc :
Note: Это просто для того, чтобы не задавать опцию -c при каждом запуске ndc (8) . Так как содержимое каталога /var/run удаляется при загрузке, и если это показалось вам полезным, то вы можете добавить эту команду в cron-таблицу для root с использованием параметра @reboot . Обратитесь к справочной странице по crontab (5) для получения более полной информации относительно этого.
Настройте syslogd (8) на создание дополнительного протоколирующего сокета log , в который может писать named . Для этого добавьте -l /etc/namedb/dev/log к переменной syslogd_flags из файла /etc/rc.conf .
Задайте запуск named и выполнение chroot в песочницу, добавив следующее в /etc/rc.conf :
named_enable="YES" named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf"
Note: Заметьте, что конфигурационный файл /etc/named.conf именуется по полному имени относительно песочницы , то есть в вышеприведённой строке указывается файл, который на самом деле является файлом /etc/namedb/etc/named.conf .
Следующим шагом является редактирование файла /etc/namedb/etc/named.conf так, чтобы named знал, какую зону загружать и где найти их на диске. Далее следует прокомментированный пример (все, что специально не прокомментировано, ничем не отличается от настройки сервера DNS, работающего не в песочнице):
После выполнения шагов выше либо перезагрузите ваш сервер, либо перезапустите syslogd (8) и запустите named (8) , не забыв использовать новые опции, заданные в syslogd_flags и named_flags . Теперь named должен заработать в песочнице!
Хотя BIND является самой распространенной реализацией DNS, всегда стоит вопрос об обеспечении безопасности. Время от времени обнаруживаются возможные и реальные бреши в безопасности.
Tip: Если возникают проблемы, то наличие последних исходных текстов и свежеоткомпилированного named не помешает.
Изначально, Вы можете отправлять почту "во внешний мир" если у Вас правильно составлен файл /etc/resolv.conf или у Вас запущен свой сервер имен. Если Вы хотите, чтобы почта, предназначенная для хоста в Вашем домене, доставлялась по назначению, есть два пути:
В любом случае, чтобы почта всегда приходила на Ваш хост, Вам нужно иметь постоянный (статический) IP адрес (а не, например, PPP-соединение). Если Вы находитесь за брандмауэром, то последний должен пропускать SMTP-пакеты.
Если Вы хотите, чтобы почта приходила непосредственно на Ваш хост:
Удостоверьтесь, что запись MX в DNS соответствует IP адресу Вашего хоста хоста.
Или для Вашего хоста вообще отсутствует MX-запись.
Выполнение любого из перечисленных условий обеспечит доставку почты для Вашего хоста.
Если Вы это видите, то можно без проблем посылать почту на .
Однако, если Вы видите это:
Эта информация обрабатывается Вашим DNS сервером. Соответствующая запись DNS, указывающая, через какой хост будет проходить Ваша почта, называется MX (от англ. M ail e X changer). Если для хоста отсутствует такая запись, почта будет прихоть прямо на этот хост.
Вы видите, что для хоста freefall существуют несколько MX-записей. Запись с наименьшим номером соотвествует хосту, на который в конце-концов попадет почта для freefall ; другие будут временно сохранять почту для freefall , если тот по какой-либо причине недоступен.
Чтобы альтернативные MX-хосты использовались наиболее эффективно, они должны быть независимо подключены к Интернет. Ваш провайдер (или дружественный сайт) скорее всего без проблем сможет оказать подобные услуги.
Вам может понадобиться создать почтовый сервер, который будет "перехватывать" почту, адресованную рабочим станциям в Вашем домене. Затем пользователи будут забирать почту либо непосредственно с сервера, либо по протоколам POP или IMAP.
Чтобы облегчить себе (и другим) жизнь, создайте на обеих машинах аккаунты с одинаковыми именами пользователей, например, с помощью команды adduser .
Сервер, который Вы будете использовать в качестве почтового, должен быть объявлен таковым для каждой машины в домене. Вот фрагмент примерной конфигурации:
Таким образом, вся корреспонденция, адресованная рабочей станции, будет обрабатываться Вашим почтовым сервером, независимо от того, что указано в A-записи.
Все это можно реализовать только в том случае, если Вы используете сервер DNS. Если Вы по каким-либо причинам не имеете возможности установить свой собственный сервер имен, Вам нужно поговорить с Вашим провайдером услуг Интернет о предоставлении сервиса DNS для Вас.
Заметьте, что если Вам требуется только получать почту для домена, соответствующая A-запись не нужна.
Последнее, что Вы должны сделать - это сказать программе sendmail , для каких доменов и/или хостов она должна принимать почту. Это можно сделать несколькими способами:
Добавьте названия этих хостов в файл /etc/sendmail.cw , если Вы используете FEATURE(use_cw_file) . Если у Вас sendmail версии 8.10 или выше, то можно отредактировать файл /etc/mail/local-host-names .
Читайте также: