Настройка кэширующего сервера доменных имен. Примеры описания зон и файлов конфигурации BIND. Запуск и проверка работоспособности.

2004 г

Система доменных имен

Материалы книги П.Б. Храмцова
iнфоцентр

Настройка кэширующего сервера доменных имен. Примеры описания зон и файлов конфигурации BIND. Запуск и проверка работоспособности.

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

Если рассматривать функции кэширующего сервера с точки зрения архитектуры DNS, описанной в RFC-1034, то это "умный" resolver. А точнее, "умный" независимый resolver, который выполняет рекурсивные запросы прикладных программ.

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

Второй основной задачей такого сервера является хранение найденной информации (записей описания ресурсов) к своем кэше в течение времени жизни этой информации. При этом в кэш в соответствии с RFC-1034 должна попадать не только информация о конечном соответствии IP-адреса и доменного имени, но и информация найденная в процессе поиска конечного соответствия, например, информация об авторитативных серверах зон доменных имен.

Мы будем рассматривать настройку такого типа сервера на примере программного обеспечения BIND, т.к. большинство серверов, которые в настоящее время установлены в сети - это серверы BIND, хотя эта точка зрения и горячо оспаривается профессором Бернштейном (автор djbdns) во всех конференциях и списках, касающихся системы DNS. По крайней мере, BIND поставляется в комплекте со свободно распространяемыми клонами Unix, что делает знакомство с ним необходимым для большинства сетевых администраторов.

Для того, чтобы настроить BIND в качестве кэширующего сервера необходимо создать и заполнить соответствующей информацией следующие файлы:

named.boot (для BIND 4.x);
named.conf (для BIND 8.x и BIND 9.x);
root.cache (для BIND 4.x);
описание серверов корневой зоны (зона типа hint для BIND 8.x и BIND 9.х);
описание зоны 127.in-addr.arpa.

Будем рассматривать эти настройки по версиям BIND, и начнем с BIND 4.x, хотя она и является очевидным атавизмом.

Настройка кеширующего сервера в BIND 4.х

Сначала следует прописать правильным образом информацию в файле настройки самого сервера - named.boot, который располагается в каталоге /etc:

directory			/etc/namedb


primary 127.in-addr.arpa 127.in-addr.arpa
cache   .                       named.root

Первая строка этого файла определяет каталог, в котором хранятся описания зон. На первый взгляд нам эти описания не нужны, ведь мы настраиваем кэширующий сервер доменных имен, но при более детальном рассмотрении каталог нужен, т.к. наш сервер будет авторитативным для одной обратной зоны - 127.in-addr.arpa.

Именно этот факт и определяет вторая строка файла конфигурации сервера, в которой указана директива primary, определяющая, что сервер является master (в терминологии BIND 4.х - primary) для зоны 127.in-addr.arpa. Имя зоны задано вторым параметром директивы primary. Третий параметр этой директивы определяет имя файла в каталоге /etc/namedb, где описана соответствующая директиве зона.

Имя файла описания этой зоны может быть любым. Например, в последнее время модно называть его localhost.rev. Собственно, это имя генерирует скрипт make-localhost, который автоматически составляет описания зоны локального хоста.

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

Теперь посмотрим на содержание файлов описанных в named.boot и расположенных по умолчанию в каталоге /etc/namedb. Если они расположены в другом месте, то это указывается в директиве directory файла named.boot.

Содержание 127.in-addr.arpa:

