Strona 1
DNS - działanie i konfiguracja usługi
2007-02-01 18:43:55
http://newbie.linux.pl/wydruk.php?wydruk=35&show=artykul
DNS - działanie i konfiguracja usługi
Autor: Krzysztof Sahal
DNS - działanie i konfiguracja usługi
Autor: Krzysztof Sahal sahal@linux.pl
Kopiowanie i rozpowszechnianie w cało
ś
ci lub w cz
ęś
ciach tylko za zgod
ą
autora.
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.
Strona 2
DNS - działanie i konfiguracja usługi
2007-02-01 18:43:55
http://newbie.linux.pl/wydruk.php?wydruk=35&show=artykul
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:
Strona 3
DNS - działanie i konfiguracja usługi
2007-02-01 18:43:55
http://newbie.linux.pl/wydruk.php?wydruk=35&show=artykul
# 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
Strona 4
DNS - działanie i konfiguracja usługi
2007-02-01 18:43:55
http://newbie.linux.pl/wydruk.php?wydruk=35&show=artykul
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
Strona 5
DNS - działanie i konfiguracja usługi
2007-02-01 18:43:55
http://newbie.linux.pl/wydruk.php?wydruk=35&show=artykul
;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
Strona 6
DNS - działanie i konfiguracja usługi
2007-02-01 18:43:55
http://newbie.linux.pl/wydruk.php?wydruk=35&show=artykul
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.
.
.
.
Strona 7
DNS - działanie i konfiguracja usługi
2007-02-01 18:43:55
http://newbie.linux.pl/wydruk.php?wydruk=35&show=artykul
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[ <<>> DiG 9.2.1 <<>> ns wp.pl]]
;; global options: printcmd
;; Got answer:
;;[CDATA[ ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40401]]
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
Strona 8
DNS - działanie i konfiguracja usługi
2007-02-01 18:43:55
http://newbie.linux.pl/wydruk.php?wydruk=35&show=artykul
;; 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
Strona 9
DNS - działanie i konfiguracja usługi
2007-02-01 18:43:55
http://newbie.linux.pl/wydruk.php?wydruk=35&show=artykul
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
Strona 10
DNS - działanie i konfiguracja usługi
2007-02-01 18:43:55
http://newbie.linux.pl/wydruk.php?wydruk=35&show=artykul
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;
Strona 11
DNS - działanie i konfiguracja usługi
2007-02-01 18:43:55
http://newbie.linux.pl/wydruk.php?wydruk=35&show=artykul
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.
Strona 12
DNS - działanie i konfiguracja usługi
2007-02-01 18:43:55
http://newbie.linux.pl/wydruk.php?wydruk=35&show=artykul
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
Strona 13
DNS - działanie i konfiguracja usługi
2007-02-01 18:43:55
http://newbie.linux.pl/wydruk.php?wydruk=35&show=artykul
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 sahal@linux.pl
Szczególnie prosz
ę
wytyka
ć
mi te fragmenty, które wydaj
ą
si
ę
by
ć
niezrozumiale.
Artykuł pochodzi ze strony: Newbie - http://newbie.linux.pl
Wyszukiwarka
Podobne podstrony:
DNS konfiguracja serwera
Konfiguracja DNS w OS Linux
Konfiguracja DNS 1
DNS konfiguracja serwera
Konfiguracja DNS w OS Linux
Konfiguracja serwera DNS w systemie operacyjnym linux
Instalacja i konfiguracja serwera DNS
Chemia wyklad I i II (konfiguracja wiÄ…zania Pauling hybrydyzacja wiazania pi i sigma)
TFTP i DNS(2)
07 Konfiguracja
DNS
Cwiczenie 12 Konfigurowanie i testowanie VPN (PPTP)
Konfiguracja pamięci mikrokontrolera 8051 dla programów napisanych w języku C
1.1.6 Opis i konfiguracja zestawu protokołów TCPIP, 1.1 Nawiązywanie połączenia z Internetem
SK-cw3 2h Konfigurowanie sieci WLAN, Sieci Komputerowe
KONFIGURACJA KROTNICY SDH SPRAWOZDANIE
więcej podobnych podstron