DNS HOWTO

Nicolai Langfeldt (janl@linpro.no), Jamie Norrish and others

Version 3.1, 2001-01-18

HOWTO become a totally small time DNS admin.

Превод : Денислав Ганчев (denikide@hotmail.com)

Не съм направил превод на последната глава и на съдържанието на документа, но според мен това е достатъчно за да се придобият основните познания. ______________________________________________________________________

Table of Contents

 

1. Preamble

1.1 Legal stuff

1.2 Credits and request for help.

1.3 Dedication

2. Introduction.

3. A resolving, caching name server.

3.1 Starting named

3.2 Resolvers

3.3 Congratulations

4. Forwarding

5. A

5.1 But first some dry theory

5.2 Our own domain

5.3 The reverse zone

5.4 Words of caution

5.5 Why reverse lookups don't work.

5.5.1 The reverse zone isn't delegated.

5.5.2 You've got a classless subnet

5.6 Slave servers

6. Basic security options.

6.1 Restricting zone transfers

6.2 Protecting against spoofing

6.3 Running named as non-root

7. A real domain example

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

9. Converting from version 4 to version 8

10. Questions and Answers

11. How to become a bigger time DNS admin.

 

 

______________________________________________________________________

 

1. Preamble

Keywords: DNS, BIND, BIND 4, BIND 8, named, dialup, PPP, slip, ISDN,

Internet, domain, name, resolution, hosts, caching.

 

This document is part of the Linux Documentation Project.

 

1.1. Legal stuff

(C)opyright 1995-2001 Nicolai Langfeldt, Jamie Norrish & Co. Do not

modify without amending copyright, distribute freely but retain

copyright message.

 

1.2. Credits and request for help.

I want to thank Arnt Gulbrandsen whom I cause to suffer through the

drafts to this work and who provided many useful suggestions. I also

want to thank the numerous people that have e-mailed suggestions and

notes.

 

This will never be a finished document; please send me mail about your

problems and successes. You can help make this a better HOWTO. So

please send comments and/or questions or money to janl@linpro.no. Or

buy my DNS book. See the bibliography for information about that. If

you send e-mail and want an answer please show the simple courtesy of

making sure that the return address is correct and working. Also,

please read the ``qanda'' section before mailing me. Another thing, I

can only understand Norwegian and English.

 

This is a HOWTO. I have maintained it as part of the LDP since 1995.

I have, during 2000, written a book on the same subject. I want to

say that, though this HOWTO is in many ways much like the book it is

not a watered down version concocted to market the book. You will

however find the book in the bibliography at the end of this HOWTO.

The readers of this HOWTO have helped me understand what is difficult

to understand about DNS. This has helped the book, but the book has

also helped me to think more about what this HOWTO needs. The HOWTO

begot the book. The book begot version 3 of this HOWTO. My thanks to

the book publisher, Que, that took a chance on me :-)

 

 

1.3. Dedication

Това HOWTO е посветено на Anne Line Norheim Langfeldt. Мисля че тя никога няма да го прочете защото не е от този вид момичета.

2. Introduction.

Какво е и какво не е.

DNS (Domain Name System). DNS конвертира машинните имената в IP адреси които имат всички машнини в мрежата. Той "map"-ва от имена към адреси и обратно и прави някои други неща също. Това HOWTO обяснява как се дефинира това "map"-ване като използваме Linux система. Mapping е просто асоциация между две неща в този случай име на машина, като ftp.linux.org, и IP на машина като следния номер (или адрес) 199.249.150.4.

DNS e нещо непознато (за вас ;-), една от тъмните страни на мрежовото администриране. Това HOWTO ще опита да направи няколко по разбираеми за вас. Обяснява как да настроим прост DNS именен сървър. Стартиране само с кешращ сървър и преминаване към стартиране на първичен DNS сървър като домейн. За по пълна информация може да проверите "qanda" частта от този документ. Ако не е обяснено то тогава трябва да прочетете "истинската документация". Аз ще обясня как се дефинира понятието "истинската документация" в последната глава.

Преди да започнете с настройките трябва да конфигурирате вашата машина така че да може да се телнетва към и от вашата машина, и успешно да се осъществяват всякакви видове връзки към мрежата, и осбенно трябва да е възможно да се прави телнет сесия към 127.0.0.0.1 към вашата собствена машина (пробвайте го сега!). Също се нуждаете от следните конфигурирани файлове /etc/nsswitch.conf (или /etc/host.conf), /etc/resolv.conf и /etc/hosts като стартираща точка, които аз няма да обяснявам тук. Ако все още не сте направили всички тези неща и не знаете как работят в Networking-HOWTO

и/или Networking-Overview-HOWTO обясняват как да настроите всичко това. Прочетете ги.

Когато казвам "вашата машина" имам предвид машината на която се опитвате да нагласите DNS. Не друга машина която може да е замесена в вашето упорито мрежово старание ;-).

Приемам че не сте зад някакъв вид защитна стена която блокира исканияата за имената. Ако сте се нуждаете ос специална конфигурация, вижте сектора "qanda".

Услугата с имената на Unix машините се извършва от програма наречена named. Това е част от "bind" пакетът които е изработен от Paul Vixie за The Internet Software Consortium. Named е включен в повечето Linux дистрибуции и обикновенно е инсталиран като /usr/sbin/named. Ако имате named вие вероятно може да го ползвате; ако го нямате може да вземете бинарните фаилове от повечето ftp Линукс сайтовете, или да вземете последното и най-добра версия от ftp.isc.org:/isc/bind/src/cur/bind-8/. Това HOWTO е за bind версия 8. Старата версия на HOWTO, за версия 4 е достъпна на адрес http://www.math.uio.no/~janl/DNS/ в случай че вие ползвате версия 4. Ако в man страницата на named съдържа информация за named.boot вие имате bind 4 (в края, FILES часта), ако се говори за named.conf вие имате bind 8. Ако имате версия 4 наистина се нуждаете от пачване на тази версия до настоящата 8, тъй като има проблеми с сигурността.

DNS е широка база от данни за мрежата. Бъдете внимателни с това какво слагате там. Ако слагате гадни неща ще получавате гадни неща. Пазете вашия DNS подреден и последователен и вие ще получите добри резултати. Научете се да го използвате, да го администритате, да го оправяте и вие ще бъдете един добър администратор, който се пази от провалите.

В този документ излагам ясно две неща които не са напълно истина ( те са най-малко половин истина мисля ). Всичко това е в интерес на опростяването. Нещата (най-вероятно ;-) ще заработят ако ми вярвате какво ви казжам.

Съвет: направете си резрвни копия на всички фаилове, които в последствие ще променяме, и ако нищо не се получи след като направим промените може да върнете старите си файлове.

3. A resolving, caching name server.

Първите конфигурации на DNS-a, е много полезна за dial-up потребители.

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

Първо вие се нуждаете от файл с име /etc/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";

};

______________________________________________________________________

В реда 'directory' се указва на named каде да търси файловете. Всички файлове named в последствие ще бъдат подобни на този. Pz е директория която се намира в /var/named, или /var/named/pz. /var/named е директорията по подразбиране при повечето Linux дистрибуции.

Също е споменат фаила /var/named/root.hints, този файл трябва да съдържа следното: (Ако копирате текста директно в файла, моля обърнете внимание на това, че не трябва да има водещи разстояния в файла, по друг начин казано всички редове трябва да започват без празно място.)

______________________________________________________________________

;

; 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

______________________________________________________________________

Този файл описва главните именни сървари в света. Той се промения с времето и трябва да бъде обновяван. Вижте "обновителният сектор" за това как да е винаги обновен.

Следващият сектор в named.conf е последната зона от файла. Ще обясня неговото използване в по нататъчните глави, за сега именувайте този файл 127.0.0.1 в поддиректорията 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 никога не чете този файл, 'resolver'-a който използва named прави това.

За да илюстрираме какво прави този файл ето следният пример: ако клиент се опита първо да намери foo, търси първо за него foo.subdomain.your-domain.edu , после foo.your-domain.edu, и накрая foo. Ако клиента се опитва да намери sunsite.unc.edu,(глупаво е но наистина това е начина по който работи),търси първо sunsite.unc.edu.subdomain.your-domain.edu после пробва sunsite.unc.edu.your-domain.edi, и накрая sunsite.unc.edu. Вие може би няма да искате да търсите прекалено много домейни защото отнема твърде много време търсенето им.

Примера приема че вие принадлежите на домейн subdomain.your-mashine.domain.edu, тогава вашата машина вериоятно се казва your-mashine.subdomain.your-domain.edu. ‘Search’ реда не трябва да съдража вашия TDL (Top Level Domain, ‘edu’ в този смисъл). Ако често се налага да се свързвате към хост който е от друг домейн вие може да добавите този домейн към ‘search’ реда както следва: (Отново махнете празните места в началото на файла, ако има такива )

 

______________________________________________________________________

search subdomain.your-domain.edu your-domain.edu other-domain.com

______________________________________________________________________

 

 

и така нататъка. Очевидно вие трябва да сложите истинските домейн имена вътре. Моля обърнете внимание, че трябва да има разтояние между края на домейн имената. Това е важно, моля обърнете внимание на това нещо.

 

 

3.1 Стартиране на named

След всичко това е време да стартираме. Ако използвате dialup връзка първо се първо се свържете. Напишете ‘ndc start’, и натиснете Enter, без опции. Ако не стане ништо и не работи опитайте ‘/usr/sbin/ndc start’ вместо това. Ако и това не работи вижте “QnA” сектора. Ако искате да видите системни съобщения които се управляват от syslog (обикновено са /var/adm/messages, но може и да са в /var/log/ ), докато стартирате named (направете tail –f /var/log/messages) трябва да се получи следния резултат:

(the lines ending in \ continue on the next line)

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 ще нарече файла който е в (единия от named.conf и root.hints се надявам ;-) Килнете named и проверете отново.

Може да тествате вашите настройки. Традиционно се използва програмата nslookup но в днешни времена се използва една нова наречена

$ 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 използвайки следната команда 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. Тогава ще се свърже с някой от name server машините в споменати в вашия root.hints файл, и ще запита за него от там. Може да отнеме малко време за да получите резултат също е нужно да претърси и домейните които сте посочили в /etc/resolv.conf. Please note the "aa" on the

"flags:" line. It means that the answer is authoritative, that it is

fresh from an authoritative server. I'll explain "authoritative"

 

Ако попитате същото отново ще получите следния резултат:

$ 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 Resolvers

Следващото зависи от вашата libc версия, нужно е да оправите един от двата файла /etc/nsswitch.conf или /etc/host.conf. Ако имате nsswithch.conf него ще оправим ако не тогава host.conf.

/etc/nsswitch.conf

Този дълъг файл определя от каде да се вземат различните видове данни от кои фаилове или от кои бази с данни. Той обикновенно съдържа помощна информация в началото, която може да прочетете. След това е реда който започва с ‘hosts:’, той трябва да чете

______________________________________________________________________

hosts: files dns

______________________________________________________________________

 

Ако няма ред който да започва с ‘hosts:’ тогава я сложете. Тя указва че тази програма трябва да първо да погледне в /etc/hosts файла, и след това проверява DNS съгласно resolv.conf.

/etc/host.conf

Той вероятно съдържа няколко реда, и трябва да изглежда по следният начин и започва с ‘order’:

______________________________________________________________________

order hosts,bind

______________________________________________________________________

Ако няма ред с ‘order’ трябва да добавите такъв. Той казва на host name resolving по установения ред първо да погледне в /etc/hosts, после да запита за именният сървер ( който вие сте задали в resolv.conf и е указан като 127.0.0.1).

3.3Вече знаете как да настроите кеширан named. Вземете си бира, мляко или каквото предпочитате за да отпразнувате.

  1. Forwarding

В голяма част от академичните или ISP мрежите ще открите че хората които са ги нагласили са използвали пренасочваща йерархия на 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;

};

______________________________________________________________________

Рестартирайте вашият именен сървър и тествайте с dig. Трябва да работи отлично.

5. Прост домейн

Как сам да си настроите ваш собствен домейн.

5.1 Но първо малко суха теория

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

DNS е йерархично, дървовидно построена структурирана система. Върхът и е написан от “.” произнася се ‘root’. Под . има много други Домейни на Топ Ниво (TLDs), най-добре познатите са org, com, edu и ner, но има и много други. Също като дървото има корени и нагоре се разклоняват клони. Ако имате други компютърни познания ще разпознаете в лицето на DNS търсещо дърво, и ще можете да намерите разклоненията, листата разклоненията и върхът.

Начина по, който протича една заявка за някоя машина преминава йерархично първо през върхът. Ако искате да намерите адреса на prep.ai.mit.edu вашия именен сървер започва да пита някъде си. Първо проверява в кеша. Ако адреса го има кеширан от преди, ще отговори по същия начин както видяхме в последното извлечение. Ако не знае ще започне да маха част от името от дясно, и ще започне да проверява дали не знае нещо за ai.mit.edu., после за mit.edu., после edu. и накрая . защото това е в искания файл. Ще запита . сервера за prep.ai.mit.edu. Този . сервер ще знае отговора, но и ще ви помогне като ви даде отпращане и ви каже каде е трябвало да гледате. Тези указания ще покажат на вашия сервер nameserver, който знае отговора. Сега ще илюстрирам точно това. +norec означава че dig пита не повтарящ се въпрос така че ние правим повторно запитване. Други те опции са да съкратим процедурите на dig така, че да не стигне твърде далече с много страници:

$ dig +norec +noH +noques +nostats +nocmd prep.ai.mit.edu.

;; res options: init defnam dnsrch

;; 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". Нашия собствен nameserver ни отпраща към nameserver “.” Избирате си един произволно:

 

 

$ 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

 

 

It refers us to MIT.EDU servers at once. Again pick one at random:

 

 

$ 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 имената.

Така стартирайки от . ние намерихме правилният “name servers” за всяко едно ниво в домейн името чрез препращане. Ако разбира се ползвате за това вашият собствен DNS server разбира се вашият named ще кешира всичката намерена информация докато я търси за вас и няма да се наложи да питате отново за нея.

 

Аналогично по логиката на дървото на всяко “.” отговаря точка на клон. И всяка част между “.” са имена на индивидуални клони на дървото. Един път ние изкачихме дървото като вземахме името което искахме (prep.ai.mit.edu) питайки root (.) или който и да е близък голям сървер на prep.ai.mit.edu вече имаме информация за него в кеша. Един път когато границата на кеша достигне своят предел отново започва да се запитват сърверите и да се търси препоръките които са ни дали.

Много по-малко се говори за него но също така е много важен домейн in-

addr.arpa. Той също е гнездо като “нормалните” домейни in-addr.arpa ни позволява да вземем хост името когато имаме адрес. Важно е да се подчертае че IP адресите са написани в обратен ред в in-addr.arpa домейна. Ако имате адреса на машината : 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. Умно а? ( Кажете “да” ) Тази обърнатост на номерата може да доведе до обърканост с години.

5.2. Our own domain

Сега да дефинираме понятието наш собствен домейн. Ние ще направим домейн linux.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, това че ние сме главен сървер за нея и е сложена в файл наречен 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 йерархия принадлежи )на zone файл е указана в zone частта на named.conf файла; в този случай е 0.0.127.in-addr.arpa.

 

