Файл зоны dns где находится

Обновлено: 02.07.2024

Прежде, чем приступить к настройке зоны, необходимо установить и предварительно настроить bind (инструкции для CentOS или Ubuntu).

Создание и настройка локальной зоны

Открываем конфигурационный файл bind.

В CentOS / Red Hat:

В Ubuntu / Debian:

И добавляем следующее:

* где test.local — имя зоны, которую будет обслуживать наш DNS-сервер. Это и есть домен, для которого bind будет хранить записи;

Описание опций настройки зоны:

Опция	Описание
type	тип зоны (в нашем случае первичная — значит master). Другие варианты — slave, stub, forward.
file	Путь к файлу с записями зоны. В данном примере указан относительный путь — то есть файл находится по пути master/test.local, который начинается относительно рабочей директории (по умолчанию — /var/named/). Таким образом, полный путь до файла — /var/named/master/test.local.
allow-transfer	Список других DNS-серверов (вторичных) для передачи им зоны. В нашем случае, зонные передачи разрешены серверу 192.168.0.15. Можно указывать подсети.
allow-update	Список хостов, с которых разрешено обновление записей в зоне (для DDNS). Можно указать подсети.

Чтобы настройки применились, необходимо перезапустить службу.

В CentOS / Red Hat:

systemctl reload named

В Ubuntu / Debian:

systemctl reload bind9

Создание файла зоны и настройка записей

Создаем каталог master (если он отсутствует).

В CentOS / Red Hat:

В Ubuntu / Debian:

И создаем файл зоны (в нашем примере test.local).

CentOS / Red Hat:

Приводим его к следующему виду:

test.local. IN SOA ns1.test.local. admin.test.local. (
2017082401 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
604800 ; Negative Cache TTL
)

IN NS ns1.test.local.
IN NS ns2.test.local.

IN MX 10 mx.test.local.
IN MX 20 mx2.test.local.

@ IN A 192.168.1.1
localhost IN A 127.0.0.1
ns1 IN A 192.168.1.2
ns2 IN A 192.168.1.3
mx IN A 192.168.1.4
mail IN A 192.168.1.5

www IN CNAME test.local.

Формат записей: <имя узла> <класс (всегда ставится IN)> <тип записи> <значение>.

Serial — порядковый номер изменения. Его необходимо каждый раз менять вручную при редактировании файла. С помощью него вторичный сервер (если такой есть), может определить, что были изменения и начать процесс копирования настроек.
Refresh указывает вторичным серверам, через какой промежуток времени они должны сделать запрос на обновление зоны.
Retry говорит вторичным серверам, как часто повторять попытки на обновление зоны, если первичный сервер не смог дать ответ (сервис был недоступен).
Expire — время в секундах, которое может работать вторичный сервер, если недоступен первичный. Если данный период истечет, а вторичный сервер так и не смог обновить зону, он должен прекратить отвечать на запросы.

Основные типы записей, использующиеся в DNS:

Чтобы зона начала работать, перечитываем ее:

Проверка

С другого компьютера вводим команду:

nslookup mail.test.local 192.168.0.15

* где 192.168.0.15 — наш настроенный DNS-сервер.
** сервер должен вернуть IP-адрес для запрошенного узла — а именно 192.168.1.5

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

Любой файл зоны должен содержать как минимум следующее:

одну запись Start Of Authority (SOA), содержащую параметры зоны;
не менее одной записи Name Server (NS), содержащей адреса DNS-серверов, ответственных за хранение и обслуживание зоны;
не менее одной записи Host (A), содержащей информацию о соответствии имени DNS-сервера, указанного в каждой записи NS, его IP-адресу.

Записи зон

При создании и изменении зоны вы чаще всего будете использовать следующие типы записей:

Тип записи	Назначение записи
Start Of Authority (SOA)	Описывает зону и ее параметры. В файле зоны встречается однократно и не требует редактирования вручную
Name Server (NS)	Описывает один DNS-сервер
Host (A)	Описывает соответствие имени хоста его IP-адресу. Используется часто
Canonical Name (CNAME)	Описывает альтернативное имя для уже существующего хоста
Mail Exchanger (MX)	Описывает почтовый хост, обрабатывающий электронную почту домена
Pointer (PTR)	Описывает соответствие IP-адреса имени хоста. Используется в зонах обратного просмотра
Service Location (SRV)	Описывает сервисы, предоставляемые хостами

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

Внимание!

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

Общий синтаксис записей зон

Любая DNS-запись имеет следующий вид:

владелец [класс] [TTL] тип данные

Описание полей DNS-записи приведено в таблице.

Поля записи разделяются любым количеством пробелов или символов табуляции.

Служебные записи (SOA и NS)

Большинство организаций, регистрирующих доменные имена, требуют наличия не менее двух обслуживающих зону DNS-серверов. Кроме того, для надежности эти серверы должны быть расположены в разных IP-сетях класса C.

Синтаксис записи NS

Синтаксис SOA-записи

Пример служебных записей зоны:

Записи хостов (A и PTR)

Синтаксис записи A

Название	Host Address
Определена в	RFC 1035
Описание	Запись, устанавливающая соответствие имени определенному IP-адресу.
Синтаксис	владелец [класс] [TTL] A IP_адрес
Параметры	IP-адрес хоста.
Пример	host1 IN A 192.168.0.1

Синтаксис AAAA-записи

Название	IPv6 Host Address
Определена в	RFC 1886
Описание	Запись, устанавливающая соответствие имени определенному IP-адресу версии 6.
Синтаксис	владелец [класс] [TTL] AААА IP_адрес_v6
Параметры	IP-адрес версии 6 хоста.
Пример	host2 IN AAAA 4321:0:1:2:3:4:567:89ab

Синтаксис PTR-записи

Записи A и PTR могут быть добавлены в зону следующим образом:

можно вручную создать необходимые записи (A и PTR) для компьютеров со статическими IP-адресами;
компьютеры, работающие под управлением Windows 2000 и использующие динамические IP-адреса, самостоятельно добавляют или изменяют необходимые записи (A и PTR) в зоне;
для компьютеров, работающих под управлением более ранних версий Windows и использующих динамические IP-адреса, добавление или изменение необходимых записей (A и PTR) осуществляется DHCP-сервером из состава Windows 2000 Server.

Примечание

Записи A и PTR не требуются для всех компьютеров. Они необходимы только для компьютеров, предоставляющих свои ресурсы в совместное использование. Тем не менее при использовании домена Active Directory Windows 2000 создает запись A для каждого компьютера в домене.

Записи альтернативных имен (CNAME)

Записи альтернативных имен позволяют использовать два или более имен для одного хоста. Использование альтернативных имен отличается от использования нескольких записей A для одного IP-адреса.

Синтаксис CNAME-записи

Альтернативные имена используются для:

изменения имени хоста, определенного при помощи записи A;
задания привычных имен для хостов, предоставляющих определенные сервисы;
распределения нагрузки между серверами, предоставляющими один и тот же сервис.

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

cоздайте запись A с новым именем, указывающую на IP-адрес хоста;
cоздайте запись CNAME со старым именем, указывающую на новое имя хоста;
удалить запись A хоста со старым именем.

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

Использование записей CNAME для задания привычных имен хостов позволяет осуществлять прозрачное перемещение сервисов с одного хоста на другой, балансировку нагрузки между хостами, прозрачно для пользователей изменять IP-адреса хостов, предоставляющих сервисы.

Рассмотрим это на примере.

Изначально в сети существовал хост, предоставляющий Web- и FTP-сервисы. Соответствующие записи зоны имели следующий вид:

host-a IN A 10.0.0.20

www IN CNAME host-a

ftp IN CNAME host-a

Со временем было принято решение переместить FTP-сервер на отдельный хост. За счет использования записей CNAME это было сделано прозрачно для пользователей:

host-a IN A 10.0.0.20

host-b IN A 10.0.0.21

www IN CNAME host-a

ftp IN CNAME host-b

