DNS - działanie i konfiguracja usługi

_out_

·

2002-12-26 · (czytany: 4043 razy)

Historia - Dlaczego powstał DNS

Korzenie Internetu si gaj eksperymentalnej sieci komputerowej ł cz cej organizacje badawcze, zwanej ARPAnet. W

latach siedemdziesi tych minionego stulecia siec ARPAnet liczyła zaledwie kilkaset hostów. Wraz z momentem kiedy

opracowany na Uniwersytecie Kalifornijskim w Berkeley zestaw protokołów TCP/IP stal si standardowym protokołem w

ARPAnecie oraz gdy doł czono go do systemu Unix BSD ł czno

z ARPAnetem stała si dost pna dla wielu

organizacji. Sie rozrosła si do tysi cy hostów. Człowiek nie jest maszyn dlatego te w przeciwie stwie do nich łatwiej

mu zapami tywa nazwy ni cyfry. Tak oto powstał plik HOSTS.TXT przechowuj cy odwzorowania nazw komputerów

ARPAnetu na adresy IP. Plik ten redagowało Centrum Informacji Sieciowej (NIC) w Instytucie Badawczym Stanforda, a

rozpowszechniany był z hosta SRI-NIC. Jak łatwo si domy li takie rozwi zanie spowodowało i wraz ze wzrostem

liczby hostów rosła wielko

pliku, a co wa niejsze zwi kszył si ruch w sieci powodowany ci głym uaktualnianiem tego

pliku. Obci enie hosta SRI-NIC zbli ało si do warto ci krytycznej tego było zbyt wiele... W 1984 roku Paul Mockapetris

wydaje dokumenty RFC 882 i 883 opisuj ce domenowy system nazw (DNS).

DNS Działanie

- Struktura DNS i RevDNS, resolwer, zapytania DNS, schemat zapytania DNS, buforowanie -

Struktura DNS

DNS to rozproszona baza danych. Dzi ki takiemu rozwi zaniu mo liwe jest lokalne zarz dzanie fragmentami całej bazy,

udost pnianie danych realizowane jest za po rednictwem mechanizmu klient-serwer. Resolwer (klient) tworzy zapytanie

DNS i wysyła je do serwera DNS. (Wi cej na ten temat w nast pnych rozdziałach). Struktura DNS jest struktur

drzewiast na szczycie tej struktury znajduje si w zeł główny (root domain - domena główna) oznaczany etykiet pust

"" (zapisywany jako kropka). Kolejnym elementem tego drzewa s tzw. TLD (Top Level Domains) czyli domeny

najwy szego rz du np.: com, pl, edu, gov, mil, de itp. Za przyporz dkowanie nazw hostów na ni szych szczeblach

hierarchii (poni ej TLD) odpowiada organizacja NIC ka dego kraju. Dlatego spotykamy np. domeny typu edu.pl, com.pl,

org.pl. Jednak e taka organizacja nie jest reguł ani obowi zkiem czego przykład stanowi organizacja domen ni szych

poziomów w Niemczech, gdzie nazwy domenowe odnosz si bezpo rednio do firm. Struktura drzewiasta uniemo liwia

dublowanie si nazw hostów czy poddomen. Nie mo na utworzy w jednej domenie dwóch poddomen o takich samych

nazwach tak samo jak niemo liwo ci jest stworzenie w tym samym katalogu dwóch podkatalogów identycznie si

nazywaj cych.

Struktura RevDNS

RevDNS to odwzorowywanie adresów IP na nazwy. W przestrzeni nazw domenowych istnieje domena in-addr.arpa,

w zły w tej domenie s etykietowane wg. liczb w kropkowej notacji adresu IP. Wynika z tego prosty wniosek, e domena

in-addr.arpa posiada 256 w złów, których etykiet jest pierwszy oktet adresu IP. Ka dy z tych w złów rozgał zia si na

kolejne 256 w złów których etykiet jest ju drugi oktet adresu IP. Tworzy si w ten sposób drzewo posiadaj ce cztery

poziomy (tyle ile jest oktetów w adresie IP). Pełna struktura została pokazana na rysunku poni ej. W ten sposób domena

in-addr.arpa w rzeczywisto ci mo e pomie ci wszystkie adresy IP Internetu. Nale y jeszcze doda , e adresy w nazwie

domenowej zapisywane s od tylu - adresowi IP 213.25.234.82 odpowiada w zełw domenie in-addr.arpa

82.234.25.213.in-addr.arpa (jak pokazano na rysunku). Taka struktura umo liwia delegowanie domen w strefie

odwzorowywanie odwrotnego.

Klient czyli Resolwer

Programy potrzebuj ce nazw z przestrzeni nazw domenowych (np. ftp) posługuj si resolwerami. Resolwer odpytuje

serwer nazw, nast pnie interpretuje otrzyman odpowied i ostatecznie zwraca informacje do programu, który ich

za dał. Wi kszo

pracy zwi zanej ze znalezieniem odpowiedzi wykonuje serwer DNS. Wi kszo

resolwerów jest

okre lanych przez specyfikacje DNS jako resolwery szcz tkowe gdy nie potrafi nawet buforowa otrzymanych

odpowiedzi (robi to serwer DNS).

Konfiguracja resolwera jest bardzo prosta, przechowuje j plik resolv.conf w katalogu /etc. Przykładowa zawarto

tego

pliku:

nameserver 194.204.159.1
nameserver 194.204.152.34

Dyrektywa nameserver informuje resolwer o tym, z jakich serwerów DNS ma korzysta , host, który wiadczy usługi

nazewnicze nie musi mie dyrektywy nameserver, poniewa resolwer domy lnie szuka serwera nazw na ho cie, w

którym działa.

Rodzaje zapyta DNS

Rekurencyjne

to zapytanie wysyłane jest głównie przez resolwery (blokuje si obsług zapyta rekurencyjnych od innych

serwerów DNS). Gdy serwer otrzymuje zapytanie rekurencyjne zostaje obarczony odpowiedzialno ci za

dostarczenie odpowiedzi. Serwer powtarza t sam procedur tzn. wysyła zapytanie do innego serwera, który

udziela mu wskazania, pytaj cy pod a za wskazaniami a do otrzymania ostatecznej odpowiedzi, któr mo e

by komunikat o bł dzie.

Iteracyjne

to zapytanie jakie wysyłaj sobie serwery DNS. Serwer DNS zwraca pytaj cemu najlepsz odpowied jak

posiada czyli wskazanie (adresy serwerów DNS bli szych domenie, o któr otrzymałzapytanie) - pytaj cy sam

wybiera jedno ze wskaza .

Schemat zapytanie DNS

W tym rozdziale dowiesz si jak przebiega proces odnalezienia adresu IP w przestrzeni nazw. Powiedzmy, e chciałby

znale

adres IP hosta antifa.zoltan.eu.org. Twój resolwer wysyła do serwera dns zapytanie rekurencyjne. Serwer nic

nie wie o tej strefie, wi c odpytuje serwery główne czy wiedz co na temat tej domeny. Serwery główne oczywi cie

bezpo rednio te o niej nic nie wiedz , ale za to zwracaj mu wskazanie do serwerów przechowuj cych dane o domenie

org. (jak ju powiniene zauwa y , nasz serwer wysłałzapytanie iteracyjne) Nasz serwer DNS wybiera spo ród tych

wskaza i odpytuje jaki serwer domeny org. Ten z kolei zwraca mu list serwerów odpowiedzialnych za domen

eu.org. Serwery eu.org ponownie zwracaj wskazanie informuj ce o tym, kto odpowiada za domen zoltan.eu.org. I tym

razem nasz serwer pod a za wskazówk i odpytuje serwer domeny zoltan.eu.org, ten serwer przegl da swoj baz

danych i stwierdza, e taki host ma adres 212.160.112.227.

Buforowanie

Mo e wydawa si , e cały ten proces jest do

skomplikowany i długotrwały, w rzeczywisto ci odbywa si to zupełnie

szybko dzi ki mechanizmowi zwanemu buforowaniem. W poprzednim paragrafie dowiedziałe si , e serwer otrzymuje

wiele wskaza do innych serwerów nazw, serwer nie zapomina o nich, a wr cz przeciwnie gromadzi je, by przyspieszy

odwzorowanie. Nast pnym razem kiedy chciałby znowu dowiedzie si , jaki adres ma host antfa.zoltan.eu.org serwer

najpierw przeszukałby swoj pami

podr czn , w której natrafiłby na t nazw i natychmiastowo udzieliłby odpowiedzi.

Co wi cej, gdyby my zapytali teraz o IP hosta tychy.eu.org, to serwer DNS przeszukuj c pami

podr czn natrafiłby

na informacj , e dane o tej domenie posiada ns.eu.org (zbuforowałt informacj wykonuj c poprzednie wyszukiwanie)

i bezpo rednio jego zapytałby o IP hosta tychy.eu.org. Oczywi cie, serwer DNS nie buforuje danych w niesko czono

-

czas, jaki serwer ma przechowywa dan informacje jest okre lany w pliku konfiguracyjnym dla danej strefy i nazywany

jest ttl (time to live). Po upływie tego czasu dane s kasowane z pami ci podr cznej.

Bind

- Info, konfiguracja (named.conf, rekord SOA, pliki stref dla RevDNS i DNS) -

Bind - Info

Paul Mockapetris byłpierwsz osob , która napisała realizacj systemu nazw domenowych nosiła ona nazw JEEVES.

Pó niejsza implementacj byłprogram BIND (Berkeley Internet Name Domain) autorstwa Kevina Dunlapa dla systemu

Unix BSD. Program BIND jest najpopularniejsz implementacj DNS i zostałprzeniesiony do praktycznie wszystkich

odmian Uniksa i Linuksa. Jego popularno

jest tak ogromna, e zostałnawet przeniesiony na platform Windows NT

firmy Microsoft.

Konfiguracja serwera DNS (Bind wersja powy ej 8.2)

Aby system nazw domenowych byłbardziej niezawodny przyj to, e powinno uruchamia si co najmniej dwa serwery

nazw. Jeden z tych serwerów to tzw. Primary DNS (master), natomiast drugi to Secondary DNS (slave). Ró nica mi dzy

nimi jest taka, e pierwszy wszystkie dane o strefach posiada zapisane na dysku i ka da zmiana strefy dokonywana jest

na tym serwerze. Serwer zapasowy (slave) w regularnych odst pach czasu pobiera pliki stref od swojego mastera

(proces ten nazywa si transferem stref). Istnieje jeszcze mo liwo

skonfigurowania serwera nazw, który nie posiada

adnych plików stref (nie posiada zwierzchno ci nad adn domen ). Taka konfiguracja jest bardzo przydatna, gdy

potrafi wykonywa zapytania DNS dla aplikacji działaj cych w sieci lokalnej i co najwa niejsze przechowywa je w

pami ci podr cznej. Konfiguracja ta nosi nazw serwera pami ci podr cznej (caching-only server) i jest najprostsza do

zrealizowania z punktu widzenia administratora. Konfiguracja wspomnianych wy ej serwerów nazw zostanie omówiona

poni ej.

Plik named.conf

Rozdziałten, w którym omawia b dziemy tworzenie pliku named.conf jest dobrym miejscem, aby omówi wspomniane

wy ej konfiguracje Binda, gdy wła nie w tym pliku zapada decyzja o funkcjach, jakie b dzie spełniałten program.

Chciałbym zaznaczy , e program Bind mo e równocze nie spełnia wszystkie funkcje, o których wspomniałem w

poprzednim paragrafie tzn. mo e by podstawowym serwerem dla jednej domeny, zapasowym dla drugiej i oczywi cie

buforowa wszystkie zapytania. W tej chwili mo e si to wydawa troch niezrozumiałe, ale w miar jak b dziemy

budowa plik konfiguracyjny powinno sta si jasne.

Przejd my wi c do konfiguracji. Dozwolone s trzy rodzaje komentarzy:

# w stylu powłoki systemu
// jak w C++
/* jak w C */

Rozpoczniemy od okre lenia kilku opcji globalnych:

// Ka da instrukcja musi ko czy

si

rednikiem

options {
directory "/var/named" ; //Ustawia katalog roboczy serwera
auth-nxdomain yes; //Dzi ki tej opcji wszystkie negatywne odpowiedzi jakie

//zbuforował serwer b d

traktowane jako autorytatywne

//tzn. je eli serwer udzieli innemu informacji

//o tym,

e dany host nie istnieje w domenie, nad któr

nie mamy

//zwierzchnictwa to pytaj cy uzna nasza odpowied

za autorytatywn

listen-on {any;}; // Opcja, dzi ki której serwer DNS b dzie nasłuchiwał

// na wszystkich interfejsach

pid-file "named.pid"; //

cie ka do pliku przechowuj cego numer procesu

named,

// wzgl dem tej ustawionej w dyrektywie directory

};

Jak wynika z poprzednich paragrafów, serwer, aby mógłdziała musi posiada wskazania do serwerów głównych.

Wskazania te znajduj si w pliku named.root lub named.cache, który dost pny jest z serwera ftp.rs.internic.net. W

obecnej chwili na całym wiecie jest trzyna cie serwerów głównych. Teraz musimy poinformowa nasz serwer DNS za

pomoc nast puj cej dyrektywy o tym, gdzie znajduje si informacja o serwerach głównych:

zone "." IN {

type hint;
file "named.root";

};

Opcja file jest lokacja pliku wzgl dem cie ki ustawionej w directory. Podobnie musimy doda pliki dla p tli zwrotnej,

której ka dy host u ywa do komunikacji z samym sob . Serwer mógłby działa poprawnie i bez konfiguracji p tli

zwrotnej, ale je li główny serwer nazw nie byłby skonfigurowany do odwzorowywania tego adresu, to jego wyszukiwanie

mogłoby zako czy si niepowodzeniem, najlepiej jest zapewni to odwzorowywanie samemu, co uczynimy za pomoc

znanej ju dyrektywy.

//odwzorowanie normalne
zone "localhost" IN {

type master;
file "db.localhost";

};

//odwzorowanie odwrotne
zone "0.0.127.in-addr.arpa" IN {

type master;
file "db.127.0.0";

};

Zawarto

plików db.localhost oraz db.127.0.0 zostanie pokazana w rozdziale dotycz cym tworzenia stref, aby nie

wprowadza zamieszania. Do tego momentu zawarto

pliku named.conf wspomnianych w poprzednich rozdziałach

konfiguracji serwera DNS jest wspólna. Nale y doda , e tak skonfigurowany serwer DNS jest ju w pełni działaj cym

serwerem pami ci podr cznej.

My jednak nie chcemy, aby nasz serwer DNS spełniałtylko tak rol . Mamy przecie domen , któr chcemy zarz dza .

Dodajmy wi c wpisy informuj ce nad jak domen mamy zwierzchno .

Je eli konfigurujemy podstawowy serwer DNS

//odwzorowanie normalne
zone "zoom.pol" IN {

type master;
file "db.zoom.pol";

};

//odwzorowanie odwrotne
zone "0.168.192.in-addr.arpa" IN {

type master;
file "db.192.168.0";

};

Je eli konfigurujemy zapasowy serwer DNS

//odwzorowanie normalne
zone "zoom.pol" IN {

type slave;
masters { 192.168.0.1; };
file "bak.zoom.pol";

};

//odwzorowanie odwrotne
zone "0.168.192.in-addr.arpa" IN {

type slave;

masters { 192.168.0.1; };
file "bak.0.168.192";

};

Kilka słów komentarza - opcja masters to lista serwerów podstawowych, od których mo na pobra informacje o strefie;

opcja type informuje o rodzaju serwera nazw (podstawowy lub zapasowy); opcja file (dla master) to cie ka do pliku, w

którym zawarte s informacje o domenie; opcja file (dla slave) pokazuje cie k do pliku, w którym serwer zapasowy

zapisze ci gni te informacje. Serwer zapasowy podczas pracy przechowuje te informacje w pami ci. Opcja ta nie jest

niezb dna, lecz zalecam jej stosowanie. Dlaczego? Oto prosty przykład: przypu my nasz serwer zapasowy działa,

pobrałju dane o jakiej strefie i zapisałje do pliku. Nagle przestaje działa serwer podstawowy tej strefy, a my musimy

zrestartowa nasz serwer zapasowy. Jak wiadomo, przy starcie serwery zapasowe ł cz si z podstawowymi by pobra

dane, ale w tym przypadku byłoby to niemo liwe, bo serwer podstawowy nie działa. My nie mamy si czym martwi - w

tej sytuacji nasz serwer zapasowy przeczyta dane z pliku, b dzie próbowałsi dalej ł czy z serwerem głównym i dalej

