W tym rozdziale przedstawiono:
· Rekordy zasobów bazy danych. Rekordy zasobów (RR od Resource Records) stanowią większą część zawartości plików strefy, wobec czego znajdują się w samym sercu systemu DNS. Zgodnie z nazwą, każdy rekord zasobów zawiera informacje o zasobie o którym DNS powinien wiedzieć. Są pomiędzy nimi inne serwery DNS, hosty oraz , obecnie, usługi których dostępność jest ogłaszana. Podrozdział ten opisuje główne typy rekordów zasobów i ich wykorzystanie.
· Plik podręczny. Plik podręczny (cache file) identyfikuje serwery nazw domeny głównej. Dzięki niemu, każdy serwer DNS może łatwo znaleźć korzeń drzewa systemu nazw domen. Podrozdział ten opisuje plik podręczny, powody dla których jest potrzebny i sposób jego wykorzystania.
· Delegacje. Zarejestrowanie podstawowego serwera DNS w jednym z serwerów należących do InterNIC czyni go dostępnym dla klientów spoza domeny, którym potrzebny jest dostęp do listy nazw w tej domenie. Publikowanie serwerów wtórnych z pomocą rekordów serwera nazw (NS od Name Server) leży w kwestii administratora domeny. W tym podrozdziale podano powody, dla których warto udostępniać inne serwery autorytatywne [poza podstawowym].
Gdyby DNS był zwierzęciem, pewnych czynności dokonywałby instynktownie, a innych zachowań dopiero pod wpływem procesu uczenia się. Ten rozdział opisuje podstawowe czynności dla których DNS został zaprojektowany – wykonywane są one niemal instynktownie (serwowanie rekordów zasobów ze swoich plików stref), oraz różnorodne rodzaje rekordów zasobów które pozwalają DNS-owi na wykonywanie — zależnie od naszych potrzeb — bardziej zaawansowanych zadań (kierowanie poczty, znajdowanie informacji o położeniu usług, poprawa infrastruktury bezpieczeństwa przez wymianę kluczy). Nie opisano tu nowych zachowań aktualizacji dynamicznej których DNS ostatnio się nauczył.
Jak w każdej relacyjnej bazie danych, architektura DNS-u składa się z tabel, z których każda zawiera pewną liczbę rekordów. Tabele bazy danych DNS nazywane są plikami strefy. Większość rekordów ma specjalne znaczenie, ponieważ mogą one podawać położenie zasobów, a nawet być związane z rekordami w innych tabelach. Wśród możliwych typów rekordów są: rekord pełnomocnictwa SOA, rekord adresu (A) i rekord wskaźnika (PTR). Szczegółowe opisy najczęściej spotykanych rekordów zasobów podano w dalszej części rozdziału. Dodatek F – „Rekordy zasobów i plik podręczny InterNIC” zawiera pełny spis rekordów zasobów.
To, jakie rekordy można zobaczyć w strefie, zależy od kilku czynników. Jakim plikiem strefy się zajmujemy? Strefy wyszukiwania w przód i wstecz, na przykład, mają bardzo niewiele wspólnych typów rekordów. Innym czynnikiem wpływającym na zawartość pliku strefy są dane, które administrator DNS-u chce (lub musi) opublikować. Pozostała część tego podrozdziału szczegółowo opisuje najważniejsze typy rekordów. Czytelnik powinien poznać je wszystkie i sposób ich użycia.
Jeśli konfiguracja DNS w Windows każe mu przechowywać dane stref w plikach, pliki bazy danych strefy znajdują się w katalogu %windir%\system32\dns. Dodatkowo, pliki szablonów umieszczone w podkatalogu .\samples służą jako przykłady formatu plików.
Serwer DNS w Windows 2000 może przechowywać konfigurację i informacje o strefach w trzech miejscach. Konfiguracja zapisana jest zawsze w Rejestrze, a poza tym może być zapisana w pliku startowym kompatybilnym z BIND-em (w jego wersji występującej na systemach Uniksowych). Dane stref mogą być przechowywane w plikach strefy lub w Active Directory. Konfiguracja startowa serwera DNS położona jest w Rejestrze w: HKLM, System, CurrentControlSet, Services, DNS, Zones; plik ma nazwę BOOT. W przeciwieństwie do pliku NAMED.BOOT w systemie UNIX, serwer DNS w Windows 2000 dopuszcza jedynie w pliku startowym wyszczególnienie dyrektyw serwera podstawowego, wtórnego i pamięci podręcznej. Rysunek 4.1 przedstawia zakładkę Zaawansowane we właściwościach serwera DNS na serwerze członkowskim.
Jeśli zmienimy ustawienia ładowania danych strefy przy rozruchu na Z pliku, na podstawie Rejestru tworzony jest plik startowy. Jeśli zmienimy te ustawienia na Z Rejestru, poprzedni plik startowy przenoszony jest do podkatalogu .\backup. W obu przypadkach w Rejestrze przechowywane są najbardziej aktualne informacje. Zmiany zachodzą natychmiast po naciśnięciu przycisku Zastosuj.
Mylący może być fakt korzystania z plików strefy do przechowywania danych strefy zawsze, z wyjątkiem korzystania z Active Directory. Mimo opisu tej opcji na rysunku 4.1, dane strefy (to znaczy, rekordy zasobów) nie są przechowywane w Rejestrze. Jeśli przechowujemy informacje o strefie w Active Directory, pliki strefy konwertowane są na obiekty katalogowe widoczne dla protokołu LDAP (Lightweight Directory Access Protocol) i plik strefy przestaje istnieć na serwerze podstawowym, chociaż nadal wykorzystywany jest na wtórnych. Ponadto, przestaje być dostępna opcja startu z pliku.
Rys. 4.1 Okno dialogowe serwera DNS Windows, w którym ustawić można opcje startowe
Format plików strefy w DNS w Windows zgodne są z RFC, wobec czego przykłady w tym rozdziale mogą dotyczyć zarówno plików strefy BIND-u jak DNS w Windows. Rozdział ten może zawierać więcej informacji niż widać w konsoli zarządzania DNS-em w Windows. W takich przypadkach, należy zdać sobie sprawę że faktyczna baza danych jest bardziej złożona niż to, co widać — ponieważ konsola zarządzania upraszcza sprawę wybierając dane do wyświetlania i dobierając inteligentnie domyślne wartości dla niektórych konfigurowalnych opcji.
Najbardziej autorytatywnymi dokumentami opisującymi formatowanie rekordów zasobów są RFC 1035, RFC 1183, RFC 1664, RFC 1886, RFC 2052, RFC 2181, RFC 2535 i RFC 2672 (dostępne w Internecie pod adresem www.isi.edu). DNS Windows automatycznie formatuje rekordy gdy korzystamy z konsoli zarządzania serwerem DNS. Jednakże jeżeli używamy pliku startowego do przenoszenia plików, na przykład pomiędzy DNS-em Windows a BIND-em, musimy dokładnie znać sposób formatowania rekordów w edytorze tekstu i tworzenia pliku startowego w formacie możliwym do zaakceptowania przez Windows. Sympatyczną funkcją DNS-u Windows jest możliwość tworzenia konfiguracji serwera DNS za pomocą konsoli zarządzania, by potem zapisać ją w pliku startowym. Pomaga to, oczywiście, przy przenosinach z DNS-u Windows do Uniksa i BIND-u, a nie w drugą stronę.
Poniższy wyjątek z RFC 1036 (strony 32-34), którego autorem jest Paul Mockapetris, objaśnia składnię formatu [rekordów] RR:
Formatem tych plików jest ciąg wpisów. Poszczególne wpisy są zasadniczo liniami tekstu, lecz możliwe jest przedłużenie listy [pozycji] do następnych linii za pomocą nawiasów, zaś łańcuchy tekstowe mogą zawierać znak CRLF (przejście do następnego wiersza z powrotem karetki). Dowolna kombinacja znaków tabulacji i spacji służy do oddzielania poszczególnych pozycji składających się na wpis. Na końcu dowolnej linii w pliku [głównym] może znajdować się komentarz. Komentarz zaczyna się od znaku średnika (;). Zdefiniowane są następujące wpisy:
<pusty> [<komentarz.>]
$ORIGIN <nazwa-domeny> [<komentarz>]
$INCLUDE <nazwa-pliku> [<nazwa-domeny>] [<komentarz>]
<nazwa-domeny><rekord-zasobu> [<komentarz>]
<pusty><rekord-zasobu> [<komentarz>]
Linie puste, zawierające komentarz lub nie, dopuszczalne są w każdym miejscu pliku. Zdefiniowano dwa wpisy sterujące: $ORIGIN i $INCLUDE. Po $ORIGIN następuje nazwa domeny; wpis ten zmienia bieżący początek względnych nazw domen na podane w nim. $INCLUDE wstawia do bieżącego pliku plik którego nazwa została podana, ponadto może ustawić względny początek nazwy domeny dla zawartego pliku. $INCLUDE może również zawierać komentarz. Proszę zwrócić uwagę, iż wpis $INCLUDE nigdy nie zmienia względnej [nazwy początkowej] dla pliku rodzicielskiego, niezależnie od zmian początku względnego dotyczących zawartego pliku.
Ostatnie dwie linie dotyczą rekordów zasobów. Jeżeli wpis dotyczący RR zaczyna się od znaku pustego, przyjmuje się że RR przynależy do ostatnio podanego właściciela. Jeśli wpis RR zaczyna się od pozycji <nazwa-domeny>, nazwa właściciela jest zmieniana. Zawartość pozycji <rekord-zasobu> może przybrać jedną z poniższych form:
[<TTL>] [<klasa>] <typ> <RDATA>
[<klasa>] [<TTL>] <typ> <RDATA>
RR zaczyna się od opcjonalnych pól TTL (czas życia, time-to-live) oraz klasa, po których następują pola typ i RDATA odpowiadające typowi i klasie. klasa i typ wykorzystują standardowe mnemoniki, zaś TTL jest liczbą całkowitą w formacie dziesiętnym. Pominięte wartości TTL i klasy ustawiane są na ostatnio podaną ściśle wartość. Ponieważ mnemoniki typ i klasa są rozłączne, analiza składni jest jednoznaczna. (Proszę zauważyć, że kolejność ta różni się od użytej w przykładach i w rzeczywistych RR; podana kolejność pozwala na łatwiejszą analizę składni i nadawanie wartości domyślnych).
Pola <nazwa-domeny> stanowią dużą część danych w pliku głównym.
Etykiety w nazwie domeny są wyrażone jako łańcuchy znaków i oddzielone kropkami. Konwencje cytowania pozwalają na zastosowanie dowolnych znaków w nazwach domen. Nazwy domen zakończone kropką są nazywane bezwzględnymi i traktowane jako pełne. Nazwy domen nie zakończone kropką są nazywane względnymi; rzeczywista nazwa domeny stanowi połączenie części względnej z [nazwą początkową] podaną we wpisie $ORIGIN, $INCLUDE lub jako opcja w procedurze ładowania pliku głównego. Nazwa względna stanowi błąd jeśli nie dysponujemy źródłem.
<łańcuch-znaków> można określić na jeden lub dwa sposoby: jako ciągły zestaw znaków [alfabetu łacińskiego? – przyp. tłum.] bez znaku spacji wewnątrz, lub jako łańcuch rozpoczęty i zakończony pytajnikiem ?.
Wewnątrz ograniczonego łańcucha może pojawić się dowolny znak z wyjątkiem samego pytajnika, który musi być cytowany za pomocą znaku \ (backslash).
Ponieważ mamy do czynienia z plikami tekstowymi, do załadowania dowolnych danych niezbędne jest kilka konwencji kodowania., a w szczególności:
. korzeń drzewa . (root)
@ Znak @ luzem oznacza bieżący początek nazwy
\X gdzie X jest dowolnym znakiem z wyjątkiem cyfry (0-9), służy do cytowania tegoż znaku tak, że nie stosuje się jego specjalnego znaczenia. Na przykład, ?\.? może służyć do umieszczenia kropki w etykiecie.
\CCC gdzie każda litera C jest cyfrą oktetu odpowiadającego liczbie dziesiętnej CCC. Wynikły oktet uznawany jest za tekst i nie sprawdza się jego znaczenia specjalnego.
( ) Nawiasy służą do grupowania danych przechodzących przez podział wiersza. W efekcie tego znaki końca wiersza wewnątrz nawiasów są ignorowane.
; Średnik służy do rozpoczęcia komentarza; dalsza część wiersza jest ignorowana.
Składna i przykłady opisujące poszczególne typy rekordów zasobów w dalszej części rozdziału są również przedstawione w RFC 1035 i RFC 2052. Dokumenty te są autorytatywne dla formatu pliku głównego. Należy jednak zrobić kilka spostrzeżeń:
· Wpisy RR analizowane są bez odróżniania małych i wielkich liter, wobec czego nazwahosta = NAZWAHOSTA = NazwaHosta.
· Długości nazw w RR są ograniczone do 63 znaków na etykietę i 256 na FQDN.
· Podkreślenia ( _ ) w rekordach usług (SRV) są podane w obecnej wersji RFC 2052 dla — prawdopodobnie tymczasowego — określania pól usługi i protokołu. Aktualnie obowiązująca robocza wersja RFC 2052bis mająca zastąpić RFC 2052 to draft-ietf-dnsind-rfc2052bis-05.txt z 16 grudnia 1999
Może jest już nowsza? – sprawdzić
· .
· Dla opcji międzynarodowych przyjęto standardowe wsparcie rozszerzonego zestawu znaków w RFC 2044, który w międzyczasie został zastąpiony przez RFC 2279. Standard UTF-8 opisany w RFC 2279 dotyczy zestawu znaków a nie konkretnie systemu DNS i został stworzony na potrzeby rekordów zasobów w DNS Windows 2000.
Zastosowanie znaku podkreślenia
Podkreślenie jest powszechnie wykorzystywane w schematach nazewniczych Windows NT, lecz stwarza problemy przy odwzorowywaniu nazw NetBIOS na przestrzeń nazw DNS. Administratorzy Windows muszą pamiętać, iż podkreślenie jest obecnie znakiem niedopuszczalnym w nazwach hostów i domen DNS. Chociaż niektóre serwery nazw jedynie zwracają uwagę na niepoprawność podkreślenia, inne mogą zwracać błąd lub całkowicie odmówić obsługi zapytań. W przypadku Windows 2000 jest to zazwyczaj mniejszym problemem, ponieważ przestrzenie nazw DNS i Windows muszą być ściśle związane. Jednakże faktem pozostaje problem współpracy serwerów DNS przy korzystaniu z nazw w standardzie UTF-8 i znaków specjalnych takich, jak podkreślenie.
Rekord SOA (początku pełnomocnictwa, Start of Authority) jest wymagany jako pierwszy wpis we wszystkich plikach stref wyszukiwania w przód i wstecz (in-addr.arpa). Rekordy SOA, zdefiniowane w RFC 1035, dostarczają kilku kluczowych informacji potrzebnych w każdej domenie. Przede wszystkim SOA określa, który serwer nazw jest autorytatywnym źródłem informacji w domenie. Rysunek 4.2 przedstawia okno dialogowe Właściwości strefy ustawione na zakładkę rekordu SOA. Właściwości strefy w konsoli zarządzania serwerem DNS można uzyskać wyróżniając ikonę strefy w lewym panelu, a następnie używając menu kontekstowego (prawy przycisk myszy) i wybierając Właściwości.
Rekordy SOA są niezwykle ważne. Zawierają składniki opisane poniżej (niektóre wartości przedstawia rys. 4.2). Poniższa lista pokazuje wszystkie możliwe opcje (chociaż niezupełnie tak, jak przedstawia je konsola zarządzania serwerem DNS Windows 2000). Wzorcowy rekord zasobu SOA wygląda jak następujący szablon (patrz również rys. 4.2):
<właściciel>
Dalsze słownictwo z Pomocy W2K w wersji poskiej
<ttl> IN SOA <źródło pliku strefy> <osoba odpowiedzialna> (<nr seryjny> <interwał odświeżania> <interwał ponawiania> <interwał wygasania> <m-ttl> )
· Właściciel. Właściciel SOA w zasadzie odnosi się do źródła strefy, czy też domeny którą reprezentuje strefa. W DNS-ie Windows 2000 właściciele to nazwy domen pojawiające się w liście serwerów pod nazwami serwerów i wprowadzane są do bazy danych automatycznie za użytkownika.
· ttl. Domyślna wartość TTL dla domeny ustawiana jest przez wartość minimalnego czasu życia (z ang. time-to-live) – patrz ostatnia pozycja listy, M-TTL). W przypadku użycia, wartość TTL zastępuje dla danego rekordu wartość domyślną (M-TTL).
· klasa. Domyślną wartością w SOA jest IN od Internet.
Rys. 4.2 Właściwości strefy w serwerze DNS Windows – informacje o rekordzie zasobu SOA.
· typ. Obecność skrótu „SOA” w kolumnie typu rekordu zasobu oznacza, iż jest to rzeczywiście rekord wskazujący, który serwer jest źródłem pełnomocnictwa w domenie.
· źródło pliku strefy. Źródło pliku strefy to nazwa hosta podstawowego serwera DNS w domenie. W DNS-ie Windows ten wpis tworzony jest automatycznie podczas użycia konsoli zarządzania DNS-em.
· osoba odpowiedzialna (nazwa skrzynki pocztowej osoby odpowiedzialnej za DNS). Jest to wpis który zazwyczaj wskazuje na adres poczty elektronicznej administratora domeny, w formacie w którym składniki oddzielane są kropkami. Na przykład, action.cnri.reston.va.us tłumaczy się na action@cnri.reston.va.us, wobec czego action to najprawdopodobniej adres pocztowy administratora systemu w CNRI.
· nr seryjny. Numer seryjny służy do nadzoru nad wersjami. Gdy dokonuje się zmian w pliku strefy i numer seryjny zostaje inkrementowany, zmiany te odbierane są przez serwery wtórne. Jeśli nie zwiększymy numeru, serwer wtórny przyjmuje że posiada poprawnie dane i nie inicjalizuje transferu danych. Serwer podrzędny żąda numeru seryjnego od nadrzędnego i porównuje go z posiadanym. Jeśli stwierdzi że numer nadrzędnego jest wyższy, inicjalizuje transfer strefy. Jeśli oba są równe, transfer nie zachodzi. Jeśli numer seryjny serwera nadrzędnego jest niższy niż podrzędnego, transfer nie następuje a serwer podrzędny zapisuje komunikat błędu do swojego dziennika błędów, informujący o posiadaniu przez serwer nadrzędny niższego numeru seryjnego niż własny.
· interwał odświeżania. Interwał odświeżania informuje serwery podrzędne jak często dokonywać próby odświeżenia strefy. Jest to interwał (albo cykl) odświeżania. Gdy kończy się interwał odświeżania w serwerze podrzędnym, dokonywana jest ocena numeru seryjnego aby stwierdzić czy jakieś zmiany danych wymagają nowego transferu. Jeśli zmiany zostały dokonane a numer seryjny zwiększony, serwery podrzędne zapisują nowy numer w trakcie przeładowania strefy. Rozdział 5 dostarcza wiadomości o pełnych i przyrostowych transferach strefy.
· interwał ponawiania. Interwał ponawiania określa po jakim czasie serwery wtórne ponawiają próbę odświeżania po nieudanym odświeżeniu.
· interwał wygasania. Czas wygasania określa, jak długo serwer wtórny może udzielać autorytatywnych odpowiedzi jeśli ponawiane próby odświeżania zawiodą. Jeśli odświeżanie zawiedzie z powodu niedostępności serwera podstawowego, wtórne w dalszym ciągu odpowiadają na zapytania aż do wygaśnięcia ważności danych strefy. Jeżeli serwer podstawowy zacznie ponownie działać, serwery podstawowe wykonują odświeżenie ku powszechnemu zadowoleniu. Jeśli ważność strefy wygaśnie bez pomyślnego odświeżenia, serwery wtórne przestają odpowiadać na zapytania dotyczące domeny.
· m-ttl. Minimalny czas życia podaje domyślną wartość czasu, przez który odpowiedź jest poprawna (tj. czas życia , TTL, odpowiedzi), jeśli nie podano dla niej konkretnej wartości TTL. Gdy klient odpytuje serwer DNS, łącznie z odpowiedzią pobiera jej TTL aby wiedzieć, jak długo może używać odpowiedzi z własnej pamięci podręcznej bez sprawdzania w serwerze możliwych zmian. Jeśli dane nie zmieniają się często, TTL może być wyższy. Wynikiem są bardziej trwałe pamięci podręczne i w rezultacie mniej zapytań. Niskie wartości TTL powodują szybsze wygasanie ważności pamięci podręcznych klientów, co z kolei powoduje częstsze zapytania o dokładnie te same rekordy. Podawanie wartości TTL w rekordzie zasobu nie zdarza się często, co oznacza że rekordy te dziedziczą wartość TTL z podanej tutaj M-TTL zapisanej w rekordzie SOA domeny.
Typowy rekord SOA może wyglądać następująco:
example.net. IN SOA ns.example.net root.example.net (
19991225000 ;nr seryjny
10800 ;interwał odświeżania
3600 ;interwał ponawiania
604800 ;interwał wygasania
86400 ) ;m-ttl
Symbol @ może również wskazywać bieżący początek nazwy (w naszym przypadku example.net), przez co następny rekord SOA jest odpowiednikiem poprzedniego:
@ IN SOA ns.example.net root.example.net (
@ odpowiada dłuższej formie: example.net. Jak wspomniano powyżej, pole ttl jest zwykle ignorowane, ponieważ domyślnie wartość M-TTL dotyczy wszystkich rekordów w strefie. Uwaga: wszystkie czasy podane są w sekundach.
Rekordy serwerów nazw mówią systemowi DNS, które serwery są delegowane w domenie lub jej poddomenach. Delegacja daje serwerowi pełnomocnictwo do odpowiadania na zapytania. Przypomina ona kierownika przydzielającego pracę innej osobie. Serwer nazw może delegować całkowitą odpowiedzialność za poddomenę na inne serwery, zaś serwer podstawowy może dokonać delegacji na serwery wtórne, tak że będą one używane do obsługi zapytań, mimo iż nie są źródłem odwzorowań adresów. Podrozdział „Delegacje” w dalszej części rozdziału opisuje delegacje bardziej szczegółowo. Rysunek 4.3 przedstawia okno dialogowe Właściwości strefy z wybraną zakładką rekordów NS.
Rekordy NS używane są w plikach stref wyszukiwania w przód i wstecz, a ich format wygląda następująco:
<właściciel> <ttl> IN NS <host.nazwa-domeny>
Pierwsze pole rekordu to właściciel; wskazuje na domenę do której serwer nazw posiada oddelegowane pełnomocnictwo. Następne pole to ttl, zazwyczaj pozostawione puste, ponieważ administratorzy zamiast niego lubią polegać na wartości M-TTL rekordu SOA. Następne pole to klasa, prawie zawsze o wartości IN (Internet). W końcu, host.nazwa-domeny serwera nazw zawiera pełną złożoną nazwę domeny (FQDN) [jakiegokolwiek] serwera który może udzielać autorytatywnych odpowiedzi w obrębie domeny.
Rys. 4.3 Właściwości strefy serwera DNS w Windows – informacje o rekordzie zasobu NS
...
paradoks24h