Со временем нагрузка на Web-сервер возросла, и было принято решение установить дополнительный Web-сервер, разделяя нагрузку между ними, что было сделано прозрачно для пользователей за счет записей CNAME:

host-a IN A 10.0.0.20

host-b IN A 10.0.0.21

host-c IN A 10.0.0.22

www IN CNAME host-a

www IN CNAME host-c

ftp IN CNAME host-b

Внимание!

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

Записи почтовых хостов (MX)

Синтаксис записи MX

@ IN MX 10 mailserver1

@ IN MX 20 mailserver2

Записи сервисов (SRV)

DNS (Domain Name System) – это система доменных имен, предназначенная для связывания доменов (названий сайтов) с IP-адресами компьютеров, обслуживающих их. То есть, данная система предназначена для облегчения поиска веб-сайтов.

Домен, который вы вводите в браузере, не является настоящим адресом сайта. Это равносильно тому, что вы отправите письмо человеку, указав на конверте лишь его Ф.И.О. и город проживания. Но как доставить ему письмо, если почтальон не знает конкретно, где находится адресат? Для этого на конверте и указывают почтовый адрес.

Для чего нужен DNS?

Вы спросите: «А зачем вообще усложнять жизнь и почему нельзя оставить только доменные имена»? Суть в том, что любой доступный во Всемирной паутине сайт – это, грубо говоря, тот же компьютер со своим айпи. Все его файлы, папки и прочие материалы хранятся на сервере. Компьютеры способны работать только с цифрами – без DNS они не поймут символьный запрос.

В Интернете роль подобной телефонной книжки отводится именно DNS. В этой системе прописана и сохранена связь сравнительно легко запоминающихся имен сайтов с тяжелыми к запоминанию цифровыми адресами. Вот только во Всемирной сети такую «книгу» ведут не знакомые Ивана Сидоровича, которые в собственных «контактах» могут назвать его как угодно, а лично он.

Где находятся записи соответствия доменов IP-адресам?

Система доменных имен владеет собственными DNS-серверами. Именно в них содержится вся информация о принадлежности того или иного домена определенному IP-адресу. Подобных серверов большое количество и они выполняют две важных функции:

хранение списка айпи и соответствующих им доменов;
кэширование записей из других серверов системы.

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

Предотвратить эту проблему призваны, так называемые, вторичные DNS-сервера, расположенные ближе к вашему устройству (как правило, они находятся у ваших провайдеров). Чтобы при повторном запрашивании какого-либо сайта не искать его адрес заново, в своем кэше они сохраняют данные о нем и оперативно сообщают IP.

Важно! Кэширование невозможно без первичных DNS-серверов, содержащих первую связь айпи с доменными именами. В процессе регистрации домена, перед тем, как ваш сайт заработает, необходимо уведомить регистратора о DNS-сервере, где будет храниться вся информация о вашем домене. А какая именно информация, об этом немного позже.

Что такое DNS-зона?

И веб-ресурс, и почта могут иметь по несколько IP-адресов – это делается с целью повышения их надежности и обеспечения быстродействия. DNS-зона – это содержимое файла, в котором прописаны связи между доменами и IP-адресами. Она содержит следующую информацию:

Это сокращенный список, включающий в себя основные поля DNS-зоны.

Дополнительная информация

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

Мы говорили о доменах с адресами, включающими в себя четыре числа. Они относятся к стандарту IPv4 и могут обслужить ограниченное количество устройств: 4 294 967 296. Да, более четырех миллиардов компьютеров – это немало, но технологический прогресс стремителен и устройства, подключаемые к Интернету, приумножаются с каждым днем. Это привело к нехватке адресов. Во избежание данной проблемы были внедрены новые IPv6 – адреса с шестью числами, которые в DNS-зоне обозначаются, как AAAA. Благодаря новому стандарту, IP-адреса смогут получить значительно больше компьютеров.
Чтобы повысить продуктивность и надежность сайта, одно доменное имя привязывают к нескольким адресам. Как правило, при запросе страницы DNS-сервера выдают IP в непроизвольном порядке.
Один и тот же IP-адрес может быть связан с несколькими доменами. Вообще, это никак не отвечает принципам DNS, где предполагается однозначная связь айпи с доменом. Но, как мы уже упоминали выше, адресов IPv4 уже не хватает на все существующие сегодня интернет-устройства, и приходится экономить. На деле это выглядит так: на сервере с определенным IP-адресом размещают несколько мелких веб-ресурсов с разными доменами, но с одинаковыми адресами. Получая запрос, обслуживающий сайты компьютер обрабатывает запрашиваемый домен и отсылает пользователю нужный веб-ресурс.

