Проверка работоспособности кэширующего 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
Можно также попросить статистику его работы. Для сервера 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 трафик и, если сеть защищена, его (трафик) контролировать.
