Słowem wstępu o serwisie DNS

Nikogo nie trzeba przekonywać jak kluczową rolę w życiu internetu pełnią serwisy DNS. Cisi bohaterowie wykonują swoje funkcje bezszelestnie pozostając w cieniu i zapewniając poprawne rozwiązywanie nazw oraz adresów.

Pozornie rola i konfiguracja serwisów jest prosta, jednak przed wnikliwymi administratorami otwiera się znacznie więcej możliwości w zakresie konfiguracji i zarządzania usługą.

W tym miejscu warto wspomnieć, że usługa DNS jest jedną z kilku kluczowych ról w sieciach komputerowych wraz z usługą adresacji automatycznej DHCP oraz że usługi te są ze sobą blisko powiązane.

Czym jest DNS – najprościej rzecz biorąc jest to usługa która tłumaczy adresy IP v4 oraz IPv6 na nazwy zrozumiałe dla Kowalskiego. Gdyby nie ona wchodząc na stronę google.com  w przeglądarkę wpisywalibyśmy http://216.58.215.110, ewentualnie http://[2a00:1450:401b:803::200e]:80 zamiast poczciwego http://google.com. Warto pamiętać, że DNS działa także w drugą stronę – przy użyciu tzw. stref zwrotnych potrafi rozpoznać adres IP i zwrócić nazwę domenową.

Ponieważ zapamiętywanie stron internetowych w postaci adresów IP byłoby raczej mozolną sprawą warto przyjrzeć się serwerom DNS ciut bliżej. Sam serwis może zostać postawiony w oparciu  o dowolny system. Może być to np. Linuksowy demon bind9 nazywany named; może być to usługa DNS Server systemu Windows Server, bądź też zupełnie osobny produkt (!) stawiany jako virtual appliance lub nawet urządzenie fizyczne!

Z punktu widzenia przeciętnego zjadacza chleba rola DNSów kończy się na powyższej formułce; administratorzy serwerów/DDI mają jednak znacznie więcej na głowie i nie chodzi tu bynajmniej o konfigurowanie prostej usługi DNS.

Te bowiem polega na konfigurowaniu np. w przypadku BINDa pliku named.conf i kreowaniu w nim stref/zon np. google.com oraz stref zwrotnych o zawrotnej nazwie <pisany-od-tyłu-adres-sieci>.in-addr.arpa, by następnie kreować właściwe pliki stref zawierające rekordy.  Posłużmy się przykładem. Nasza firma posiada własną domenę lubieplacki.corp. Posiada także własny serwer DNS na który po zakupie domeny oddelegowano zarządzenie <zaparkowano domenę>.  Na serwerze DNS musi więc istnieć skonfigurowana strefa oraz konfiguracja rekordów domeny.  Ale tym w szczegółach zajmiemy się w kolejnej odsłonie boju DNS.

Na początek warto wiedzieć, że każda strefa posiada swój rekord identyfikacyjny stanowiący swoistą nalepkę na domenę (rekord SOA). W rekordzie SOA znajdują się różne tajemnicze wartości czasów (TTL) które mówią po jakim czasie rekordy domeny mają się przeterminować i powinny zostać zapomniane przez klientów a następnie pobrane od nowa. Trzeba bowiem wiedzieć, że z uwagi na dynamikę zmian w nazewnictwie DNS nie jest usługa statyczną jak pomnik z czasów epoki słusznie minionej.  Z drugiej strony nie może być także w pełni dynamiczna bo ilość zapytań o np. google.com w ciągu sekundy na całym świecie zapchałaby nawet serwery DNS firmy G.

Skorzystano więc z mechanizmu cache’owania nazw gdzie się tylko da. Tak oto rekordy cacheowane sa zarówno po stronie naszego klienta który odpala przeglądarkę (resolver),  jak również wszelkich serwerów DNS pośredniczących w rozwiązywaniu nazwy.  Owe czasy w rekordzie SOA mają więc pomóc w wyczyszczeniu danych o nazwie z wszystkich cache’ów co jest niezbędne bo strony www (szczególnie takie które są osadzone na balansowanych serwerach WWW i zwracane użytkownikowi algorytmem roundrobin / ew randomowo) często zmieniają adres IP. Gdyby nie istniał cache raz zapamiętana referencja strona www <–> adres IP istniałaby wiecznie, nawet jak strona umrze, domena wygaśnie albo zostanie relokowana pod inny adres.

No dobrze, ale zanim wrócimy do naszego SOA musimy sobie odpowiedzieć na pytanie:  jak odbywa się rozpoznawanie nazwy np. przez przeglądarkę? Prosta sprawa. Nasz komputer posiada skonfigurowany adres serwera DNS – w domu będzie to najczęściej serwer DNS ISP (dostawcy), a w firmie – firmowy DNS.  Odpalamy przeglądarkę, wpisujemy www.kubraczekdlapsa.net  i przeglądarka, zwana resolverem, kontaktuje się z najbliższym lub skonfigurowanym wprost w ustawieniach karty sieciowej serwerem DNS w poszukiwaniu upragnionej strony. Nasz serwer DNS ma za zadanie przeprowadzić cały proces rozpoznania nazwy i wrócić z tarczą albo na tarczy – proces ten zwany jest zapytaniem rekursywnym. Niestety nasz serwer DNS nic nie wie o tej stronie – nikt inny z naszej sieci nie próbował się na nią dostać więc nie ma jej w cache serwera. Serwer musi się więc skontaktować z innymi serwerami DNS żeby zdobyć więcej informacji. W tej sytuacji odpytywane są serwery tzw. root (czyli po prostu najwyższe główne serwery DN na świecie). Rozbijają naszą nazwę na części i mówią coś w stylu: nie mam pojęcia co to jest www.kubraczekdlapsa.net, ale wiem jaki serwer DNS odpowiada za część „.net” – oto jego adres. Nasz serwer kontaktuje się z serwerem który odpowiada za część .net z kolejnym pytaniem o całą nazwę. Podobnie jak root DNS serwer odpowiada, że nie wie jaki jest adres dla naszej requestowanej nazwy, ale ma w swoich rekordach „.net” zarejestrowaną nawę serwera dla kubraczekdlapsa. Nasz lokalny DNS zwraca się więc z zapytaniem do serwera odpowiedniego dla kubraczekdlapsa.net i tym razem uzyskuje adres IP dla rekordu www znajdującego się w kubraczekdlapsa.net i ten oto adres zostaje zapisany w cache wszystkiego po drodze i zwracany jest do resolvera – przeglądarki, która otwiera upragnioną stronę.

Tu warto dodać, że o ile nasz pierwszy serwer DNS odpowiada za rozwiązanie nazwy od A do Z i zwrócenie gotowego wyniku, o tyle serwery pośredniczące zwracają tylko wynik częściowy (iteratywny).  Wynika to z konieczności optymalizacji i hierarchizacji DNS – inaczej serwery wysokiego szczebla byłyby najbardziej obciążone.

W kolejnej odsłonie przedstawię DNS w szczegółach.

 

Dodaj komentarz