Подводим итоги

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

Оцените эту статью. Чтобы мы могли делать лучший контент! Напишите в комментариях, что вам понравилось и не понравилось!

Доменная система имён (DNS) – собственно, система, привязывающая IP-адрес к символьному имени домена. Система DNS работает по принципу иерархии и использует произвольное количество частей (доменов), разделяемых точкой. Корневые домены или домены верхнего уровня в сети Internet управляются центром InterNIC (Public Information Regarding Internet Domain Name Registration Services).

Для нахождения того или иного ресурса в сети система DNS использует DNS-сервера содержащие базу данных типа «IP-адрес – имя домена». Можно сказать, что вся информация о зонах хранится в файлах описания зон, а при запуске сервера она загружается в оперативную память. Поэтому, базой данных сервера называют всю совокупность файлов описания зон сервера.

Файлы зон содержат информацию о пространстве имен и могут содержать директивы и записи ресурсов. Директивы указывают серверу доменных имен на выполнение определённых задач или применение специальных настроек в зоне. Ресурсные записи определяют параметры зоны и соотносят пользователей с определёнными хостами. В файле зоны необязательно могут присутствовать директивы, но в нем обязательно должны быть ресурсные записи.

Пример файла зоны:

Все директивы и ресурсные записи вводятся в отдельной строке, комментарии размещаются после точки с запятой (;).

Директивы начинаются со знака доллара ($), после которого вводится имя директивы. Зачастую директивы пишут в начале файла зоны.

Ниже приведены часто используемые директивы:

$ TTL – Устанавливает значение времени жизни по умолчанию (TTL) для зоны. Это время, на протяжении которого запись ресурса этой зоны действительна в кэше других серверов. Каждая запись ресурса может содержать свое собственное значение TTL , который перекрывает эту директиву.

Основные ресурсные записи DNS

Пример записи SOA:

Serial – Серийный номер самого файла зоны. Серийный номер увеличивается каждый раз при изменении данных домена. Когда вторичный сервер проверяет необходимость обновления данных, он проверяет серийный номер записи SOA на первичном сервере.

TTL – Время жизни. Время, на протяжении которого запись ресурса этой зоны действительна в кэше других серверов.

*Обратите внимание, что временные промежутки можно вводить не только в секундах. Возможны варианты ввода данных в других форматах, например: 2w14h(2 недели 14 часов), 1d2h(1 день 2 часа), 4h30m(4 часа 30 минут), 30m45s(30 минут 45секунд), или любые другие варианты при использовании соответствующих букв. Кроме записи SOA, существуют другие ресурсные записи. Мы рассмотрим основные:

Запись А – запись соответствия имени хоста его IP-адресу.

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

Запись NS (Name Server) – запись адреса узла отвечающего за доменную зону. Указывает на сервера DNS, ответственные за конкретный домен и его поддомены.

В сети Интернет DNS управляется через достаточно сложную систему авторизированных корневых серверов имён, и других менее крупных серверов имён, которые содержат и кэшируют информацию о конкретных доменах.

В этом документа рассматривается BIND 8.x, так как это стабильная версия, используемая во FreeBSD. BIND 9.x может быть установлен как порт net/bind9 .

Протокол DNS стандартизован в RFC1034 и RFC1035.

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

. является корневой зоной

org. является зоной ниже корневой зоны

1.2.3.in-addr.arpa является зоной, в которую включены все IP-адреса, формирующие пространство адресов 3.2.1.*.