b dzie w pełni spełniałrol serwera zapasowego. Gdyby my nie posiadali tego pliku, serwer zapasowy nie miałby

ródła danych, a co za tym idzie, nie odpowiadałby na zapytania dotycz ce tej domeny. Prosz sobie wyobrazi , jakie to

ma skutki je eli posiadamy tylko jeden serwer podstawowy i jeden zapasowy.

I to w zasadzie koniec podstawowej konfiguracji pliku named.conf. O kolejnych opcjach zwi zanych z rejestracj

zdarze , bezpiecze stwem i narz dziami usprawniaj cymi prace z serwerem DNS dowiesz si w nast pnych

rozdziałach. Teraz pora by w ko cu pozna budow plików stref, tych plików, które umieszczałe w dyrektywie zone w

opcji file dla Twojej domeny...

Rekord SOA (Start Of Authorihy)

...nauk t rozpoczniemy od rekordu SOA, który znajduje si w ka dym pliku strefy. Komentarze w pliku strefy

poprzedza si znakiem rednika.

Posta rekordu SOA

domain.pl.

IN

SOA

dns1.domain.pl. hostmaster.domain.pl. (

2002081401

;SERIAL

3h

;REFRESH

1h

;RETRY

1w

;EXPIRE

1h )

;MINIMUM

A teraz czas na wyja nienie wszystkich warto ci w tym rekordzie.

domain.pl. - nazwa domeny, dla której jeste my serwerem

IN - klasa rekordu (podana warto

dla sieci TCP/IP)

SOA - typ rekordu

dns1.domain.pl. - nazwa podstawowego serwera DNS dla naszej domeny

hostmaster.domain.pl. - adres kontaktowy email do osoby odpowiedzialnej za stref (pierwsza kropk nale y

traktowa jako znak @ (at))

SERIAL - warto

dla zapasowego serwera DNS. Przy ka dej zmianie w strefie w serwerze podstawowym nale y

zwi ksza t warto , gdy sprawdzaj c aktualno

swoich danych serwer podstawowy porównuje numer, którym

obecnie dysponuje z numerem, który wła nie pobrał. W momencie, gdy pobrany numer jest wi kszy zostaje rozpocz ty

transfer całej strefy. Wg mnie najlepszy format numeru seryjnego to taki, jaki podano w przykładzie YYYYMMDDNN,

gdzie YYYY - rok, MM - miesi c, DD - dzie , NN - numer modyfikacji danego dnia.

REFRESH - informacja dla serwera zapasowego co jaki czas ma sprawdza aktualno

swoich danych strefowych

RETRY - je eli nie udało si poł czy z serwerem podstawowym po upływie czasu od wie ania (np. awaria ł cza w

sieci, w której pracuje serwer podstawowy), to w tym polu znajduje si informacja dla serwera zapasowego co ile ma

ponawia prób nawi zania poł czenia

EXPIRE - czas, po jakim serwer zapasowy uzna dane w strefie za nie aktualne, je eli nie zdoła si poł czy z serwerem

podstawowym po okresie czasu zdefiniowanym w polu RETRY

MINIMUM - jest to czas, przez jaki serwery b d przechowywały wszelkie negatywne odpowiedzi

Uwaga: Nale y pami ta , aby wszystkie nazwy domenowe w rekordzie SOA zako czy kropk .

Uwaga: Wszystkie warto ci ttl oraz czasy w poszczególnych polach rekordu SOA domy lnie s podawane w

sekundach. Aby upro ci zapis dost pne s nast puj ce skróty:

h - godzina
d - dzie
w - tydzie

Plik strefy odwzorowywania normalnego

Do ka dego pliku strefy musi zosta ustawiony jako pierwszy domy lny ttl, nast pnie dodaje si rekord SOA opisany

powy ej. Po nich musz zosta wymienione serwery DNS dla danej domeny. Kolejna czynno

to uzupełnienie pliku

strefy o konkretne rekordy zasobów (resource records) dla hostów w naszej domenie.

Ogólna posta rekordu zasobów: nazwa_domenowa [ttl] klasa typ_rekordu dane_rekordu

Pole klasa powinno zawiera dla sieci TCP/IP warto

IN, pole ttl oznacza czas wa no ci informacji (domy lnie w

sekundach); je li je pomini to zostanie wykorzystana warto

$ttl z pliku strefy.

Na tym etapie nale y wyja ni znaczenie poszczególnych najcz ciej u ywanych typów rekordów. S to:

A

Ten rekord wi e adres IP z nazwa hosta. Mo e istnie tylko jeden rekord dla danego hosta, poniewa nazwa

ta jest uznawana za kanoniczn (oficjaln ). Reszta nazw tego hosta musi zosta zdefiniowana jako alias za

pomoc rekordu CNAME. Pole dane_rekordu powinno zawiera adres IP w notacji kropkowej.

CNAME

Ten rekord odwzorowuje alias na kanoniczn nazw hosta. Dzi ki temu rekordowi mo liwe jest utworzenie

wielu nazw tego samego hosta. Pole dane_rekordu powinno zawiera kanoniczna nazw hosta.

NS

Rekordy te okre laj wszystkie serwery (master i slave) dla danej domeny. Pole dane_rekordu powinno

zawiera kanoniczn nazw hosta, który jest serwerem strefy.

Przykładowy plik (fragment strefy mojej sieci lokalnej)

$ttl 3h ; domy lny ttl dla strefy

;pocz tek rekordu SOA
zoom.pol.

IN

SOA

holly.zoom.pol. out.holly.zoom.pol. (

2002081001
3H
15M
1W
1D ); koniec rekordu SOA

;Serwery nazw dla domeny zoom.pol
zoom.pol.

IN

NS

holly.zoom.pol.

;Rekordy zasobów strefy zoom.pol
holly.zoom.pol.

IN

A

192.168.0.1

antifa.zoom.pol.

IN

A

192.168.0.3

apacz.zoom.pol.

IN

A

192.168.0.6

;Definicje aliasów
mail.zoom.pol.

IN

CNAME

holly.zoom.pol.

dns.zoom.pol.

IN

CNAME

holly.zoom.pol.

A teraz obiecany plik dla p tli zwrotnej.

localhost.

IN

SOA localhost.

hostmaster.localhost. (

42
3H
15M
1W
1D )

localhost.

IN

NS

localhost.

localhost.

IN

A

127.0.0.1

Plik strefy odwzorowywania odwrotnego

Podobnie jak dla strefy odwzorowywania normalnego pierwszy wpis stanowi domy lny ttl, potem rekord SOA, nast pnie

rekordy zasobów dotycz ce serwerów strefy odwzorowywania odwrotnego i na ko cu rekordy zasobów dla konkretnej

strefy. Jednak e w pliku tym wykorzystuje si do tego celu jeden rekord.

PTR

Rekord ten słu y do powi zania nazw w domenie in-addr.arpa z nazwami hostów (jak wspomniano w

poprzednich rozdziałach nazwy w tej domenie to odpowiednie oktety adresu IP w notacji kropkowej). Pole

dane_rekordu musi zawiera kanoniczn nazw hosta.

Przykładowy plik (fragment strefy mojej sieci lokalnej)

$ttl 3h

;domy lny ttl dla strefy

;rekord SOA
0.168.192.in-addr.arpa.

IN

SOA

holly.zoom.pol.

out.holly.zoom.pol.

(

02030202
3h
1h
1w
1h );koniec rekordu SOA

;Serwer dla strefy 0.168.192.in-addr.arpa
0.168.192.in-addr.arpa.

IN

NS

holly.zoom.pol.

;Rekordy zasobów
1.0.168.192.in-addr.arpa.

IN

PTR

holly.zoom.pol.

3.0.168.192.in-addr.arpa.

IN

PTR

antifa.zoom.pol.

6.0.168.192.in-addr.arpa.

IN

PTR

apacz.zoom.pol.

Odwzorowanie odwrotne p tli zwrotnej

0.0.127.in-addr.arpa.

1D

IN

SOA

localhost.

hostmaster.localhost. (

42
3H
15M
1W

1D )

0.0.127.in-addr.arpa.

IN NS

localhost.

1.0.0.127.in-addr.arpa.

IN PTR

localhost.

Powiniene umie ju skonfigurowa serwer DNS, pora by dowiedziałsi , w jaki sposób DNS radzi sobie z

