Jednym z istotnych elementów codziennego zarządzania, czy samej nauki zarządzania strefą DNS (bazą danych przechowującą konfigurację dla danej domeny DNS) jest nabycie umiejętności posługiwania się narzędziami służącymi do diagnostyki, wyszukiwania problemów, w (s)konfigurowanej przez nas strefie DNS.

Czyli problem, który zakładamy, że mamy, jest na przykład taki:
– Skonfigurowałem w mojej strefie DNS rekord typu MX (na potrzeby poczty serwera poczty elektronicznej). Jak ja mam się teraz dowiedzieć, czy on wogóle (ten rekord) działa, i może być prawidłowo rozwiązywany przez aplikacje pocztowe?
– Zmieniłem nakierowanie domeny używanej dla strony internetowej, na nowy inny adres IP (bo przerzuciliśmy tą stronę na inny serwer), i dzwonił tam Pan przed chwilą, że u niego strona przestała działać (a u mnie jakoś jak patrzyłem działa). To co się dzieje, że jemu nie działa, a mi tak?
– i wiele wiele innych podobnych…
i dlatego też właśnie musimy znaleźć i opanować, jakieś narzędzie służące do diagnostyki konfigurowanej strefy DNS.

Jednym z bardziej znanych tego typu narzędzi jest aplikacja nslookup, która jest wbudowana w każdy system operacyjny MS Windows (choć już niekoniecznie w system GNU/Linux, ale o tym za chwilę).

Najistotniejszą zaletą narzędzia nslookup jest to, że pozwala na wysłanie do dowolnego wskazanego serwera DNS, prośbę o zwrócenie wskazanego typu rekordu dla wskazanej nazwy DNS. Tylko tyle, i aż tyle…
Także dzięki temu narzędziu, możemy wysłać zapytanie, coś w stylu tak, jak byśmy chcieli się dowiedzieć, czy Wojtek potrafi się dodzwonić na wskazany numer telefonu, a jak się już dodzwoni, to również kto mu się tam odzywa po odebraniu tego telefonu.

Oczywiście, korzystanie z narzędzia nslookup, wymaga posiadania w miarę dobrej wiedzy teoretycznej dotyczącej logiki działania protokołu DNS, i ten artykuł nie ma na celu omawiania złożoności działania systemu DNS. Aczkolwiek osoby, które chciałyby poszerzyć swoją wiedzą dotyczącą zasad działania systemu rozwiązywania nazw DNS, zapraszamy na poniższy cykl na kanale YouTube, który to zresztą tenże artykuł ma też na celu wspomagać:

 

 

A nie mogę wykorzystać zwykłego ping’a do diagnostyki DNS?

Fakt, co niektórzy, do diagnostyki DNS wykorzystują aplikację ping. A niby jak? Szybki przykład:

Załóżmy, że skonfigurowaliśmy właśnie na potrzebę nowej witryny internetowej, nowy rekord typu A dla nazwy „google.pl” (tak, wiem, że istnieje już i jest zajęta 🙂 ) nakierowany na adres IP serwera, na którym ta strona ma być ulokowana. Teraz więc chcielibyśmy sprawdzić, czy na komputerach będzie ta domena w sposób prawidłowy już rozwiązywana na właściwy adres IP. Wtedy więc wystarczy wykonać ping na tenże adres DNS jaki skonfigurowaliśmy (czyli „google.pl”):

i jak można zauważyć na powyższym zdjęciu, wykonaliśmy ping na adres „google.pl”, po czym widać, że tenże adres domenowy został rozwiązany na adres IP: 216.58.201.99.  Czyli sumarycznie udało nam się zweryfikować prawidłowe rozwiązywanie nazwy na adres IP (zakładamy, że na taki adres IP faktycznie chcieliśmy tą domenę nakierować).

Cóż, w pewnym zakresie jak widać to niby działa, i nie neguję też żeby nie było wogóle logiki wykorzystania ping’a (bo czasem szybko uzyskujemy z nim jednak to co potrzebujemy), aaaaale w praktyce to jednak nam to narzędzie pomoże tylko w niewielkim zakresie… Dlaczego? Gdyż aplikacja ping wysyła prośbę o zwrócenie konkretnie rekordu A/AAAA dla wskazanej nazwy, żeby wiedzieć, jakie urządzenia, o jakim adres IP ma „pingować”.
Tak więc powstaje w tym momencie pytanie: a co z pozostałymi typami rekordów (MX, NS, SOA, SRV, itd.)? Kiiiiiiszka.
A po drugie, zakłada też (szczególnie, gdy chcemy realizować diagnostykę tzw. lokalnych domen DNS), że jednak najpierw musielibyśmy skonfigurować w naszym systemie w danych adresowych TCP/IP:

wykorzystywanie (i to jako preferowany, a nie alternatywny) adresu IP serwera DNS, tego, do którego chcemy wysyłać w ramach testów zapytania – no i tu właśnie wtedy jest kolejny duży problem. Gdyż może chcemy wysłać do danego wskazanego serwera DNS zapytania na potrzeby diagnostyki, ale wcale nie chcemy, a nawet to nie jest często wcale takie proste, aby w pełni korzystać z tegoż serwera DNS do rozwiązywania nazw (ja osobiście np. korzystam z DNS over HTTPS, i tu zmiana preferowanego serwera DNS we właściwościach TCP/IP na jakiś dowolny, wcale nie jest aż taką szybką i prostą sprawą…).
Aby trochę lepiej może powyższe zrozumieć: to tak, jakbyśmy chcieli przez jakiś czas potestować pewne wybrane produkty w pewnym sklepie, i aby to zrobić, to musimy jednak wszystkie zakupy jakie robimy, do momentu aż skończymy testowanie tych wybranych produktów, robić właśnie w tym sklepie, i tylko w tym sklepie… Także czasem może i chcę potestować wybrane produkty, ale to nie znaczy, że kompletnie wszystko chcę kupować w tym sklepie. A i może się okazać, że mam umowę na wyłączność z innym sklepem, w którym realizuję obecnie swoje wszystkie zakupy, i chciałbym może potestować te produkty, ale nie mogę po prostu tak całkiem sklepu zmienić…

Dlatego też w praktyce okazuje się, że tego typu narzędzie jak nslookup, jest nieocenione w codziennej pracy z serwerami DNS…

 

 

To gdzie można znaleźć, i jak zainstalować narzędzie nslookup?

Jeżeli chodzi o system MS Windows, to narzędzie to jest wbudowane w tenże system, i nie trzeba robić nic, aby móc z niego korzystać, tylko no właśnie… nauczyć się z niego korzystać 🙂

Inaczej sprawa wygląda, jeżeli chodzi o systemy GNU/Linux, gdyż tutaj w praktyce konieczne doinstalowanie jest odpowiedniego pakietu z repozytorium.
W tym celu należy wykonać w wierszu poleceń polecenie (zależnie od wersji dystrybucji jaką posiadamy):

## Dla CentOS, RHEL ##
yum install bind-utils

## Dla Fedora ##
dnf install bind-utils

## Dla Debian, Ubuntu ##
apt update
apt install dnsutils

Po zainstalowaniu powyższego odpowiedniego pakietu narzędzie nslookup powinno być dostępne do użytku.
Czy wersje dla Linux’a i Windows się różnią? Niestety troszeczkę tak… W Linux’ie jest troszeczkę nowsza wersja tego narzędzia, dzięki czemu dostajemy np. możliwość rozwiązywania nazw z obsługą DNSSEC’a (co fakt, nie działa to i tak, tak fajnie, jak w narzędziu dig, ale jednak mimo wszystko można tu wskazać prośbę o zwrócenie wskazanych rekordów DNSSEC’owych, a w wersji Windows nie). Niestety mnie osobiście nie udało się sprawnie znaleźć sposobu na „aktualizację” nslookup w Windows do „nowszej” wersji. I szybciej zwyczajnie było mi sobie wgrać inne alternatywne narzędzie jakim jest dig (ale to narzędzie to już temat na inny kolejny odcinek), albo uruchamiam szybciutko Linux’a w ramach mechanizmu Windows Subsystem for Linux (co też jest tematem na inny osobny odcinek), gdzie mam zainstalowany i dig i nslookup.

 

 

Tryb interaktywny oraz nieinteraktywny

Na początek warto wiedzieć, że nslookup działa w 2 trybach – interaktywnym i nieinteraktywnym. W trybie „interaktywnym”, uruchamiamy nslookup, i tenże jest jakby uruchomiony przez cały czas, a my podajemy już mu tylko w kolejnych krokach, jakie akcje chcemy, aby wykonywał. W trybie „nieinteraktywnym” po prostu dla każdej akcji, musimy z osobna wywołać aplikację nslookup z odpowiednimi parametrami. Poniżej będą pokazane przykłady w obydwu trybach, aby zobaczyć różnicę między nimi, także myślę, że szybko się zrozumie różnicę między nimi, która jest niewielka.

Na pytanie: który z tych trybów jest lepszy? Nie ma dobrej odpowiedzi: jedni lubią lody śmietankowe, a inni waniliowe…

 

 

Zwykłe rozwiązywanie nazwy DNS na adres IP z wykorzystaniem nslookup

To na początek zabaw z nslookup, wróćmy do przykładowego problemu początkowego, do którego użyliśmy wcześniej narzędzia ping, czyli założenia, że skonfigurowaliśmy właśnie na potrzebę nowej witryny internetowej, nowy rekord typu A dla nazwy „google.pl” orazwww.google.pl” (tak tak, znowu wiem, że istnieje już i jest zajęta ta domena 🙂 ) nakierowany na adres IP serwera, na którym ta strona ma być ulokowana.

Aby wysłać prośbę o zwrócenie rekordu A/AAAA dla wskazanej nazwy, w naszym przykładzie niech będzie www.google.pl (potocznie by niektórzy powiedzieli np. „aby znaleźć adres IPv4/IPv6 hosta www.google.pl„), przez serwer DNS jaki aktualnie jest wykorzystywany przez nasz system do rozwiązywania nazw (czyli tzw. „rekursywyny resolver” – tak strasznie to się nazywa akurat, ale to nie ja wymyślałem tą nazwę), należy uruchomić wiersz poleceń i wpisać (dla trybu nie-interaktywnego):

nslookup www.google.pl

przykładowo:

gdzie widać wydanie polecenie z prośbą o zwrócenie rekordu typu A oraz AAAA dla nazwy www.google.pl, po czym nslookup wskazuje, że wysłał zapytanie do serwera DNS (resolwera rekursywnego) pod adresem IP 103.86.99.99 (gdyż taki aktualnie wykorzystuje nasz system operacyjny do rozwiązywania nazw – jest skonfigurowany aktualnie jako preferowany serwer DNS), a tenże serwer DNS odesłał odpowiedź, że wskazana nazwa jest nakierowana na adres IPv4 172.217.17.227 oraz IPv6 2a00:1450:4016:80c::2003 (czyli „wujek google” wychodzi też na to, że ma wdrożone IPv6 😉 – co też jest jakąś interesującą informacją diagnostyczną).

 

W trybie interaktywnym, adekwatnie dla powyższego przykładu, wpisujemy polecenie nslookup, a następnie jak przejdziemy do trybu interaktywnego i widzimy znak „>” zachęcający do wprowadzania poleceń, wpisujemy nazwę „www.google.pl„, a na końcu, jak już dostaniemy odpowiedź z serwera DNS, to aby wyjść z tegoż trybu interaktywnego, wpisujemy parametr „quit”:

 

 

 

Rozwiązywanie w ramach wyszukiwania wstecznego dla wskazanego adresu IP (zapytanie o rekord PTR)

Adekwatnie jak dla wcześniejszego przypadku dotyczącego rozwiązywania rekordu A/AAAA dla strefy wyszukiwania do przodu, tak na podobnej zasadzie można wysłać zapytanie o zwrócenie rekordu PTR.

Dla trybu nie-interaktywnego:

 

 

oraz dla trybu interaktywnego:

 

 

 

A jak zmienić typ rekordu dla wysyłanego zapytania?

Narzędzie nslookup, jak powyżej można było zauważyć, domyślnie (jeżeli jawnie nie wskażemy) wysyła zapytania o rekordy A/AAAA (lub PTR jeżeli podamy adres IP, a nie nazwę DNS).

Możemy jednak wysłać zapytanie o dowolny inny wybrany typ rekordu. Wtedy w trybie interaktywnym uruchamiamy parametr „set type=”, gdzie po znaku „=” należy podać wybrany przez nas typ rekordu (zakładamy, że dobrze sami wiemy jakie typy rekordów istnieją, i o jakie więc typy chcemy pytać 😉 ), natomiast w trybie nie-interaktywnym użycie parametru jest podobne, tylko wskazujemy go po myślniku „-type=„, a potem podajemy wybrany przez nas typ rekordu.

 

Przykładowo dla trybu interaktywnego:

  • set type=ns – spowoduje wysłanie prośby o zwrócenie rekordów NS obsługujących wskazaną domenę DNS (tj. zwróci nam adresy wszystkich serwerów DNS, które utrzymują tzw. strefę, czyli bazę danych z konfiguracją danej domeny DNS):
  • set type=mx – spowoduje wysłanie prośby o zwrócenie rekordów MX dla wskazanej domeny DNS, używanych na potrzeby poczty elektronicznej (tj. zwróci nam de facto adresy serwerów SMTP obsługujących pocztę dla danej danej domeny):
  • itd.

 

Przykładowo dla trybu nie-interaktywnego:

  • -type=ns – spowoduje wysłanie prośby o zwrócenie rekordów NS obsługujących wskazaną domenę DNS (tj. zwróci nam adresy wszystkich serwerów DNS, które utrzymują tzw. strefę, czyli bazę danych z konfiguracją danej domeny DNS):
  • -type=mx – spowoduje wysłanie prośby o zwrócenie rekordów MX dla wskazanej domeny DNS, używanych na potrzeby poczty elektronicznej (tj. zwróci nam de facto adresy serwerów SMTP obsługujących pocztę dla danej danej domeny):
  • itp. (dla innych typów rekordów)

 

 

 

