BIND9 в многонодов режим на работа
Версия 1.0.2 (26 април 2006г.)
Copyright ©2006 Веселин Колев, Софийски Университет "Св. Климент Охридски"
Лиценз: CC Attribution-ShareAlike
- Въведение.
- Директорийна структура и съдържание на решението.
- Процедура по изграждане и управление на нодове.
- Особености на използването на rndc при многонодов режим на работа на named.
1. Въведение.
По подразбиране, инсталацията на BIND9 се извършва в рамките на една инстанция (от гледна точка на работна единица на услуга - един нод). Това означава, че в системата има само един майчин процес на демона named. В над 90% от случаите на инсталации на BIND9 върху UNIX и UNIX-подобни базирани системи, това е напълно достатъчно. В по-редки случаи може да се наложи в една система да има повече от един нода на named, които да работят паралелно. Причините за това може да са няколко. Погледнато реално, да се извършва виртуализация чрез Xen само за да се стартира един отделен сървър за имена, е нерантабилно от гледна точка на натоварването на системата и самата сложност на инсталация. Много по-лесният вариант е да се реализира още един сървър за имена в една и съща система, като още един нод на демона named. Такъв вариант е по-добър в многопроцесорни системи, ако е нужно всеки даден демон да използва отделен процесор. Ресурсите, които се използват от демона named могат да бъдат лесно регулирани, доколкото всеки нод (всеки отделен демон named) има ясна идентификация като име на процес и потребител, с чиито права функционира.
Когато се говори за Red Hat Enterprise Linux обикновено става дума за сървърски системи с висока производителност и висока значимост от гледна точка на ресурсите, осигуряващи услугите, които се прдлагат на основа на тях. Това са консервативни системи, в които нещата не се променят значимо в рамките на жизнения цикъл на версията на дистрибуцията. Именно на тази и други особености трябва да е подчинена и идеологията на решението, което ще бъде описано тук. То не трябва да засяга или променя значимо системата и да не води до объркване тези, които я администрират. Следователно трябва да е максимално просто и лесно управляемо. Именно за това се използва стандартен за Red Hat Enterprise Linux инициализационен скрипт, максимално близък до този на услугата named. Решението трябва да може да бъде обновявано с минимален брой стъпки и при нужда да е лесно остранимо от системата, без да "замърсява" директорийната структура. Именно тези изисквания са заложени в реализацията му, която е описана по-долу.
Разбира се, решението може да се реализира и върху други UNIX и UNIX-подобни дистрибуции. За целта обаче, ще трябва да се съобрази с локалната идеология за управление на услугите в системата, конкретното разположение на директории и файлове и т.н.
Този документ е предназначен за системни администратори с опит в администрирането на сървъри за имена. От тази гледна точка описанието в него би било трудно разбираемо за начинаещи потребители.
Решението е тествано и оптимизирано в рамките на повече от една година в условия на продукция, върху двата основни сървъра за имена в мрежата на Софийския Университет "Св. Климент Охридски". На базата на това решение са реализирани нодовете на сървърите за имена по проекта AS112 и тези на СУ (върху всяка машина има по два нода на named - един за нуждите на AS112 и друг за нуждите на СУ). Така решението е "чисто" и сървърите за имена на проекта AS112 не са обвързани по никакъв начин с тези на СУ, освен това, че процесите на named работят вурху една и съща машина.
Всичко описано по-долу няма претенции да бъде единствено правилно и не бива да се разглежда като задължителен за следване шаблон по изграждане на подобни решения. Изложените тук техники и схеми са само едно възможно решение.
Авторът не носи отговорност за евентуално възникнали проблеми или нанесени преки или косвени щети, причинени от прилагането на описаните техники и схеми в този документ.
2. Директорийна структура и съдържание на решението.
Показаната по-долу директорийна структура е по-скоро примерна, а не задължителна. Реализиращият решението има пълната свобода да разположи файловете в системата на място, което е удобно за него.
Файловият набор на решението се състои от два файла. Единият файл е инициализиращ скрипт, а втория е конфигурационен файл за инициализиращия скрипт. Инициализиращият скрипт се намира във файла /usr/local/miltinode-named/init.d/named-node_name, а конфигурацията на инициализиращия скрипт - във файла /usr/local/miltinode-named/sysconfig/named-node_name.
- съдържание на инициращия скрипт /usr/local/miltinode-named/init.d/named-node_name:
#!/bin/bash
#
# Made by Vesselin Kolev
# Based on Red Hat's named init script
#
# named-node_name This shell script takes care of starting and stopping
# multinode named daemon.
#
# chkconfig: - 55 45
# description: named (BIND) is a Domain Name Server (DNS) \
# that is used to resolve host names to IP addresses. \
# This is local setup for multinode support support.
# probe: true
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
[ -r /etc/sysconfig/network ] && . /etc/sysconfig/network
RETVAL=0
prog=`echo $0 | sed -e 's/.*\///'`
# Check that networking is up.
[ "${NETWORKING}" = "no" ] && exit 1
[ -r /etc/sysconfig/$prog ] && . /etc/sysconfig/$prog
[ -x /usr/sbin/$prog ] || exit 1
[ -r ${ROOTDIR}/etc/named.conf ] || exit 1
start() {
# Start daemons.
if [ -n "`/sbin/pidof $prog`" ]; then
echo -n $"$prog: already running"
return 1
fi
echo -n $"Starting $prog: "
ckcf_options='';
if [ -n "${ROOTDIR}" -a "x${ROOTDIR}" != "x/" ]; then
OPTIONS="${OPTIONS} -t ${ROOTDIR}"
ckcf_options="-t ${ROOTDIR}";
if [ -s /etc/localtime ]; then
cp -fp /etc/localtime ${ROOTDIR}/etc/localtime
fi;
fi
conf_ok=0;
if [ -x /usr/sbin/named-checkconf ] && /usr/sbin/named-checkconf $ckcf_options; then
conf_ok=1;
else
RETVAL=$?;
fi
if [ $conf_ok -eq 1 ]; then
daemon /usr/sbin/$prog -u ${NAMED_USER} ${OPTIONS};
RETVAL=$?;
else
named_err=`/usr/sbin/$prog -g 2>&1 | sed s/\n/\\n/g`;
if [ `tty` != "/dev/console" ]; then
echo -e "\n$named_err";
echo -n "Error in configuration file /etc/named.conf : ";
fi;
failure $"Error in configuration file /etc/named.conf : $named_err";
echo
return $RETVAL;
fi;
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog
echo
return $RETVAL
}
stop() {
# Stop daemons.
echo -n $"Stopping $prog: "
/usr/sbin/rndc -s ${BIND_IP} -k ${RNDC_KEY_FILE} stop >/dev/null 2>&1
RETVAL=$?
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog || {
# killproc named
# Never do this! Can cause corrupt zone files!
/usr/sbin/rndc -s ${BIND_IP} -k ${RNDC_KEY_FILE} stop >/dev/null 2>&1
RETVAL=$?
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog
echo
return $RETVAL
}
success
echo
return $RETVAL
}
rhstatus() {
/usr/sbin/rndc -s ${BIND_IP} -k ${RNDC_KEY_FILE} status
return $?
}
restart() {
stop
# wait a couple of seconds for the named to finish closing down
sleep 2
start
}
reload() {
echo -n $"Reloading $prog: "
p=`/sbin/pidof -o %PPID $prog`
RETVAL=$?
if [ "$RETVAL" -eq 0 ]; then
/usr/sbin/rndc -s ${BIND_IP} -k ${RNDC_KEY_FILE} reload >/dev/null 2>&1 || /usr/bin/kill -HUP $p;
RETVAL=$?
fi
[ "$RETVAL" -eq 0 ] && success $"$prog reload" || failure $"$prog reload"
echo
return $?
}
probe() {
# named knows how to reload intelligently; we don't want linuxconf
# to offer to restart every time
/usr/sbin/rndc -s ${BIND_IP} -k ${RNDC_KEY_FILE} reload >/dev/null 2>&1 || echo start
return $?
}
# See how we were called.
case "$1" in
start)
start
;;
stop)
stop
;;
status)
rhstatus
;;
restart)
restart
;;
condrestart)
if [ -e /var/lock/subsys/$prog ]; then restart; fi
;;
reload)
reload
;;
probe)
probe
;;
*)
echo $"Usage: $0 {start|stop|status|restart|condrestart|reload|probe}"
exit 1
esac
exit $?
- съдържание на конфигурацията в /usr/local/miltinode-named/sysconfig/named-node_name:
# BIND named process options
#
# Made by Vesselin Kolev
# Based on Red Hat's /etc/sysconfig/named file
#
# ~~~~~~~~~~~~~~~~~~~~~~~~~~
# Currently, you can use the following options:
#
# ROOTDIR="/some/where" -- will run named in a chroot environment.
# you must set up the chroot environment
# (install the bind-chroot package) before
# doing this.
#
# OPTIONS="whatever" -- These additional options will be passed to named
# at startup. Don't add -t here, use ROOTDIR instead.
#
# ENABLE_ZONE_WRITE=yes -- If SELinux is disabled, then allow named to write
# its zone files and create files in its $ROOTDIR/var/named
# directory, necessary for DDNS and slave zone transfers.
# Slave zones should reside in the $ROOTDIR/var/named/slaves
# directory, in which case you would not need to enable zone
# writes. If SELinux is enabled, you must use only the
# 'named_write_master_zones' variable to enable zone writes.
#
# ENABLE_SDB=yes -- This enables use of 'named_sdb', which has support
# -- for the ldap, pgsql and dir zone database backends
# -- compiled in, to be used instead of named.
NODE_PROCESS_NAME=named-node_name
NAMED_USER=named-node_name_user
ROOTDIR=full_path_to_the_chroot_dir
BIND_IP=IP_ADDRESS_OF_THE_NODE
RNDC_KEY_FILE=full_path_to_the_HMAC-MD5_key_file
3. Процедура по изграждане и управление на нодове.
- Създаване на група и непривилигерован потребител за всеки нод
От гледна точка на сигурността и по-точно сепарацията на привилегии в системата, е добре за всеки нод на демона named да има отделен непривилигирован потребител и групата, към която той принадлежи да съдържа само този потребител. С правата на непривилигерования потребител се изпълняват процесите на демона named за съответния нод.
Едно примерно създаване на група за нод с име as112 би изглеждало по следния начин:
# groupadd named-as112
След това създаването на потребителя може да протече по следния пример-шаблон:
# useradd -g named-as112 -s /bin/false -d /dev/null -c "named user - node as112" named-as112
Подобно по своя характер създаване на група и потребител трябва да следва за всеки от наличните в системата нодове на named.
Ако в системата се следва нумерационен план за GID и UID, в горните командни редове трябва да се укажат желаните числови стойности според нумерационния план.
- Създаване на псевдоними на името на процеса на named за всеки нод
Създаването на псевдоними на процеса на named е задължително, за да може процесите на нодовете да могат да бъдат отличавани по име в системата (всеки нод да има уникално име на процес). Самото създаване на псевдоними се извършва чрез създаване на symlink връзки с различни имена, сочещи към /usr/sbin/named, например:
# ln -s /usr/sbin/named /usr/sbin/named-as112
# ln -s /usr/sbin/named /usr/sbin/named-as5421
създава псевдоними за нодове с имена as112 и as5421. Ефектът от създаването на псевдонимите е такъв, че след стартиране, името на процеса съвпада с името на symlink връзката и така може да се намери неговия PID номер (макар демона named да се управлява само чрез rndc и това в базовия случай да отменя използването на PID номера на майчиния процес, то има случаи, в които се налага да този уникален номер да се знае).
Подобен начин за създване на псевдоними е възможно най-рационалния. Причината е, че при актуализация на пакета bind (в състава на който е файла /usr/sbin/named), става дефакто актуализация и на всички псевдоними. Това например не би било така, ако вместо symlink връзки се използваше копиране на /usr/sbin/named във файлове с имена, свързани с нодовете.
- Създаване на инициращи зареждането на услугата скриптове за всеки нод
Тези скриптове са символни връзки към шаблонния инициращ скрипт с име named-node_name, който се намира в директорията /usr/local/named-multinode/init.d/. За нодовете с имена as112 и as5421, този процес би изглеждал така:
# ln -s /usr/local/named-multinode/init.d/named-node_name /etc/rc.d/init.d/named-as112
# ln -s /usr/local/named-multinode/init.d/named-node_name /etc/rc.d/init.d/named-as5421
По този начин в директорията с инициращите скриптове /etc/rc.d/init.d/, са привидно (symlink) създадени два нови скрипта, които дефинират две нови услуги, а именно named-as112 и named-as5421.
Удобството от такова създаване на услуги е, че инициращия им скрипт много лесно може да се актуализира. Достатъчно е да се направят промени в скрипта-шаблон named-node_name, който се намира в директорията /usr/local/named-multinode/init.d/ и те веднага влизат в сила за всички инициращи скриптове, които сочат към шаблона. Тази схема създава добра функционалност и улеснява лесно актуализациите и повишава надежността и сигурността на услугите.
- Създаване на конфигурационни файлове за инициращите скриптове за всеки нод
Всеки инициращ скрипт за нод има свой конфигурационен файл с променливи. Доколкото всеки нод може да има индивидуални неподаващи се на шаблонизиране стартиращи конфигурационни опции, то конфигурационните файлове за инициращите скриптове не може да се реализират като symlink връзки към шаблон. За това шаблона се копира в директория /etc/sysconfig и му се присвоява същото име, каквото носи инициращия скрипт, с когото е обвързан и след това в него се задват конкретните стартиращи опции за конкретния нод. Ето например как това може да се реализира за примера с нодове с имена as112 и as5421:
# cp /usr/local/named-multinode/sysconfig/named-node_name /etc/sysconfig/named-as112
# cp /usr/local/named-multinode/sysconfig/named-node_name /etc/sysconfig/named-as5421
Едни примерни указания във файла /etc/sysconfig/named-as112 могат да имат вида:
NODE_PROCESS_NAME=named-as112
NAMED_USER=named-as112
ROOTDIR=/home/chroot/named-as112
BIND_IP=192.175.48.1
RNDC_KEY_FILE=/etc/su-as112.key
Подобен пример би могъл да бъде даден и за /etc/sysconfig/named-as5421:
NODE_PROCESS_NAME=named-as5421
NAMED_USER=named-as5421
ROOTDIR=/home/chroot/named-as5421
BIND_IP=62.44.96.1
RNDC_KEY_FILE=/etc/su-as5421.key
- Инсталиране и актуализиране на пакета bind-chroot
От гледна точка на сигурността на услугата, е добре да се използва опционалното заключване на демона named, налично като стартова за него опция. За целта трябва да се изгради chroot директория, в която да стане заключването на процеса. Във Fedora Core и Red Hat Enterprise Linux и дериватите му, създаването на chroot директорията и минималното й съдържание се извършва от пакета bind-chroot. Проверката за това дали пакетът bind-chroot е инсталиран в системата, може да се извърши чрез инструмента rpm по следния начин:
# rpm -q bind-chroot
Ако пакетът е наличен в системата, на нов ред ще бъде изведено името и версията му.
Ако пакетът bind-chroot е наличен в системата е добре да бъде актуализиран (ако са налични актуализирани версии към момента, които не са локално инсталирани). Това може да стане чрез инструмента yum:
# yum update bind-chroot
Ако системата не е дериват, а е оригинален Red Hat Enterprise Linux и в нея няма допълнително инсталиран yum, то актуализацията може да се извърши и с инструмента up2date:
up2date bind-chroot
Ако пакетът bind-chroot не е истиналиран в системата, инсталацията му може да бъде извършена с инструмента yum:
# yum install bind-chroot
Ако се използва Red Hat Enterprise Linux, а не негов дериват и няма допълнително инсталиран инструмент yum, то инсталацията на пакета bind-chroot може да се извърши и чрез инструмента up2date:
up2date -i bind-chroot
Целта на инсталирането на този пакет, ако не е наличен вече в система, е да създаде шаблон за chroot средата, която ще се използва от нодовете. За всеки нод се създава отделна chroot среда, като се използва шаблона инсталиран от bind-chroot във /var/named/chroot.
- Създаване на chroot среда за всеки нод
За всеки нод се създава директория, в която ще се намира съответната за неговия демон named chroot среда. Добре е името на тази директория да бъде ясно свързано с името на нода. Това не е задължително, но е добра практика особено в системи, които се администрират от повече от един администратор:
# mkdir -p /home/chroot/named-as112
# mkdir -p /home/chroot/named-as5421
Чрез този пример се създават chroot директориите за нодовете с имена as112 и as5421. След това чрез инструмента rsync се извършва локално синхронизиране на съдържанието на директорията /var/named/chroot, което бива създадено при инсталиране на пакета bind-chroot, в chroot директориите на нодовете:
# cd /home/chroot
# rsync -var /var/named/chroot/etc /var/named/chroot/dev /var/named/chroot/var named-as112/
# rsync -var /var/named/chroot/etc /var/named/chroot/dev /var/named/chroot/var named-as5421/
Нарочно директориите, които ще бъдат синхронизирани се указват поименно, а не се синхронизира тоталното съдържание на /var/named/chroot. Причината е, че ако /var/named/chroot не е прясно инсталирана, а е използвана за някакъв период от време в ролята й на chroot директория на демона named, то в тази директория може да има монтиране на proc в поддиректория proc/ (може да има и наличие на други директории, които също не са част от прясно инсталирания пакет bind-chroot). Безмислено е тази директория и нейното съдържание да бъде копирано.
Трябва да се отбележи синтаксиса на описание на директориите, които ще бъдат синхронизирани. Указването им става като след името на директорията няма знак за продължения на пътя "/". Причината е следната. Ако има знак за удължаване на пътя "/", то в директорията-цел на синхронизация (такива директории-цели в примера по-горе са /home/chroot/named-as112 и /home/chroot/named-as5421), няма да бъдат създадени поддиректории dev/, etc/ и var/, а съдържанието им ще бъде копирано в директорията-цел без създаването на поддиректориите dev/, etc/ и var/
Използването на rsync в този случай указва на добра практика. Ако след време излезе актуализация на пакета bind-chroot, директорията /var/named/chroot ще бъде използвана като шаблон за актуализация и на chroot директориите за отделните нодове, чрез използване именно на rsync. Разбира се, при това трябва чрез опция "--exclude" да се направи така, че да се избегне изтриването на дефинираните от администратора конфигурационни файлове и зонални файлове, а така също и от създадените от демона named зонални файлове и журнали. Ето примерен команден ред, който актуализира chroot директорията на нодовете от горния пример, спрямо шаблона /var/named/chroot, която засяга само поддиректория dev/:
# cd /home/chroot
# rsync -var --delete-after /var/named/chroot/dev named-as112/
# rsync -var --delete-after /var/named/chroot/dev named-as5421/
ВНИМАНИЕ!!! Всички файлове, които са специфично читаеми или писаеми от демона named-node_name за съотвения нод, трябва да бъдат с така установени права за собственост върху тях, че да се съблюдава факта, че всеки нод се стартира с правата на различен непривилигерован потребител. За горния пример нода на named за as112 се стартира с правата на непривилигерования потребител named-as112, а този за as5421 с правата на непривилигерования потребител named-as5421.
- Управление на услугата по нодове
След като за всеки нод бъдат извършени описаните по-горе стъпки и бъдат поставени специфичните конфигурационни файлове, ключове и зонални файлове, е ред на описанието на процедурите по стартиране, презареждане, проверка на статуса и спиране на услугата. Доколкото дистрибуциите Fedora Core и Red Hat Enterprise Linux (и дериватите му) са SystemV базирани, то за управлението на услугите по нодове се използват отделни инициращи скриптове в директорията /etc/rc.d/init.d. Проверката на наличните чрез инициращия скрипт функционалности за управление може да се извърши така:
# service named-node_name
или пренесено за основния пример, а именно за имена на нодове as112 и as5421:
# service named-as112
# service named-as5421
Примерният изход с налични функционалности от изпълнението на горните командни редове, може да изглежда така:
# service named-as112
Usage: /etc/init.d/named-as112 {start|stop|status|restart|condrestart|reload|probe}
# service named-as5421
Usage: /etc/init.d/named-as5421 {start|stop|status|restart|condrestart|reload|probe}
- Управление на поведението на услугата при зареждане на системата
Стартирането на услугата при зареждането на системата може да се укаже чрез инструмента chkconfig. Първата стъпка е прибавянето на услугата за управление чрез инструмента chkconfig. То може да се извърши по следния модел:
# chkconfig --add named-as112
# chkconfig --add named-as5421
При това прибавяне chkconfig ще прочете заглавната част на инициращия скрипт за съответните нодове, ще провери в кои нива на стартиране на системата трябва да се стартират нодовете и ще изгради нужните за това symlink връзки в директорията на съответното ниво (по подразбиране сървърските инсталации без стартирана графична среда се зареждат в ниво номер 3 - initlevel 3).
Ако след това се налага някой нод да бъде неактивен в дадено ниво на стартиране на системата, то дезактивирането може да се осъществи чрез chkconfig по начин, подобен на следния
# chkconfig --level 5 named-as112 off
# chkconfig --level 5 named-as5421 off
В този пример се извършва дезактивирането на нодове as112 и as5421 при стартиране на системата в ниво 5 (initlevel 5). Ако трябва да се направи активиране в дадено ниво, вместо "off" като аргумент се използва "on". Ако трява да се върне състоянието "по подразбиране" на услугата в дадено ниво (това, зададено в заглавната част на инициращия скрипт), се указва опцията "reset".
Премахването на дадена услуга, свързана с нод, от обслужване в рамките на процеса на зареждане на услуги в различните стартови нива на системата, може да стане чрез използването на инструмента chkconfig, като се следва схемата:
# chkconfig --del named-as112
4. Особености на използването на rndc при многонодов режим на работа на named.
Rndc е инструмент за управление на демона named през TCP сокет. В дистрибуциите Fedora Core и Red Hat Enterprise Linux (и дериватите му), по подразбиране rndc чете настройките си от конфигурационния файл /etc/rndc.conf. В случаите на еднонодова инсталация (както е по подразбиране при инсталация на пакета bind), това не е проблем. Всички команди, които ще бъдат подадени чрез rndc към демона named следват простия синтаксис "rndc commnad", доколкото в /etc/rndc.conf е указано командите да отиват по подразбиране към rndc порта на даден IP адрес. В случаите на многонодова BIND9 инсталация, подаването на команди към даден нод чрез rndc е по-комплексно. Доколкото всеки нод на named е обвързан с конкретен IP адрес, то rndc трябва да знае към кой точно нод да изпрати командата и следователно трябва от някъде да взима информация за IP адреса му (и евентуално номера на порт, на който named приема rndc комуникация, ако този порт е различен от стандартния).
При изпращането на команда към демона named на даден нод чрез rndc, се използва указване на IP адреса, до който тази команда се изпраща. За целта се използва наличната за това опция "-s" на rndc. Указването на IP адрес чрез опцията "-s" не решава напълно проблема. Нужно е да се укаже и ключ за използването му в алгоритъм HMAC-MD5, чрез който между rndc и named да тече електронно подписана комуникация. Добре е всеки нод да използва различен подписващ ключ. Има три варианта на указване на ключа, който rndc да използва за да подписва електронно комуникацията с даден нод: по име на файл, който го съдържа, по име на ключа или като асоциация на име на ключ към IP адрес на нод.
Ако се използва директно указване на ключа като файл, който го съдържа, командния ред за извикване на rndc с цел подаване на команда за проверка на статуса на нода с IP адрес 192.175.48.1 би изглеждал така:
# rndc -s 192.175.48.1 -k /etc/su-as112.key status
Ако се използва името на ключа, то този ключ трябва да е включен във файла /etc/rndc.conf чрез указването на пълния път до файла, който съдържа ключа с това име. Това указване става чрез декларацията "include" на отделен ред във файла /etc/rndc.conf, например:
include "/etc/su-as112.key";
В един файл може да има повече от един ключ, но в рамките на включваните по този начин ключове в /etc/rndc.conf не трява да има два ключа с едно и също име. Ако се използва тази концепция, може да се даде следния пример на командния ред за извикване на rndc с цел подаване на команда за проверка на статуса на нода с IP адрес 192.175.48.1:
# rndc -s 192.175.48.1 -y su-as112 status
Тази концепция важи и в случаите, когато се извиква файл (чрез опция "-k"), в който се намират повече от един ключа и трябва да се укаже кой точно от тях да се използва.
По-лесният начин е във файла /etc/rndc.conf да се укаже асоциация на даден ключ към даден адрес на нод. По този начин на rndc се указва само IP адреса на нода и той сам намира ключа, чрез който да подписва електронно комуникацията. За да може да се реализира това ниво на автоматизация на избора на ключ, в /etc/rndc.conf се използват структури подобни на следната:
server 192.175.48.1 {
key "su-as112";
};
include "/etc/su-as112.key";
В примера се предполага, че ключът с име su-as112 се намира във файла /etc/su-as112.key. Подобна структура се изгражда за всеки един нод, с който ще се води електронно подписана комуникация иницирана чрез инструмента rndc. За пример може да се покаже как в този случай би изглеждал командния ред за извикване на rndc с цел подаване на команда за проверка на статуса на нода с IP адрес 192.175.48.1:
# rndc -s 192.175.48.1 status
добре
зле
Вариант за отпечатване