trasowaniem poczty elektronicznej.

DNS i MAIL

- Rekord MX, trasowanie poczty -

Kiedy nie było usługi DNS i serwery pocztowe dysponowały tylko plikiem HOST.TXT (lub /etc/hosts) mogły tylko

dostarczy poczt pod znany adres IP. Je li si to nie udawało, przewa nie odwlekały wysłanie lub te odsyłały

wiadomo

do nadawcy. Mechanizm DNS pozwala na definiowanie zapasowych hostów odbieraj cych poczt , a

ponadto umo liwia dodanie do pliku strefy nazw domenowych, które s tylko miejscem przeznaczenia poczty i nie

reprezentuje adnego hosta. Do konfiguracji trasowania poczty wykorzystuje si rekord MX. Przykładowy rekord

zasobów dla domeny zoom.pol wygl da nast puj co.

zoom.pol

IN

MX

1

holly.zoom.pol.

Nale y go przeczyta nast puj co: host holly.zoom.pol jest wymiennikiem poczty dla domeny zoom.pol. Liczba 1 jest to

parametr rekordu MX nazywany warto ci preferencji i jest on liczb całkowit z przedziału 0-65535. Parametr ten

odgrywa olbrzymia rol przy trasowaniu poczty. Zauwa , e nazwa zoom.pol jest tylko miejscem przeznaczenia poczty,

nie reprezentuje ona adnego hosta (przypomnij sobie stref dla tej domeny). Przykład:

Nasze wymienniki poczty

zoltan.eu.org.

IN

MX

10

zoltan.eu.org.

zoltan.eu.org.

IN

MX

15

antifa.zoltan.eu.org.

zoltan.eu.org.

IN

MX

20

linux.slupsk.net.

Hostem, do którego ma trafia docelowo poczta jest zoltan.eu.org, poniewa ma najmniejsz warto

preferencji.

Pozostałe dwa hosty s zapasowymi wymiennikami poczty. Oto jak to działa. Kiedy serwer poczty wysyła maila do

domeny zoltan.eu.orgi, a host zoltan.eu.org nie działa wysyła poczt do jednego z wymienników o najmniejszej mo liwej

warto ci preferencji. W tym przypadku do antifa.zoltan.eu.org (gdyby i ten host nie działał, poczta trafiłaby do hosta

linux.slupsk.net). Aby zapobiec zap tlaniu si tego mechanizmu, tzn. aby przypadkiem host antifa nie słałpoczty do

hosta linux.slupsk.net, lub co jest jeszcze bardziej nonsensowne, do samego siebie odrzuca wszystkie rekordy MX o

warto ci preferencji mniejszej lub równej swojej. W ten sposób host antifa wie, e poczt mo e przekaza ju tylko do

hosta zoltan.eu.org, co uczyni, gdy tylko ten b dzie znowu dost pny. Oczywi cie serwer poczty na ho cie zoltan.eu.org

musi by skonfigurowany tak, eby wiedział, e poczta, któr otrzymuje jest przeznaczona dla niego, a serwery poczty

na hostach antifa.zoltan.eu.org oraz linux.slupsk.net musz by skonfigurowane jako przeka niki.

Uwaga: nazwa hosta, który jest wymiennikiem poczty powinna by jego nazw kanoniczn .

Tworzenie i delegacja poddomen

- Delegacje stref odwzorowywania normalnego i odwrotnego -

W rozdziale tym zajmiemy si delegowaniem poddomen. O ile je li chodzi o stref odwzorowywania normalnego sprawa

jest prosta, to przy delegacji strefy in-addr.arpa pojawia si kilka kłopotów, a je li tak, to i kilka sposobów ich

rozwi zania.

Delegacje poddomen

Jeste my posiadaczami domeny linux.pl. Powiedzmy, e jaka organizacja poprosiła nas o to, aby my oddelegowali jej

domen firma.linux.pl (oczywi cie za darmo nic nie ma :>). Firma ta podała nam adresy IP i/lub nazwy domenowe ich

serwerów DNS, do których mamy domen oddelegowa . Oto jakie rekordy nale y doda do strefy linux.pl, aby to zrobi :

firma.linux.pl.

IN

NS

dns.organizacja.pl.

firma.linux.pl.

IN

NS

dns2.organizacja.pl.

Je eli jednak organizacja chce, aby serwery DNS posiadały nazwy w poddomenie, jak im delegujemy, wówczas nale y

doda nast puj ce rekordy:

firma.linux.pl.

IN

NS

dns.firma.linux.pl.

firma.linux.pl.

IN

NS

dns2.firma.linux.pl.

dns.firma.linux.pl.

IN

A

212.160.112.227

;adresy IP serwerów

dns2.firma.linux.pl.

IN

A

213.25.234.82

;nazw organizacji

Dwa rekordy A nosz nazw rekordów spajaj cych (glue records). Dlaczego s konieczne? Otó odpowied jest

nast puj ca: serwer szukaj cy nazwy w domenie firma.linux.pl najpierw odpytałby nasz serwer o rekordy NS dla tej

strefy. Nasz serwer oczywi cie udzieliłby odpowiedzi podaj c dns.firma.linux.pl oraz dns2.firma.linux.pl. No tak, tylko e

nazwy te znajduj si w strefie, o któr zdalny serwer pytał, co oznacza, e nie ma mo liwo ci poznania ich adresów IP -

bł dne koło. Gdyby nie rekordy klej ce, tak wła nie by było, dzi ki nim nasz serwer DNS zna adresy IP serwerów, do

których oddelegowano poddomen i to wła nie je zwraca pytaj cemu.

Delegacje strefy in-addr.arpa

Je eli oddelegowujemy stref in-addr.arpa dziel c j na granicy oktetu, nie ma problemu, post pujemy identycznie jak

przy oddelegowywaniu strefy odwzorowywania normalnego. Przykładowo delegujemy z sieci klasy B podsie klasy C

(stref macierzyst niech dla przykładu b dzie 2.15.in-addr.arpa):

1.2.15.in-addr.arpa.

IN

NS

dns.linux.pl.

1.2.15.in-addr.arpa.

IN

NS

dns2.linux.pl.

Problem pojawiłby si gdyby my z tej przykładowo stworzonej poddomeny chcieli wydelegowa siec 15.2.1.0/25 czyli

siec rozci gaj c si od adresu 15.2.1.0 do 15.2.1.127. Jest kilka rozwi za tego problemu, lecz my omówimy tutaj to

zdefiniowane przez dokumentacje RFC (RFC2317). Polega ono na utworzeniu w pliku strefy 15.2.1 odpowiedniej liczby

rekordów CNAME (w tym przypadku 128) wskazuj cych na nazwy w nowych poddomenach, które s oddelegowywane

do odpowiednich serwerów nazw. Oto przykład:

0.1.2.15.in-addr.arpa.

IN

CNAME

0.0-127.1.2.15.in-addr.arpa.

1.1.2.15.in-addr.arpa.

IN

CNAME

1.0-127.1.2.15.in-addr.arpa.

.
.
.
127.1.2.15.in-addr.arpa.

IN

CNAME

127.0-127.1.2.15.in-addr.arpa.

;oddelegowujemy now

domen

0-127 do odpowiedzialnych za ni

serwerów

0-127.1.2.15.in-addr.arpa.

IN

NS

dns.sub.linux.pl.

0-127.1.2.15.in-addr.arpa.

IN

NS

dns2.sub.linux.pl.

Na szcz cie nie trzeba samemu wpisywa tych wszystkich aliasów. Ułatwia nam to instrukcja kontrolna $GENERATE.

Oto jej zastosowanie dla naszej delegacji:

$GENERATE

0-127 $.1.2.15.in-addr.arpa. IN CNAME

$.0-127.1.2.15.in-

addr.arpa.
0-127.1.2.15.in-addr.arpa.

IN

NS

dns.sub.linux.pl.

0-127.1.2.15.in-addr.arpa.

IN

NS

dns2.sub.linux.pl.

Trzy instrukcje zamiast stu trzydziestu! My l , e jest to oszcz dno

pracy. Działanie tej instrukcji jest tak oczywiste, e

nie ma sensu go opisywa . Ten, do którego delegujemy t stref powinien umie ci odpowiednie instrukcje zone w pliku

named.conf swoich serwerów DNS.

Jak to działa? Kiedy wysłane zostaje zapytanie o adres 15.2.1.12 trafia ono do naszego serwera, który rozpoznaje

rekord 12.1.2.15.in-addr.arpa jako alias dla nazwy 12.0-127.1.2.15.in-addr.arpa i odsyła pytaj cego do serwerów nazw

strefy 0-127.1.2.15.in-addr.arpa. Serwery nazw tej strefy udzielaj pytaj cemu ostatecznej odpowiedzi w postaci nazwy

domenowej przypisanej danemu adresowi (oczywi cie je li takowa istnieje).

Co jednak gdyby my naszej przykładowej klasy B nie chcieli podzieli wzdłu oktetu? Jak wtedy wygl dałaby delegacja?

Oto przykład: przyjmijmy, e nasza sie podzielimy wg maski 255.255.252.0 co daje nam 64 sieci po 1024 hosty ka da

(jedna siec jest wielko ci czterech sieci klasy C). Chcemy jedn z tych podsieci wydelegowa , powiedzmy, e b dzie to

podsie rozci gaj c si od adresu 15.2.4.0 do adresu 15.2.7.255. Aby to uczyni dodajemy nast puj ce rekordy do

strefy 2.15.in-addr.arpa:

4.2.15.in-addr.arpa.

IN

NS dns.linux.pl.

4.2.15.in-addr.arpa.

IN

NS dns2.linux.pl.

.
.
.
7.2.15.in-addr.arpa.

IN

NS dns.linux.pl.

7.2.15.in-addr.arpa.

IN

NS dns2.linux.pl.

Korzystaj c instrukcji $GENERATE

$GENERATE

4-7

$.2.15.in-addr.arpa.

IN

NS

dns.linux.pl.

$GENERATE

4-7

$.2.15.in-addr.arpa.

IN

NS

dns2.linux.pl.

Serwery, do których wydelegowali my t stref musz posiada po jednej instrukcji zone w pliku named.conf dla

ka dego rekordu NS (czyli w tym wypadku cztery).

Narz dzia- nslookup, dig, host, rndc -

W rozdziale tym zostan opisane czynno ci zwi zane z diagnozowaniem oraz testowaniem serwera nazw za pomoc

ró nych narz dzi, zostanie omówiony tak e program rndc, ułatwiaj cy i usprawniaj cy prace z demonem named.

nslookup

Nslookup jest bardzo rozpowszechnionym programem, lecz nie zajmiemy si nim zbyt wiele, poniewa posiada wiele

wad i zostałoficjalnie uznany za prze ytek w dystrybucji BIND 9. Program ten mo e przyjmowa argumenty w wierszu

polece lub pracowa w trybie interaktywnym. Wiersz polece u ywany jest przewa nie gdy mamy zamiar zada

jakiemu serwerowi pojedyncze zapytanie, tryb interaktywny najlepiej wykorzystywa kiedy b dziemy musieli zadawa

zapytania do kilku serwerów. Nslookup naraz pracuje z jednym serwerem DNS. Oto przykładowe zapytania w wierszu

polece .

nslookup ne.eu.org

wysyła zapytanie o adres IP hosta ns.eu.org

nslookup zoltan.eu.org ns.eu.org

wysyła zapytanie o adres IP hosta zoltan.eu.org do serwera nazw ns.eu.org

nslookup -query=mx linux.net

wysyła zapytanie o rekordy mx w strefie linux.net

nslookup -query=cname slupsk.net

wysyła zapytanie o rekordy mx w strefie linux.net

nslookup -query=mx linux.net

wysyła zapytanie o rekordy mx w strefie linux.net

nslookup 213.25.234.34

wysyła zapytanie odwrotne

Tryb interaktywny wł cza si wywołuj c nslookup bez parametrów, komendy wpisujemy po znaku zach ty '>'. Aby

zmieni odpytywany serwer u ywamy dyrektywy:

server [nazwa.domenowa.serwera lub jego IP]

Aby wybra typ rekordów u ywamy wyra enia

set q=typ_rekordu

Aby pozna nazw domenow hosta o danym IP po prostu w wierszu polece nslookup wpisujemy to IP. Tak samo

post pujemy, gdy chcemy pozna adres IP hosta, którego nazw domenow znamy. Przykładowa sesja nslookup:

> set q=mx
> server dns.tpsa.pl
> zoltan.eu.org
Server:

dns.tpsa.pl

Address:

194.204.159.1#53

zoltan.eu.org

mail exchanger = 1 zoltan.eu.org.

> set q=ns
> linux.pl
Server:

192.168.0.1

Address:

192.168.0.1#53

linux.pl

nameserver = dns4.linux.pl.

linux.pl

nameserver = dns1.linux.pl.

linux.pl

nameserver = dns2.linux.pl.

linux.pl

nameserver = dns3.linux.pl.

> server localhost
Default server: localhost
Address: 127.0.0.1#53
> set q=a
> dns.tpsa.pl

Server:

localhost

Address:

127.0.0.1#53

Non-authoritative answer:
Name:

dns.tpsa.pl

Address: 194.204.159.1
>exit

My l , e nie wymaga to komentarza.

dig

Program dig (Domain Information Groper) nie jest tak popularny jak opisany wy ej nslookup, nie posiada trybu

interaktywnego, wszystkie jego opcje podawane s w wierszu polece . Dig inteligentnie interpretuje argumenty, tzn.

mo na poda je w dowolnej kolejno ci - program b dzie wiedział, e 'a','mx'czy te 'ns'to typy rekordów a nie nazwy

domenowe. Serwer nazw, który chcemy odpyta nale y poprzedzi znakiem '@'.Mo na poda jego nazwe jako adres

IP lub jako nazw domenow . Domy lnie odpytywane s serwery nazw z pliku resolv.conf. Ciekaw cech tego

narz dzia jest to, e wyniki odpytywania s podane taki, jakby przegl dało si plik strefy dla domeny, a dodatkowe

komentarze sprawiaj , e cało

przyjmuje bardzo czyteln form . Na przykład, oto wynik odpytania o rekordy NS dla

domeny wp.pl:

; <![CDATA[ <<>&gt; DiG 9.2.1 &lt;&lt;&gt;&gt; ns wp.pl]]&gt;

;; global options:

printcmd

;; Got answer:
;;<![CDATA[ ->&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id:

40401]]&gt;

;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;wp.pl.

IN

NS

;; ANSWER SECTION:
wp.pl.

86400

IN

NS

ns1.wp.pl.

wp.pl.

86400

IN

NS

ns2.wp.pl.

wp.pl.

86400

IN

NS

dns.task.gda.pl.

;; ADDITIONAL SECTION:
dns.task.gda.pl.

86400

IN

A

153.19.250.100

ns1.wp.pl.

86400

IN

A

212.77.102.200

ns2.wp.pl.

86400

IN

A

153.19.102.182

;; Query time: 387 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug 23 03:02:20 2002
;; MSG SIZE

rcvd: 134

Pierwszy wiersz to wersja programu oraz powtórzenie zapytania. Skróty nast puj ce po słowie flags oznaczaj :

qr

wskazuje, e komunikat jest odpowiedzi

aa

wskazuje, e odpowied jest autorytatywna (w tym przypadku nie jest, bo udzieliłjej serwer, który nie jest

autorytatywny dla domeny wp.pl)

rd

wskazuje, e w zapytaniu ustawiony byłbit rekurencji

ra

wskazuje, e odpytany serwer obsługuje rekurencyjne zapytania; gdyby nie obsługiwałflaga ta nie zostałaby

ustawiona, a serwer potraktowałby zapytanie jako iteracyjne

Pozostałe dane w tym wierszu to liczba zapyta wysłanych, ilo

otrzymanych w odpowiedzi rekordów w sekcji

odpowiedzi (ANSWER), zwierzchno ci (AUTHORITY) oraz dodatkowej (ADDITIONAL). Jak wida w odpowiedzi,

otrzymali my trzy serwery nazw odpowiedzialne za domen wp.pl, a w sekcji dodatkowej odpowiadaj ce im rekordy A.

Ostatnie cztery linie informuj o tym, ile czasu trwało zapytanie, jaki serwer zostałodpytany i kiedy, oraz rozmiar (w

bajtach) zapytania i odpowiedzi.

Na koniec kilka przykładowych zapyta :

dig @zoltan.eu.org zoltan.eu.org axfr

przeprowadza transfer strefy zoltan.eu.org od serwera zoltan.eu.org

dig ns wp.pl

odpytuje jeden z serwerów w pliku resolv.conf o rekordy NS domeny wp.pl

dig -x 213.25.234.82 @dns.tpsa.pl

wykonuje zapytanie odwrotne do serwer dns.tpsa.pl

host

Program host posiada podobne mo liwo ci jak wspomniani wy ej jego poprzednicy. Jest to do

proste w u yciu

narz dzie, dlatego te nie b d si zbytnio na jego temat rozpisywał. Na szczególn uwag zasługuje w nim opcja

umo liwiaj ca sprawdzenie poprawno ci delegacji strefy. Oto przykład:

$ host -t ns zoltan.eu.org ns.eu.org

Using domain server:
Name: ns.eu.org
Address: 137.194.2.218#53
Aliases:

zoltan.eu.org name server ATECOM.SKI.SLUPSK.PL.
zoltan.eu.org name server PB82.SLUPSK.SDI.TPNET.PL.

$ host -t ns zoltan.eu.org atecom.ski.slupsk.pl

Using domain server:
Name: ATECOM.SKI.SLUPSK.PL.
Address: 212.160.112.222#53
Aliases:

zoltan.eu.org name server pb82.slupsk.sdi.tpnet.pl.
zoltan.eu.org name server atecom.ski.slupsk.pl.

$ host -C zoltan.eu.org.

Nameserver atecom.ski.slupsk.pl:
zoltan.eu.org SOA pb82.slupsk.sdi.tpnet.pl. out.holly.linux.slupsk.net.
2002081801 10800 900 604800 86400
Nameserver pb82.slupsk.sdi.tpnet.pl:
zoltan.eu.org SOA pb82.slupsk.sdi.tpnet.pl. out.holly.linux.slupsk.net.
2002081801 10800 900 604800 86400

Najpierw od autorytatywnego serwera nazw strefy zwierzchniej pobrali my rekordy NS dla interesuj cej nas strefy.

Prosz zauwa y , e program host pokazałjakiego serwera u yłdo wykonania zapytania. Nast pnie od dowolnego z

serwerów tej strefy pobieramy rekordy NS, któr on przechowuje. Je eli rekordy s takie same, to połowa sukcesu,

oznacza to, e dane w strefie nadrz dnej i podrz dnej s spójne. Je li liczba rekordów uzyskana od jednego serwera

jest ró na od tych uzyskanych od drugiego lub gdy rekordy s ró ne, to wła nie zobaczyli my powód np. takiego

komunikatu w logach:

named[11312]:
lame server resolving 'pepe.nsb.pl' (in 'nsb.pl'?): 158.75.61.4#53

Kolejnym krokiem jest wywołanie programu host z parametrem 'C'.Sprawdzi on ka dy serwer wymieniony przy

rekordzie NS pod k tem zwierzchno ci nad badan stref . Je eli serwer jest autorytatywny to program host zwróci

odpowiedni rekord SOA. Liczba zwróconych rekordów SOA musi by taka sama jak liczba rekordów NS danej strefy.

Po wi cej informacji na temat programu host odsyłam do pomocy lub podr cznika systemowego.

rndc

Aby umo liwi korzystanie z narz dzia rndc konieczne jest dodanie do pliku named.conf nast puj cych linii.

controls {

inet * allow {any;} keys { "rndc-key"; };

};

key "rndc-key" {

algorithm hmac-md5;
secret "xV20v+w5rYs="

};

Obja nienie opcji:

inet

serwer nasłuchuje na komunikaty kontrolne domy lnie na porcie 953

secret

przechowuje zakodowane hasło. Aby wygenerowa to hasło nale y u y polecenia dnssec-keygen np.:

dnssec-keygen -a hmac-md5 -b 64 -n host jakies_haslo

Wynikiem tego polecenia b d dwa pliki, w ka dym z nich b dzie znajdowało si zakodowane hasło. Po wi cej

informacji o tym programie odsyłam do podr cznika systemowego.

allow

jest to lista hostów, od których serwer mo e przyjmowa komunikaty kontrolne

algorithm

algorytm kodowania hasła, hmac-md5 jest jedyny obecnie obsługiwanym algorytmem

keys

lista kluczy rozpoznawana przez serwer nazw, ka dy z kluczy wymieniony na tej li cie musi zosta

zdefiniowany jak przykładowy klucz rndc-key za pomoc dyrektywy key.

oraz stworzenie pliku /etc/rndc.conf o zawarto ci:

options {

default-server localhost;
default-key "rndc-key";

};

key "rndc-key" {

algorithm hmac-md5;
secret "xV20v+w5rYs=";

};

Wyja nienie opcji:

default-server

do jakiego serwera domy lnie wysła komunikaty kontrolne w przypadku nie zdefiniowania serwera w wierszu

polece

default-key

jakiej nazwy klucza u y domy lnie je eli nie została zdefiniowana w wierszu polece

algorithm

patrz opis dla pliku named.conf

secret

przechowuje zakodowane hasło, wpis musi by identyczny jak ten w pliku named.conf serwera, do którego

wysyłamy komunikaty kontrolne

Je eli zarz dzamy wi ksz ilo ci serwerów, mo emy w pliku rndc.conf u y takiej instrukcji dla ka dego serwera.

server zoltan.eu.org {

key "zoltan-key";

};

Oczywi cie, musimy zdefiniowa ten klucz w pliku rndc.conf hosta, z którego b dziemy wysyła komunikaty, a tak e w

pliku named.conf serwera do którego te komunikaty b dziemy wysyła (i doda go do listy kluczy obsługiwanych przez

serwer).

Uwaga: Nale y zadba , aby pliki named.conf oraz rndc.conf były dost pne tylko i wył cznie dla obsługi serwera nazw.

Wa niejsze funkcje programu rndc:

reload

ponownie wczytuje pliki stref oraz plik named.conf

reconfig

przeładowuje plik named.conf oraz tylko nowe strefy

dumpdb

zrzuca do katalogu domowego serwera zawarto

cache

flush

czy ci cache (pami

podr czn )

Przykładowe wywołania:

rndc reload

wykona reload dla domy lnego serwera u ywaj c domy lnego klucza

rndc -s zoltan.eu.org reload

wykona reload serwera zoltan.eu.org u ywaj c klucza z dyrektywy server, je eli taka istnieje dla tego serwera,

je eli nie - u yje klucza domy lnego

rndc -s ns.eu.org -y eu-key reload

wykona reload serwera ns.eu.org u ywaj c klucza o nazwie eu-key

Rejestracja zdarze

- Opis sposobów rejestracji zdarze w pakiecie BIND -

BIND posiada bardzo rozbudowany mechanizm rejestracji zdarze , który mo na skonfigurowa na wiele sposobów

dostosowuj c go tym samym nawet do najbardziej wymy lnych potrzeb administratora. Jednak odpowiednia

konfiguracja rejestrowania wymaga od administratora przede wszystkim eksperymentów. Ogranicz si w tym artykule

do podania pewnych przykładów, które sam sprawdziłem i informacji jakie rejestrowałem, gdy uznałem je za istotne.

Oczywi cie, potrzeby s ró ne w zale no ci od osoby, dlatego rozdziałten prosz traktowa jako mał prezentacj

mo liwo ci jakie oferuje pakiet BIND w tej dziedzinie.

Istnieje wiele kategorii komunikatów, oto niektóre z nich (* oznacza, e kategoria ta istnieje tylko w BIND 9, ** w BIND 8):

default

je li nie okre lisz kanałów dla innych kategorii, to serwer wysyła wszystkie komunikaty ich dotycz ce do kanału

przypisanego kategorii default, (BIND 8 i 9). Dla BIND 8 trafiaj tu jeszcze wszystkie inne komunikaty, które nie

zostały sklasyfikowane (tzn. nie posiadaj własnej kategorii)

general*

Jest to specjalnie wydzielona kategoria obejmuj ca wszystkie niesklasyfikowane komunikaty serwera (tzn. te,

które nie maja własnej kategorii)

eventlib**

informacje o zdarzeniach systemowych

panic**

informacje o problemach powoduj cych zamkniecie serwera

packet**

informacje o dekodowaniu odebranych i wysłanych pakietów

lame-servers

informacje o bł dnych delegacjach

update

informacje o dynamicznych uaktualnieniach

statistics**

raport o działaniu serwera

security

informacje dotycz ce zezwole lub ich braku na dane operacje

queries

informacje o otrzymywanych przez serwer zapytaniach

xfer-in

informacje o transferach stref do lokalnego serwera

xfer-out

informacje o transferach stref z lokalnego serwera

Pozostałe nie opisane kategorie to: cname**, client*, config, database*, db**, dnssec*, insist**, load**, maintenance**,

ncache**, network*, notify, os**, parser**, resolver*, response-checks**.

Ka dy komunikat posiada typ wa no ci, jest ich (typów) w sumie siedem, Oto one od najwa niejszego poczynaj c, a na

najmniej wa nym ko cz c: critical, error, warning, notice, info, debug [level], dynamic.

Je eli pominiemy parametr level przy typie debug, zostanie domy lnie u yta warto

1. Aby wł czy tryb diagnostyczny

nale y u y narz dzia rndc (rndc trace). Typ wa no ci debug ustala na sztywno szczegółowo

komunikatów

diagnostycznych, tzn. je eli ustawili my go np. na 2, to, niezale nie ile razy wy lemy do serwera polecenie ledzenia,

szczegółowo

zawsze pozostanie 2. Inaczej jest je li wybierzemy typ dynamic - wtedy szczegółowo

b dzie zale ała

od tego, ile wy lemy polece

ledzenia. Tryb diagnostyczny wył cza si poleceniem rndc notrace.

Ka da kategoria musi trafi do jakiego kanału. Kanałokre la gdzie konkretnie maja trafi komunikaty danej kategorii i

wa no ci. Mo e to by plik, demon syslog, czy te kanałnull (mam nadziej , e nie musz wyja nia losu informacji

trafiaj cych do tego kanału). BIND domy lnie definiuje cztery rodzaje kanałów, których nie mo na usun

lub zmieni , a

s to: default_syslog, default_debug, default_stderr, null. Pierwszy z nich wysyła informacje do demona syslog,

drugi zapisuje je w pliku named.run, trzeci wysyła na standardowe wyj cie bł dów nameda, czwarty nie wymaga

komentarza.

Tak samo jak kanały, domy lnie zdefiniowane s kategorie wiadomo ci, które maj do nich trafi i tak w BIND 9:

category default { default_syslog; default_debug; };

BIND 8

category default { default_syslog; default debug; };
category panic { default_syslog; default_stderr; };

category packet { default_debug; };
category eventlib { default_debug; };

Wiemy ju jak definiowa inne kategorie i ustala dla nich kanały na podstawie przytoczonych domy lnych ustawie

BINDa, pora, aby nauczy si definiowa wła nie kanały. Wa na uwaga mo emy przedefiniowa , to do jakich kanałów

trafiaj domy lne kategorie, zostanie to pokazane w przykładzie ni ej.

channel zapytania {

file "query.log" versions 3 size 20k;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;

};

channel zap_syslog {

syslog deamon;
severity info;

};

Zdefiniowali my dwa nowe kanały. Pierwszy z nich to plik o nazwie query.log, który maksymalnie mo e osi gn

rozmiar 20 kB (po osi gni ciu tego rozmiaru BIND zaprzestanie uzupełnia plik). Ustalili my, e maksymalnie mog

istnie trzy dodatkowe kopie tego pliku powstaj ce przy restartowaniu serwera. Dodatkowo okre lili my, e do ka dego

zapisaneego komunikatu ma zosta dodany tzw. timestamp oraz informacja jakiej kategorii jest to komunikat oraz

poziom jego wa no ci. Oczywi cie, w pliku query.log nie zobaczymy niczego, dopóki nie wł czymy trybu

diagnostycznego, co zostało opisane wy ej przy omawianiu tego trybu. Drugi kanałb dzie wysyłałwszystkie

komunikaty do demona syslog (poziom wa no ci w tym wypadku mo e by maksymalnie info z tego prostego powodu,

e nie mo na wysyła komunikatów diagnostycznych serwera DNS do demona syslog).

Wszystkie zdefiniowane kanały oraz to, do jakich kanałów maj trafia informacje z danych kategorii umieszczamy

wewn trz pliku named.conf w dyrektywie logging.

logging {

channel zapytania {

file "query.log" versions 3 size 20k;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;

};

channel zap_syslog {

syslog deamon;
severity info;

};

channel transfer {

file "xfer.log" versions 2 size 10k;
severity info;
print-time yes;
print-category yes;

};

category default { default_syslog; };
category queries { zapytania; zap_syslog; };
category xfer-in { transfer; };
category xfer-out { transfer; };
category lame-servers { null; };
};

Oto co wynika z powy szej konfiguracji. Poniewa denerwowały mnie wszystkie informacje na temat bł dnych delegacji

w innych strefach, postanowiłem je wyrzuci . Interesowało mnie kto stara si pobra moje strefy, wiec postanowiłem

zarejestrowa wszystkie transfery stref do osobnego pliku, chciałem zna szczegóły dotycz ce zapyta , jakie obsługuje

mój serwer wi c, nakazałem rejestrowanie ich w pliku query.log (oczywi cie je li wł cz debugowanie), informacje na

poziomie info dotycz ce zapyta wysyłane s do demona syslog (mogłem oczywi cie u y kanału default_syslog, ale

chciałem pokaza jak zbudowa kanałwysyłaj cy informacje do tego demona). Nie chc c, aby wszystkie pozostałe

komunikaty BIND zapisywałw pliku named.run przedefiniowałem kategori default, aby wysyłała je tylko do syslog.

Zagadnienia ró ne

- SOA - uwagi, bezpiecze stwo, skróty, dystrybucja obci enia, RevDNS i TP SA. -

Uwagi do pola MINIMUM w rekordzie SOA

RFC2308 definiuje nowe u ycie tego pola, a mianowicie, jako domy lnego ttl-a dla buforowania odpowiedzi

negatywnych, dotychczas pole to było u ywane do ustawiania domy lnego czasu ttl dla rekordów, które nie miały go

zdefiniowanego. Nowe RFC zaleca definiowanie tego czasu za pomoc nast puj cego wyra enia na pocz tku pliku

strefy.

$TTL warto _liczbowa

Dla ciekawostki dodam, e pole to było przedefiniowywane ju kilkakrotnie, a pierwotnie jego warto

oznaczała

minimalny czas, przez jaki maj by buforowane rekordy zasobów danej strefy.

Bezpiecze stwo

Zagadnienie bezpiecze stwa DNS jest bardzo szerokie, rozpoczynaj c od odpowiedniej konfiguracji samego serwera

nazw, poprzez TSIG (zabezpieczenia kluczem transakcji tj. transferów stref itp.), DNSSEC (DNS Security Extensions -

wykorzystanie kryptografii z kluczem publicznym do podpisywania danych w strefach), a ko cz c na zaawansowanych

konfiguracjach sieci z hostami bastionowymi, wewn trznymi serwerami nazw.

Istnieje wiele opcji konfiguracyjnych serwera DNS, które znacznie ograniczaj dost p osobom niepowołanym

przechowywanych przez niego danych. Wszystkie poni sze dyrektywy dodawane s do pliku named.conf. Oto one:

version "string";

umieszczana wewn trz dyrektywy options, ustawia odpowied na zapytanie version.bind utrudniaj c

identyfikacj naszego serwera nazw zło liwej osobie, która np. wła nie przeszukuje www.securityfocus.com w

poszukiwaniu odpowiedniego exploita

allow-query { lista_adresów; };

opcja, dzi ki której zyskujemy kontrol nad tym kto mo e odpytywa nasz serwer nazw, lista_adresów to

adresy hostów lub sieci, którym na to pozwalamy np.: { 192.168.0/24; 127.0.0.1; }. Opcje te mo emy umie ci

wewn trz dyrektywy options (jest wtedy traktowana jako globalna) lub wewn trz dyrektywy zone strefy, dla

której chcemy wprowadzi ograniczenia.

allow-transfer { lista_adresów; };

opcja ta ogranicza liczb hostów, które mog przeprowadzi transfer strefy. Podobnie jak w poprzednim

przypadku lista_adresów to adresy hostów, którym zezwolimy na ewentualne transfery; dla serwerów, które s

podstawowymi powinna zawiera adresy serwerów podrz dnych, a serwery podrz dne nie powinny zezwala

nikomu na transfer strefy. Opcja ta mo e by u yta wewn trz dyrektywy options lub wewn trz dyrektywy zone

dla danej strefy.

recursion no;

opcja ta zakazuje naszemu serwerowi nazw przetwarzania zapyta rekurencyjnych

allow-recursion { lista_adresów; };

opcja ta informuje nasz serwer, aby przetwarzałzapytania rekurencyjne tylko i wył cznie od hostów, które s

na li cie adresów

Notacja skrótowa

Tworzenie plików stref mo e wydawa si czynno ci do

m cz ca, szczególnie je eli nasza strefa odwzorowania

normalnego czy te odwrotnego posiada wiele rekordów zasobów. Na szcz cie istnieje kilka skrótów, które bardzo

usprawniaj i przede wszystkim przyspieszaj tworzenie pliku strefy.

Pierwszy parametr instrukcji zone to nazwa domenowa strefy zwana ródłem (origin); nazwa ta jest automatycznie

dodawana do ka dej wyst puj cej w pliku strefy nazwy domenowej nie zako czonej kropk . Do zmiany ródła wewn trz

pliku strefy stosuje si instrukcje $ORIGIN nowe_zrodlo.

Je eli nazwa domenowa jest taka sama jak ródło, mo na j zapisa u ywaj c znaku '@'(at). Taki zapis

wykorzystywany jest przewa nie w rekordach SOA.

Je eli w polu nazwa_domenowa rekordu zasobów znajduje si znak spacji lub tabulacji, to serwer u yje nazwy z

ostatniego rekordu zasobu, który posiadałnazw inn ni spacja lub znak tabulacji. Ten zapis wykorzystywany jest gdy

konfigurujemy wiele typów rekordów dla jednego hosta.

Oto jak wygl daj przykładowe pliki stref po zastosowaniu skrótów:

strefa odwzorowania normalnego, ródło - zoom.pol.

$ttl 3h

;do wszystkich nazw nie zako czonych kropk

zostaje dodane

ródło

; ródło jest takie samo jak nazwa domenowa wiec stosuje si

znak '@'

@

IN

SOA

holly out.holly (

2002081001
3H
15M
1W
1D )

IN

NS

holly

;nazwa jest spacj

lub tabulatorem. Poprzedni rekord

;zawieraj cy nazw

inn

ni

spacja czy tabulator to SOA

;wi c domy lnie wiadomo,

e rekord ten dotyczy nazwy

ródłowej

;Rekordy zasobów strefy zoom.pol
holly

IN

A

192.168.0.1

IN

MX

1

holly

;nazw

jest spacja lub tabulatorem wiec

;rekord dotyczy hosta holly

antifa

IN

A

192.168.0.3

apacz

IN

A

192.168.0.6

;Definicje aliasów
mail

IN

CNAME

holly

dns

IN

CNAME

holly

strefa odwzorowania odwrotnego, ródło - 0.168.192.in-addr.arpa.

$ttl 3h

@

IN

SOA

holly.zoom.pol.

out.holly.zoom.pol. (

02030202
3h
1h
1w
1h )

IN

NS

holly.zoom.pol.

1

IN

PTR

holly.zoom.pol.

3

IN

PTR

antifa.zoom.pol.

;jak wspomniano wy ej,

ródło mo na zmieni

w

;dowolnym miejscu pliku strefy

$ORIGIN zoom.pol.
6.0.168.192.in-addr.arpa.

IN

PTR

apacz

Dystrybucja obci enia

Mechanizm rotowania rekordów jest szczególnie przydatny, gdy posiadamy kilka hostów pełni cych te same funkcje (np.

mirrorowane serwery ftp) i chcemy w miar równomiernie rozło y ruch pomi dzy nimi. Dokonuje si tego umieszczaj c

w pliku strefy nast puj ce rekordy:

ftp.linux.pl.

60

IN

A

213.25.234.82 ;serwer ftp

ftp.linux.pl.

60

IN

A

212.160.112.227 ;przykładowy mirror pierwszy

ftp.linux.pl.

60

IN

A

213.25.234.170 ;przykładowy mirror drugi

Jak to działa?

Bardzo prosto: kiedy serwer otrzymuje zapytanie o nazw ftp.linux.pl zwraca adresy w kolejno ci:

213.25.234.82, 212.160.112.227, 213.25.234.170

otrzymuj c kolejne zmienia ich kolejno

w nast puj cy sposób:

212.160.112.227, 213.25.234.170, 213.25.234.82

na trzecie zapytanie odpowie:

213.25.234.170, 213.25.234.82, 212.160.112.227

a na czwarte:

213.25.234.82, 212.160.112.227, 213.25.234.170

I tak w kółko. Mechanizm ten jest domy lnie wł czony, jednak, aby zapewni mu prawidłowe funkcjonowanie, nale y dla

rotowanych rekordów ustawi mały ttl, przykładowo na 60 sekund, jak uczyniono to powy ej.

Gdy jednak posiadamy główny serwer ftp oraz np. jeden zapasowy i chcieliby my, aby zapasowy u ywany byłtylko

wtedy, gdy główny nie działa, rotowanie rekordów tylko przeszkadza Aby je zmieni nale y posłu y si podinstrukcj

dyrektywy options - rrset-order. Jej posta :

rrset-order {

class IN type ANY name "*.zoltan.eu.org" order fixed;

//specyfikacja kolejno ci
};

Słowo kluczowe order okre la kolejno

w jakiej b d zwracane rekordy. Dost pne s nast puj ce opcje:

fixed

rekordy b d zawsze zwracane w tej samej kolejno ci

cyclic

rekordy b d rotowane

random

rekordy b d zwracane losowo

Parametr name okre la domen , jakiej dotyczy ta reguła (domy lnie wszystkie czyli "*"). Parametry class oraz type, jak

nie trudno si domy li , oznaczaj odpowiednio klas rekordów oraz ich typ (domy lnie jest to klasa IN oraz wszystkie

typy rekordów). Parametry domy lne, je li nam odpowiadaj , mo emy pomin , wiec specyfikacja kolejno ci dla

wszystkich rekordów byłaby taka: order fixed;). Dozwolona jest tylko jedna instrukcja rrset-order, ale mo e ona zawiera

wiele zapisów okre laj cych kolejno . Wykorzystywany jest pierwszy pasuj cy do danej grupy rekordów.

Chciałbym zaznaczy , e rozwi zanie tego problemu wykorzystuj ce instrukcje rrset-order jest zakłócane przez

buforowanie nazw przez serwery, jednak lepszy rydz ni nic. (Istnieje nowy typ rekordu SRV, który jest doskonałym

rozwi zaniem tego problemu, lecz nie jest on zbytnio rozpowszechniony, a na dodatek delikatnie mówi c, istnieje

bardzo mało aplikacji klienckich obsługuj cych ten typ rekordu.

RevDNS i TP SA

TP SA nie wykorzystuje sposobu delegacji strefy odwrotnej opisanego przeze mnie, a niestety zyskaliby my wtedy

czytelno

i porz dek danych. Nie b d na łamach tego artykułu tłumaczyłjak zarejestrowa własn stref w TP SA,

odsyłam do strony http://www.tpnet.pl/rev.phphttp://www.tpnet.pl/rev.php gdzie proces post powania rejestracyjnego

zostałdokładnie wytłumaczony krok po kroku.

Od Autora

- Uwagi, wyja nienia -

W opisie tym całkowicie pomin łem zagadnienie IPv6 w DNS, poniewa jest to obszerny temat, a artykułi tak rozrósłsi

do do

du ych rozmiarów. Przypuszczam, e temu tematowi po wi c osobny artykuł(który w najbli szym czasie

powinien zosta opublikowany na stronie).

W cz ci "Bezpiecze stwo" nie omówiłem mechanizmów TSIG oraz DNSSEC. Je eli chodzi o ten pierwszy, s dz , e

powinienem w niedługim czasie uzupełni artykuł. Opis DNSSEC nie pojawi si w ogóle. Powodem jest brak czasu,

obszerno

tematu, a co najwa niejsze, prace nad mechanizmem DNSSEC ci gle trwaj i pewne aspekty jego działania

mog si jeszcze zmieni . Obecna specyfikacja znajduje si w RFC2535.

Uwagi, sugestie i zapytania do autora...

...prosze kierowa na adres [e-mail]

Szczególnie prosz wytyka mi te fragmenty, które wydaj si by niezrozumiale.

Oryginałartykułu mo na przeczyta na stronie Słupskiej Grupy U ytkowników Linuksa (SLUG), pod adresem

http://www.linux.slupsk.pl

…::Artykuł ci gni ty ze strony http://www.linux.pl ::…