A gdybym tak chciał wysłać zapytanie do wskazanego przeze mnie serwera DNS (bez zmiany w systemie operacyjnym domyślnego serwera DNS)?

Jak już było wspominane na początku artykułu, nslookup używa domyślnie do wysłania generowanych przez nas zapytań, serwera DNS, który jest w naszym systemie operacyjnym skonfigurowany w ramach konfiguracji danych adresowych interfejsu sieciowego, jako „preferowany”.

Powstaje więc pytanie, jak możnaby wysłać zapytanie do wybranego przez nas serwera DNS (aby dzięki temu zobaczyć, jak ten konkretny wskazany przez nas serwer DNS, rozwiąże wysłane przez nas zapytanie), bez oczywiście modyfikowania ustawień konfiguracyjnych interfejsu sieciowego naszego komputera (bo nie możemy, czy bądź nie chcemy). Czyli coś na zasadzie: Tak, codziennie korzystam z telefonu Samsung Galaxy Sx, i wiem jak na nim to coś wygląda, ale chciałbym tak zobaczyć, jak na Xiaomi x to będzie wyglądało, a nie chcę całkowicie w tej chwili na Xiaomi x przechodzić, aby to zobaczyć.

 

W trybie interaktywnym można wykorzystać do tego celu parametr „server {adres IP}„, po czym zostaniemy poinformowani o zmianie serwera DNS używanego do wysyłanych zapytań, a następnie możemy już tworzyć i wysyłać interesujące nas zapytania o dane typy rekordów dla danych nazw DNS:

Przykładowo:

 

W trybie nie-interaktywnym wystarczy po nazwie, dla której chcemy wysłać zapytanie, podać adres serwera DNS, do którego chcemy wysłać to zapytanie.

Przykładowo:

 

 

Jak mogę rozpoznać błędną konfigurację w zwracanych odpowiedziach przez nslookup?

nslookup używamy w pierwszej mierze, aby sprawdzić, czy stworzony przez nas rekord w strefie DNS jest rozwiązywany w sposób prawidłowy przez aplikacje na urządzeniach. I widzieliśmy już powyżej przykłady prawidłowo rozwiązanych zapytań o wskazane nazwy.
Ale teraz powstaje pytanie: A jak w sumie mam rozpoznać, że odpowiedź jaką pokazał mi nslookup, wskazuje właśnie jednak na jakieś problemy z wykonaną przeze mnie konfiguracją?

Spróbujemy w tym celu zerknąć teraz na kilka przykładów z życia wziętych. Przy czym używać będziemy teraz już tylko trybu nie-interaktywnego, aby nie mnożyć tego samego przykładu razy x, a mam nadzieję, że po poprzednich przykładach udało się załapać różnicę między tymi trybami, i jak niewielka ona w sumie jest.

 

Na początek załóżmy, że chcemy wysłać zapytanie z prośbą o zwrócenie rekordu typu A, dla nazwy „12345.google.pl„. I nagle okazuje się, że nslookup zwraca nam takową następującą odpowiedź:

jak można zauważyć w drugim zaznaczeniu, nslookup wskazuje „Non-existent domain”, co oznacza: próbowałem znaleźć ten rekord dla tej domeny, ale on niestety nie istnieje…
Skąd taka sytuacja? A tu już powodów może być wiele, aczkolwiek pierwszy najczęstszy zaraz jaki się nasuwa, to na przykład błędnie (z literówką) wpisana nazwa domeny w strefie DNS (np. 1234.google.pl zamiast 12345.google.pl).

 

To teraz zerknijmy na inną, dość dziwacznie prezentowaną informację zwracaną przez nslookup, po wysłanym zapytaniu z prośbą o zwrócenie rekordu typu SRV dla nazwy google.pl„:

Co w tym dziwnego? Ano to, że ja wysłałem przecież zapytanie o rekord SRV, a nslookup pokazuje mi rekord… typu SOA…
Także: „halo, halo, ale ja nie o to pytałem”.

W ten sposób paradoksalnie nslookup mówi nam, że niestety nie ma takiego rekordu dla tej nazwy o którą pytaliśmy, a tu w razie czego masz rekord SOA, dzięki któremu dowiesz się jaki jest mail do admina zarządzającego tą strefą DNS, czy jaki jest adres podstawowego serwera DNS obsługującego tą strefę (bo może warto do niego bezpośrednio, jako do źródła, zadać też to pytanie – w końcu jak on nie będzie potrafił nam udzielić odpowiedzi, to znaczy, że wina jest u niego, a nie dlatego, że ktoś gdzieś coś przekłamał po drodze…, i wtedy przyda się ten mail do admina zarządzającego tą strefą).

 

Jeszcze z jednym ciekawym błędem możemy się spotkać.
Przykładowo, próbujemy wysłać zapytanie z prośbą o zwrócenie rekordów typu NS dla nazwy „google.pl„, ale skierowane do serwera DNS pod adresem 1.1.1.1 (tj. tzw. CloudFlare):

no i widzimy nagle „DNS request timed out„.

To oznacza, że nslookup próbował wysłać nasze zapytanie pod wskazany adres, ale… tam się nikt nie odzywa pod tym adresem, także nie bardzo ma jak nas obsłużyć.
Skąd to się może wziąć? Bo tego sklepu, gdzie miał iść zrobić zakupy, albo tam wcale nie ma, albo jest zamknięty, albo nie można się do niego dostać (bo ktoś nam blokuje dostęp – zapora ogniowa na przykład). I oczywiście, że nie sklepu, a… serwera DNS 🙂

 

 

 

 

A jak wyszukiwać problemy wynikające z mechanizmu buforowania zapytań (TTL) w pamięci podręcznej serwerów DNS?

TTL (Time To Live) dla rekordów DNS, to czas życia danego rekordu DNS’owego w pamięci podręcznej, czy to klienta DNS, czy to serwera DNS, który tenże rekord otrzymał w ramach wysłanego zapytania. Czas ten w praktyce definiuje, jak dużo czasu minie, zanim wszystkie urządzenia, po dokonanej przez nas zmianie ustawień tegoż rekordu w strefie DNS, „zobaczą” już tą zmianę.

Załóżmy więc, że we wcześniejszym przytaczanym przykładzie nowej witryny internetowej udostępnionej pod adresem google.pl, zmieniliśmy serwer, na którym ta strona jest udostępniona, a tym samym zmieniliśmy w rekordzie typu A dla nazwy „google.pl” nakierowanie na nowy adres IP serwera, na którym ta strona jest teraz udostępniona.
Powstaje więc pytanie, czy wszyscy już zaraz po wykonanej przez nas zmianie łączą się z tą stroną, która jest teraz już na nowym serwerze (pod nowym adresem IP)?
Odpowiedź brzmi: Nie.
Gdyż właśnie stosowanie mechanizmu pamięci podręcznej wraz z czasem życia rekordów (TTL) powodują, że niestety niektóre serwery DNS oraz same urządzenia klienckie, posiadają jeszcze w swojej pamięci podręcznej DNS „stary” rekord, w którym jest „stary” adres IP. Stąd będą jeszcze wykorzystywać ten „stary” rekord i „stary” adres IP.
A jak długo?
To już zależy, jak dawno temu ten serwer DNS, czy urządzenie klienckie, pobierało tenże rekord DNS (najbardziej pesymistyczna wersja, to na sekundę przed wykonaną przez nas zmianą konfiguracji tego rekordu w strefie DNS). Także musimy założyć, że musimy poczekać max. tyle, ile wynosi ustawiony przez nas w strefie czas TTL dla tegoż rekordu.

 

OK, trochę sobie w duużym skrócie przypomnieliśmy logikę działania mechanizmu TTL dla rekordów DNS (tu w razie czego zachęcam do skorzystania z cyklu na kanale YouTube podlinkowanym na początku artykułu). To teraz możemy wrócić do problemów z nim związanych, i wykorzystaniem nslookup do ich rozwiązywania.

Na początek chcielibyśmy się dowiedzieć na przykład, jaki ktoś skonfigurował domyślny czas TTL dla wszystkich rekordów w zarządzanej przez siebie strefie domeny DNS. Ktoś, czyli oznacza to, że to nie jest strefa DNS zarządzana przez nas, a przez kogoś innego. Ale jednak (bo np. chcemy komuś udowodnić, dlaczego u niego, po dokonanej przez niego konfiguracji w tej jego strefie DNS, działa strona www już pod nowym zmienionym adresem, a innym, w tym nam, niekoniecznie) chcielibyśmy się dowiedzieć, jaki jest domyślny czas życia rekordów TTL w strefie wskazanej przez nas domenie DNS.

W tym celu wystarczy za pomocą narzędzia nslookup wysłać zapytanie o rekord SOA (czyli wykorzystujemy parametr -type=soa) wskazanej domeny DNS.
Przykładowo:

i widzimy, że dla domeny DNS „google.pl” domyślny czas życia rekordów w tej strefie DNS to 1 minuta (czyli tu trzeba przyznać całkiem mało, i szyyyybko wszyscy się przełączą na zmieniony adres w rekordzie A, aczkolwiek też trzeba pamiętać, że ma to swoje konsekwencje – więcej zapytań, a więc i więcej czasu procesora wykorzystanego, oraz przepustowości łącza).

 

Aczkolwiek też należy pamiętać, że to, iż domyślny czas TTL dla rekordów w strefie jest akurat taki, to nie znaczy, że dla zadanego wybranego rekordu też będzie taki sam, gdyż każdy rekord może mieć skonfigurowany inny niż domyślny, swój własny czas życia rekordu TTL (a jak nie ma, to wtedy właśnie przyjmowany jest ten domyślny czas TTL).
Stąd powstaje teraz na przykład pytanie: To jak sprawdzić jaki jest faktyczny czas życia TTL dla zadanego rekordu (bo w końcu doszliśmy, że jednak może się różnić od domyślnego)?

W tym celu musielibyśmy najpierw dowiedzieć się, jaki jest adres autorytatywnego serwera DNS dla strefy, w której znajduje się rekord, jaki na interesuje.
Au, au, co????
Autorytatywny serwer DNS to de facto ten, który utrzymuje strefę DNS dla danej domeny, i nieważne, czy jest to serwer nadrzędny, czy podrzędny. Ważne jest to, iż ten właśnie może nam zwrócić odpowiedź autorytatywną, czyli nie obarczoną błędem wynikającym z wcześniej omówionego mechanizmu buforowania rekordów w pamięci podręcznej serwerów DNS. Gdyż jeżeli wysyłamy nasze zapytanie do „nieważne jakiego serwera DNS” (takiego, który nie utrzymuje strefy dla domeny DNS, z której rekord chcemy uzyskać), to serwer ten jest określany wtedy jako nieautorytatywny, ponieważ odpowiedź może zostać wzięta z pamięci podręcznej tegoż serwera (jeżeli tam się znajdowała), a to oznacza, że jeżeli akurat przed chwilą administrator tej strefy zmienił konfigurację tego interesującego nas rekordu, to my jednak dostaniemy ten „stary” jeszcze rekord (czyli ta odpowiedź jest jednak obarczona jakimś możliwym ryzykiem błędu, a z serwera autorytatywnego nie).

Jak już wiemy o co mniej więcej chodzi z serwerem autorytatywnym, to musimy się dowiedzieć, jakie są adresy serwerów autorytatywnych dla interesującej nas strefy. Jak tego dokonać? Ano wysyłając zapytanie z prośbą o zwrócenie rekordów NS dla tej interesującej nas strefy, tj. listy adresów serwerów DNS utrzymujących strefę dla tej domeny DNS.

Przykładowo, dla omawianej już wcześniej domeny „google.pl”, zapytanie to wyglądałoby następująco:

czyli zostały nam zwrócone 4 adresy serwerów DNS, które utrzymują tą strefę.

Teraz wystarczy, wysłać do któregokolwiek z nich (ale jednak dokładnie któregoś z nich) zapytanie z prośbą o zwrócenie interesującego nas rekordu, dodając do polecenia nslookup parametr „-debug” (pokazujący odpowiedzi z rozszerzonymi informacjami, w tym czasem TTL).

Przykładowo, dla rozpatrywanego wcześniej przypadku rekordu typu A nazwy „google.pl”, wyglądałoby to następująco:

gdzie w ramach odpowiedzi dotyczącej interesującego nas (i wskazanego w zapytaniu) rekordu A, można zauważyć, że czas TTL wynosi 300 sekund (5 minut), czyli taki jest dokładnie czas życia rekordu A dla nazwy „google.pl” – a jeżeli wrócimy i przeanalizujemy wcześniejsze rozważania, to zobaczymy, ze domyślne TTL dla tej strefy wynosiło 1 minutę, czyli jednak wyszło, że czas życia tego rekordu A dla nazwy „google.pl” jest inny, niż ten domyślny 🙂

Ojej, wiem jaki jest domyślny czas życia rekordów w tej strefie, wiem jaki jest też dokładnie rekordu A dla nazwy „google.pl”. Tylko co mi to w sumie też mówi?

Ano, teraz na przykład możemy jakoś dowiedzieć się, z jakiego serwera DNS korzysta dana osoba na swoim urządzeniu (jak się o tym dowiedzieć, to hmm, inna kwestia, bo musimy to zrobić we współpracy z nią, prosząc ją o odczytanie takiej informacji zgodnie z naszymi wskazówkami). A jak już się dowiemy z usług którego serwera DNS ta dana osoba korzysta, to możemy się dowiedzieć, jak długo jeszcze ten interesujący nas rekord nazwy DNS będzie „przebywał” w pamięci podręcznej tegoż serwera DNS. Czyli za jaki czas, ta nieszczęsna strona tej osobie zacznie działać znowu normalnie 🙂

W tym celu musimy podobnie jak poprzednio, wysłać zapytanie z prośbą o zwrócenie interesującego nas rekordu, dodając do polecenia nslookup parametr „-debug” (pokazujący odpowiedzi z rozszerzonymi informacjami, w tym czasem TTL), ale już teraz zapytanie to ma być wysłane do serwera DNS, którego używa ten użytkownik do rozwiązywania nazw (taki ma skonfigurowany u siebie w systemie na interfejsie sieciowym, jako preferowany serwer DNS).

Przykładowo, dla rozpatrywanego wcześniej przypadku rekordu typu A nazwy „google.pl”, wyglądałoby to następująco, gdybyśmy wysłali to zapytanie do serwera DNS pod adresem 1.1.1.1:

gdzie w ramach odpowiedzi dotyczącej interesującego nas (i wskazanego w zapytaniu) rekordu A, można zauważyć, że czas TTL wynosi 87 sekund (1 minuta 27 sekund), czyli taki jest jeszcze dokładnie pozostały czas życia rekordu A dla nazwy „google.pl” w serwerze DNS 1.1.1.1. Z tego wynika, że można tej danej osobie powiedzieć, że musi jeszcze poczekać całą minutę i 27 sekund, i będzie już OK (choć tu w sumie jest jeszcze jeden możliwy problem, ale to wrócimy za chwileczkę do niego) 🙂

A jeżeli tak dla testów, wyślemy teraz szybko to samo zapytanie, ale do innego serwera DNS, na przykład 9.9.9.9 (Quad9):

to można zauważyć, że tu tenże rekord w pamięci podręcznej będzie jeszcze przechowywany przez 4 minuty i 8 sekund. Także, oczywiście, że ten czas będzie różny na różnych serwerach DNS, gdyż w różnych momentach ten rekord tam był przez nie pobierany i zapisywany do swojej pamięci podręcznej. A tylko serwer autorytatywny nie pokazuje czasu przez jaki będzie jeszcze przebywać rekord w pamięci podręcznej, gdyż nie ma takiej potrzeby, a pokazuje po prostu jaki jest tam ustawiony czas życia TTL tego rekordu.

 

Na koniec tej problematyki, jedna istotna sprawa jeszcze. Pamięć podręczną DNS posiadają nie tylko serwery DNS, ale również mogą ją posiadać klienci DNS (Windowsy domyślnie ją posiadają, a Linux’y nie co ciekawe). Stąd może się okazać, że i na serwerze DNS rekord znikł, ale to nie oznacza teoretycznie, że znikł również z pamięci podręcznej samego klienta DNS na naszym urządzeniu.
Jak się o tym dowiedzieć wtedy?
Wykonując na naszym urządzeniu klienckim (z systemem Windows, gdyż Linux’y nie posiadają domyślnie pamięci podręcznej DNS przypominam) polecenie:

i możemy zauważyć na powyższym przykładzie, że czas przez jaki jeszcze będzie przechowywany rekord A nazwy „google.pl” w pamięci podręcznej naszego systemu, to 293 sekundy (w praktyce niestety rekordów w pamięci podręcznej jest baaaardzo dużo, więc troszkę poszukamy, ale są na szczęście poukładane alfabetycznie).

Co istotne i ciekawe, to możemy ten czas oczekiwania przyspieszyć, wyczyszczając całą pamięć podręczna klienta DNS w naszym systemie, wykorzystując do tego celu poniższe polecenie:

 

 

A gdybym tak się chciał dowiedzieć jakie adresy serwerów DNS utrzymujących strefę mojej domeny DNS są skonfigurowane/wpisane w  serwerach DNS operatora tej mojej domeny DNS?

Załóżmy, że mamy wykupioną i zarejestrowaną domenę DNS w publicznym systemie DNS. Wtedy, w szczególności, gdy utrzymujemy strefę DNS na swoich własnych serwerach DNS (a nie na serwerach DNS rejestratora/pośrednika u którego zakupiliśmy domenę), to mogą się pojawić sytuacje (np. gdy zlecamy zmianę adresów naszych serwerów DNS utrzymujących strefę, a wpisanych u operatora tej domeny), w których chcielibyśmy się dowiedzieć, jakie więc dokładnie w tej chwili są wskazywane na tych serwerach DNS operatora adresy IP serwerów DNS, które obsługują strefę naszej domeny DNS.

Stąd teraz spróbujemy zobaczyć, jak za pomocą narzędzia nslookup możemy się właśnie dowiedzieć, jakie adresy serwerów DNS utrzymujących strefę zadanej domeny DNS, są skonfigurowane/wpisane w serwerach DNS operatora tejże domeny.

 

Aby się dowiedzieć powyższe, musimy najpierw dowiedzieć się, jakie są adresy serwerów DNS operatora rozszerzenia tej naszej zadanej domeny. W tym celu wysyłamy zapytanie o tą naszą zadaną nazwę DNS do jednego (dowolnego) z 13 serwerów root:

  • a.root-servers.net
  • b.root-servers.net
  • c.root-servers.net
  • d.root-servers.net
  • e.root-servers.net
  • f.root-servers.net
  • g.root-servers.net
  • h.root-servers.net
  • i.root-servers.net
  • j.root-servers.net
  • k.root-servers.net
  • l.root-servers.net
  • m.root-servers.net

