3.5.2.1 О службе DNS (bind)
Скачать документ
Собственный DNS-сервер
Установка и настройка Bind
Окружение
- Версия ОС: 8
- Конфигурация ОС: Рабочая станция, Сервер графический
- Редакция ОС: Стандартная
Если локальная сеть не подключена к сети Интернет, возможно, что в ней не требуется отдельный DNS-сервер. В Linux преобразованием доменных имён в IP-адреса занимается несколько механизмов, и DNS — лишь один из них.
В простейшем случае, имена и IP-адреса всех узлов можно задать в файле /etc/hosts. Порядок, в котором система обращается к различным источникам имён, задаётся в файле /etc/nsswitch.conf. Например, строка:
hosts: files nisplus nis dns указывает, что сначала используется /etc/hosts, затем службы NIS/NIS+, и лишь потом — DNS.
Если задачу преобразования имён в адреса взял на себя провайдер, собственный DNS-сервер можно не устанавливать. В этом случае во всех системах в файле /etc/resolv.conf указывается адрес DNS-сервера провайдера (через директиву nameserver). Даже если сеть использует приватные адреса (RFC1918), DNS-запросы к внешним серверам продолжат работать. Внутри сети можно использовать IP-адреса или файл /etc/hosts.
Собственный DNS-сервер
Однако уже здесь очевидны две задачи, для решения которых можно организовать собственную службу доменных имён.
Первая задача — ускорение DNS-запросов. Если канал подключения к Интернет обладает большим временем задержки (например, четверть секунды), DNS-запросы к внешним серверам могут быть медленными, что особенно заметно при работе с веб-страницами. DNS — распределённая база с кешированием: ответы сохраняются в памяти сервера на определённое время (TTL). Это позволяет значительно сократить время последующих обращений к тем же доменам.
Вторая задача — именование устройств в интранет-сети. Если в локальной сети есть собственные сервисы (веб-сервер, почта и т.д.), их удобно называть по доменным именам, а не по IP. Хотя можно использовать /etc/hosts, масштабируемее и надёжнее — DNS.
Установка и настройка Bind
Для запуска DNS-сервера используйте Bind (обратите внимание, пакет и сервис называются bind, а сама служба — named). В системах с безопасностью chroot дополнительно устанавливается пакет bind-chroot, в котором все рабочие файлы находятся в /var/named/chroot/.
Для запуска named в режиме кеширующего DNS-сервера достаточно раскомментировать и заполнить раздел настройки forwarders (вышестоящие серверы) в файле /var/named/chroot/etc/named.conf. Обратите внимание на возможные ограничения на право обращаться к серверу с обычными и рекурсивными запросами (настройки allow-query и allow-recursion). Можно раскомментировать, находящиеся в этом файле, установки по умолчанию. Эти настройки открывают доступ только абонентам локальных сетей, т.е. сетей, к которым компьютер подключён непосредственно.
grep allow- /var/named/chroot/etc/named.conf
allow-query { localhost; any; };
allow-query-cache { localhost; any; };
Создание зон
Для корректной работы локального DNS-сервера нужно определить две основные зоны:
Прямую зону — обеспечивает преобразование доменных имён в IP-адреса;
Обратную зону — выполняет обратное преобразование: IP-адресов в доменные имена.
Каждая зона должна содержать запись типа SOA (Start of Authority, «начало зоны»). В этой записи определяются основные временные и административные параметры домена, в том числе электронный адрес лица, ответственного за домен (администратора) и серийный номер зоны.
Серийный номер — это целое число в диапазоне от 0 до 4294967295 (2**32). При любом изменении в файле зоны этот номер необходимо увеличивать. Именно по нему вторичные и кэширующие DNS-серверы определяют, устарела ли зона, и при необходимости обновляют свои данные.
Для удобства и читаемости часто используется формат серийного номера вида:
<год><месяц><число><версия>где все числа, кроме года, двузначные, а версия может обнуляться раз в день, соответствовать времени (например, по формуле 100*(часы*60+минуты)/(60*24) или иметь сквозную нумерацию (в этом случае появляется сложность с переходом от версии 99 к версии 100, то есть 0). Даже если серийный номер генерируется автоматически, рекомендуется пользоваться этим форматом, наглядно отражающим время создания зоны.
Пример минимальной зоны, содержащей только записи SOA и одну обязательную NS-запись, находится в файле /usr/share/doc/bind/sample/var/named/named.localhost.
Кроме SOA, каждая зона должна содержать как минимум одну запись типа NS (Name Server), указывающую авторитетный DNS-сервер для домена. Некоторые зоны создаются и настраиваются автоматически, например через файл: /var/named/chroot/etc/named.rfc1912.zones. Они нужны для обслуживания сети, привязанной к сетевой заглушке (127.0.0.1/8).
При создании зоны стоит помнить, что имя обслуживаемого домена указывается в конфигурационном файле, а в файле самой зоны можно использовать относительные имена (без точки в конце). Это упрощает переименование зоны — достаточно изменить одну строку в конфигурации. Рекомендуется добавлять описания зон в конфигурационный файл /var/named/chroot/etc/named.rfc1912.zones.
Прямая зона
Прямая зона отвечает за преобразование доменных имён в IP-адреса — операцию, которая требуется большинству сетевых приложений. Основной тип записей в этой зоне — A (Address), связывающий доменное имя с конкретным IP-адресом.
Помимо записей типа A, в прямой зоне часто встречаются:
CNAME (Canonical Name) — позволяет назначить псевдонимы, указывающие на основное имя, облегчая администрирование;
MX (Mail eXchange) — определяет сервер, на который должны доставляться почтовые сообщения, адресованные домену.
Пример конфигурации прямой зоны для домена internal.domain.net (незначащие поля соответствующих файлов заменены на . . .):
# cat /var/named/chroot/etc/named.rfc1912.zones
. . .
zone "example" IN {
type master;
file "internal.domain.net";
allow-update { none; };
};
. . .
# cat /var/named/chroot/var/named/internal.domain.net
$TTL 1D
@ IN SOA server root.server (
2004082202 ; serial
12H ; refresh
1H ; retry
1W ; expire
1H ; ncache
)
IN NS server
MX 10 server
Server A 10.10.10.1
www CNAME server
mail CNAME server
jack A 10.10.10.100В данном примере все ключевые сетевые функции выполняет один хост с адресом 10.10.10.1, зарегистрированный под несколькими именами:
server.internal.domain.net
mail.internal.domain.net
Несмотря на то, что имя mail является CNAME-записью для server, MX-запись указывает всё же не на него, а на действительный адрес — так рекомендовано RFC. Это важно, поскольку MX-записи не должны ссылаться на псевдонимы (CNAME).
Обратная зона
Для того, чтобы преобразовывать IP-адреса в доменные имена, у каждой сети должна быть обратная зона. Если такой зоны нет, и в файле /etc/hosts тоже ничего не написано, операция не выполнится. Такое преобразование нужно гораздо реже и в основном по соображениям административным: для того, чтобы выяснить принадлежность компьютера (с которого, допустим, пытаются атаковать сервер) по его IP-адресу. Некоторые почтовые серверы проверяют, содержится ли IP-адрес машины, передающей сообщение, в обратной зоне и похоже ли полученное доменное имя на то, что указано в сообщении, и при несовпадении отказываются принимать письмо. К сожалению, поскольку неудобства, связанные с отсутствием обратной зоны, понятны лишь грамотному администратору, а таких на просторах Интернета не слишком много, обратные зоны во множестве сетей либо отсутствуют, либо дают неверную информацию. В случае внутренней сети обратная зона необязательна, но желательна — для простоты администрирования и удовлетворения потребностей разных программных продуктов, которые ею пользуются.
Обратная зона состоит почти целиком из записей типа PTR (Pointer, указатель). Чтобы не умножать сущностей, решено было не вводить новый способ работы сервера имён и представить обратное преобразование IP-адреса как прямое преобразование доменного имени специального вида. Например, чтобы выяснить доменное имя компьютера с адресом 1.2.3.4, необходимо запросить информацию о доменном имени 4.3.2.1.in-addr.arpa. Таким образом, каждой подсети класса C (или выше) соответствует определённый домен, в котором можно найти ответ. Вот как выглядит обратная зона для нашего воображаемого домена:
cat /var/named/chroot/etc/named.rfc1912.zones
zone "12.11.10.in-addr.arpa" { type master;
file "12.11.10.in-addr.arpa";
};
cat /var/named/chroot/var/named/12.11.10.in-addr.arpa
$TTL 1D
@ IN SOA server.internal.domain.net. root.server.internal.domain.net (
2004082201 ; serial
12H ; refresh
1H ; retry
1W ; expire
1H ; ncache
)
IN NS server.internal.domain.net
0 PTR internal.domain.net.
1 PTR server.internal.domain.net
100 PTR jack.internal.domain.net.Обратите внимание, что относительные адреса, использованные в левой части записей PTR, раскрываются в полные вида <адрес>.12.11.10.in-addr.arpa, а в правой части используются полные (которые вполне могут указывать на имена в разных доменах).
Проверить синтаксическую правильность конфигурационного файла и файла зоны можно с помощью утилит named-checkconf и named-checkzone, входящих в пакет bind. Они же используются при запуске службы командой service bind start. Однако при интенсивной эксплуатации сервера, когда остановка службы нежелательна, можно попросить службу перечитать файлы настроек или определённые зоны с помощью утилиты rndc — вот тогда не стоит забывать о проверке синтаксиса.
Стоит иметь в виду, что, в отличие от прямых зон, обратные описывают административную принадлежность компьютеров, но сами принадлежат хозяину сети (как правило, провайдеру). Возникает особого рода затруднение, связанное с работой DNS-сервера уже не во внутренней сети, а в сети Интернет. Дело в том, что подсети класса C (т. н. сети /24, в которых сетевая маска занимает 24 бита, а адрес компьютера — 8) выдаются только организациям, способным такую подсеть освоить (в сети класса C 254 абонентских IP-адреса, один адрес сети и один широковещательный адрес). Чаще всего выдаются совсем маленькие подсети — от /30 (на два абонентских адреса) до /27 (на 30 адресов) — или другие диапазоны, сетевая маска которых не выровнена по границе байта. Таких подсетей в обратной зоне получится несколько, а возможности просто разделить её, отдав часть адресов в администрирование хозяевам, нет. Грамотный провайдер в таких случаях пользуется RFC2317 (есть в пакете bind-docs), предписывающем в обратной зоне заводить не записи вида PTR, а ссылки CNAME на адреса в «классифицированных» обратных зонах специального вида. Обратное преобразование становится двухступенчатым, зато администрирование каждой классифицированной зоны можно отдать хозяину.
Первичный и вторичный серверы
DNS-сервер, отвечающий на запросы из сети Интернет, должен быть зарегистрирован в родительском домене. В самом деле, единственный способ узнать, кто обслуживает домен internal.domain.net — спросить об этом у DNS-сервера домена domain.net. Так что о выделении поддомена необходимо договариваться с провайдером. Регистрацией в доменах первого уровня занимаются выделенные организации. Например, домен в зоне .ru необходимо регистрировать в компании АНО «Региональный Сетевой Информационный Центр» (RU-CENTER).
Правила требуют, чтобы при регистрации домена было указано не менее двух DNS-серверов, которые будут его обслуживать. Из всех зарегистрированных серверов (записей типа NS в родительской зоне) только одна соответствует т.н. первичному (master) серверу, а остальные — т.н. вторичным (slave). Для внешнего пользователя вторичный сервер не отличается от первичного: он столь же авторитетен в ответе на запрос об именах его домена. Отличия только в способе администрирования. Все изменения вносятся в зоны первичного сервера, а вторичный только кеширует эти зоны, целиком получая их по специальному межсерверному протоколу. Полученная зона складывается в файл, редактировать который бессмысленно: первичный сервер при изменении зоны рассылает всем своим вторичным указание скачать её заново. Право на скачивание зоны можно ограничить настройкой allow-transfer (как правило, в ней перечисляются адреса вторичных серверов). Вот слегка отредактированная цитата из руководства по Bind, описывающая задание вторичного сервера в файле настроек:
// We are a slave server for eng.example.com
zone "eng.example.com" { type slave;
file "slave/eng.example.com";
// IP address of eng.example.com master server masters { 192.168.4.12; };
};Вторичный сервер хорошо размещать где-нибудь подальше от первичного, во всяком случае, в другой сети — так повышается надёжность обработки запроса (если один сервер недоступен, возможно, ответит второй) и возрастает скорость распространения записей по кешам промежуточных серверов.
Проверка и отладка
Проверку работоспособности и доступности DNS-сервера лучше всего делать утилитой dig из пакета bind-utils. Это утилита, выдающая максимум информации о том, что происходило с запросом (запрашивая обратное преобразование, не забудьте добавить ключ -x). Более лаконична, но не менее эффективна утилита host из того же пакета. Упоминаемую старыми руководствами по UNIX утилиту nslookup использовать не рекомендуется.
# dig jack.internal.domain.net <<>> DiG 9.2.4rc5 <<>> jack.internal.domain.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32751 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;jack.internal.domain.net. IN A ;; ANSWER SECTION: jack.internal.domain.net. 86400 IN A 10.11.12.100 ;; AUTHORITY SECTION: internal.domain.net. 86400 IN NS server.internal.domain.net. ;; ADDITIONAL SECTION: server.internal.domain.net. 86400 IN A 10.11.12.1 ;; Query time: 37 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Aug 22 16:07:17 2004 ;; MSG SIZE rcvd: 95
Наконец, для выяснения административной принадлежности тех или иных доменов и сетей можно воспользоваться утилитой whois, которая обращается к специальной сетевой базе данных (не имеющей отношения к DNS).
Дата последнего изменения: 09.04.2025
Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.