Сервера имён обычно используются в двух видах: авторитетный сервер имён и кэширующий сервер имён.

Авторитетный сервер имён нужен, когда:

нужно предоставлять информацию о DNS остальному миру, отвечая на запросы авторизированно.

блоку адресов IP требуется обратные записи DNS (IP в имена хостов).

резервный (slave) сервер имён должен отвечать на запросы о домене, когда основной не работает или не доступен.

Кэширующий сервер имён нужен, когда:

локальный сервер DNS может кэшировать информацию и отвечать на запросы быстрее, чем это происходит при прямом опросе внешнего сервера имён.

требуется уменьшение общего сетевого трафика (DNS составляет около 5% всего трафика Интернет, или чуть больше).

Во FreeBSD даемон BIND, по очевидным причинам, называется named .

Файлы зон обычно располагаются в каталоге /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-адресам в нашем описанном ранее вымышленном домене.

Кэширующий сервер имён - это сервер имён, не отвечающий ни за какую зону. Он просто выполняет запросы от своего имени и сохраняет результаты для последующего использования. Для настройки такого сервера достаточно исключить все описания зон из стандартной конфигурации сервера имён.

Note: Многие рекомендуют вместо настройки named на использование chroot , запускать named внутри jail (8) . В этом разделе такой подход не рассматривается.

Так как named не сможет обратиться ни к чему вне песочницы (например, совместно используемым библиотекам, сокетам протоколов и так далее), то нужно выполнить несколько шагов, чтобы named смог работать нормально. В следующем списке предполагается, что каталогом песочницы является /etc/namedb и что вы не делали никаких изменений в содержимом этого каталога. Выполните следующие шаги, работая как пользователь root .

Создайте все каталоги, которые ожидает увидеть named :

Измените и создайте базовые файлы зоны и настроек:

Если вы используете FreeBSD версии ранее 4.9-RELEASE, то постройте статически скомпонованную копию named-xfer и скопируйте её в песочницу:

После установки статически скомпонованного named-xfer , во избежание появления старых копий библиотек и программ в дереве исходного кода, требуется некоторая зачистка:

и удалите ваше дерево /usr/obj :

При этом из вашего дерева исходных текстов будет удалён весь ``мусор'', и повторение вышеописанных шагов должно выполниться успешно.

Если вы используете FreeBSD 4.9-RELEASE или более позднюю версию, то копия named-xfer в каталоге /usr/libexec по умолчанию является статически скомпонованной, и вы можете просто скопировать её в песочницу при помощи команды cp (1) .

Создайте файл устройства dev/null , который named может видеть и писать в него:

Создайте символическую ссылку /var/run/ndc на /etc/namedb/var/run/ndc :

Задайте запуск 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, работающего не в песочнице):

options < directory "/"; named-xfer "/bin/named-xfer"; version ""; // Не выдавайте версию BIND query-source address * port 53; >; // управляющий сокет ndc controls < unix "/var/run/ndc" perm 0600 owner 0 group 0; >; // Далее следуют зоны: zone "localhost" IN < type master; file "master/named.localhost"; allow-transfer < localhost; >; notify no; >; zone "0.0.127.in-addr.arpa" IN < type master; file "master/localhost.rev"; allow-transfer < localhost; >; notify no; >; 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 "master/localhost-v6.rev"; allow-transfer < localhost; >; notify no; >; zone "." IN < type hint; file "master/named.root"; >; zone "private.example.net" in < type master; file "master/private.example.net.db"; allow-transfer < 192.168.10.0/24; >; >; zone "10.168.192.in-addr.arpa" in < type slave; masters < 192.168.10.2; >; file "slave/192.168.10.db"; >;

Хотя BIND является самой распространенной реализацией DNS, всегда стоит вопрос об обеспечении безопасности. Время от времени обнаруживаются возможные и реальные бреши в безопасности.

Tip: Если возникают проблемы, то наличие последних исходных текстов и свежеоткомпилированного named не помешает.

Читайте также: