DNS HOWTO
Nicolai Langfeldt (janl@linpro.no), Jamie Norrish and others (English)
Христо Илиев (ik0@mailbg.net) 2001 (Български)
Version 3.1, 2001-01-18
КАКДА стана DNS администратор за изключително кратко време.
______________________________________________________________________
Съдържание
1. Предисловие
1.1 Законови права
1.2 Благодарности и молба за помощ.
1.3 Посвещение
2. Въведение
3. Преобразуващ и кеширащ сървър на имената
3.1 Стартиране на named
3.2 Преобразуватели (Resolvers)
3.3 Поздравления
4. Пренасочване
5. Проста настройка на домейн
5.1 Но първо малко суха теория
5.2 Наш собствен домейн
5.3 Обратната зона
5.4 Внимание
5.5 Защо обърнатите заявки не работят.
5.5.1 Обратната зона не е делегирана.
5.5.2 Имате извънкласова подмрежа
5.6 Подчинени сървъри
6. Основни опции за сигурността.
6.1 Ограничаване предаването на зоните
6.2 Защита срещу spoofing
6.3 Стартиране на named без root привилегии
7. Един истински пример
7.1 /etc/named.conf (or /var/named/named.conf)
7.2 /var/named/root.hints
7.3 /var/named/zone/127.0.0
7.4 /var/named/zone/land-5.com
7.5 /var/named/zone/206.6.177
8. Поддръжка
9. Преминаване от версия 4 към версия 8
10. Въпроси и отговори
11. Как да стана по-голям DNS администратор.
______________________________________________________________________
1. Предисловие
Ключови думи: DNS, BIND, BIND 4, BIND 8, named, dialup, PPP, slip, ISDN,
Internet, domain, name, resolution, hosts, caching.
Този документ е част от Linux Documentation Project.
1.1. Законови права
(C)opyright 1995-2001 Nicolai Langfeldt, Jamie Norrish & Co. Do not
modify without amending copyright, distribute freely but retain
copyright message.
1.2. Благодарности и молба за помощ.
Искам да благодаря на Arnt Gulbrandsen който ме изтърпя по време на
черновите ми по този проект и за неговите полезни предложения. Също
искам да благодаря на всички които ми изпратиха писма с предложения
и бележки.
Това никога нима да бъде завършен документ; моля изпращайте писма с
проблеми и техни разрешения. Ти може направиш това HOWTO по-добро.
Моля изпращайте коментари и/или въпроси или пари на janl@linpro.no. Или
си купете моята книга за DNS. Виж библиографията накрая. Ако
изпратите писмо и искате отговор моля проявете малко вежливост като
се уверите че обратния адрес е валиден и работещ . Също,
моля прочетете частта ``ВиО'' преди да ми пишете . Освен това, Аз
разбирам само Норвежки и Английски.
Това е КАК-ДА (HOWTO). Поддържам го като част от LDP от 1995.
През 2000 година написах книга по същата тема. Искам да кажа,
въпреки че това HOWTO прилича много на книгата, не е
съкратена версия за търговска реклама на книгата. Въпреки това
ще намерите книгата в библиографията в края на това HOWTO.
Читателите на това HOWTO ми помогнаха да разбера, че е трудно
да се разбере DNS. За това помага книгата, но книгата също ми
ми помогна да мисля от какво това HOWTO се нуждае. Това HOWTO
е като баща на книгата. Книгата се зароди от версия 3 на това HOWTO.
Благодарности на издателя ми, че ми даде шанс :-)
1.3. Посвещение
Това HOWTO е посветено на Anne Line Norheim Langfeldt. Въпреки че тя
сигурно никога няма да го прочете, защото не е такъв тип момиче.
2. Въведение.
Какво е това и какво не е.
DNS е съкращение от Domain Name System (Система за домейн имената).
DNS преобразува имената на машините в IP адреси,
каквито всички машини в мрежата имат. Преобразува (или "maps"
казано на жаргон) от име в адрес и от адрес в име,
и няколко други неща. Това HOWTO описва как се определя такъв
mappings използвайки Unix система, и няколко неща специфични за Linux.
Мапинга е просто асоциация между две неща, в случая
името на машината, като ftp.linux.org, и IP номера (адреса) на машината
199.249.150.4. DNS съдържа също мапинг по обратния начин,
от IP номерът към името на машината; това се нарича "обратен
мапинг".
DNS е, за непосветен (ти ;-), една от най-неразбираемите части на
мрежовото администриране. За щастие DNS не е чак толкова труден.Това
HOWTO ще се опита да направи нещата малко по-ясни. Описва как да
настройте прост DNS сървър, започвайки със само кеширащ сървър и
продължавайки с настройките на главен DNS сървър. За
по-комплексни настройки вижте главата ``ВиО'' в този документ.
Ако там не са описани, то трябва да прочетете Истинска Документация.
Ще се върна отново на това какво съдържа тази Истинска Документация
в ``последната глава''.
Преди да започнете трябва на настройте вашата машина, така че
да можете свържете с нея с telnet, и успешно да извършвате всякакви
връзки с Мрежата, и особено да можете да извършите telnet
127.0.0.1 и да видите собствената си машина (пробвайте сега!). Нуждаете се
от добри /etc/nsswitch.conf, /etc/resolv.conf и /etc/hosts файлове като за
начало, защото няма да обяснявам функциите им тук. Ако все още
не сте ги настроили или не работят, Networking-HOWTO
и/или Networking-Overview-HOWTO обясняват как да го направите.
Прочетете ги.
Когато казвам `вашата машина' имам предвид машината на която се опитвате
да настройте DNS , не някоя друга машина която имате или някоя по мрежата.
Приемам, че не сте зад защитна стена, която блокира заявките.
Ако се нуждаете от специални настройки --- вижте главата ``ВиО''.
Предаването на имената Unix се извършва от програма наречена named. Това е
част от пакета ``BIND'' който се координира от The Internet
Software Consortium. Named е включен в повечето Linux дистрибуции
и обикновено е инсталиран като /usr/sbin/named, обикновено от пакет
наречен BIND.
Ако имате named може да го използвате; ако нямате
може да изтеглите най-новия и най-готин изходен код
(source) от . Това HOWTO е за
BIND версия 8. Старата версия на това HOWTO, за BIND 4, е
достъпна на в случай че използвате
BIND 4. Ако man страницата на named се говори за (на края, в графата
FILES) named.conf вие имате BIND 8; ако се говори за named.boot
имате BIND 4. Ако имате 4 по причини за сигурност е добре
да преминете до най-новата версия на BIND 8. Сега.
DNS е световна база данни. Внимавайте какво слагате в нея. Ако
слагате излишни неща, вие и другите ще ги получавате. Поддържайте
вашия DNS малък и последователен и ще получите добри резултати от него.
Научете се да го използвате, администрирате, подобрявате и ще
станете следващия добър администратор, пазещ мрежата
да не затъне до колене от безотговорно управление.
Съвет: Правете копие на всички файлове които променяте,
а вече имате, така ако след като прочетете това и нещо не
работи, можете да си върнете отново работещата конфигурация.
3. Преобразуващ и кеширащ сървър на имената.
За първи досег с DNS конфигуриране, много полезен за потребители
използващи за връзка с мрежата модем, кабелен модем или ADSL.
При Red Hat и Red Hat подобни дистрибуции може да постигнете подобен
практически резултат както от първата част на това HOWTO инсталирайки
пакетите bind, bind-utils и caching-nameserver. Ако използвате Debian
просто инсталирайте bind и bind-doc. Разбира се само инсталирането на тези
пакети няма да ви научи така както прочитането на това HOWTO. Затова
инсталирайте пакетите, и след това прочетете и проверете коректността
на инсталираните файлове.
Кеширащия сървър на имена ще намира отговор на заявките за име
и ще помни отговорът, следващия път когато ви потрябва. Това значително
ще намали чакането на отговор от отдалечен DNS сървър, особено ако
сте с бавна връзка.
Първо се нуждаете от файл наречен /etc/named.conf (Debian:
/etc/bind/named.conf). Този файл се чете при стартирането на named.
За сега той съдържа само:
______________________________________________________________________
// Config file for caching only name server
options {
directory "/var/named";
// Uncommenting this might help if you have to go through a
// firewall and things are not working out. But you probably
// need to talk to your firewall admin.
// query-source port 53;
};
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};
______________________________________________________________________
Различните Linux дистрибуции може да използват различни имена за всеки
файл споменат тука, но те съдържат същите неща.
Редът `directory' казва на named къде да търси файловете. Всички
файлове впоследствие ще бъдат относно това. Така pz е
директория след /var/named, т.е., /var/named/pz. /var/named е
главната директория според Linux File system Standard.
Файла наречен /var/named/root.hints е главното тука.
/var/named/root.hints съдържа това: (Ако копирате (cut and paste) този
файл от електронна версия на този документ, отбележете че
не трябва да има интервали в началото, т.е. всички редове
трябва да започват с не-празен символ. Някои програми
добавят интервали в началото на редовете, които могат да
предизвиквайки объркване. В такъв случай, премахнете
началните интервалите)
______________________________________________________________________
;
; There might be opening comments here if you already have this file.
; If not don't worry.
;
. 6D IN NS M.ROOT-SERVERS.NET.
. 6D IN NS I.ROOT-SERVERS.NET.
. 6D IN NS E.ROOT-SERVERS.NET.
. 6D IN NS D.ROOT-SERVERS.NET.
. 6D IN NS A.ROOT-SERVERS.NET.
. 6D IN NS H.ROOT-SERVERS.NET.
. 6D IN NS C.ROOT-SERVERS.NET.
. 6D IN NS G.ROOT-SERVERS.NET.
. 6D IN NS F.ROOT-SERVERS.NET.
. 6D IN NS B.ROOT-SERVERS.NET.
. 6D IN NS J.ROOT-SERVERS.NET.
. 6D IN NS K.ROOT-SERVERS.NET.
. 6D IN NS L.ROOT-SERVERS.NET.
;
M.ROOT-SERVERS.NET. 6D IN A 202.12.27.33
I.ROOT-SERVERS.NET. 6D IN A 192.36.148.17
E.ROOT-SERVERS.NET. 6D IN A 192.203.230.10
D.ROOT-SERVERS.NET. 6D IN A 128.8.10.90
A.ROOT-SERVERS.NET. 6D IN A 198.41.0.4
H.ROOT-SERVERS.NET. 6D IN A 128.63.2.53
C.ROOT-SERVERS.NET. 6D IN A 192.33.4.12
G.ROOT-SERVERS.NET. 6D IN A 192.112.36.4
F.ROOT-SERVERS.NET. 6D IN A 192.5.5.241
B.ROOT-SERVERS.NET. 6D IN A 128.9.0.107
J.ROOT-SERVERS.NET. 6D IN A 198.41.0.10
K.ROOT-SERVERS.NET. 6D IN A 193.0.14.129
L.ROOT-SERVERS.NET. 6D IN A 198.32.64.12
______________________________________________________________________
Този файл описва коренните (root) сървъри на имена в света. Сървърите
се променят с времето. Вижте ``техн. експлоатация'' как да го поддържате
с най-новите промени.
Следващата част в named.conf е последната зона. Ще обясня нейната
употреба в следващите глави; за сега просто създайте този файл
наречен 127.0.0 в поддиректория pz: (Отново, моля махнете
началните интервали, ако копирате от тук)
______________________________________________________________________
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
1 ; Serial
8H ; Refresh
2H ; Retry
4W ; Expire
1D) ; Minimum TTL
NS ns.linux.bogus.
1 PTR localhost.
______________________________________________________________________
След това, се нуждаете от /etc/resolv.conf ,нещо като това : (Отново:
Изтрийте интервалите!)
______________________________________________________________________
search subdomain.your-domain.edu your-domain.edu
nameserver 127.0.0.1
______________________________________________________________________
Редът `search' описва кои домейни да се претърсват за всички имена
на хостове към които искате да се свържете. Редът `nameserver' указва
адреса на вашия сървър на имената, в случая вашата собствена машина
тъй като е стартиран named (127.0.0.1 е правилно, без значение дали вашата
има и друг адрес). Ако искате списък от сървъри
слагайте по един `nameserver' на всеки ред. (Забележка: Named никога не
чете този файл, програмите които използват named го правят. Забележка 2:
В някои resolv.conf файлове има ред "domain". Това е добре, но
не използвайте "search" и "domain" едновременно, само едно от двете
ще работи).
Ето какво прави този файл: Ако клиент търси foo,
тогава foo.subdomain.your-domain.edu се опитва първо, след това foo.your-
domain.edu, и накря foo. Не би трябвало да поставяте твърде много
домейни в реда "search", защото отнема време да се търсят всички.
В примера се допуска, че вие принадлежите на домейна subdomain.your-
domain.edu; вашата машина, тогава, вероятно се нарича your-
machine.subdomain.your-domain.edu. Редът "search" не би трябвало да съдържа
вашият TLD (Top Level Domain, `edu' в случая). Ако често се налага
да се свързвате към машина с друг домейн, може да добавите домейна в
в редът "search" , например : (Не забравяйте да махнете началните
интервали, ако има такива)
______________________________________________________________________
search subdomain.your-domain.edu your-domain.edu other-domain.com
______________________________________________________________________
и така нататък. Естествено трябва да поставите истински имена да
домейни. Моля отбележете липсата на точки в края на имената на
домейните. Това е важно.
3.1. Стартиране на named
След всичко това е време да стартираме named. Ако използвате dialup
връзка свържете се първо. Напишете `ndc start', и натиснете return, без
параметри. Ако не става, пробвайте `/usr/sbin/ndc start'. Ако все още
има проблеми вижте главата ``ВиО''. Ако гледате вашия syslog
message файл (обикновено /var/adm/messages, или в директорията
/var/log ) докaто стартирате named (изпълнете tail -f /var/log/messages)
трябва да видите нещо като това:
(редовете завършващи с \ продължават на следващия)
Dec 15 23:53:29 localhost named[3768]: starting. named 8.2.2-P7 \
Fri Nov 10 04:50:23 EST 2000 ^Iprospector@porky.\
devel.redhat.com:/usr/src/bs/BUILD/bind-8.2.2_P7/\
src/bin/named
Dec 15 23:53:29 localhost named[3768]: hint zone "" (IN) loaded\
(serial 0)
Dec 15 23:53:29 localhost named[3768]: Zone "0.0.127.in-addr.arpa"\
(file pz/127.0.0): No default TTL set using SOA\
minimum instead
Dec 15 23:53:29 localhost named[3768]: master zone\
"0.0.127.in-addr.arpa" (IN) loaded (serial 1)
Dec 15 23:53:29 localhost named[3768]: listening on [127.0.0.1].53 (lo)
Dec 15 23:53:29 localhost named[3768]: listening on [10.0.0.129].53\
(wvlan0)
Dec 15 23:53:29 localhost named[3768]: Forwarding source address is\
[0.0.0.0].1034
Dec 15 23:53:29 localhost named[3769]: Ready to answer queries.
Ако има съобщение за грешка , Named ще ви каже в кои файл е тя.
Върнете се и погледнете файла. Стартирайте "ndc restart" когато
поправите грешката.
Сега може да тествате вашите настройки. Обикновено програма
наречена nslookup се използва за това. В наши дни се препоръчва
да използвате dig .
$ dig -x 127.0.0.1
; <<>> DiG 8.2 <<>> -x
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;; 1.0.0.127.in-addr.arpa, type = ANY, class = IN
;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 1D IN PTR localhost.
;; AUTHORITY SECTION:
0.0.127.in-addr.arpa. 1D IN NS ns.penguin.bv.
;; Total query time: 30 msec
;; FROM: lookfar to SERVER: default -- 127.0.0.1
;; WHEN: Sat Dec 16 00:16:12 2000
;; MSG SIZE sent: 40 rcvd: 110
Ако това е което сте получили, значи работи. Поне се надяваме.
Ако получите нещо друго, върнете се обратно и проверете
всичко. Всеки път когато променяте named.conf трябва да
рестартирате named using с командата "ndc restart" .
Сега въведете запитване. Опитайте някоя машина близо до вас.
pat.uio.no и близо до мен, в Университета в Осло:
$ dig pat.uio.no
; <<>> DiG 8.2 <<>> pat.uio.no
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUERY SECTION:
;; pat.uio.no, type = A, class = IN
;; ANSWER SECTION:
pat.uio.no. 1D IN A 129.240.130.16
;; AUTHORITY SECTION:
uio.no. 1D IN NS nissen.uio.no.
uio.no. 1D IN NS ifi.uio.no.
uio.no. 1D IN NS nn.uninett.no.
;; ADDITIONAL SECTION:
nissen.uio.no. 1D IN A 129.240.2.3
ifi.uio.no. 1H IN A 129.240.64.2
nn.uninett.no. 1D IN A 158.38.0.181
;; Total query time: 112 msec
;; FROM: lookfar to SERVER: default -- 127.0.0.1
;; WHEN: Sat Dec 16 00:23:07 2000
;; MSG SIZE sent: 28 rcvd: 162
Този път dig пита вашият named да търси машината pat.uio.no. Той
се свързва с един от сървърите описани във вашият
root.hints файл, и пита сървър далеч от вас. Може да мине малко
време преди да получите резултат защото може да търси във всички
домейни описани в /etc/resolv.conf. Моля отбележете "aa" в
редът "flags:". Това означава, че отговорът е достоверен, т.е. че
взет от достоверен сървър. Ще обясня "достоверен" по-късно.
Ако попитате пак, ще получите това :
$ dig pat.uio.no
; <<>> DiG 8.2 <<>> pat.uio.no
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUERY SECTION:
;; pat.uio.no, type = A, class = IN
;; ANSWER SECTION:
pat.uio.no. 23h59m58s IN A 129.240.130.16
;; AUTHORITY SECTION:
UIO.NO. 23h59m58s IN NS nissen.UIO.NO.
UIO.NO. 23h59m58s IN NS ifi.UIO.NO.
UIO.NO. 23h59m58s IN NS nn.uninett.NO.
;; ADDITIONAL SECTION:
nissen.UIO.NO. 23h59m58s IN A 129.240.2.3
ifi.UIO.NO. 1d23h59m58s IN A 129.240.64.2
nn.uninett.NO. 1d23h59m58s IN A 158.38.0.181
;; Total query time: 4 msec
;; FROM: lookfar to SERVER: default -- 127.0.0.1
;; WHEN: Sat Dec 16 00:23:09 2000
;; MSG SIZE sent: 28 rcvd: 162
Отбележете липсата на флага "aa" в този отговор. Това означава,
че named не е излизал от мрежата този път, информацията е в
кеша сега. Но кешираната информация може да е остаряла.
Така сте информиран за тази (много малка) вероятност, чрез
липсата на "aa" . Но сега знаете, че Вашият кеш работи.
3.2. Преобразуватели
Всички ОС изпълняващи стандартът C API имат повикванията gethostbyname
и gethostbyaddr. Те могат да вземат информация от няколко различни
източника. От къде ще я вземат се конфигурира в
/etc/nsswitch.conf при Linux (и някои Unix системи). Това голям
файл указващ от кой файл или база данни да се взимат различни
типове данни. Той обикновено съдържа полезни съвети най-отгоре, които
трябва да вземете под внимание. След това намерете реда започващ с
`hosts:'; трябва да бъде нещо като това:
______________________________________________________________________
hosts: files dns
______________________________________________________________________
(Помните за началните интервали, нали ? Няма да споменавам за тях
отново.)
Ако няма ред започващ с `hosts:' сложете горният.
Той казва програмите да търсят първо в файла /etc/hosts , след това
проверява DNS съгласно resolv.conf.
3.3. Поздравления
Сега вече знаете как да настройте кеширащ named. Вземи бира, мляко, или
каквото там предпочиташ за да го отпразнуваш !!!
4. Пренасочване (Forwarding)
В големите, добре организирани, академични или фирмени
мрежи понякога ще видите,че администратора е настроил
пренасочваща йерархия на DNS сървъри което помагат да се
намали както вътрешното, така и външното мрежово натоварване. Не е
лесно да разбереш дали си в такава мрежа или не. Обаче това не е
важно и използвайки DNS сървъра на вашия доставчик като
``forwarder'' може да направите отговорите на запитванията
по-бързи и с по-малко натоварване на вашата мрежа.
Ако използвате модем това може да бъде една малка победа.
За примера ще допуснем, че вашият мрежов доставчик
има два сървъра на имената, които искат да използвате, с IP адреси
10.0.0.1 и 10.1.0.1. Тогава, във вашият named.conf файл, вътре в
отворената секция наречена ``options'', добавете редовете:
______________________________________________________________________
forward first;
forwarders {
10.0.0.1;
10.1.0.1;
};
______________________________________________________________________
Освен това има хубав трик за dialup машини използвайки препращане,
което е описано в частта ``ВиО'' .
Рестартирайте сървърът и пробвайте с dig. Би трябвало да работи добре.
5. Проста настройка на домейн
Как да настроим свой собствен домейн.
5.1. Но първо малко суха теория
Най-напред: прочетохте всичко до тука, нали?
Преди наистина да започна тази част, ще ви предам малко теория
и пример как DNS работи. Би било хубаво да го прочетете
защото ще е полезно за вас. Ако не мислите така, то поне
му хвърлете един поглед набързо. Спрете се на промените
на вашия named.conf файл.
DNS е йерархична, разклонена система. Върхът се бележи с
`.' и се произнася `root' (корен), подобно на други подобни структури.
Под . се намират домейните от най-високо ниво (Top Level Domains);
най-известни са ORG, COM, EDU и NET, но има още много. Точно както
дърво има корен и постепенно се разклонява. Ако имате компютърно
образование ще разпознаете DNS като search tree, и ще
видите подобни разклонения, листови разклонения и краища. Точките са
разклоненията, краищата са при имената.
Когато направим заявка за някоя машина, търсенето се
изпълнява отзад напред ( recursively ) в
йерархията за почвайки от корена (root). Ако търсите адреса
prep.ai.mit.edu., вашият сървър трябва да започне питането от някъде. Той
започва като погледне в неговия кеш (cache). Ако знае отговорът, кеширан
по-рано, ще отговори по същия начин както и предишния път.
Ако не го знае, ще започне да премахва части от името, започвайки от
ляво, проверявайки дали знае нещо за ai.mit.edu., след това mit.edu.,
и накрая edu. ако не той знае за . защото това беше във файла
root.hints. Ще попита . сървър за prep.ai.mit.edu. Този .
сървър няма да знае отговорът, но ще помогне на вашия сървър като
го препрати и му каже къде да погледне. Това
препращане евентуално ще отведе вашия сървър до друг, който знае
отговорът. Ще поясня това с пример. +norec означава че dig е
задал не-рекурсивен въпрос, така че ние ще направим рекурсията сами.
Другите параметри са за да намалим количеството информация от dig ,
така че да не получим твърде много страници:
$ dig +norec +noH +noques +nostats +nocmd prep.ai.mit.edu.
;; res options: init defnam dnsrc
;; got answer:
; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 13
;; AUTHORITY SECTION:
. 5d23h48m47s IN NS I.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS E.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS D.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS A.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS H.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS C.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS G.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS F.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS B.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS J.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS K.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS L.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS M.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
I.ROOT-SERVERS.NET. 6d23h48m47s IN A 192.36.148.17
E.ROOT-SERVERS.NET. 6d23h48m47s IN A 192.203.230.10
D.ROOT-SERVERS.NET. 6d23h48m47s IN A 128.8.10.90
A.ROOT-SERVERS.NET. 6d23h48m47s IN A 198.41.0.4
H.ROOT-SERVERS.NET. 6d23h48m47s IN A 128.63.2.53
C.ROOT-SERVERS.NET. 6d23h48m47s IN A 192.33.4.12
G.ROOT-SERVERS.NET. 6d23h48m47s IN A 192.112.36.4
F.ROOT-SERVERS.NET. 6d23h48m47s IN A 192.5.5.241
B.ROOT-SERVERS.NET. 6d23h48m47s IN A 128.9.0.107
J.ROOT-SERVERS.NET. 6d23h48m47s IN A 198.41.0.10
K.ROOT-SERVERS.NET. 6d23h48m47s IN A 193.0.14.129
L.ROOT-SERVERS.NET. 6d23h48m47s IN A 198.32.64.12
M.ROOT-SERVERS.NET. 6d23h48m47s IN A 202.12.27.33
Това е препращане.То ни дава само Достоверните източници (Authority
section), без Отговор (Answer section). Нашия сървър се препраща до друг
сървър. Вземете един пожелание:
$ dig +norec +noH +noques +nostats +nocmd prep.ai.mit.edu. @H.ROOT-SERVERS.NET.
; (1 server found)
;; res options: init defnam dnsrch
;; got answer:
; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
;; AUTHORITY SECTION:
MIT.EDU. 2D IN NS BITSY.MIT.EDU.
MIT.EDU. 2D IN NS STRAWB.MIT.EDU.
MIT.EDU. 2D IN NS W20NS.MIT.EDU.
;; ADDITIONAL SECTION:
BITSY.MIT.EDU. 2D IN A 18.72.0.3
STRAWB.MIT.EDU. 2D IN A 18.71.0.151
W20NS.MIT.EDU. 2D IN A 18.70.0.160
Препраща ни веднага към сървърът MIT.EDU. Отново вземете един случайно:
$ dig +norec +noH +noques +nostats +nocmd prep.ai.mit.edu. @bitsy.mit.edu
; (1 server found)
;; res options: init defnam dnsrch
;; got answer:
; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; ANSWER SECTION:
prep.ai.mit.edu. 3h50m7s IN A 198.186.203.18
;; AUTHORITY SECTION:
AI.MIT.EDU. 6H IN NS FEDEX.AI.MIT.EDU.
AI.MIT.EDU. 6H IN NS LIFE.AI.MIT.EDU.
AI.MIT.EDU. 6H IN NS ALPHA-BITS.AI.MIT.EDU.
AI.MIT.EDU. 6H IN NS BEET-CHEX.AI.MIT.EDU.
;; ADDITIONAL SECTION:
FEDEX.AI.MIT.EDU. 6H IN A 192.148.252.43
LIFE.AI.MIT.EDU. 6H IN A 128.52.32.80
ALPHA-BITS.AI.MIT.EDU. 6H IN A 128.52.32.5
BEET-CHEX.AI.MIT.EDU. 6H IN A 128.52.32.22
Този път получихме "ANSWER SECTION", и отговор на нашият въпрос.
"AUTHORITY SECTION" съдържа информация за това кои сървъри да
питаме за ai.mit.edu следващият път. Така може да питате директно тях
следващия път когато се интересувате за имена в ai.mit.edu.
Започвайки от . намираме последователно сървъри на имената за всяко ниво
в име на домейн чрез препращане. Ако използвате собствен DNS сървър
вместо всички тези други сървъри, named разбира се ще
кешира всичката информация която е намерил с dig за вас, и
няма нужда да пита отново.
В тази аналогия всяка ``.'' в името е точка на разклонение. И
всяка част между две ``.'' е името на индивидуален клон в
дървото. Едно изкачване по дървото говорейки с името което търсим
(prep.ai.mit.edu) питайки за коренът (.) или някой сървър между корена
и prep.ai.mit.edu имаме информация за него в кеша.
Ако се достигне пределът на кеша рекурсивните преобразуватели започват
да питат сървърите, последвалите препращания (краен брой) подпомагат
за допълването на името.
Колкото малко се говори , толкова и важен е домейна in-
addr.arpa. Той е също както `нормалните' домейни , но
ни позволява да вземем името когато имаме адреса.
Важно е да се отбележи че тука IP адреса е написан в
обратен ред. Ако имате адрес на машина:
192.148.52.43 named процедира точно както и при
prep.ai.mit.edu пример : намира сървърът arpa. . Намира in-addr.arpa.
сървъри, намира 192.in-addr.arpa. сървъри, намира 148.192.in-addr.arpa.
сървъри, намира 52.148.192.in-addr.arpa. сървъри. Намира необходимия
запис за 43.52.148.192.in-addr.arpa. Умно нали? (Кажи `ДА'.)
The reversion of the numbers can be confusing for years though.
5.2. Наш собствен домейн
Сега да определим наш собствен домейн. Ще направим домейн
linux.bogus и дефинираме машини в него. Използвам за име да домейн bogus
за да съм сигурен, че няма да смутим никой Там Някъде.
Само още нещо преди да започнем: Не всички символи са разрешени в
името. Ограничени сме от символите в английската азбука: a- z,
цифрите 0-9 и символа '-' (тире). Ограничете се в тези
символи. Главните и малките символи са идентични за DNS, така
pat.uio.no е идентично с Pat.UiO.No .
Ние вече стартирахме тази част с този ред в named.conf:
______________________________________________________________________
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};
______________________________________________________________________
Отбележете липсата на `.' в края на името на домейна в този
файл. Това казва, че ще дефинираме зоната 0.0.127.in-
addr.arpa, че сме главен (master) сървър за нея и е описана
в файл наречен pz/127.0.0. Ние вече настроихме този файл:
______________________________________________________________________
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
1 ; Serial
8H ; Refresh
2H ; Retry
4W ; Expire
1D) ; Minimum TTL
NS ns.linux.bogus.
1 PTR localhost.
______________________________________________________________________
Моля отбележете `.' в края на пълното име на домейна в този
файл, в сравнение с named.conf по-горе. Някои хора обичат да
започват всеки файл за зона с директивата $ORIGIN , но това е
излишно. Източникът (където в DNS йерархията принадлежи) на
файла на зоната е определен в named.conf file; в този
случай това е 0.0.127.in-addr.arpa.
Зоновия файл съдържа 3 `resource records' (RRs): A SOA RR. A NS
RR и PTR RR. SOA е съкратено от Start Of Authority
(Начало на достоверния източник). Знакът `@' е
специално означаване на числата означаващи източникът,
и тъй като тук като графата домейн за този файл
е 0.0.127.in-addr.arpa , първият ред всъщност означава
0.0.127.in-addr.arpa. IN SOA ...
NS е Name Server RR (Запис за Сървърът на Имената).
Няма знакът '@' в началото на този реда;
той се подразбира тъй като предишния ред започва с '@'. Това
спестява малко писане. Следователно реда NS може да бъде записан и :
0.0.127.in-addr.arpa. IN NS ns.linux.bogus
Това казва на DNS коя машина е сървър на имената на домейна 0.0.127.in-
addr.arpa, в случая ns.linux.bogus. 'ns' е обичайно име за такъв
сървър, но също както и с web сървърите обикновено наименовани
www.something името може да бъде всякакво.
Накрая записът PTR (Domain Name Pointer) (Указател за
името на домейна) казва, че името на
адрес 1 в подмрежата 0.0.127.in-addr.arpa, .т.е, 127.0.0.1
се наименова localhost.
Записът SOA е в началото на всички файлове за зони, и трябва да е
само един във всеки файл за зона. Той описва зоната, от къде идва
(машина наречена ns.linux.bogus), кой е отговорен за нейното
съдържание (hostmaster@linux.bogus; сложете вашия e-mail
адрес тука), каква версия е файла за зоната (serial: 1), и
други неща необходими за кеша и второстепенните DNS сървъри. За
останалите параметри (refresh, retry, expire и minimum) използването
числата от това HOWTO би трябвало да е добре. Преди SOA
е поставен задължителния ред $TTL 3D. Сложете го във всичките
ви файлове за зони.
Сега рестартирайте вашият named (с "ndc restart") и използвайте dig за да
изпробвате новите настройки. -x е за обратна заявка:
$ dig -x 127.0.0.1
; <<>> DiG 8.2 <<>> -x
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;; 1.0.0.127.in-addr.arpa, type = ANY, class = IN
;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 1D IN PTR localhost.
;; AUTHORITY SECTION:
0.0.127.in-addr.arpa. 1D IN NS ns.penguin.bv.
;; Total query time: 5 msec
;; FROM: lookfar to SERVER: default -- 127.0.0.1
;; WHEN: Sat Dec 16 01:13:48 2000
;; MSG SIZE sent: 40 rcvd: 110
Така dig успява да открие localhost от 127.0.0.1, добре. Сега за нашата
главна задача, домейна linux.bogus , добавете нова зона в named.conf:
______________________________________________________________________
zone "linux.bogus" {
notify no;
type master;
file "pz/linux.bogus";
};
______________________________________________________________________
Отбележете отново липсата на `.' в края на името на домейна в named.conf
В файла за зоната linux.bogus ще поставим малко фалшива (на амер. bogus)
информация:
______________________________________________________________________
;
; Zone file for linux.bogus
;
; The full zone file
;
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, todays date + todays serial #
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
;
NS ns ; Inet Address of name server
MX 10 mail.linux.bogus ; Primary Mail Exchanger
MX 20 mail.friend.bogus. ; Secondary Mail Exchanger
;
localhost A 127.0.0.1
ns A 192.168.196.2
mail A 192.168.196.4
______________________________________________________________________
Две неща трябва да се отбележат за записа SOA. ns.linux.bogus трябва да бъде
действителна машина с A запис. Не е правилно да има CNAME
запис машина спомената в SOA запис. Името й няма нужда
да бъде `ns', трябва да бъде някое действително име. Следващото,
hostmaster.linux.bogus се чете като hostmaster@linux.bogus. Това
трябва да бъде a mail псевдоним, или пощенска кутия, която хората поддържащи
DNS проверяват редовно. Всяко писмо относно домейнът
ще бъде изпратено на адреса написан тука. Не е нужно да бъде
`hostmaster', може да бъде вашият нормален e-mail, но e-mail
адресът `hostmaster' често се очаква, че също работи.
Има един нов RR тип в този файл, MX, или Mail eXchanger RR.
Той казва на системите за поща, къде да изпращат пощата адресирана до
someone@linux.bogus, именно mail.linux.bogus или mail.friend.bogus.
Цифрата преди името на всяка машина е приоритетът на съответния MX RR.
RR с най-ниско число (10) е адресът на който би трябвало да се изпрати ако
е възможно. Ако опитът се провали, писмото се изпраща на следващия с
по-голямо число, второстепенния сървър, т.е., mail.friend.bogus който има
приоритет 20 .
Рестартирайте named чрез ndc restart. Разгледайте резултатите с dig:
$ dig any linux.bogus +pfmin
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23499
;; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1
;; QUERY SECTION:
;; linux.bogus, type = ANY, class = IN
;; ANSWER SECTION:
linux.bogus. 3D IN MX 10 mail.linux.bogus.linux.bogus.
linux.bogus. 3D IN MX 20 mail.friend.bogus.
linux.bogus. 3D IN NS ns.linux.bogus.
linux.bogus. 3D IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial
8H ; refresh
2H ; retry
4W ; expiry
1D ) ; minimum
След внимателен поглед ще откриете грешка. Редът
linux.bogus. 3D IN MX 10 mail.linux.bogus.linux.bogus.
е грешен. Трябва да бъде
linux.bogus. 3D IN MX 10 mail.linux.bogus.
Нарочно направих грешката за да се поучим от нея :-) Поглеждайки
в файла за зоната намираме този ред :
MX 10 mail.linux.bogus ; Primary Mail Exchanger
Липсва точката. Или съдържа 'linux.bogus' в повече. Ако
името на машината не завършва с точка в файла за зоната, източникът се
добавя в края, причинявайки удвояването linux.bogus.linux.bogus. Така
и двете :
______________________________________________________________________
MX 10 mail.linux.bogus. ; Primary Mail Exchanger
______________________________________________________________________
или
______________________________________________________________________
MX 10 mail ; Primary Mail Exchanger
______________________________________________________________________
е правилно. Аз предпочитам последния начин, заради по-малкото писане.
Някой ще се съгласят с това, друг не . Във файла за зоната
домейнът трябва или да бъде написан целият и да завършва с `.'
или да не е написан изобщо , в такъв случай се допълва от домейнът
източник.
Трябваше да наблегна, че в named.conf не трябва да има `.'
след името на домейна. Нямате си и представа колко много пъти
тази точка присъства и разваля работата, обърквайки хората.
Така след като обърнах внимание на това, ето отново файла за зоната,
с малко допълнителна информация в него :
______________________________________________________________________
;
; Zone file for linux.bogus
;
; The full zone file
;
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, todays date + todays serial #
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
;
TXT "Linux.Bogus, your DNS consultants"
NS ns ; Inet Address of name server
NS ns.friend.bogus.
MX 10 mail ; Primary Mail Exchanger
MX 20 mail.friend.bogus. ; Secondary Mail Exchanger
localhost A 127.0.0.1
gw A 192.168.196.1
HINFO "Cisco" "IOS"
TXT "The router"
ns A 192.168.196.2
MX 10 mail
MX 20 mail.friend.bogus.
HINFO "Pentium" "Linux 2.0"
www CNAME ns
donald A 192.168.196.3
MX 10 mail
MX 20 mail.friend.bogus.
HINFO "i486" "Linux 2.0"
TXT "DEK"
mail A 192.168.196.4
MX 10 mail
MX 20 mail.friend.bogus.
HINFO "386sx" "Linux 1.2"
ftp A 192.168.196.5
MX 10 mail
MX 20 mail.friend.bogus.
HINFO "P6" "Linux 2.1.86"
______________________________________________________________________
Ето няколко нови RR: HINFO (Host INFOrmation) има две
части; добър навик е да ограждате с кавички всяка. Първата е
хардуера или процесора на машината, а втората софтуера или ОС
на машината. Машината наречен 'ns' има Pentium процесор и е с
Linux 2.0. CNAME (Canonical NAME) е начина да дадете на една машина
няколко имена. Така www е псевдоним (alias) на ns.
Употребата на записа CNAME е малко спорна, но е добре ако спазвате
правилото, че MX, CNAME или SOA записи никога не трябва да сочат към
CNAME запис, а към нещо с A запис, така не е препоръчително да имате
______________________________________________________________________
foobar CNAME www ; NO!
______________________________________________________________________
правилното е
______________________________________________________________________
foobar CNAME ns ; Yes!
______________________________________________________________________
Добре да приемете, че CNAME не е правилно име за
e-mail адрес : webmaster@www.linux.bogus е неправилно за e-mail адрес
за настройките по-горе. Начинът да избегнете това е
като използвате A записи (и може би някои други също, като MX запис).
Например така:
______________________________________________________________________
www A 192.168.196.2
______________________________________________________________________
Много от arch-BIND-wizards, препоръчват въобще да не използвате CNAME.
Но дискусията защо или защо не е извън обсега на това HOWTO.
Но както може да видите, това HOWTO и много сайтове
не спазват това правило.
Заредете новата база данни, стартирайки ndc reload, което предизвиква
named да прочете своите файлове отново.
$ dig linux.bogus axfr
; <<>> DiG 8.2 <<>> linux.bogus axfr
$ORIGIN linux.bogus.
@ 3D IN SOA ns hostmaster (
199802151 ; serial
8H ; refresh
2H ; retry
4W ; expiry
1D ) ; minimum
3D IN NS ns
3D IN NS ns.friend.bogus.
3D IN MX 10 mail
3D IN MX 20 mail.friend.bogus.
3D IN TXT "Linux.Bogus, your DNS consultants"
gw 3D IN TXT "The router"
3D IN HINFO "Cisco" "IOS"
3D IN A 192.168.196.1
localhost 3D IN A 127.0.0.1
mail 3D IN HINFO "386sx" "Linux 1.2"
3D IN MX 10 mail
3D IN MX 20 mail.friend.bogus.
3D IN A 192.168.196.4
www 3D IN CNAME ns
donald 3D IN TXT "DEK"
3D IN HINFO "i486" "Linux 2.0"
3D IN MX 10 mail
3D IN MX 20 mail.friend.bogus.
3D IN A 192.168.196.3
ns 3D IN HINFO "Pentium" "Linux 2.0"
3D IN MX 10 mail
3D IN MX 20 mail.friend.bogus.
3D IN A 192.168.196.2
ftp 3D IN HINFO "P6" "Linux 2.1.86"
3D IN MX 10 mail
3D IN MX 20 mail.friend.bogus.
3D IN A 192.168.196.5
@ 3D IN SOA ns hostmaster (
199802151 ; serial
8H ; refresh
2H ; retry
4W ; expiry
1D ) ; minimum
;; Received 29 answers (29 records).
;; FROM: lookfar to SERVER: 127.0.0.1
;; WHEN: Sat Dec 16 01:35:05 2000
Това е добре. Както виждате изглежда точно както и файла за зоната.
Нека погледнем само за www :
$ dig www.linux.bogus +pfmin
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27345
;; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1
;; QUERY SECTION:
;; www.linux.bogus, type = A, class = IN
;; ANSWER SECTION:
www.linux.bogus. 3D IN CNAME ns.linux.bogus.
ns.linux.bogus. 3D IN A 192.168.196.2
С други думи, истинското име на www.linux.bogus е ns.linux.bogus,
също така, дава информацията която има за ns,
достатъчна да се свържете ако бяхте програма.
Сега сме на половината път.
5.3. Обратната зона (The reverse zone)
Сега програмите могат да преобразуват имената в linux.bogus в адреси, с които
могат да се свързват. Необходима е също обратна зона, веднъж направена
DNS може да преобразува от адрес в име. Това име се използва от
много сървъри от различен тип (FTP, IRC, WWW и други) за да решат
дали те искат да разговарят с вас или не, и ако искат, дори какъв
приоритет да ви бъде даден. За пълен достъп до всички услуги в
Internet обратната зона е необходима.
Сложете това в named.conf:
______________________________________________________________________
zone "196.168.192.in-addr.arpa" {
notify no;
type master;
file "pz/192.168.196";
};
______________________________________________________________________
Това е точно както с 0.0.127.in-addr.arpa, и съдържанието е
подобно :
______________________________________________________________________
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; Serial, todays date + todays serial
8H ; Refresh
2H ; Retry
4W ; Expire
1D) ; Minimum TTL
NS ns.linux.bogus.
1 PTR gw.linux.bogus.
2 PTR ns.linux.bogus.
3 PTR donald.linux.bogus.
4 PTR mail.linux.bogus.
5 PTR ftp.linux.bogus.
______________________________________________________________________
Сега рестартирайте named (ndc restart) и разгледайте отново с dig :
______________________________________________________________________
$ dig -x 192.168.196.4 +pfmin
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8764
;; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUERY SECTION:
;; 4.196.168.192.in-addr.arpa, type = ANY, class = IN
;; ANSWER SECTION:
4.196.168.192.in-addr.arpa. 3D IN PTR mail.linux.bogus.
______________________________________________________________________
Изглежда всичко е OK, за да получите цялата информация пробвайте :
______________________________________________________________________
dig -x 192.168.196 AXFR
; <<>> DiG 8.2 <<>> -x AXFR
$ORIGIN 196.168.192.in-addr.arpa.
@ 3D IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial
8H ; refresh
2H ; retry
4W ; expiry
1D ) ; minimum
3D IN NS ns.linux.bogus.
4 3D IN PTR mail.linux.bogus.
2 3D IN PTR ns.linux.bogus.
5 3D IN PTR ftp.linux.bogus.
3 3D IN PTR donald.linux.bogus.
1 3D IN PTR gw.linux.bogus.
@ 3D IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial
8H ; refresh
2H ; retry
4W ; expiry
1D ) ; minimum
;; Received 8 answers (8 records).
;; FROM: lookfar to SERVER: 127.0.0.1
;; WHEN: Sat Dec 16 01:44:03 2000
______________________________________________________________________
Изглежда добре! Ако при вас нещо не е наред, погледнете вашия
syslog за съобщения за грешки, Обясних как да направите това в първата
глава под заглавието ``Стартиране на named''
5.4. Внимание
Има няколко неща които трябва да кажа тука. IP адресите използвани
в примерите по-горе са взети от една от запазените 'частни мрежи',
т.е., те не са разрешени за публично използване в Internet. Така
те са подходящи за примери в HOWTO. Второто нещо е
редът notify no; . Това казва на named да не известява подчинените
(slave) сървъри когато се промени някой от файловете за зони.
В BIND-8 named може да уведомява другите сървъри с NS запис
в зоните когато зоната е променена. Това удобство обикновено
се използва, но за частни експерименти с зоните това свойство е добре
да е изключено --- не искаме нашите експерименти да "замърсяват"
Internet, нали ?
И, разбира се, този домейн е напълно фалшив, също както и всички
адреси в него. За истински пример за домейн вижте
глава 7 .
5.5. Защо обърнатите заявки не работят
Има няколко проблема които обикновено се пропускат при заявките по
име и се забелязват когато настройваме обратните зони. Преди да
продължите имате нужда от работещи обратни заявки на вашите машини
от вашия сървър на имената. Ако това не е така върнете се и оправете
проблема преди да продължите.
Ще обърна внимание на два типа грешки на обратните заявки
когато се правят от машини извън вашата мрежа :
5.5.1. Обратната зона не е делегирана (The reverse zone isn't delegated.)
Когато попитате доставчик за адресно пространство и за
име на домейн, той обикновенно се удостоверява (delegate).
Удостоверяването е лепилото на NS записите което ви помага да
преминавате от един сървър към друг , както обясних в главата "суха теория"
по-горе. Прочетохте я , нали ? Ако вашата обратна зона не работи
върнете се и я прочетете . Сега.
Обратната зона също трябва да се удостовери. Ако получите мрежата
192.168.196 с домейнът linux.bogus от вашия доставчик, те
трябва да сложат NS запис за вашата обратна зона също както и за вашата
права зона. Ако следвате веригата от in-addr.arpa до
вашата мрежа може би ще намерите прекъсване във веригата, най-вероятно
при вашия доставчик . Ако намерите такова прекъсване свържете се
с доставчика ви и ги помолете да оправят грешката.
5.5.2. Имате извънкласова подмрежа (classless subnet)
Тази тема е за малко по-напреднали, но извънкласовите подмрежи са
доста често срещани напоследък и е вероятно да имате такава, ако
сте малка фирма.
Извънкласовите подмрежи е пътят по който върви Internet напоследък. Преди
няколко години имаше дискусии за недостига на IP адреси. Умните
хора от IETF (the Internet Engineering Task Force, те се грижат
за да работи Internet) си напънаха мозъците и решиха проблема.
Но на една цена. Цената е, че получавате по-малко от клас ``C''
подмрежа и някои неща може да не работят. Моля вижте "Ask Mr. DNS" на
за добро обяснение на
това и как да се справите с него.
Прочетохте ли го ? Няма да го обяснявам затова моля прочетете го.
Първата част от проблема е че вашият ISP трябва да разбира
техниката описан от Mr. DNS. Не всички малки ISP разбират
напълно това. Ако трябва да им го разясните бъдете
упорит. Но първо се уверете че вие сте го разбрали ;-). Те ще
настроят добра обратна зона на техния сървър, която може да проверите
за коректност с dig.
Втората и последна част от проблема е че вия трябва да разберете
техниката. Ако не сте сигурни, върнете се и прочетете отново.
Тогава може да настроите вашата извънкласова обратна зона описана
от Mr. DNS.
Тук обаче има един друг проблем. Старите преобразуватели не могат да
следват трика с CNAME във веригата от преобразувания и няма да могат
да стигнат до твоята машина. Това може да стане в резултат на
пренасочване в грешен клас на достъп, отказ на достъп или нещо
подобно . Ако се натъкнете на това, единственото решение
(което аз знам) е за вашият ISP да добави вашите PTR записи директно
в техния "измамен" извънкласов файл за зона , вместо трика с CNAME
записа.
Някои ISP предлагат други начини за решение на това, като Web базирани
формуляри да въведете обратни зони или други автоматизирани системи.
5.6. Подчинени сървъри
След като сте настроили вашите зони правилно на главните сървъри
имате нужда от поне един подчинен сървър. Подчинените сървъри са нужни
за подсигуряване . Ако вашия главен сървър спре останалите хора в
мрежата ще могат да получат информация за вашия домейн от
подчинения. Подчинения би трябвало да бъде възможно най-далече. Главния
и подчинен сървъри трябва да делят възможно най-малко от : Захранване,
LAN, ISP, град и държава. Ако всички от по-горните неща са
различни за вашите главен и подчинен сървъри, вие сте намерили
наистина добър подчинен сървър.
Подчинения е просто сървър на имената, който копира файловете за
зоните от главния. Описва се така :
______________________________________________________________________
zone "linux.bogus" {
type slave;
file "sz/linux.bogus";
masters { 192.168.196.2; };
};
______________________________________________________________________
Механизъм наречен zone-transfer (прехвърляне на зоните) се използва
за копиране на информацията. Zone-transfer се контролира от вашия
SOA запис :
______________________________________________________________________
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, todays date + todays serial #
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
______________________________________________________________________
Зоната се прехвърля само ако серийния номер на главния е
по-голям от този на подчинения. Подчинения проверява през определен
интервал(refresh) дали главния е бил променен. Ако проверката не е успешна
(защото главния не работи) той ще продължи да проверява на всеки интервал
(retry). Ако опитите продължат да са неуспешни до изтичане на интервала
(expire), подчинения ще премахне зоната и повече няма да бъде сървър за нея.
6. Основни опции за сигурността.
От Jamie Norrish
Настройки за намаляване на възможните проблеми.
Има няколко прости стъпки след които вашият
сървър да стане по сигурен и да се намали натоварването. Този
материал е само за начална точка ; ако сте заинтересован
от сигурността (и би трябвало), потърсете и други
материали по темата в мрежата (вижте ``последна глава'').
Следващите конфигурации се отнасят за named.conf. Ако
условието се намира в секцията "options" на файла, тя се отнася за всички
зони описани в този файл. Ако се намира в описание на зона,
отнася се само за тази зона. Вписаното в зоната (ако има) се взима под
внимание вместо това в "options".
6.1. Ограничаване на прехвърлянето на зоните
Понеже вашите подчинени сървъри трябва да отговарят на заявки за
вашият домейн, те трябва да могат да изтеглят информацията за зоните от
главния сървър. Почти никой друг не би трябвало да прави това. Следователно
ограничаването на прехвърлянето на зоните чрез опцията allow-transfer.
192.168.1.4 е IP адреса на ns.friend.bogus и добавяме себе си за да
може да тестваме :
______________________________________________________________________
zone "linux.bogus" {
allow-transfer { 192.168.1.4; localhost; };
};
______________________________________________________________________
Чрез ограничаването на прехвърлянето, осигурявате че хората ще
получават отговор само за своите питания - никой не може просто да пита
за всички детайли във вашите настройки.
6.2. Защита от спуфинг (spoofing)
Първо, забранете всички заявки за домейни които не са ваши, освен от
вашите локални машини. Това не само ще предотврати злонамерена
употреба на вашия DNS сървър, но и ще намали ненужната му употреба.
______________________________________________________________________
options {
allow-query { 192.168.196.0/24; localhost; };
};
zone "linux.bogus" {
allow-query { any; };
};
zone "196.168.192.in-addr.arpa" {
allow-query { any; };
};
______________________________________________________________________
След това, забранете рекурсивните заявки, освен вътрешните.
Това ще намали риска от "cache poisoning" атаки (при които невалидни
данни се изпращат към вашия сървър).
______________________________________________________________________
options {
allow-recursion { 192.168.196.0/24; localhost; };
};
______________________________________________________________________
6.3. Стартиране на named без root привилегии
Добра идея е да стартирате named като обикновен потребител, така
ако някой кракер получи някакви права на сървъра, те ще бъдат възможно
най-малки. Трябва да направите потребител и група за named с
под който да го стартирате, след това променете скрипта който стартира
named. Подайте на новите име и група на named чрез флаговете -u и -g .
За пример, при Debian GNU/Linux 2.2 би трябвало за редактирате
/etc/init.d/bind да съдържа следния ред (където потребителя и
групата named са създадените от вас) :
______________________________________________________________________
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -u named -g named
______________________________________________________________________
Същото може да бъде направено и при Red Hat and или други дистрибуции.
Dave Lugo описва конфигурация за сигурност, използвайки chroot на
което сигурно ще ви
заинтересува .
7. Един истински пример
Ето списък с няколко истински файлове на зони
Посъветваха ме да включа и истински пример на работещ домейн,
наред с обучаващите примери.
Използвам този пример с позволението на David Bullock от LAND-5.
Тези файлове са от 24 Септември 1996, редактирани са
за BIND 8 и са разширени от мен . Така, това което ще видите
тук е различно от това което ще получите при заявка от сървъра
на LAND-5 сега.
7.1. /etc/named.conf (or /var/named/named.conf)
Тук ще намерим главни зони за две обратни зони необходими за
мрежата 127.0.0 и подмрежата 206.6.177 на LAND-5, и главния
ред за правата зона на land-5.com. Също отбележете, че вместо да
слага файловете в директория pz, както аз в това HOWTO, той
използва директория наречена zone.
______________________________________________________________________
// Boot file for LAND-5 name server
options {
directory "/var/named";
};
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "zone/127.0.0";
};
zone "land-5.com" {
type master;
file "zone/land-5.com";
};
zone "177.6.206.in-addr.arpa" {
type master;
file "zone/206.6.177";
};
______________________________________________________________________
Ако сложите това във вашия named.conf file за проба МОЛЯ сложете
``notify no;'' за двете зони на land-5 за да не предизвикате
някой инцидент.
7.2. /var/named/root.hints
Запомнете, че този файл е динамичен, и че този показан тук е стар.
По-добре използвайте създаден сега с dig, както обясних по-рано.
______________________________________________________________________
; <<>> DiG 8.1 <<>> @A.ROOT-SERVERS.NET.
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
;; QUERY SECTION:
;; ., type = NS, class = IN
;; ANSWER SECTION:
. 6D IN NS G.ROOT-SERVERS.NET.
. 6D IN NS J.ROOT-SERVERS.NET.
. 6D IN NS K.ROOT-SERVERS.NET.
. 6D IN NS L.ROOT-SERVERS.NET.
. 6D IN NS M.ROOT-SERVERS.NET.
. 6D IN NS A.ROOT-SERVERS.NET.
. 6D IN NS H.ROOT-SERVERS.NET.
. 6D IN NS B.ROOT-SERVERS.NET.
. 6D IN NS C.ROOT-SERVERS.NET.
. 6D IN NS D.ROOT-SERVERS.NET.
. 6D IN NS E.ROOT-SERVERS.NET.
. 6D IN NS I.ROOT-SERVERS.NET.
. 6D IN NS F.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4
J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10
K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129
L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12
M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33
A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4
H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53
B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107
C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12
D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90
E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10
I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17
F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241
;; Total query time: 215 msec
;; FROM: roke.uio.no to SERVER: A.ROOT-SERVERS.NET. 198.41.0.4
;; WHEN: Sun Feb 15 01:22:51 1998
;; MSG SIZE sent: 17 rcvd: 436
______________________________________________________________________
7.3. /var/named/zone/127.0.0
Просто нормалния, задължителен SOA запис, и запис за преобразуване на
127.0.0.1 в localhost. И двете са необходими. Нищо повече за този
файл. Този файл няма нужда да се променя , освен ако вашия
сървър за имената или e-mail-а на администратора се промени.
______________________________________________________________________
@ IN SOA land-5.com. root.land-5.com. (
199609203 ; Serial
28800 ; Refresh
7200 ; Retry
604800 ; Expire
86400) ; Minimum TTL
NS land-5.com.
1 PTR localhost.
______________________________________________________________________
Ако разгледате различни инсталации на BIND , ще видите че
реда $TTL липсва . Той не се използваше преди , чак след
версия 8.2 на BIND започна да предупреждава за липсата му.
Препоръчвам ви да слагате $TTL във файловете за зони ако липсва.
7.4. /var/named/zone/land-5.com
Тук намираме задължителния запис SOA , и необходимите NS записи.
Забелязваме също, че имат второстепенен сървър ns2.psi.net. Така и би
трябвало да бъде, винаги е добре да имате такъв сървър като копие. Също
така виждаме, че главния хост наречен land-5 се грижи за
много различни Internet услуги, и е постигнато с
CNAME (алтернатива е използването на A записи).
Както се вижда от SOA записа, файла за зоната слага началото на
land-5.com, отговорния човек е root@land-5.com. hostmaster е
друг често използван адрес. Серийният номер е в обичайния
формат yyyymmdd заедно със серийния номер за деня;
вероятно това е шеста версия на файла за зоната на
20 Септември 1996. Запомнете, че номера трябва да се увеличава
монотонно, тук има една цифра за номера за деня, така че
след 9 преработвания трябва да се изчака до другия ден преди да се
редактира файла отново. Решение е използването на две цифри.
______________________________________________________________________
@ IN SOA land-5.com. root.land-5.com. (
199609206 ; serial, todays date + todays serial #
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
NS land-5.com.
NS ns2.psi.net.
MX 10 land-5.com. ; Primary Mail Exchanger
TXT "LAND-5 Corporation"
localhost A 127.0.0.1
router A 206.6.177.1
land-5.com. A 206.6.177.2
ns A 206.6.177.3
www A 207.159.141.192
ftp CNAME land-5.com.
mail CNAME land-5.com.
news CNAME land-5.com.
funn A 206.6.177.2
;
; Workstations
;
ws-177200 A 206.6.177.200
MX 10 land-5.com. ; Primary Mail Host
ws-177201 A 206.6.177.201
MX 10 land-5.com. ; Primary Mail Host
ws-177202 A 206.6.177.202
MX 10 land-5.com. ; Primary Mail Host
ws-177203 A 206.6.177.203
MX 10 land-5.com. ; Primary Mail Host
ws-177204 A 206.6.177.204
MX 10 land-5.com. ; Primary Mail Host
ws-177205 A 206.6.177.205
MX 10 land-5.com. ; Primary Mail Host
; {Отрязвам много от повтарящите се дефиниции}
ws-177250 A 206.6.177.250
MX 10 land-5.com. ; Primary Mail Host
ws-177251 A 206.6.177.251
MX 10 land-5.com. ; Primary Mail Host
ws-177252 A 206.6.177.252
MX 10 land-5.com. ; Primary Mail Host
ws-177253 A 206.6.177.253
MX 10 land-5.com. ; Primary Mail Host
ws-177254 A 206.6.177.254
MX 10 land-5.com. ; Primary Mail Host
______________________________________________________________________
Ако проверите сървъра на land-5 , че откриете че имената са в
формат ws_число. От късните версии на BIND 4 named започна да
налага ограничения на символите които могат да се използват за
имена. Тъй като те няма да работят при BIND-8 , заместих с
'-' (тире) вместо '_' (долна черта) за това HOWTO.
Отбележете че работните станции нямат индивидуални
имена, а представка последвана с последните две числа от IP
номера. Използвайки тази идея може значително да облекчите
поддръжката, но също така и подразните вашите клиенти.
Също така забелязваме че funn.land-5.com псевдоним на land-5.com, но
използвайки A запис, а не CNAME. Това е добро действие както
отбелязахме по-рано.
7.5. /var/named/zone/206.6.177
Ще коментирам този файл по-долу
______________________________________________________________________
@ IN SOA land-5.com. root.land-5.com. (
199609206 ; Serial
28800 ; Refresh
7200 ; Retry
604800 ; Expire
86400) ; Minimum TTL
NS land-5.com.
NS ns2.psi.net.
;
; Servers
;
1 PTR router.land-5.com.
2 PTR land-5.com.
2 PTR funn.land-5.com.
;
; Workstations
;
200 PTR ws-177200.land-5.com.
201 PTR ws-177201.land-5.com.
202 PTR ws-177202.land-5.com.
203 PTR ws-177203.land-5.com.
204 PTR ws-177204.land-5.com.
205 PTR ws-177205.land-5.com.
; {Отрязвам много от повтарящите се дефиниции}
250 PTR ws-177250.land-5.com.
251 PTR ws-177251.land-5.com.
252 PTR ws-177252.land-5.com.
253 PTR ws-177253.land-5.com.
254 PTR ws-177254.land-5.com.
______________________________________________________________________
Обратната зона е частта от настройката, която може да причини повечето
проблеми. Използва се да се намери името ако имаме IP номера на
машината. Пример: имате IRC сървър и приемате връзки от
IRC клиенти. Обаче вие сте Норвежки IRC сървър и искате да
приемате връзки само от клиенти в Норвегия и другите
Скандинавски страни. Когато получите връзка от клиент,
C библиотеката може да ви каже IP номера на машината,
защото IP номера на клиента се съдържа във всички пакети
преминали през мрежата. Сега може да извикате функция наречена
gethostbyaddr която търси името по даден IP номер.
Gethostbyaddr пита DNS сървъра. Да предположим че клиента е
ws-177200.land-5.com. IP номера предаден от C библиотеката към IRC
сървъра е 206.6.177.200. Да намерим името на машината трябва да
намерим 200.177.6.206.in-addr.arpa. DNS сървърът ще намери първо
arpa. сървъри, след това in-addr.arpa. сървъри, следвайки обратната
следа през 206, след това 6 и накрая намира сървъра за
зоната 177.6.206.in-addr.arpa при LAND-5. От където накрая
намира отговора, че за 200.177.6.206.in-addr.arpa имаме ``PTR
ws-177200.land-5.com'' запис, означаващ че името на
206.6.177.200 е ws-177200.land-5.com. След обяснението на това как
prep.ai.mit.edu се търси, това е малко опростено.
Да се върнем на примера с IRC сървъра. Той приема връзки
само от Скандинавските страни т.е. *.no, *.se, *.dk,
името ws-177200.land-5.com определено не отговаря а това условие,
и сървъра ще откаже връзката. Ако обратния мапинг на
206.2.177.200 през зоната in-addr.arpa сървъра не успее да
намери име ще остане да сравнява 206.2.177.200 с *.no, *.se и *.dk,
и естествено няма да съвпадне.
Някои хора ще ви кажат, че обратното преобразуване са важни
само за сървъри, и не са важни като цяло. Това не е така: Много ftp,
news, IRC и дори някои http (WWW) сървъри не приемат връзки
от машини на които не могат да намерят името. Така че обратното
преобразуване всъщност е много важно.
8. Техн. експлоатация
Поддържайте го ! (Keeping it working.)
Има едно нещо за което трябва да грижите при named, освен да го
поддържате активен. Това е подновяването на файла root.hints.
Най-лесния начин е с dig. Първо стартирайте dig без аргументи и ще
видите root.hints на вашия сървър. След това попитайте един от
коренните сървъри с dig @rootserver. Забележете че ще получите
изход много подобен на файла root.hints. Запазете го като файл (dig
@e.root-servers.net . ns >root.hints.new) и заменете стария
root.hints с него.
Не забравяйте да презаредите named .
Al Longyear ми изпрати скрипт, който автоматично обновява
root.hints. Добавете в crontab да се стартира веднъж месечно и
забравете този проблем. Скриптът приема, че имате работещ
mail и псевдонима `hostmaster' е нагласен. Променете го по
вашите нужди и настройки.
______________________________________________________________________
#!/bin/sh
#
# Update the nameserver cache information file once per month.
# This is run automatically by a cron entry.
#
# Original by Al Longyear
# Updated for BIND 8 by Nicolai Langfeldt
# Miscelanious error-conditions reported by David A. Ranch
# Ping test suggested by Martin Foster
# named up-test suggested by Erik Bryer.
#
(
echo "To: hostmaster "
echo "From: system "
# 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
[ където
описва как той се справил с този проблем :
Стартирам 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.