Administrowanie DNS Strona 1 z 17
Materiały pomocnicze do laboratorium z przedmiotu:
Sieci Komputerowe (SKP1)
Temat: Konfiguracja DNS w sieci TCP/IP
Opracował: dr inż. Janusz Marzec, ZEJiM IRE PW
Warszawa, grudzień 1996.
Name Service jest serwisem informacyjnym o podstawowym znaczeniu dla sieci
Internet. Dzięki niemu istnieje możliwość posługiwania się łatwymi do zapamiętania
nazwami komputerów w miejsce ich numerów IP. Udzielanie odpowiedzi na pytanie:
jaki jest numer IP komputera, którego nazwa jest znana, stanowi podstawowe zadanie
tego serwisu. Istnieje także możliwość uzyskania odpowiedzi na pytanie: jak nazywa
się komputer o znanym numerze IP - tę funkcję spełnia odwrotny Name Service, tzw.
IN-ADDR.ARPA. Name Service udziela też odpowiedzi na pytania dotyczące
sposobu przekazywania poczty elektronicznej i propaguje inne informacje o
komputerach (sprzęt, system operacyjny, protokoły używane przez komputer do
realizacji różnych serwisów).
Materiał ten został opracowany z wykorzystaniem przykładów plików konfiguracyjnych
zaczerpniętych z dokumentacji systemu Solaris f-my SUN.
Struktura DNS
Konfigurowanie klienta DNS
Konfigurowanie serwera DNS
Tworzenie plików danych DNS
Standard Resource Record Format
Składnia RR
Control Entries
Typy rekordów RR
SOA - Start of Authority
NS - Name Server
A - Address
HINFO - Host Information
WKS - Well Known Services
CNAME - Canonical Name
PTR - Domain Name Pointer
MX - Mail Exchanger
file://D:\podreczniki\DNS.HTM 01-01-25
Administrowanie DNS Strona 2 z 17
Modyfikowanie Plików Danych DNS
Struktura DNS
Domain Name Service (DNS) jest protokołem warstwy aplikacji (7 layer OSI model) i
wchodzi w skład standardowego zestawu protokołów TCP/IP. Należy do grupy serwisów
nazw (naming service); pozyskuje i propaguje informacje o komputerach (hosts) w sieci.
Domain Name Service działa zarówno w obrębie lokalnej domeny administracyjnej jak i
poprzez granice domen. Jest realizowany przez zestaw serwerów, nazywanych Name
Servers, z których każdy realizuje ten serwis dzięki działaniu programu typu daemon pod
nazwą Program jest także nazywany Berkeley Internet Name Domain
service, w skrócie BIND, ponieważ powstał w University of California w Berkeley.
Po stronie komputerów korzystających z tego serwisu (client), DNS jest implementowany
w postaci tzw. resolvera. Resolver nie jest żadnym wyodrębnionym programem, jest to
raczej biblioteka wkompilowana w aplikację żądającą znajomości nazw komputerów ( plik
na komputerach UNIX, plik dla działającego pod DOS
popularnego programu NCSA, plik w MS-WINDOWS 3.11 itp.).
Zadaniem resolvera jest wskazywanie Name Servera który może udzielić odpowiedzi na
pytanie dotyczace nazw komputerów lub wskazać inny server posiadający żądaną
informację.
DNS Clients
Name Server, na którym działa program może także używać resolvera, tak więc
mogą istnieć dwa rodzaje kilentów DNS:
client-only
client/server
Na komputerze typu client-only nie działa . Komputer ten korzysta z resolvera,
który dostarcza listę Name Servers, do których można kierować zapytania dotyczące nazw.
Komputer typu client/server DNS może kierować zapytania dotyczące adresów sam do
siebie.
DNS Servers
Domain Name Service może być aplikowany do strefy (zone), która pokrywa się z domeną
adresową lub przekracza jej granice. Oznacza to, że Name Server może obsługiwać
zarówno domenę, w której się znajduje, jak i komputery czy domeny poza granicami swojej
domeny. Strefa powinna zawierać co najmniej dwa Master Servers.
Master Servers
"Master" serwery posiadają wszystkie dane dotyczące strefy, są %3ńródłem tych
danych dla innych serwerów; w tym sensie są autorytatywne. Często Master Servers
są nazywane Autoritative Name Servers. Zaleca się, aby dane odnoszące się do danej
strefy były osiągalne na co najmniej dwóch autorytatywnych serwerach. Jeden z nich
file://D:\podreczniki\DNS.HTM 01-01-25
Administrowanie DNS Strona 3 z 17
powinien mieć status Primary Master Server i co najmniej jeden - status Secondary
Master Server czyli serwera, dysponującego kopią danych Primary MS, mogącego
udostępniać te dane w przypadku przeciążenia lub awarii Primary MS.
Administrator DNS konfiguruje Name Service i dokonuje w nim zmian, edytując
odpowiednie pliki konfiguracyjne Primary MS. Serwer ten "załadowuje" dane z
dysku w momencie uruchomienia programu i od tego momentu staje się
najbardziej autorytatywnym %3ńródłem danych o strefie. Primary MS określa także,
które Secondary MS mają charakter autorytatywny.
Administrator nowo ustanawianej domeny adresowej musi przekazać informacje o
tym jaki komputer jest Primary Name Serverem w jego domenie administratorowi
domeny wyższego rzędu (poziomu). Nie należy w tym przypadu mylić dwóch
serwisów: ARPA i IN-ADDR.ARPA. W przypadku ARPA liczba poziomów domen
nie jest limitowana - jest ich tyle z ilu członów rozdzielonych kropkami składa się
nazwa komputera. Na przykład domena (zdegenerowana do jednego adresu)
csd.ia.pw.edu.pl jest zawarta w domenie ia.pw.edu.pl, ta z kolei w pw.edu.pl itd. W
przypadku IN-ADDR.ARPA liczba poziomów domen jest stała - domena
1.31.81.148.in-addr.arpa jest zawarta w 31.81.148.in-addr.arpa, ta z kolei w
81.148.in-addr.arpa itd.
Secondary MS jest serwerem posiadającym kopię danych o strefie. Danych tych
dostarcza mu Primary MS, on też autoryzuje Secondary MS w sensie
autorytatywności danych. W trakcie "bootowania" przez Secondary MS
następuje pobranie danych z Primary MS. Pó%3ńniej następuje okresowe sprawdzanie,
czy nie zaszła potrzeba dokonania aktualizacji danych.
Jeden serwer może funkcjonować jako Master dla wielu stref - dla jednych jako
Primary dla innych jako Secondary.
Caching and Caching-Only Servers
Wszystkie Name Servers przechowują odebrane informacje tak długo, aż nie upłynie
zadeklarowany czas ważności danych. W tym sensie są to, tzw. Caching Servers.
Proces utraty ważności danych jest kontrolowany przez pole (time-to-live)
dołaczone do danych otrzymywanych z innych serwerów.
Można uruchamić Name Server typu Caching-Only Server. Server taki nie jest
autorytatywny w żadnej strefie. Dysponuje jedynie danymi zgromadzonymi w trakcie
wysyłania zapytań do innych serwerów. Sensowne jest ustanawianie serwerów typu
Caching-Only na komputerach generujących wiele zapytań NS, np. silnie obciążone
komputery na których pracuje wielu użytkowników.
Konfigurowanie klienta DNS na komputerach UNIX
Aby umożliwić komputerowi korzystanie z Name Service'u, trzeba uruchomić tzw.
resolver. Wymaga to utworzenia pliku .
Tworzenie pliku
Resolver używa pliku jako %3ńródła danych o adresach Name
file://D:\podreczniki\DNS.HTM 01-01-25
Administrowanie DNS Strona 4 z 17
Serverów, do których można wysyłać zapytania. Jeżeli resolver natrafia na adres
komputera (lub nazwę odpowiadającą adresowi), buduje zapytanie i przesyła je do
jednego z serverów, który jest mu znany (z pliku ). Server
przesyła odpowied%3ń korzystając z lokalnych zasobów, albo na podstawie informacji
uzyskanej od innych Name Serverów.
Oprócz listy serwerów, plik zawiera nazwę domeny adresowej
co umożliwia operowanie nazwami komputerów w formie skróconej.
Pierwsza linia omawianego pliku ma składnię
gdzie jest pełną nazwą domeny adresowej, np: ire.pw.edu.pl
Kolejne linie podaja adresy IP, pod które resolver powinien kierować zapytania. Linie
te mają składnię:
Przykładowy plik zaczerpnięty z dokumentacji systemu Solaris:







Konfigurowanie serwera DNS
Ponieważ każdy Name Server jest jednocześnie klientem innych serwerów, należy najpierw
przeprowadzić opisaną powyżej procedurę konfigurowania klienta DNS. Następnie należy
utworzyć plik bootujący i zestaw plików danych DNS. Jeśli skrypt inicjalizujący pracę
serwera, , stwierdzi obecność pliku
bootującego, , następuje uruchomienie programu i tym samym
rozpoczęcie działania serwera DNS.
Tworzenie pliku bootującego i plików danych DNS
Program typu daemon korzysta w typowym rozwiązaniu z pięciu plików:
pliku bootującego o domyślnej nazwie i lokalizacji i czterech
plików danych. Historyczne nazwy plików danych to: , , i
. Dla uniknięcia pomyłek ( np. wyżej wymieniony plik i
plik ) i dla nadania plikom danych cech identyfikujących domenę
adresową, na serwerach DNS Wydziału Elektroniki przyjęła się konwencja
nadawania następujacych nazw plików danych DNS : , ,
i . W miejscu xxx nazwy pliku występuje symbol
identyfikujacy domenę adresową, np: ire, ipe, ia. Pliki danych są zwyczajowo
umieszczane w katalogu .
file://D:\podreczniki\DNS.HTM 01-01-25
Administrowanie DNS Strona 5 z 17