;   From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90
;   $Id: PROTO.localhost.rev,v 1.1 1995/03/21 16:33:44 wollman Exp $
;
; This file is automatically edited by the `make-localhost' script in
; the /etc/namedb directory.
;


@      IN     SOA    iris.polyn.kiae.su. root.iris.polyn.kiae.su. (
                             961015  ; Serial
                             3600    ; Refresh
                             300     ; Retry
                             3600000 ; Expire
                             3600 )  ; Minimum
       IN     NS     iris.polyn.kiae.su.
1      IN     PTR    localhost.polyn.kiae.su.

Все, что начинается с ";" - это комментарии. Имя авторитативного сервера, указанное сразу после SOA берется скриптом генерации этого файла из команды hostname. Почтовый адрес - это адрес администратора сервера. NS запись снова ссылается на имя хоста, на котором запущен сервер и последняя запись - это PTR (pointer) на доменное имя localhost.polyn.kiae.su. Естественно, что, если в зоне polyn.kiae.su есть еще один хост с сервером доменных имен, то там тоже будет такая же обратная зона, с точно такой же записью, но ссылаться в реальности такая запись будет совсем на другой физический хост.

Вообще-то, в "прямой" зоне можно "в лоб" прописать некоторый IP-адрес для localhost.polyn.kiae.su. Это совершенно не повлияет работоспособность системы. Но в данном тексте мы "прямые" зоны не рассматриваем, т.к. описываем только кэширующий сервер.

Содержание файла named.root:

;     This file holds the information on root name servers needed to
;     initialize cache of Internet domain name servers
;     (e.g. reference this file in the "cache  .  "
;     configuration file of BIND domain name servers).
;
;     This file is made available by InterNIC registration services
;     under anonymous FTP as
;         file                /domain/named.root
;         on server           FTP.RS.INTERNIC.NET
;     -OR- under Gopher at    RS.INTERNIC.NET
;         under menu          InterNIC Registration Services (NSI)
;            submenu          InterNIC Registration Archives
;         file                named.root
;
;       last update:    Nov 8, 1995
;       related version of root zone:   1995110800
;
;
; formerly NS.INTERNIC.NET
;
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
;
; formerly NS1.ISI.EDU
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     128.9.0.107
;
; formerly C.PSI.NET
;
.                        3600000      NS    C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
;
; formerly TERP.UMD.EDU
;
.                        3600000      NS    D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.      3600000      A     128.8.10.90
;
; formerly NS.NASA.GOV
;
.                        3600000      NS    E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10
;
; formerly NS.ISC.ORG
;
.                        3600000      NS    F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
.                        3600000      NS    G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
.                        3600000      NS    H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.      3600000      A     128.63.2.53
;
; formerly NIC.NORDU.NET
;
.                        3600000      NS    I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17
; End of File

Мы специально включили именно эту версию файла named.root, которая шла с дистрибутивом BIND 4.9.6 для операционной системы IRIX 6.5. При реальной работе с BIND следует и версию named поставить поновее и файл описания корневой зоны получить "свежий".

Теперь мы имеем все необходимые файлы для запуска кэширующего сервера. Запускаем сервер:

>named

и все должно работать.

Настройка кэширующего сервера в BIND 8.х и BIND 9.х

Отличие данного случая от случая BIND 4.х, описанного выше, заключается в том, что вместо named.boot мы должны создать файл named.conf, который имеет совсем другой формат управляющих директив. Вот пример его содержания:

options {
        directory "/etc/namedb";
};
zone "." in {
        type hint;
        file "named.root";
};
zone "0.0.127.in-addr.arpa" in {
        type master;
        file "127.in-addr.arpa";
};

Это содержание файла named.conf полностью соответствует конфигурации BIND 4.х, которую мы разбирали выше.

Директива options определяет каталог, в котором хранятся файлы описания зон, директива zone определяет зоны, которые поддерживает сервер.

Зона "." сервером не поддерживается. Это корневая зона. Поэтому она имеет тип hint, т.е. "подсказка" на то, где описаны серверы корневой зоны.

Зона "0.0.127.in-addr.arpa" имеет тип master, т.к. данный сервер действительно является мастером для этой зоны.

Заметим, что по умолчанию в BIND 8.x и BIND 9.x файл named.conf расположен в разных каталогах. В BIND 8.x в каталоге /etc/namedb, а в BIND 9.х в каталоге /etc. Но, в принципе, используя параметры командной строки named этот порядок можно переиграть. Тем более его можно переиначить при сборке сервера из исходных текстов.

Теперь можно запускать named:

>named

Для BIND 8 сервер действительно запуститься, а вот для BIND 9.x этого скорее всего не произойдет. В файле системного журнала будет получено сообщение вида:

Nov 20 13:49:36 quest named[34123]: starting BIND 9.2.1
Nov 20 13:49:36 quest named[34123]: none:0: open: /etc/rndc.key: file not found
Nov 20 13:49:36 quest named[34123]: couldn't add command channel 127.0.0.1#953:
file not found

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

options {
        directory "/etc/namedb";
};
controls {};
zone "." in {
        type hint;
        file "named.root";
};
zone "0.0.127.in-addr.arpa" in {
        type master;
        file "127.in-addr.arpa";
};

Мы просто вставили директиву controls с пустым содержанием.

Вообще говоря, лучше создать требуемые файлы ключей и работать через программу rndc, но в контексте данного материала, когда мы рассматриваем последовательно BIND 4.x - BIND 8.x - BIND 9.x, отмена контроля выглядит вполне логично.

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

Для того, чтобы отделить весь мир от "наших" хостов нужно создать список доступа:

acl "our_folks" { 192.168.1.0/24; };
options {
        directory "/etc/namedb";
  allow-recursion { "our_folks"; };
  allow-query {"our_folks"}
  version "unknown";
  fake-iquery no;
};
controls {};
zone "." in {
        type hint;
        file "named.root";
};
zone "0.0.127.in-addr.arpa" in {
        type master;
        file "127.in-addr.arpa";
};

В данном файле конфигурации мы разрешили рекурсию (рекурсивные запросы) с нашей локальной сети, кроме того, разрешили какие-либо запросы (не только рекурсивные) тоже только с нашей локальной сети, скрыли версию named и отменили явно инверсные запросы (fake-iquery).

Вообще говоря, в данном случае можно было не вводить ограничения рекурсию, а ограничить только саму возможность обработки запросов (allow-query). Рекурсивные запросы - это только одно из подмножеств запросов и оно автоматически попадает на наложенное на обработку запросов ограничение.

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

На самом деле в рекомендациях CERT (Computer Emergency Responds Team) есть еще несколько моментов, которые позволяют ограничить себя от разного сорта неприятностей с кэширующим сервером доменных имен.

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

В BIND 9.x это реализовано по умолчанию, а в BIND 8.x для этой цели нужно вставить опцию use-id-pool:

acl "our_folks" { 192.168.1.0/24; };
options {
        directory "/etc/namedb";
  allow-recursion { "our_folks"; };
  allow-query {"our_folks"}
  version "unknown";
  fake-iquery no;
  use-id-pool yes;
};
controls {};
zone "." in {
        type hint;
        file "named.root";
};
zone "0.0.127.in-addr.arpa" in {
        type master;
        file "127.in-addr.arpa";
};

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

В пакете BIND 9.x в комплект поставки входит легковесный resolver. Его функциональность не соответствует функциональности кэширующего сервера. Легковесный resolver может выполнять только рекурсивные запросы программного обеспечения, которое функционирует на том же самом хосте, где этот resolver запущен. Он не может обслуживать группу хостов.

Проверка работоспособности кэширующего named.

Первое, что нужно выполнить после запуска сервера, посмотреть, появился ли он в списке исполняемых процессов:

polyn: {26} ps -ax | grep named
74541  ??  Ss     0:13.95 /usr/sbin/named
polyn: {27}

Если процесса нет, то нужно обратиться к файлу системного журнала и посмотреть, почему сервер не запустился:

Nov 20 13:48:09 quest named[34110]: starting BIND 9.2.1
Nov 20 13:48:09 quest named[34110]: /etc/named.conf:4: missing ';' before 'zone'
Nov 20 13:48:09 quest named[34110]: loading configuration: failure
Nov 20 13:48:09 quest named[34110]: exiting (due to fatal error)

Например, в данном случае при запуске были обнаружены ошибки в синтаксисе файла named.conf. По этой причине BIND 9.2.1 не запустился.

Если сервер запустился, то можно обратиться к нему при помощи команды dig или другой команды проверки работоспособности DNS:

generate# dig @localhost -t txt -c chaos version.bind.


; <<>> DiG 8.3 <<>> @localhost -t -c version.bind.
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;;      version.bind, type = TXT, class = CHAOS


;; ANSWER SECTION:
version.bind.           0S CHAOS TXT    "unknown"


;; Total query time: 1 msec
;; FROM: generate.polyn.kiae.su to SERVER: localhost  127.0.0.1
;; WHEN: Wed Nov 20 19:29:17 2002
;; MSG SIZE  sent: 30  rcvd: 51


generate#

Можно также попросить статистику его работы. Для сервера BIND 4.x в его работу нужно просто вмешаться сигналом ABRT:

IRIS 1# ps -ae | grep named
        204 ?      36:00 named
IRIS 2# kill -ABRT 204
IRIS 3#more /var/tmp/named.stats
+++ Statistics Dump +++ (1037807339) Wed Nov 20 18:48:59 2002
2434023 time since boot (secs)
2434023 time since reset (secs)
12427   Unknown query types
518901  A queries
147     NS queries
33      SOA queries
177315  PTR queries
47964   MX queries
92      TXT queries
190     AAAA queries
60      type 33 queries
112     type 38 queries
24      AXFR queries
99118   ANY queries
++ Name Server Statistics ++
(Legend)
        RR      RNXD    RFwdR   RDupR   RFail
        RFErr   RErr    RAXFR   RLame   ROpts
        SSysQ   SAns    SFwdQ   SDupQ   SErr
(Global)
…

Здесь только начало отчета файла статистики. Он довольно большой. Кроме того, каждое прерывание сервера (на самом деле мы выполняем прерывание, только сервер его перехватывает и обрабатывает) таким образом приводит к дописыванию статистики в конец файла, что только увеличивает его размер. Если сервер работает не долго (только запущен), то цифры отчета будут не большими J:

quest# more /etc/namedb/named.stats
+++ Statistics Dump +++ (1037800585)
success 0
referral 0
nxrrset 0
nxdomain 0
recursion 0
failure 0
--- Statistics Dump --- (1037800585)
quest#

Для того, чтобы появилась хоть какая-то статистика нужно его о чем-нибудь спросить:

quest# /usr/local/bin/dig @localhost www.ru +short
194.87.0.50
quest#

Теперь если посмотреть статистику обращений, то получим:

quest# more /etc/namedb/named.stats
+++ Statistics Dump +++ (1037800853)
success 3
referral 0
nxrrset 0
nxdomain 0
recursion 1
failure 0
--- Statistics Dump --- (1037800853)
quest#

На самом деле для того, чтобы "прочувствовать" на нашем сервере кэширование, мы спросили сервер не один, а три раза. Именно это и отражено в отчете (success). А рекурсивный запрос был выполнен только один (recursion).

Для BIND 8.х статистику получают командой ndc. Записывается статистика при этом не в /var/tmp, а уже в директорию файлов описания зоны. При этом мы запускаем ndc в интерактивном режиме:

polyn: {1} ndc
Type   help  -or-   /h   if you need help.
ndc> stats
Statistics dump initiated.
ndc> /exit
polyn: {2}

При помощи ndc можно не только собирать статистику, но и управлять сервером.

На самом деле приведенные примеры файлов статистики (кроме первого) сделаны при помощи команды rndc для сервера BIND 9.2.1. Для того, чтобы их получить, настройка сервера без удаленного контроля не годится. Нужно включить удаленный контроль.

Для того, чтобы его включить, нужно сгенерировать ключ. Это можно сделать любой из программ: dnskeygen из пакета BIND 8 или dnssec-keygen. На самом деле, вторая программка на некоторых системах не работает из-за ошибки взаимодействия с /dev/random, поэтому мы воспользовались первой.

quest# dnskeygen -H 128 -h -n rndc-key
** Adding dot to the name to make it fully qualified domain name**
Generating 128 bit HMAC-MD5 Key for rndc-key.


Generated 128 bit Key for rndc-key. id=0 alg=157 flags=513


quest#

Теперь нужно поправить named.conf:

quest# more named.conf
options {
        directory "/etc/namedb";
        };
zone "." {
        type hint;
        file "named.root";
};
zone "0.0.127.in-addr.arpa" {
        type master;
        file "localhost.rev";
};
key "rndc-key" {
        algorithm hmac-md5;
        secret "0V5661f2iotUKMKVDXNydQ==";
};
controls { inet 127.0.0.1 allow { localhost; } keys {"rndc-key"; }; };


quest#

Появилась директива key и изменилась директива controls. Собственно, нам нужен был только ключ, который записан в опции secret. Он был сгенерирован программой dnskeygen по имени rndc-key и помещен в файл Krndc-key.+157+00000.private в том же каталоге, из которого запускалась программа генерации ключа. На самом деле там появился еще один файл Krndc-key.+157+00000.key с KEY записью описания ресурсов. Ключ можно взять и оттуда.

Само слово "rndc-key" в директиве key файла named.conf - это просто имя ключа, на которое мы ссылаемся в директиве controls.

Теперь нужно создать файл настройки rndc - rndc.conf в каталоге /etc:

options {
        default-server localhost;
        default-key "rndc-key";
};
key "rndc-key" {
        algorithm hmac-md5;
        secret "0V5661f2iotUKMKVDXNydQ==";
};

Директива key в точности повторяет директиву из файла настройки named. Теперь запускаем named:

>named

Все должно работать. При этом можно выполнять команду rndc.

На самом деле существует более простой путь. Нужно было просто создать файл rndc.key в каталоге /etc, который содержал бы описание ключа:

key "rndc-key" {
        algorithm hmac-md5;
        secret "0V5661f2iotUKMKVDXNydQ==";
};

При этом из файла конфигурации named можно вообще убрать директивы controls и key:

options {
        directory "/etc/namedb";
        };
zone "." {
        type hint;
        file "named.root";
};
zone "0.0.127.in-addr.arpa" {
        type master;
        file "localhost.rev";
};

BIND 9.2.1 сам прочитает rndc.key и запуститься с каналом управления для локальной машины:

Nov 20 17:39:46 quest named[34430]: starting BIND 9.2.1
Nov 20 17:39:46 quest named[34430]: command channel listening on 127.0.0.1#953

Программа rndc при этом также не нуждается в файле настройки rndc.conf, а использует файл ключа rndc.key.

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

Рекомендованная литература:

P. Mockapetris. RFC-1034. DOMAIN NAMES - CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
P. Mockapetris. RFC-1035. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.
BIND 9 Administrator Reference Manual. (http://www.nominum.com/resources/documentation/Bv9ARM.pdf)
BIND Configuration File Guide (8.3.4) (ftp://ftp.isc.org/isc/bind/src/8.3.4/bind-doc.tar.gz)

Полезные ссылки:

http://www.isc.org/products/BIND/bind8.html - страничка BIND 8.
http://www.isc.org/products/BIND/bind4.html - страничка BIND 4.9.11
http://www.acmebw.com/resources/papers/securing.pdf - Securing an Internet Name Server. CERT Coordination Center. Carnegie Mellon University. 2002. Довольно подробный и обстоятельный обзор возможных проблем безопасности серверов доменных имен с рекомендациями по их (серверов) конфигурации.
bind9-users-bounce@isc.org - список рассылки и форум пользователей BIND9. Очень забавное чтение. Особенно полемика разработчиков BIND и профессора Бернштейна.

Назад Оглавление Вперед