Този “zone файл” съдържа три `resource records' ( записи за ресурсите ) (RRs): A SOA RR. A NS RR и PTR RR. SOA е съкращение на Start Of Authority. Знакът “@” е с специално обозначаващо предназначение – произхода, и докато “domain” колоната за този файл казва 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” е обичайно име за именни сървери, но с уеб сървери често срещани е www.нещо така че името може да бъде нещо си.

 

И най-накрая PTR ( Къде води домейн името ) този запис казва че хоста на адрес 1 е в подмрежата 0.0.127.in-addr.arpa, тоест е 127.0.0.1 и е именуван localhost.

SOA е предисловие за всички зонови файлове, и трябва да има точно един във всеки зонов файл. Той описва зоната, от къде идва ( машина наречена ns.linux.bogus), кой трябва да е отговорен за неговото съдържание (hostmaster@linux.bogus; тук трябва да поставите вашият емайл адрес), коя версия на зоновия файл е това (serial: 1), и другите неща които трябва да прави с кеширането и вторичните DNS сървери. За останалите полета (refresh, retry, expire and 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

 

 

Така справи се с намирането на localhost от 127.0.0.1 добрееее. Сега за нашата главна задача, домейна linux.bogus сложете нова “zone” секция в named.conf:

 

 

______________________________________________________________________

zone "linux.bogus" {

notify no;

type master;

file "pz/linux.bogus";

};

______________________________________________________________________

 

 

Обърнете внимание на липсата на “.” в домейн името в named.conf файла.

 

В linux.bogus zone файла ще сложим някаква фалшива информация:

 

______________________________________________________________________

;

; 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 трябва да бъде с верен А част. Не е легално да имате CNAME част за машина в SOA част. Неговото име не е задължително да е “ns”, може да бъде всяко легално хост име. Следващо hostmaster.linux.bogus трябва да се чете като hostmaster@linux.bogus. Това трябва да бъде mail alias (препратка към майл адрес), или пощенска кутия, където човекът подържащ DNS да чете пощата редовно. Всякакви пощенски препоръки към домейна ще бъдат изпращани към адреса посочен там. Името не е нужно да бъде “hostmaster”, може да бъде вашият нормален емайл адрес, но емайл адреса “hostmaster” се очаква да работи по-добре.

 

Има нов тип RR в този файл, а именно MX, или Mail eXchanger RR. Той указва на майл системите къде да изпращат майл, който е адресиран за someone@linux.bogus, а именно на mail.linux.bogus или mail.friend.bogus. Номера преди името на всяка машина е MX RR’s приоритета. 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.

 

 

Аз обмислено извърших грешка за да може да се научите от нея :-) Поглеждайки в zone файла откриваме този ред:

 

 

MX 10 mail.linux.bogus ; Primary Mail

 

 

Липсва точката. Или има прекалено много “linux.bogus”. Ако името на машината не завършва с точка в zone файла ще бъде добавен произхода, което ще доведе до двойно linux.bogus.linux.bogus. И така кой от двата е правилен.

 

______________________________________________________________________

MX 10 mail.linux.bogus. ; Primary Mail Exchanger

______________________________________________________________________

 

 

or

 

______________________________________________________________________

MX 10 mail ; Primary Mail Exchanger

______________________________________________________________________

 

 

Аз предпочитам втория има по-малко за писане. Има някой BIND експерти който не са съгласни, и някой които са съгласни с това. В zone файла домейна трябва да бъде написан или само mail или с “.” като бъде включено цялото име на домейна.

 

Трябва да отбележа че в named.conf файла не трябва да има “.” след имената на домейните.

 

Та ето и новиат zone файл, с малко допълнителна информация:

 

 

______________________________________________________________________

;

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

______________________________________________________________________

 

 

Тук има няколко нови RRs: HINFO (Host INFOrmation) има две части; добър навик е да описвате всяка. Първата част е хардуера или CPUто на машината, и втората е софтуера или операционната система на машината. Машината наречена “ns” има Pentium CPU и Linux 2.0. CNAME (Canonical NAME) е начин да се дадат няколко имена на всяка машина. Така www е alias (препратка) за ns.

 

Използването на CNAME е малко спорно. Но е безопасно да следвате правилата че MX, CNAME or SOA записите не трябва да се обръщат към CNAME записа, те могат да се обръщат само с за нещо с A записа, така че не ви съветвам да правите следното

 

______________________________________________________________________

foobar CNAME www ; NO!

______________________________________________________________________

 

 

но е правилно да направите

 

______________________________________________________________________

foobar CNAME ns ; Yes!

______________________________________________________________________

 

 

 

Също така е правилно да приемем че CNAME е неправилно хост име за емайл адрес: webmaster@www.linux.bogus е неправилен емайл адрес зададен с настройката която е дадена по-горе. Трябва да очаквате няколко майл администратора да си заминат :-). Начина да за избегнете това е да използвате А запис ( и вероятно някой други, като MX запис)вместо него:

 

______________________________________________________________________

www A 192.168.196.2

______________________________________________________________________

 

 

Няколко the arch-BIND-wizards(така да се каже BIND магьосника), препоръчват да не се използва въобще 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

 

 

Това е добре. Както виждате отговора много прилича на самия zone файл.

Нека да проверим отделно какво става с 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 в адреси към които те могат да се свързват. Но също така е необходима и зона за обратно преобразуване, от адреси към имена. Това име се използва от много различни видове сървери (FTP, IRC, WWW и други) за да решат дали искат да се свържат с вас или не и за да разберат какви предимства имат. За пълния достъп на всички услуги по Интернет зоната за обратно преобразуване е необходима.

 

Сложете това в 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.

______________________________________________________________________

 

 

изглежда добре, напишете целия адрес за да го изследвате и него:

 

 

______________________________________________________________________

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, аз обясних това как да направите това в първите обяснения под заглавието ``Starting named''.

 

 

5.4. Words of caution

Има някой неща които трябва да добавя тука. IP номерата използвани в примерите горе са взети от частта на “частните адреси”, тоест те не могат да се използват в публичното интернет пространство. Така че така е по безопасно да се използват в примерите с това HOWTO. Следващото нещо е известяващият ред no. Той казва на named да не уведомява вторият (slave) сървер когато той получи някой нов обновление за някой от zone файловете. В BIND-8 named може да увеодмява другите сървери който са посочени в NS zone файла когато zone е обновен. Това е удобно за обикновена употреба. Но за частни експериментчета трябва да бъде изключено ние не искаме нашият експеримент да замърсява интернет, нали ?

 

И разбира се този домейне е крайно фалшив и всички адреси в него. За истински пример от истински домейн погледнете следващият сектор от HOWTO-to.

 

5.5. Why reverse lookups don't work.

 

Има няколко причини които може да доведат до това, нормално това се избягва като се нагласят обратните преобразувания в точните файлове. Преди да пуснете сървера трябва да пуснете обратното преобразуване на вашата машина на вашият именен сървер. Ако не работи отидете обратно и го оправете.

 

 

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

5.5.1. The reverse zone isn't delegated.

Когато поискате от провайдера ви да ви осигури множество от адреси и име домейн, името нормално се делегира в смисъла на указание към тези адреси. Делегирането е поставянето му в NS записите за да ви помогне да преминете от един на друг именен сървер, което бяхме обяснили с суха теория в по горните точки. Вие го прочетохте нали? Ако зоната ви за обратно преобразуване не работи вървете обратно и го прочетете. ВЕДНАГА.

 

Зоната за обратно преобразуване също се нуждае от такова делигиране. Ако имате мрежа в обхвата 192.168.196 с linux.bogus домейн от вашият провайдер ще е необходимо да поставят запис в NS както за преобразуваща така и за обратно преобразуваща зона. Ако следвате веригата от in-addr.arpa и така нагоре до вашата мрежа сигурно ще намерите място където нишката се къса това вероятно е при вашият интернет доставчик. Оправете този пропуск като се обадите на вашият интернет доставчик и го помолите да отстрани грешката.

 

5.5.2. You've got a classless subnet

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

 

Подмрежите от даден клас са това което крепи интернет в днешно време. Преди не много време имаше голям шум около недостига на IP номера. Умните хора от ITEF (the Internet Engineering Task Force, те направиха така че интернет да работи) обединиха усилия и разрешиха проблема. На каква цена. Цената е това че ако вие получите по-малка от “С” клас подмрежа някой неща може да се повредят. Моля вижте и питайте господин DNS на <http://www.acmebw.com/askmrdns/00007.htm> за по добри обяснения и как да се справите с това.

 

Прочетохте ли го? Нямам намерение да го обяснявам така че го прочетете.

 

Първият проблем е че вашият интернет доставчик трябва да разбере техниките обяснени от мистър DNS. Не всички малки провайдери имат работещо обяснение за разбирането на това. Ако искате бъдете настойчив и им го обяснете. Но бъдете сигурен че вие първи ще го разберете ;-). Те тогава ще настроят добре зоната си за обратно преобразуване на техният сървер, който вие можете да изследвате дали е коректно конфигуриран с dig.

 

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

 

Тука има още един капан, който се крие. Старите преобразователи на имена няма да могат да разберат CNAME използването в процеса на преобразуването и процеса ще се прекъсне при обратното преобразуване на адреса на вашата машина. Това може да се отрази в определянето на погрешен мрежов клас за вашата машина, забранен достъп или нещо друго. Ако се сблъскате с подобен проблем, единственият начин по който може да го разрешите е да помолите вашият доставчик да сложи RTP запис директно в техните trick classless zone file вместо CNAME записа.

 

Някой доставчици ще ви предложат други начини да се справите с този проблем, като Web базираните форми да сложите reverse-mappings в или в друга автомагични системи.

 

5.6. Slave servers

Когато нагласите един път вашите зони коректно на главният сървер ще ви е необходимо най-малкото един подчинен сървер. Подчинените сървери са необходими за заздравяване. Ако главният ви сървер се повреди ще може да получат информация за вашия домейн от подчиненият сървер. Подчиненият сървер трябва да е на колкото се може по голямо разтояние от главния. Вашият главен сървер трябва да споделя колкото се може по малко от тези неща с главният сървер: захреанване, мрежа, доставчик, град и държава. Ако колкото се може повече неща са спазени значи наистина сте си намерили добър подържащ сървер.

 

Подчиненият съревер е просто именен сървер който е копирал зоновите файлове от главния. Вие го нагласяте ето така:

 

______________________________________________________________________

zone "linux.bogus" {

type slave;

file "sz/linux.bogus";

masters { 192.168.196.2; };

};

______________________________________________________________________

 

 

Механизмът се нарича зонов-трансфер и се използва за копиране на информация. Зоновият трансфер се контролира от 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 interval) подчинения ще премахне зоната от неговата система с файлове и ще престане да бъде сървер за това.

 

 

6. Basic security options.

By Jamie Norrish

 

Нагласяне на конфигурациите опции за да намалим възможността за проблеми.

 

 

Има няколко прости неща които трябва да направите, за да направите вашият сървер по-сигурен и да намалите неговото зареждане. Материала тук не е нещо голямо а само отправна точка; ако сте заинтересувани от сигурността (и трябва да сте), моля консултирайте се с други ресурси от мрежата ( погледнете “последната глава”).

 

Следващото конфигурационно направление се среща в named.conf. Ако настройките се срещат в options сектора на файла, те се отнасят за всички зони посочени в този файл. Ако се намират в zone сектора то те се отнасят само за тази зона. Zone сектора се записва върху options сектора.

 

6.1. Restricting zone transfers

За да може вашият помощен сървер да отговаря на запитвания за вашият домейн, те трябва да мога да правят обмен на zone информацията от вашият първичен сървер. Много малко други е необходимо да правят същото. Ето за това определянето на zone трансфера се позволява от allow-transfer опцията, 192.168.1.4 е IP адреса на ns.friend.bogus и добавя вас като дебъгваща опция:

 

______________________________________________________________________

zone "linux.bogus" {

allow-transfer { 192.168.1.4; localhost; };

};

______________________________________________________________________

 

 

Като ограничавате зоната на трансфера вие сте сигурни че единствената информация достъпна за хората е тази за директното запитване – никой не може да запита за всички детайли по вашата настройка.

 

6.2. Protecting against spoofing

Първо забранете всички запитвания(query) от домейните които не притежавате, с изключение на вашите локални/вътрешни машини. Това не само ще предотврати злоумишленото използване на вашият сървер но и ненужното му използване.

 

______________________________________________________________________

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

};

______________________________________________________________________

 

 

После забранете recursive повтарящи се запитваният освен от вътрешната/локална мрежа. Това намалява риска кешови атаки (когато фалшива дата се исипва в вашият сървер).

______________________________________________________________________

options {

allow-recursion { 192.168.196.0/24; localhost; };

};

______________________________________________________________________

 

 

6.3. Running named as non-root

Пускането на named като потребител, който не е root е много добра идея, така ще ограничите привилегиите на кракерите, които случаййййно се доберат до сървера ви. Първо трябва да създадете група и потребител под които трябва да се пуска named и тогава модифицирайте скрипта, който използвате за init процеса. Моля създайте новият потребител с група named използвайки флаговете –u и –g.

 

Като пример в Debian GNU/Linux 2.2 вие може би трябва да преправите /etc/init.d/bind script и да имате следният ред ( кадето потребителят и групата named са били създадени:

 

______________________________________________________________________

start-stop-daemon --start --quiet --exec /usr/sbin/named -- -u named -g named

______________________________________________________________________

 

 

Същото може да направите с Red Hack и с другите дистрибуции. Dave Lugo е описал сигурноста с chroot нагласянето на DNS http://www.etherboy.com/dns/chrootdns.html интересно е да го прочетете.

 

7. A real domain example

Къде да видим някой истински zone файлове.

 

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

 

Аз използвам този пример с позволението на David Bullock от LAND-5. Тези файлове са от 24ти Септември 1996, и са редактирани за да се доближат до BIND 8 и продължени от мен. Така че това което ще видите тук се различава от това което ще ви даде запитване към LAND-5’s сървера сега.

 

7.1. /etc/named.conf (or /var/named/named.conf)

Тука намираме главните zone сектори за двете ни зони за преобразуване:

127.0.0 мрежата и LAND-5 206.6.177 подмрежата, и първичния ред за land-5 пренасочващата (forward) зона. Имайте предвид това че вместо да ползват директория наречена 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 файл за да си поиграете с него МОЛЯ ВИ поставете “notify no;” в zone сектора за двете 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. И двата са задължителни. Нищо повече не е необходимо за този файл. Сигурно няма да се наложи никога да променяте този файл освен ако не промените вашият nameserver или hostmaster адрес.

 

 

______________________________________________________________________

@ 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 реда в zone файловете ако откриете че липсва.

 

 

7.4. /var/named/zone/land-5.com

Тук забелязваме задължителният SOA запис, и необходимия NS. Ние можем да забележим че има втори name server на ns2.psi.net. Това трябва да е точно така винаги да имате един резервен сервер. Също така можем да забележим, че главния хост наречен land-5 който се грижи за много различни Интернет услуги и, че той го прави в CNAME-тата ( алтернатвата е използването на А линия)

 

Както виждате от SOA записа, zone файла произлиза от land-5.com, човека който го администрира е root@land-5.com. hostmaster e друго често използвано име за това. Серийният номер е в обичаен yyyymmdd формат с днешните серийни номера; това може би е шестата версия на zone файла от 20ти Септември 1996. Запомнете това, че серийният номер трябва да нараства монотонно, ето тук има само една цифра за днешния serial#, така че след 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

; {Many repetitive definitions deleted - SNIP}

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 nameserver-a ще намерите хост имената са в формата на ws_number. Като в по-старата BIND 4 версия named започва да ограничава символите които могат да се използват за хост имена. Това не работи точно така с BIND-8, и аз употребявам “-“ на мястото на “_” в това HOWTO.

 

Още нещо показва че workstations-те нямат собствени имена, но по-скоро представки следвани от последните две части от IP номерата. Използването на това може да опрости поддръжката значително, но може да стане и много безлично, и до някаде да изнерви вашите клиенти.

 

Също така виждаме funn.land-5.com e препратка (alias) за land-5.com, но използва А записа, не 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.

; {Many repetitive definitions deleted - SNIP}

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.

______________________________________________________________________

 

 

Reverse зоната е тази която в процеса на самата настройка може да ни навлече доста нерви. Тя трябва да намира хост имената ако имате IP номерата на машината. Пример: имате IRC сервер, който приема връзки от IRC клиенти. Както и да е вие сте Норвежки IRC сервер и приемате връзки единствен само от Норвегия и другите Скандинавски страни. Когато получите връзка от клиент C библиотеката може да ви каже IP номера на свързващата се машина защото IP номера се съдържа в всички пакети които минават през мрежата. Сега можете да извикате функция наречена gethostbyaddr, която проверява за името на хоста от даден IP номер. Gethostbyaddr ще запита DNS сервера, който ще намери DNS да провери за машината. Да предположим че връзката е от ws-177200.land-5.com. IP номера с C библиотеката които идват до IRC сервера, ни казват, че IP номера е 206.6.177.200. За да намерим името на тази машина ние трябва да намерим 200.177.6.206.in-addr.arpa. DNS сървера първо ще намери arpa. сървери после ще намери in-addr.arpa., следващи до обратното преобразуване на 206, после 6 и накрая ще намери сървер за 177.6.206.in-addr.arpa зоната(zone) на 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 сървера. IRC сървера приема само връзки от скандинавски страни, или *.no, *.se, *.dk, името ws-177200.land-5.com въобще не отговаря на нито един от тези, и сървера ще забрани връзката. Ако няма обратно преобразуване на 206.2.177.200 в in-addr.arpa zone зоната няма да може да намери името и ще трябва да стравнява 206.2.177.200 със *.no, *.se and *.dk, нито едно от което няма да отговаря.

 

Някой хора ще ви кажат, че обратното преобразуване е важно само за услугите, и че не е важно за всичко. Не е така: много ftp, news, IRC дори и http (WWW) сървери няма да приемат връзка от машини, за които не могат да определят имената. Така че обратното преобразуване за сърверите е задължително.

 

8. Maintenance

Да го задържим да работи.

 

Има една подържаща задача която трябва да изпълните на nameds, това ще го накара да работи добре. Това държи root.hints файловете винаги обновени. Най-лесният начин е да използвате dig. Първо пуснете dig без аргументи така ще откриете root.hints съгласно вашият собствен сървер. После питайте някой от дадените root сервери с dig @rootserver. Трябва да се отбележи че изхода ще изглежда ужасно като root.hints файла. Запазете го в файл (dig

@e.root-servers.net . ns >root.hints.new) и преместете старият root.hints с него.

 

Да не забравите да презаредите named след обновлението.

Al Longyear ми изпрати този скрипт който автоматично обновява root.hints. Инсталирайте crontab за да се пуска веднъж месечно и забравете. Скрипта приема че имате работещ емайл и е дефиниран пренасочен (mail-alias) “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 <hostmaster>"

echo "From: system <root>"

# 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 файла от ftp-то на Internic. Не използвайте ftp за да обновите root.hints горният метод е много по приятелски за мрежата.

 

9. Converting from version 4 to version 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

______________________________________________________________________

 

 

Командният ред e bind8/src/bin/named това е директорията ( това трябва да е сорс дистрибуция ако имате бинарни пакети скрипта вероятно е някаде наоколо, не съм сигурен точно каде), напишете:

 

______________________________________________________________________

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

};

______________________________________________________________________

 

 

В BIND 8 директорията bind8/src/bin/named/test може да намерите това и копие от zone файловете, които много хора могат да добавят веднага. Форматите за zone файловете и root.hints файловете са идентични, както и командите за обновяване.

 

10. Questions and Answers

Моля прочетете този сектор преди да ми пишете.

1. Моят named иска named.boot файл

 

Прочели сте грешно HOWTO. Моля вижте старите версии на това HOWTO които обясняват BIND 4 <http://www.math.uio.no/~janl/DNS/>

 

2. Как да използвам DNS зад firewall?

 

Решението е : forward only;. Може би се нуждаете

 

___________________________________________________________________

query-source port 53;

___________________________________________________________________

 

 

вътрешни опции -> ``options'' част от named.conf файла както предполагате в примера с -> ``caching'' сектора.

 

3. How do I make DNS rotate through the available addresses for a

service, say www.busy.site to obtain a load balancing effect, or

similar?

 

Make several A records for www.busy.site and use BIND 4.9.3 or

later. Then BIND will round-robin the answers. It will not work

with earlier versions of BIND.

 

4. I want to set up DNS on a (closed) intranet. What do I do?

 

You drop the root.hints file and just do zone files. That also

means you don't have to get new hint files all the time.

 

5. How do I set up a secondary (slave) name server?

 

If the primary/master server has address 127.0.0.1 you put a line

like this in the named.conf file of your secondary:

 

 

___________________________________________________________________

zone "linux.bogus" {

type slave;

file "sz/linux.bogus";

masters { 127.0.0.1; };

};

___________________________________________________________________

 

 

You may list several alternate master servers the zone can be copied

from inside the masters list, separated by ';' (semicolon).

 

6. I want BIND running when I'm disconnected from the net.

 

There are four items regarding this:

 

· Specific to BIND 8, Adam L Rice has sent me this e-mail, about how

to run DNS painlessly on a dialup machine:

 

 

I have discovered with newer versions of BIND that this

[<em/shuffeling files, -ed/] is no longer necessary. There is a

"forward" directive in addition to the "forwarders" directive that

controls how they are used. The default setting is "forward first",

which first asks each of the forwarders, and then tries the normal

approach of doing the legwork itself if that fails. This gives the

familiar behaviour of gethostbyname() taking an inordinately long time

when the link is not up. But if "forward only" is set, then BIND

gives up when it doesn't get a response from the forwarders, and

gethostbyname() returns immediately. Hence there is no need to

perform sleight-of-hand with files in /etc and restart the server.

In my case, I just added the lines

forward only;

forwarders { 193.133.58.5; };

to the options { } section of my named.conf file. It works very nicely. The

only disadvantage of this is that it reduces an incredibly sophisticated

piece of DNS software to the status of a dumb cache. To some extent, I would

just like to run a dumb cache for DNS instead, but there doesn't seem to be

such a piece of software available for Linux.

 

 

· I have received this mail from Ian Clark <ic@deakin.edu.au> where

he explains his way of doing this:

 

 

I run named on my 'Masquerading' machine here. I have

two root.hints files, one called root.hints.real which contains

the real root server names and the other called root.hints.fake

which contains...

----

; root.hints.fake

; this file contains no information

----

When I go off line I copy the root.hints.fake file to root.hints and

restart named.

When I go online I copy root.hints.real to root.hints and restart

named.

This is done from ip-down & ip-up respectively.

The first time I do a query off line on a domain name named doesn't

have details for it puts an entry like this in messages..

Jan 28 20:10:11 hazchem named[10147]: No root nameserver for class IN

which I can live with.

It certainly seems to work for me. I can use the nameserver for

local machines while off the 'net without the timeout delay for

external domain names and I while on the 'net queries for external

domains work normally

 

 

Peter Denison thought that Ian does not go far enough though. He

writes:

 

 

When connected) serve all cached (and local network) entries immediately

for non-cached entries, forward to my ISPs nameserver

When off-line) serve local network queries immediately

fail all other queries **immediately**

The combination of changing the root cache file and forwarding queries

doesn't work.

So, I've set up (with some discussion of this on the local LUG) two nameds

as follows:

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

And combined this with port forwarding, to send port 53 to 61053 when

off-line, and to port 60053 when online. (I'm using the new netfilter

package under 2.3.18, but the old (ipchains) mechanism should work.)

Note that this won't quite work out-of-the-box, as there's a slight bug in

BIND 8.2, which I have logged wth the developers, preventing a slave

having a master on the same IP address (even if a different port). It's a

trivial patch, and should go in soon I hope.

 

 

· I have also received information about how BIND interacts with NFS

and the portmapper on a mostly offline machine from Karl-Max

Wanger:

 

 

I use to run my own named on all my machines which are only

occasionally connected to the Internet by modem. The nameserver only

acts as a cache, it has no area of authority and asks back for

everything at the name servers in the root.cache file. As is usual

with Slackware, it is started before nfsd and mountd.

With one of my machines (a Libretto 30 notebook) I had the problem

that sometimes I could mount it from another system connected to my

local LAN, but most of the time it didn't work. I had the same effect

regardless of using PLIP, a PCMCIA ethernet card or PPP over a serial

interface.

After some time of guessing and experimenting I found out that

apparently named messed with the process of registration nfsd and

mountd have to carry out with the portmapper upon startup (I start

these daemons at boot time as usual). Starting named after nfsd and

mountd eliminated this problem completely.

As there are no disadvantages to expect from such a modified boot

sequence I'd advise everybody to do it that way to prevent potential

trouble.

 

 

· Finally, there is HOWTO information about this at Ask Mr. DNS at

<http://www.acmebw.com/askmrdns/#linux-dialup>. It is about BIND 4

though, so you have to adapt what he says to BIND 8.

 

7. Where does the caching name server store its cache? Is there any

way I can control the size of the cache?

 

The cache is completely stored in memory, it is not written to disk

at any time. Every time you kill named the cache is lost. The

cache is not controllable in any way. named manages it according

to some simple rules and that is it. You cannot control the cache

or the cache size in any way for any reason. If you want to you can

``fix'' this by hacking named. This is however not recommended.

 

8. Does named save the cache between restarts? Can I make it save it?

 

No, named does not save the cache when it dies. That means that

the cache must be built anew each time you kill and restart named.

There is no way to make named save the cache in a file. If you

want you can ``fix'' this by hacking named. This is however not

recommended.

 

9. How can I get a domain? I want to set up my own domain called (for

example) linux-rules.net. How can I get the domain I want assigned

to me?

 

Please contact your network service provider. They will be able to

help you with this. Please note that in most parts of the world

you need to pay money to get a domain.

 

10.

How can I secure my DNS server? How do I set up split DNS?

 

Both of these are advanced topics. They are both covered in

<http://www.etherboy.com/dns/chrootdns.html>. I will not explain

the topics further here.

 

 

11. How to become a bigger time DNS admin.

Documentation and tools.

 

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 <http://www.dns.net/dnsrd/> (DNS

Resources Directory), <http://www.isc.org/bind.html>; 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

<news:comp.protocols.tcp-ip.domains> 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

<http://www.cis.ohio-state.edu/~barr/rfc1912-errors.html>

 

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.