Plik bootujący definiuje typ serwera jako Primary, Secondary lub
Caching-Only Name Server. Określa także strefę, w której serwer jest autorytywny i
z jakich plików danych powinien pobrać dane początkowe.

określa nazwy serwerów obsługujących domeny adresowe wyższego
rzędu i adresy tych serverów. Choć dla prawidłowego uruchomienia serwera
wystarczy tylko określenie tzw. root serverów, tzn. głównych serwerów sieci Internet
administrowanych przez NIC, administratorzy DNS z reguły umieszczają w tym
pliku dłuższą listę serwerów - poprawia to podobno sprawność działania DNS
bezpośrednio po uruchomieniu .

Plik zawiera wszystkie dane o komputerach w strefie. W omawianym dalej
przykładzie plik ten nazywa się .

Plik opisuje strefę w domenie IN-ADDR.ARPA (specjalna domena
umożliwiająca tzw. inverse mapping, tzn. przyporządkowywanie numerów IP
nazwom). W omawianym dalej przykładzie plik ten nazywa się .

Plik określa adres "local loopback interface" lub adres w
pseudosieci lokalnej. Adres ten jest 127.0.0.1.
Tworzenie pliku bootującego DNS
Zawartość pliku bootujacego zależy od typu serwera. Prześled%3ńmy to na przykładzie
Primary Servera.
Przeanalizujmy kolejne linie tego pliku.
Linia ta definiuje katalog domyślny DNS. Zdefiniowanie katalogu domyślnego
file://D:\podreczniki\DNS.HTM 01-01-25
Administrowanie DNS Strona 6 z 17
pozwala stosować adresowanie względne w obrębie plików danych DNS. Jeśli brak
tej linii należy podawać pełne ścieżki dostępu.
Kropka w tej linii symbolizuje tzw. root domain, czyli punkt początkowy Name
Service'u całej sieci Internet. Linia ta informuje serwer, że adresy root servers może
znale%3ńć w pliku (zlokalizowanym w katalogu ).
Aby ustanowić Primary Name Server, należy stworzyć plik zawierajacy wszystkie
autorytatywne dane dla strefy DNS. W pliku należy umieścić linię która
w pierwszym polu stwierdza, że serwer jest Primary dla strefy określonej w drugim
polu (Uwaga! Kropka na końcu nazwy jest niezbędna), a plik zawierający
autorytatywne dane dla tej strefy jest określony w polu trzecim.
Kolejne dwie linie określają serwer jako Primary dla domeny 32.128.in-
addr.arpa (odwrotnej domeny adresowej dla domeny Podunk.Edu) i dla domeny
0.0.127.in-addr.arpa, tzn. dla zapytań adresowych w obrębie serwera (local host
loopback), oraz podają nazwy adekwatnych dla tych domen plików danych.
Przeanalizujmy przykładowy plik dla Secondary Servera w tej samej
domenie co Primary Server z poprzedniego przykładu.
Plik ten różni się od poprzednio analizowanego obecnością linii .
W linii tej, pomiędzy domeną a plikiem danych, wymieniono numery IP Master
serwerów, z których Secondary Server pobiera dane. Na pierwszym miejscu
wymienia się Primary Server, a dalej ewentualnie inne Secondary Servery. Inne jest
także znaczenie pola trzeciego. Zawarta jest w nim nazwa pliku tworzonego przez
sewer, a zawierającego dane będace kopią danych uzyskanych z Primary Servera.
Kiedy serwer rozpoczyna pracę, dane są pobierane z takiego pliku (o ile istnieje), a
potem następuje sprawdzenie, poprzez skonsultowanie z serwerem typu Primary, czy
dane są wciaż aktualne.
Często serwer funkcjonuje jako Primary dla jednej lub kilku stref i jako Secondary
dla jednej lub kilku stref, dlatego w pliku może być wiele linii typu
i . W szczególności każdy Secondary Server jest Primary
Serverem "sam dla siebie" (local host loopback - 0.0.127.in-addr.arpa).
file://D:\podreczniki\DNS.HTM 01-01-25
Administrowanie DNS Strona 7 z 17
Poniżej przykłdowy plik dla Caching-Only Server.
Brak w tym plików linii o charakterze autorytatywnym. Serwer ten gromadzi jedynie
dane uzyskane w trakcie poprzednich zapytań.
Tworzenie plików danych DNS
Wszystkie pliki danych DNS są tworzone zgodnie ze standardem: Standard Resource
Record Format. W standardzie tym każda linia pliku to record, tzw. Resource Record
(RR). Każdy plik danych DNS musi zawierać pewne Resource Records.
Szczegółowy opis Standard Resource Record Format zostanie przedstawiony
pó%3ńniej, po zaprezentowaniu przykładowych plików danych DNS
Plik zawiera wszystkie dane o komputerach w strefie, tzn. nazwy serwerów,
adresy, informacje o komputerach (sprzęt i system operacyjny), aliasy nazw
komputerów, informacje o sposobie przekazywania poczty i przyporzadkowanie
protokołów do poszczególnych serwisów na komputerach. Informacje te zawarte są
w rekordach NS, A, HINFO, CNAME, MX, MB, MG i WKS. Plik zawiera także
rekord SOA który wskazuje początek danych dla strefy i zawiera nazwę komputera
przechowującego plik .
Przykładowy plik :
file://D:\podreczniki\DNS.HTM 01-01-25
Administrowanie DNS Strona 8 z 17
Plik ustanawia "local loopback interface" w obrębie serwera. Powinien
zawierać nazwę serwera i wska%3ńnik PTR przy nazwie .
Przykładowy plik :
Plik jest plikiem konfigurującym "inverse mapping". Powinien zawierać
nazwy Master serwerów i wska%3ńniki PTR do wszystkich komputerów.
Przykładowy plik :
Plik zawiera nazwy i adresy "root serwerów" sieci Internet.
Przykładowy plik :
file://D:\podreczniki\DNS.HTM 01-01-25
Administrowanie DNS Strona 9 z 17
Standard Resource Record Format
Pliki danych DNS zapisywane są w specjalnym formacie zwanym Standard Resource
Record Format. Każda linia pliku stanowi rekord tzw. Resource Record (RR),
zawierąjacy pola odseparowane znakami spacji lub tabulacji, albo dowolną
kombinacją tych znaków (white space)..
Kolejność pól w rekordzie jest stała. Dwa pierwsze są opcjonalne. Zawartość
ostatniego zależy od pola .
Pierwsze pole zawiera nazwę domeny, do której odnosi się rekord. Jeśli pole jest
puste w danym RR, obowiązuje nazwa z poprzedniego RR.
Nazwa domeny może być albo pełna (fully qualified) zakończona kropką, albo
skrócona - w takim przypadku dołączana jest do niej wcześniej zdefiniowana pełna
nazwa domeny.
Drugie pole, także opcjonalne (skrót od time-to-live) określa jak długo dane mają być
przechowywane w bazach danych DNS. Po upływie tego czasu, wyrażonego w
sekundach, dane traca ważność i są ponownie pobierane z autorytatywnego serwera.
Jeśli pole jest puste przyjmuje wartość określoną w rekordzie
SOA (Start Of Authority) opisanym dalej.
Jeżeli wartość jest zbyt mała, serwery generują dużą liczbę zapytań, wciaż
odświeżajac zawartość swoich baz danych. Jeśli wartość jest zbyt duża,
jakiekolwiek zmiany dokonywane w plikach DNS Primary Serverów propagują się w
sieci Name Serverów zbyt wolno.
Najczęściej wartości ustawia się miedzy dniem (86400) a tygodniem (604800).
Niektórzy administratorzy stosują taktykę używania dużych wartości, obniżanych w
okresach modyfikacji struktury sieci.
Wszystkie RR o tej samej nazwie, typie i klasie powinny mieć jednakowy .
Trzecie pole określa klasę rekordu. W chwili obecnej istnieje tylko jedna klasa IN.

Czwarte pole określa typ RR. Istnieje wiele typów RR. Najczęściej używane zostaną
omówione pó%3ńniej. Na razie zajmijmy się składnią obowiązującą w polach nazw i
danych RR.
file://D:\podreczniki\DNS.HTM 01-01-25
Administrowanie DNS Strona 10 z 17
Składnia RR
Zawartość piątego pola danych zależy od typu konkretnego RR. W polu tym, tak jak
i w polu nazw, duże i małe litery nie są rozróżniane, ale ponieważ sytuacja ta może
ulec zmianie w przyszłości, należy postępować tak jakby były rozróżniane.
Znaki specjalne
Następujące znaki mają specjalne znaczenie:
.
Pojedyncza kropka w polu nazwy oznacza bieżącą domenę.
@
Pojedynczy znak @ w polu nazwy oznacza bieżące %3ńródło danych.
..
Dwie kropki w polu nazwy reprezentują pusta nazwę "root domain" (istotne tylko dla
administratorów NIC i w sieciach izolowanych od Internetu).
\X
X jest symbolem różnym niż cyfra (0-9). Symbol \ anuluje specjalne znaczenie znaku
specjalnego.
\DDD
D jest cyfrą. Oktet taki jest traktowany jako tekst, a nie jako fragment adresu IP.
( )
Nawiasy służą do grupowania danych zapisanych w różnych liniach. Znaki końca
linii wewnatrz nawiasów nie są rozpoznawane.
;
Średnik rozpoczyna komentarz. Reszta linii jest ignorowana.
*
Gwiazdka funkcjonuje jako znak uogólnienia (wildcard o znaczeniu jak w wyrażeniu
regularnym UNIX).
W większości RR nazwy są podawane w formie skróconej - nie zakończonej kropką.
Jest do nich dołączana nazwa domeny bieżącej. Dla uniknięcia błędów dobrze jest
przyjąć zasadę używania pełnych (fully qualified) nazw zakończonych kropką, jeśli
nazwa jest spoza domeny dla której tworzymy pliki danych DNS. Warto podkreślić,
file://D:\podreczniki\DNS.HTM 01-01-25
Administrowanie DNS Strona 11 z 17
że z punktu widzenia DNS nazwa komputera jest też nazwą domeny - domeny
zdegenerowanej do jedenego adresu komputera.
Control Entries
Jedynymi liniami, które nie sa zgodne ze standardowym formatem RR w plikach
danych DNS są "control entries". Istnieją w obrębie plików danych DNS dwa typy
"control entries":

