"
# Is named up? Check the status of named.
case `ndc status 2>&1` in
*'cannot connect to command channel'*)
echo "named is DOWN. root.hints was NOT updated"
echo
exit 0
;;
esac
PATH=/sbin:/usr/sbin:/bin:/usr/bin:
export PATH
# NOTE: /var/named must be writable only by trusted users or this script
# will cause root compromise/denial of service opportunities.
cd /var/named 2>/dev/null || {
echo "Subject: Cannot cd to /var/named, error $?"
echo
echo "The subject says it all"
exit 1
}
# Are we online? Ping a server at your ISP
case `ping -qnc 1 some.machine.net 2>&1` in
*'100% packet loss'*)
echo "Subject: root.hints NOT updated. The network is DOWN."
echo
echo "The subject says it all"
exit 1
;;
esac
dig @e.root-servers.net . ns >root.hints.new 2> errors
case `cat root.hints.new` in
*NOERROR*)
# It worked
:;;
*)
echo "Subject: The root.hints file update has FAILED."
echo
echo "The root.hints update has failed"
echo "This is the dig output reported:"
echo
cat root.hints.new errors
exit 1
;;
esac
echo "Subject: The root.hints file has been updated"
echo
echo "The root.hints file has been updated to contain the following
information:"
echo
cat root.hints.new
chown root.root root.hints.new
chmod 444 root.hints.new
rm -f root.hints.old errors
mv root.hints root.hints.old
mv root.hints.new root.hints
ndc restart
echo
echo "The nameserver has been restarted to ensure that the update is complete."
echo "The previous root.hints file is now called
/var/named/root.hints.old."
) 2>&1 | /usr/lib/sendmail -t
exit 0
______________________________________________________________________
Някои от вас, ще кажат че root.hints file може да се намери и от
ftp сървъри от Internic. Моля не използвайте ftp за обновяване
root.hints, горния метод е по-добър за мрежата ... и за Internic.
9. Преминаване от версия 4 към версия 8
Това всъщност е главата за използване на BIND 8 написана от David E.
Smith (dave@bureau42.ml.org). Редактирана съобразно новото й име.
Няма какво толкова за вършене, освен използването на named.conf вместо
named.boot, всичко е идентично. BIND 8 идва с perl скрипт
които "превежда" стария стил файловете в новия. Примерен named.boot
(стар стил) за само кеширащ сървър:
______________________________________________________________________
directory /var/named
cache . root.hints
primary 0.0.127.IN-ADDR.ARPA 127.0.0.zone
primary localhost localhost.zone
______________________________________________________________________
От командния ред, в директорията bind8/src/bin/named (при
положение че имате дистрибуция с изходните кодове. Ако имате
binary пакет, скрипта може би е някъде там, не съм сигурен къде
би трябвало да бъде.), напишете:
______________________________________________________________________
./named-bootconf.pl < named.boot > named.conf
______________________________________________________________________
Което ще създаде named.conf:
______________________________________________________________________
// generated by named-bootconf.pl
options {
directory "/var/named";
};
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "127.0.0.zone";
};
zone "localhost" {
type master;
file "localhost.zone";
};
______________________________________________________________________
Работи за всичко което може да имате в named.boot, но не
добавя нови допълнения и опции , които BIND 8 позволява.
Ето по-завършен named.conf който изпълнява същите неща,
но е малко по-ефективен.
______________________________________________________________________
// This is a configuration file for named (from BIND 8.1 or later).
// It would normally be installed as /etc/named.conf.
// The only change made from the `stock' named.conf (aside from this
// comment :) is that the directory line was uncommented, since I
// already had the zone files in /var/named.
options {
directory "/var/named";
datasize 20M;
};
zone "localhost" IN {
type master;
file "localhost.zone";
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "127.0.0.zone";
};
zone "." IN {
type hint;
file "root.hints";
};
______________________________________________________________________
В директорията bind8/src/bin/named/test от пакета BIND 8 ще намерите
това, както и копие от файловете за зоните, които повечето хора
могат да вземат и използват веднага.
Формата на файловете за зони и root.hints са идентични, както и
командите за тяхното обновяване.
10. Въпроси и Отговори
Първо прочетете това преди да ми пишете.
1. Named иска файл named.boot
Четете грешно HOWTO. Моля вижте старата версия на
това HOWTO, която описва BIND 4, на
2. Как да използвам DNS зад защитна стена ?
Съвет : forward only;. Може да имате нужда и от
___________________________________________________________________
query-source port 53;
___________________________________________________________________
вътре в частта ``options'' на файла named.conf както посъветвах в
примера в главата за кеширане.
3. Как да накарам DNS да редува няколко възможни адреса за
услуга, да кажем www.busy.site за да се постигне баланс на
натоварването или нещо подобно?
Направете няколко A записа за www.busy.site и използвайте BIND 4.9.3
или по-нов. След това BIND ще редува отговорите. Това не работи
при по-старите версии на BIND.
4. Искам да настроя DNS в (затворен) intranet. Какво да направя ?
Пропуснете файла root.hints и просто конфигурирайте зоните. Това
означава, че няма нужда постоянно да обновявате файла root.hint.
5. Как на настроя подчинен сървър ?
Ако главния сървър има адрес 127.0.0.1 сложете следното
във вашия named.conf файл :
___________________________________________________________________
zone "linux.bogus" {
type slave;
file "sz/linux.bogus";
masters { 127.0.0.1; };
};
___________________________________________________________________
Може да изброите няколко главни сървъри , разделени
с ';' (точка и запетая).
6. Искам BIND да работи когато не съм свързан с мрежата.
Ето четири начина да постигнете това :
· Относно BIND 8, Adam L Rice ми изпрати това писмо, за това как
стартира DNS на dialup връзка без да му създава проблеми:
Открих, че при новите версии на BIND
[
директива "forward" в допълнение на директивата "forwarders" която
контролира как се използват. По подразбиране е "forward first",
което първо пита всеки от forwarders, и след това опитва нормалния
си подход на работа ако това се провали. Това е подобно на
обичайното поведение на gethostbyname() отнемайки необичайно много
време когато няма връзка. Ако "forward only" е сложено , тогава BIND
се отказва когато не получи отговор от forwarders, и
gethostbyname() връща моментално. Оттук следва че няма нужда да
изпълнява sleight-of-hand с файлове в /etc и рестартиране на сървърът.
В моя случай, просто добавих
forward only;
forwarders { 193.133.58.5; };
в частта options { } на моят named.conf файл. Работи доста добре.
Единственото неудобство е че изключително намаля комплексността
на част от DNS софтуера до статуса на кеша. В тази насока, бих
искал да проверявам само DNS кеша , но изглежда няма такава
програма за Linux.
· Получих това писмо от Ian Clark където
описва как той се справил с този проблем :
Стартирам named на моята 'Masquerading' машина. Имам
два root.hints файла, единия наречен root.hints.real който съдържа
истинските коренни сървъри и друг наречен root.hints.fake ,
който съдържа ...
----
; root.hints.fake
; this file contains no information
----
Когато съм изключен копирам root.hints.fake като root.hints и
рестартирам named.
Когато се включа копирам файла root.hints.real като root.hints и
рестартирам named.
Правя това с ip-down & ip-up съответно.
Първият път когато дам заявка когато съм изключен за име за което
named няма информация слага съобщение като това в messages.
Jan 28 20:10:11 hazchem named[10147]: No root nameserver for class IN
а това е нещо с което мога да живея.
Това определено работи при мен.Използвам сървъра на
локалната машина когато съм изключен без да има закъснение за
външни заявки , а когато съм ``вързан" външните заявки си
работят както е нормално.
- Според Peter Denison обаче, Ian не е обмислил всичко достатъчно.
Изпрати ми това :
Когато съм свързан) предоставя цялата кеширана (и на локалната мрежа)
информация незабавно, а за не-кеширана пита сървъра на
доставчикът ми
Когато не съм) предоставя локалните заявки незабавно, а за всички останали
не успява **моментално**
Комбинацията със сменянето на файла и пренасочените заявки
не работи .
Така, аз конфигурирах (с малко дискусия в местната LUG) два named
както следва :
named-online: forwards to ISPs nameserver
master for localnet zone
master for localnet reverse zone (1.168.192.in-addr.arpa)
master for 0.0.127.in-addr.arpa
listens on port 60053
named-offline: no forwarding
"fake" root cache file
slave for 3 local zones (master is 127.0.0.1:60053)
listens on port 61053
Комбинирайки това с пренасочване на портове, изпращам порт 53 към
61053 когато не съм свързан, и към 60053 когато съм свързан (използвам
новият netfilter под 2.3.18, но и стария (ipchains) механизъм би трябвало да
работи.)
· Също така получих информация за това как се държи BIND с NFS
и portmapper на повечето offline машини от Karl-Max Wanger:
Използвам собствен named на всичките ми машини които
се свързват в Internet чрез модем.Всъщност сървърът
само кешира, няма зона за authority и пита за всичко
сървърите описано във файла root.cache. Както е нормално
за Slackware, той се стартира преди nfsd и mountd.
При една от моите машини (notebook Libretto 30) имах проблем
че понякога можех да го монтирам от друга система свързана в
моята LAN, но повечето пъти това не ставаше. Имах същият ефект
независимо дали използвах PLIP, PCMCIA ethernet карта или PPP
през серийния интерфейс.
След като поразпитах и експериментирах открих че
очевидно named се намесваше при стартирането на nfsd и
mountd , така че стартирах тези daemons по време на стартирането
както нормално и след това стартирах named. Проблема се
разреши напълно.
Тъй като няма проблем от такава промяна на реда на
стартиране, съветвам всички да го сторят за да предотвратят
подобен проблем.
· Накрая, има HOWTO информация за това при Ask Mr. DNS на
. Тя е за BIND 4,
така че трябва да я преправите за BIND 8.
7. Къде сървъра запазва кешираната информация ? Има ли начин
да контролирам големината на кеша ?
Кешът се записва изцяло в паметта, не се записва на диск
никога. Всеки път когато спрете named кеша се загубва. Кешът
се регулира все пак . named го подържа в зависимост от
няколко прости правила и това е. Не може да контролирате
големината му във всички случаи по всяко правило. Ако искате
може да ``поправите'' това като промените named, това обаче
не се препоръчва.
8. Записва ли named кеша между рестартиранията? Мога ли
да го направя да го запазва?
Не, named не запазва кеша когато "умира". Това означава
че кеша се изгражда наново всеки път когата рестартирате named.
Няма начин да накарате named да запазва кеша във файл. Ако искате
може да ``поправите'' това като промените named,това обаче
не се препоръчва.
9. Как мога да получа домейн? Как да настроя мои собствен домейн
(например) linux-rules.net. Как да получа домейн приписан на мен?
Моля свържете се с вашия доставчик. Те ще могат да ви
помогнат. Отбележете, че в повечето точки на света
трябва да платите за да получите домейн.
10. Как да направя моят DNS сървър по-сигурен? Как да конфигурирам
разделен DNS?
И двете са теми за напреднали. Описани са в
. Няма
да ги обяснявам тук.
11. Как да стана по-добър DNS администратор.
Документации и помощни инструменти.
Real Documentation exists. Online and in print. The reading of
several of these is required to make the step from small time DNS
admin to a big time one. In print I have written The Concise Guide to
DNS and BIND (by Nicolai Langfeldt), published by Que (ISDN
0-7897-2273-9). The book is much like this HOWTO. Just more details,
and a lot more of everything. But the standard book is DNS and BIND
by C. Liu and P. Albitz from O'Reilly & Associates (ISBN
0-937175-82-X). It's excellent too. Get the 3rd edition, it covers
BIND 8 as well as BIND 4. There is also a section on DNS in TCP/IP
Network Administration, by Craig Hunt from O'Reilly (ISBN
0-937175-82-X). Another must for good DNS administration (or good
anything for that matter) is Zen and the Art of Motorcycle Maintenance
by Robert M. Pirsig :-) Available as ISBN 0688052304 and others.
Online you will find stuff on (DNS
Resources Directory), ; A FAQ, a
reference manual (BOG; BIND Operations Guide) as well as papers and
protocol definitions and DNS hacks (these, and most, if not all, of
the RFCs mentioned below, are also contained in the BIND
distribution). I have not read most of these, but then I'm not a big-
time DNS admin either. Arnt Gulbrandsen on the other hand has read
BOG and he's ecstatic about it :-). The newsgroup
is about DNS. In addition there
are a number of RFCs about DNS, the most important are probably the
ones listed here. Those that have BCP (Best Current Practice) numbers
are highly recommended.
RFC 2671
P. Vixie, Extension Mechanisms for DNS (EDNS0) August 1999.
RFC 2317
, BCP 20, H. Eidnes et. al. Classless IN-ADDR.ARPA delegation,
March 1998. This is about CIDR, or classless subnet reverse
lookups.
RFC 2308
, M. Andrews, Negative Caching of DNS Queries, March 1998.
About negative caching and the $TTL zone file directive.
RFC 2219
, BCP 17, M. Hamilton and R. Wright, Use of DNS Aliases for
Network Services, October 1997. About CNAME usage.
RFC 2182
, BCP 16, R. Elz et. al., Selection and Operation of Secondary
DNS Servers, July 1997.
RFC 2052
A. Gulbrandsen, P. Vixie, A DNS RR for specifying the location
of services (DNS SRV), October 1996
RFC 1918
Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear,
Address Allocation for Private Internets, 02/29/1996.
RFC 1912
D. Barr, Common DNS Operational and Configuration Errors,
02/28/1996.
RFC 1912 Errors
B. Barr Errors in RFC 1912, this is available at
RFC 1713
A. Romao, Tools for DNS debugging, 11/03/1994.
RFC 1712
C. Farrell, M. Schulze, S. Pleitner, D. Baldoni, DNS Encoding of
Geographical Location, 11/01/1994.
RFC 1183
R. Ullmann, P. Mockapetris, L. Mamakos, C. Everhart, New DNS RR
Definitions, 10/08/1990.
RFC 1035
P. Mockapetris, Domain names - implementation and specification,
11/01/1987.
RFC 1034
P. Mockapetris, Domain names - concepts and facilities,
11/01/1987.
RFC 1033
M. Lottor, Domain administrators operations guide, 11/01/1987.
RFC 1032
M. Stahl, Domain administrators guide, 11/01/1987.
RFC 974
C. Partridge, Mail routing and the domain system, 01/01/1986.