Archiwum dla Marzec, 2016

Resolver’ami są programy, które pośredniczą pomiędzy programami użytkownika a name server’ami. W najprostszym przypadku, resolver otrzymuje żądanie obsługi przez program użytkownika (np. program pocztowy, FTP lub TELNET) w postaci np. wywołania systemowego i zwraca żądaną odpowiedź w formie umożliwiającej odczytanie przez program (a zgodnej z formatem danych na hoście).

Resolver zwykle jest umieszczony na komputerze z którego pochodziło zgłoszenie obsługi, choć do udzielenia odpowiedzi może potrzebować zasięgnąć informacji u innych name server’ów na innych host’ach. Ponieważ może komunikować się z kilkoma name server’ami lub też tylko wyciągnąć informację z lokalnego cache’a, czas oczekiwania na odpowiedź może trwać od milisekund do kilku sekund.

Ważnym zadaniem resolver’a jest eliminowanie opóźnień w sieci i obciążeń name server’ów, poprzez odpowiadanie na podstawie danych zawartych w lokalnym cache’u. Cache jest wielodostępny przez różne procesy, komputery, użytkowników i bardziej efektywny od zwykłego jedno-dostępnego cache’a.

Sposób komunikowania się procesu-klienta z resolver’em zależy od konwencji lokalnych, ale musi spełniać trzy podstawowe funkcje:

  1. translacja nazwy komputera na jego adres Funkcja pochodzi jeszcze z czasów, kiedy wszystkie hosty były wpisywane do pliku HOSTS.TXT. Poprzez podanie ciągu znaków, wywołujący chce otrzymać w zamian jeden lub więcej 32-bitowych adresów IP. W DNS’ie takie żądanie jest interpretowane jako żądanie znalezienie właściwego rekordu RR typu A. Ponieważ DNS nie zachowuje porządku w rekordach, funkcja może posortować otrzymane adresy, lub wybrać „najlepszy”, jeżeli wymagane jest zwrócenie jako wyniku operacji tylko jednego adresu klientowi. Chociaż podanie wielu adresów może być pożądane, to jednak jedynym sposobem na zachowanie kompatybilności z serwisem z czasów HOSTS.TXT jest podanie tylko tego „najlepszego”.
  2. translacja adresu host’a na jego adres Bardzo często takie zgłoszenie podąża za pierwszym typem. Podając 32-bitowy adres IP chcemy uzyskać informację o nazwie komputera w postaci ciągu znaków. Oktety adresu IP są odwróconej kolejności i uzupełnione przyrostkiem „.in-addr.arpa”. Do tego celu używa się zapytania typu PTR, by uzyskać odpowiedni rekord zawierający główną nazwę host’a. Przykładowo, zgłoszenie odszukania nazwy komputera o adresie IP 149.156.96.9 powoduje, iż szukany jest rekord PTR o wartości „9.96.156.149.in-addr.arpa”.
  3. funkcja ogólnego lustrowania (general lookup) Pobiera informacje z DNS’u i nie ma odpowiednika w poprzednich funkcjach. Dostarczane są QNAME, QTYPE i QCLASS, a potrzebne są wszystkie pasujące rekordy RR. Ta funkcja często wykorzystuje format DNS do pobrania wszystkich rekordów, bez względu na przyjęte lokalnie konwencje.

Niezależnie od funkcji i wyniku przeszukiwania, resolver zawsze zwraca rezultaty klientowi przesyłając:

  • Jeden lub więcej rekordów RR zawierających dane żądane przez klienta. W tym wypadku odpowiedź formułowana jest w odpowiednim dla klienta formacie.
  • Błąd nazwy (name error) Dzieje się tak wtedy, gdy nazwa, o którą pytano nie istnieje. Może być to np. spowodowane pomyłką przy wpisywaniu nazwy host’a.
  • Błąd danych (data not found error) Zdarza się tak w przypadku, gdy nazwa istnieje, lecz dane o które chodzi – nie. Przykładowo, funkcja zwracająca adres komputera w skrzynce pocztowej zasygnalizuje taki błąd, jeżeli nazwa istnieje, lecz nie ma rekordu zawierającego jej adres.

 

Może się zdarzyć, iż nazwa na którą natrafi resolver jest aliasem. Np. sytuacja, w której resolver po podaniu nazwy host’a i wykonaniu translacji na adres, otrzymuje alias znaleziony w rekordzie CNAME. Resolver powinien zwrócić alias klientowi jako wynik., jednak wwiększości przypadków ponawiane jest przeszukiwanie już dla aliasu. W przypadku gdy resolver wykonuje tylko funkcję lustrowania (lookup) nie pożądane jest by szedł śladem aliasu, jeżeli zapytanie zgadza się z rekordem CNAME. Pozwala to na sprawdzenie czy jakiś alias w ogóle się znajduje. Przykładem takiego zapytania typu CNAME może być sytuacja, w której użytkownika nie interesuje gdzie rekord CNAME wskazuje (w przypadku aliasu), ale sama jego zawartość.

Należy jednak zachować szczególną ostrożność przy konstruowaniu aliasów. Wielostopniowe aliasy są nieefektywne i powinno się ich unikać, choć z drugiej strony resolver nie powinien ich sygnalizować jako błędu. Natomiast zapętlone aliasy (alias loops) lub aliasy wskazujące do nieistniejących nazw powinny sygnalizować klientowi błąd.

W przypadku, gdy resolver nie jest w stanie wykonać resolving’u, nie powinien być sygnalizowany błąd nazwy lub błąd danych programowi, który zlecił wykonanie jednej z funkcji. Może być wiele przyczyn powodujących chwilowe niemożności poprawnego spełnienia żądania obsługi. Resolver może zostać odseparowany od reszty sieci z powodu np. utraty połączenia, problemów z gateway’em lub nawet przez przypadkowy błąd lub nieosiągalność wszystkich serwerów w domenie.

Zalecanym rozwiązaniem w takich sytuacjach jest zaimplementowanie błędu tymczasowego jako jednej z funkcji. Nie jest zalecane rozwiązanie, w którym żądanie obsługi jest blokowane – a co za tym idzie, blokowany jest program użytkownika.

Reklamy