Linia ta składa się z w pierwszej kolumnie i z nazwy pliku. Umożliwia to
organizowanie pliku danych DNS nie w postaci pojedynczego pliku, a zbioru plików,
np: zawierających rekordy pogrupowane według typów. Na przykład linia:
powoduje właczenie do pliku danych DNS rekordów RR odnoszacych się do poczty
zawartych w pliku .

Polecenie umożliwia zmianę bieżacej domeny. Na przykład, linia:
powoduje, że do nazw skróconych występujących w następnych liniach dołączana
jest zadeklarowana nazwa domeny. Polecenie to jest przydatne w przypadku plików
danych DNS zawierających dane o kilku domenach adresowych.
Typy rekordów RR
Kilka najczęściej używanych typów RR przedstawia tabela poniżej.
Typ Opis
SOA Start of Authority
NS Name Server
A Internet Address
CNAME Canonical Name (nickname)
HINFO Host Information
WKS Well Known Services
PTR Pointer
MX Mail Exchanger
Przeglądając prezentowany wcześniej przykładowy plik łatwo odnale%3ńć
rekordy wymienionych w tabeli typów. Przeanalizujmy je bardziej szczegółowo.
file://D:\podreczniki\DNS.HTM 01-01-25
Administrowanie DNS Strona 12 z 17
SOA - Start of Authority
Rekord ten posiada następujący format:
Rekord SOA oznacza początek strefy DNS. Końcem strefy jest następny rekord
SOA.
Pole to określa nazwę domeny. W przykładowym pliku w polu tym jest
symbol @ wskazujący, że %3ńródłem danych bieżących jest komputer, na którym
rezyduje plik .

Jedyna istniejąca klasa rekordów RR.
Typ omawianego rekordu.
W tym polu umieszcza się nazwę komputera, na którym zainstalowany jest plik
danych DNS.
Adres pocztowy osoby odpowiedzialnej za serwer. Adres ma formę nielegalną z
powodu specjalnego znaczenia znaku @ wewnątrz RR. Przed wysłaniem E-maila do
administratora serwera należy adres skorygować, zastępując pierwszą kropkę
znakiem @.
W polu tym wpisuje się numer wersji pliku. Kolejne tworzone wersje muszą mieć
coraz większe numery. Secondary Server na podstawie tego pola stwierdza czy
nastąpiły zmiany na Primary Serverze i czy zachodzi potrzeba dokonania aktualizacji
plików. jest liczbą dziesiętną z maksimum czterema cyframi po przecinku.
W praktyce dobrze sprawdza się następująca konwencja tworzenia numeru wersji:
cztery pierwsze cyfry to rok, dwie następne to miesiac, dalej dzień i dwie ostatnie to
numer kolejnej zmiany w danym dniu.
file://D:\podreczniki\DNS.HTM 01-01-25
Administrowanie DNS Strona 13 z 17
Pole to określa co ile sekund Secondary Server powinien sprawdzać na Primary
Serverze (badając pole Serial) czy nie zachodzi konieczność aktualizacji danych.

Pole to mówi co ile sekund Secondary Server ma ponawiać próby dokanania
aktualizacji danych w przypadku kłopotów z połączeniem się z Primary Serverem.

Czas przez jaki "żyją" na Secondary Serwerze dane, których nie udaje się
aktualizować (autoryzować) na Primary Serverze.
W tym polu określony jest domyślny czas dla tych RR, które nie mają w
swojej linii.
Poniżej przykładowy rekord SOA:
NS - Name Server
Format rekordu NS wyglada nastepująco:
Rekordy NS tworzą listę serverów odpowiedzialnych za domenę. Jeśli pole nazwy
jest puste obowiązuje nazwa domeny z poprzedniego RR. Każdy Master Server w
domenie powinien mieć swój rekord NS.
Przykładowy RR typu NS:
A - Address
Format rekordu A wygląda nastepujaco:
file://D:\podreczniki\DNS.HTM 01-01-25
Administrowanie DNS Strona 14 z 17
Rekordy A tworzą listę adresów komputerów. W polu nazwy pojawia się nazwa
komputera w polu adresu jego adres. Niektóre komputery (routery) mogą mieć kilka
adresów.
Przykładowy RR typu A:
HINFO - Host Information
Format rekordu HINFO jest następujący:
Rekord ten podaje dane o typie (marce) komputera i jego systemie operacyjnym. Dla
danego komputera może istnieć tylko jeden RR typu HINFO. Jeśli w polu
lub występują spacje, pole należy zamknąć w cudzysłów.
Przykladowy RR typu HINFO:
WKS - Well Known Services
Format rekordu WKS jest następujacy:
Rekord ten wymienia serwisy realizowane przy pomocy poszczególnych protokołów
na danym komputerze. Zawartość tego rekordu powinna być zgodna z zawartością
pliku . Proszę zwrócić uwagę na brak spacji między protokołem a
pierwszym serwisem na liście.
Przykładowy RR typu WKS:
file://D:\podreczniki\DNS.HTM 01-01-25
Administrowanie DNS Strona 15 z 17
CNAME - Canonical Name
Format rekordu CNAME jest następujacy:
Rekord CNAME wprowadza nazwy umowne (nickname) komputerów które
funkcjonują równolegle z ich nazwami oryginalnymi (canonical name). Rekordy tego
typu znajdują zastosowanie w dwóch sytuacjach. Pierwsza to sytuacja, gdy ulega
zmianie nazwa komputera -dzięki wprowadzeniu nickname w postaci starej nazwy,
użytkownicy przyzwyczajeni do tej starej nazwy mogą dalej pracować na
komputerze. Druga to dobry obyczaj nadawania umownych nazw serwerom, np:
komputer będący serwerem WWW otrzymuje nazwę umowną www, anonymous ftp
server - nazwę umowną ftp, a NNTP Server nazwę news.
Przykładowy rekord CNAME:
PTR - Domain Name Pointer
Format rekordu PTR jest następujący:
Rekord PTR pozwala przywiązać pewne nazwy specjalne do pewnych lokalizacji w
obrębie domeny. Rekordy PTR są używane w odwrotnym Name serwisie IN-
ADDR.ARPA do tłumaczenia adresów (nazw specjalnych) na nazwy rzeczywiste. W
przykładzie poniżej występuje przypisanie adresów komputerów do nazw. W
pierwszej linii adres występuje w postaci skróconej, w drugiej (dla komputera spoza
bieżącej domeny) -w pełnej. Proszę zwrócić uwagę na odwrotną w stosunku do
adresu IP kolejność oktetów.
Przykładowe rekordy PTR:
MX - Mail Exchanger
Format rekordu MX jest następujący:
Rekord MX jest używany do określenia komputerów, które wiedzą jak przesłać
file://D:\podreczniki\DNS.HTM 01-01-25
Administrowanie DNS Strona 16 z 17
pocztę do konkretnego komputera lub do domeny. Może być więcej niż jeden rekord
MX dla danej nazwy (wiecej niż jedna droga dostarczania poczty). W takim
przypadku najpierw następuje próba dostarczenia poczty drogą o mniejszej wartości
. Pole w rekordzie MX może być puste, wtedy
przyjmowana jest nazwa bieżąca (tak jak w rekordach HINFO).
Przykładowe rekordy MX:
Pierwsza linia oznacza, że komputer Seismo.CSS.GOV. wie jak i przyjmuje
obowiązek dostarczania poczty adresowanej do Mounari.OZ.AU ( ma na przykład
prywatne połączenie z tym komputerem). Druga linia wskazuje komputer potrafiący
dostarczać pocztę adresowaną do domeny foo.COM, a trzecia -komputer
dostarczający pocztę adresowaną do wszystkich subdomen i komputerów w domenie
foo.COM.
Modyfikowanie plików danych DNS
Kiedy przeprowadza się modyfikację plików danych DNS (np. przyłączając nowy
komputer do sieci), należy pamiętać o zmianie numeru wersji w rekordzie SOA (Serial
number). W przeciwnym wypadku zmiana nie będzie zauważona przez inne Master
Servery.
Po zakończeniu edycji plików należy spowodować, żeby program "zauważył"
wprowadzone zmiany. Należy go w tym celu zrestartować. Można to zrobić na przykład
następujaco:
Odczytać PID programu wykonując polecenie:
W odpowiedzi komputer wyświetla linię o przykładowej zawartości:
Należy "zabić"
Teraz należy ponownie uruchomić program :
Powinno to spowodować ponowne uruchomienie programu w tle (bo jest
to program typu daemon).
Uwaga ! Nie należy uruchamiać programu spod . Powoduje to wielokrotne
file://D:\podreczniki\DNS.HTM 01-01-25
Administrowanie DNS Strona 17 z 17
uruchamianie programu i uniemożliwia prawidłowe działanie Name Service'u.
file://D:\podreczniki\DNS.HTM 01-01-25