Przykładowo, dla wcześniej rozpatrywanej już nazwy „google.pl” zapytanie takowe wyglądałoby następująco:

i w odpowiedzi możemy zobaczyć adresy serwerów DNS operatora rozszerzenia .pl (czyli serwery DNS NASK’u).

 

Teraz wybieramy sobie adres dowolnego serwera DNS operatora, i do niego wysyłamy zapytanie o wskazaną przez nas domenę (czyli w naszym analizowanym przykładzie „google.pl”):

i jak możemy zauważyć w zaznaczeniu na powyższym zrzucie, otrzymujemy listę adresów serwerów DNS jakie są zarejestrowane u operatora rozszerzenia .pl, iż utrzymują strefę dla wskazanej przez nas nazwy DNS (czyli w naszym przykładzie było to „google.pl”). Jak można też zaobserwować dla naszego analizowanego przypadku, zostały zwrócone adresy 4 serwerów DNS (czyli strefa jest skonfigurowania na tych 4 serwerach, i takowe adresy zostały zgłoszone do operatora): ns1.google.com, ns2.google.com, ns3.google.com, ns4.google.com.  

 

Tylko… tak w sumie to poznaliśmy adresy tych serwerów w postaci nazwy DNS, a jakie są adresy IP tych serwerów, i dlaczego nie zostały nam zwrócone adresy IP tylko nazwy DNS?

To dlaczego są zwrócone nazwy DNS, wiąże się z logiką tworzenia rekordów NS – w nich należy podać w pełni kwalifikowaną nazwę domeny serwera który utrzymuje strefę, przy czym ta nazwa domeny musi być oczywiście rozwiązywalna na adres IP poprzez rekord A/AAAA.

W naszym analizowanym przypadku, u operatora rozszerzenia .pl zostały zarejestrowane nazwy domeny pochodzące z innego rozszerzenia .com, stąd adresy IP nie są zwracane, gdyż nie ma problemu, aby teraz z osobna wygenerować zapytanie z prośbą o zwrócenie rekordu A tejże nazwy. Jeżeli więc chcemy się dowiedzieć jaki adres IP się kryje pod tą nazwą domeny, to wystarczy za pomocą nslookup wygenerować zapytanie o zwrócenie rekordu A dla tej danej nazwy serwera DNS utrzymującego strefę, wysłanego… do niego samego 🙂 Przecież w końcu on najlepiej jako serwer autorytatywny tej strefy DNS zna odpowiedź.
Przykładowo:

i w dolnym zaznaczeniu widzimy adres IPv4 oraz IPv6 tegoż serwera DNS. I wykonujemy dalej w ten sposób podobnie, dla kolejnych wcześniej zwróconych adresów serwerów DNS.

 

Aczkolwiek, co ciekawe, jeżeli by się okazało, że u operatora danego rozszerzenia domeny DNS, zostały zarejestrowane w pełni kwalifikowane nazwy domeny z rozszerzeniem tego właśnie operatora, to pojawiłaby się mała pętla… Stąd wtedy operator również oprócz samych nazw w rekordach NS, musi u siebie zarejestrować tzw. doklejone rekordy A/AAAA rozwiązujące tą nazwę na adres IP, i takowe wtedy zwraca nam razem z rekordami NS.
Poniżej przykład jak to wygląda w praktyce, dla nazwy nazwa.pl:

i tu jak widzimy są już wskazane nie tylko nazwy DNS, ale także adresy IP serwerów, które utrzymują strefę dla wskazanej nazwy DNS.

 

 

Podsumowanie

Mam nadzieję, że na bazie powyższych przykładów, udało się zaintrygować narzędziem nslookup, i możliwościami diagnostycznymi jakie nam daje, choć oczywiście jak większość tego typu narzędzi, wymaga ono od nas posiadania jednak pewnej wiedzy, aby można było z niego wycisnąć sporo…

Napewno dużą zaletą tego narzędzia w przypadku Windows’a jest to, że po prostu już tam domyślnie jest… W systemie Linux wymaga on w praktyce chyba w większości dystrybucji doinstalowania go, jest to sumarycznie to samo narzędzie, tak samo działające jak w Windows, choć zauważalną różnicą, jest obsługa zapytań o rekordy DNSSec’owe:

Aczkolwiek, większe trochę możliwości, szczególnie właśnie odnośnie diagnostyki DNSSEC’a, ma narzędzie będące konkurentem dla nslookup, jakim jest dig. Ale to narzędzie, to już historia na inny kolejny artykuł 🙂

 

 

Udostępnij, jeśli ci się spodobało: