Какда стана dns администратор за изключително кратко време

BIND 4. Ако man страницата на named се говори за (на края, в графата

FILES) named.conf вие имате BIND 8; ако се говори за named.boot

имате BIND 4. Ако имате 4 по причини за сигурност е добре

да преминете до най-новата версия на BIND 8. Сега.

DNS е световна база данни. Внимавайте какво слагате в нея. Ако

слагате излишни неща, вие и другите ще ги получавате. Поддържайте

вашия DNS малък и последователен и ще получите добри резултати от него.

Научете се да го използвате, администрирате, подобрявате и ще

станете следващия добър администратор, пазещ мрежата

да не затъне до колене от безотговорно управление.

Съвет: Правете копие на всички файлове които променяте,

а вече имате, така ако след като прочетете това и нещо не

работи, можете да си върнете отново работещата конфигурация.

3. Преобразуващ и кеширащ сървър на имената.

използващи за връзка с мрежата модем, кабелен модем или 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

directory "/var/named";

// 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.

;

. 6D IN NS M.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

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. (

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

връзка свържете се първо. Напишете `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

;; 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.

0.0.127.in-addr.arpa. 1D IN NS ns.penguin.bv.

;; 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

;; 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

uio.no. 1D IN NS nissen.uio.no.

uio.no. 1D IN NS ifi.uio.no.

uio.no. 1D IN NS nn.uninett.no.

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

;; 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

;; 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

UIO.NO. 23h59m58s IN NS nissen.UIO.NO.

UIO.NO. 23h59m58s IN NS ifi.UIO.NO.

UIO.NO. 23h59m58s IN NS nn.uninett.NO.

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

;; 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. Поздравления

каквото там предпочиташ за да го отпразнуваш !!!

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.

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

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. (

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

;; 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.

0.0.127.in-addr.arpa. 1D IN NS ns.penguin.bv.

;; 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

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 20 mail.friend.bogus. ; Secondary Mail Exchanger

;

localhost A 127.0.0.1

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

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

______________________________________________________________________

или

______________________________________________________________________

______________________________________________________________________

е правилно. Аз предпочитам последния начин, заради по-малкото писане.

Някой ще се съгласят с това, друг не . Във файла за зоната

домейнът трябва или да бъде написан целият и да завършва с `.'

или да не е написан изобщо , в такъв случай се допълва от домейнът

източник.

Трябваше да наблегна, че в named.conf не трябва да има `.'

след името на домейна. Нямате си и представа колко много пъти

тази точка присъства и разваля работата, обърквайки хората.

Така след като обърнах внимание на това, ето отново файла за зоната,

с малко допълнителна информация в него :

______________________________________________________________________

;

; Zone file for linux.bogus

; The full zone file

;

$TTL 3D

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.friend.bogus.

MX 10 mail ; Primary Mail Exchanger

MX 20 mail.friend.bogus. ; Secondary Mail Exchanger

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"

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

$ORIGIN linux.bogus.

@ 3D IN SOA ns hostmaster (

199802151 ; serial

8H ; refresh

2H ; retry

4W ; expiry

1D ) ; minimum

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

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)

могат да се свързват. Необходима е също обратна зона, веднъж направена

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. (

8H ; Refresh

2H ; Retry

4W ; Expire

1D) ; Minimum TTL

NS ns.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

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

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

;; 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" на