Archiwum dla Styczeń, 2014

Każda implementacja resolver’a niewiele różni się od pozostałych algorytmami. Główne różnice polegają na obsłudze błędów.

Jednym ze stosowanych rozwiązań jest użycie tzw. stub resolver’a. Polega to na przeniesieniu funkcji rozwiązywania poza maszynę lokalną do name server’a, który jest w stanie przeprowadzać zapytania rekursywne (recursive queries). Taka metoda dobrze się sprawdza w przypadku, gdy chcemy prowadzić serwis DNS na komputerze klasy PC, któremu zwykle brak jest zasobów na dokonywanie rekursywnych zapytań lub też w przypadku centralizacji cache’a dla całej sieci lokalnej. Jedyne czego stub resolver potrzebuje. to lista serwerów przeprowadzających rekursywne zapytania. Oczywiście dane muszą być zapisane w plikach konfiguracyjnych, gdyż z powodu nieskomplikowanej budowy nie byłby w stanie znaleźć sam bazy danych w sieci lokalnej. Jednak rozwiązania oparte na stub resolver’ach nie są zalecane z powodu dużej zawodności w przypadku większego obciążenia sieci.

Poza swoimi zasobami, resolver może również korzystać z informacji zawartych w strefach zarządzanych przez lokalny name server. Zwiększa się szybkość dostępu do danych, ale należy być ostrożnym ,by nie spowodować przepisania danych z cache’a jako wyniku (jeżeli wykorzystane będą dane ze stref lokalnych).

Podany algorytm resolving’u opiera się na domyślnym przyjęciu, że wszystkie funkcje zostały skonwertowane do ogólnego lustrowania (general lookup) i używane są podane niżej struktury, niezbędne do reprezentowania postępu w rozwiązywaniu zapytania.

SNAME

nazwa domeny, której szukamy

STYPE

typ rekordu QTYPE podanego żądania przeszukiwania

SCLASS

typ rekordu QCLASS

SLIST

struktura określająca jakie strefy i name server’y obecnie odpytuje resolver. Pozwala na kontrolowanie historii przebiegu poszukiwania.

SBELT

Struktura bezpieczeństwa, podobna do SLIST.

CACHES

truktura zapamiętująca wyniki odpowiedzi na poprzednie zapytania.

 

9.2. Komunikaty (Messages)

Wszystkie informacje krążące wewnątrz protokołu domeny przenoszone są za pomocą osobnego formatu zwanego komunikatem lub wiadomością (message). Format komunikatu podano poniżej.

 Górna część nagłówka wiadomości jest podzielona na pięć sekcji, z których niektóre mogą być puste (w pewnych okolicznościach).

Oto sekcje:

HEADER

(nagłówek). Jest zawsze obecny, posiada również specjalne pole określające, które z pozostałych sekcji są obecne w wiadomości, jak również pole określające czy wiadomość jest zapytaniem, odpowiedzią, standardowym zapytaniem czy też innym typem określonym przez opcode.

QUESTION

pola zawierające opis zapytań do name server’a. Pola mogą być typem query type (QTYPE), lub query class (QNAME), bądź też zapytaniem o nazwę domeny (QNAME).

ANSWER

zawiera RRs odpowiadające na pytania. Ta sekcja, jak i następne mają format listy (może być pusta) połączonych rekordów RR..

AUTHORITY

sekcja zawiera rekordy RR wskazujące na to, gdzie znajduje się miarodajny (authoritative) name server.

ADDITIONAL

tu znajdują się rekordy, które związane są z zapytaniem, lecz nie tak całkiem dokładnie z odpowiedzią na nie.

Reklamy