Odpytywanie DNS za pomocą dig i nslookup

Moduł 8: Bezpieczeństwo i rozwiązywanie problemów · Czas czytania: 10 min

Cel lekcji: Po tej lekcji będą Państwo potrafili za pomocą dig i nslookup odpytywać rekordy, sprawdzać konkretny serwer nazw i odczytywać wynik.

Kluczowe pojęcia: dig, nslookup, Resolve-DnsName, +short, @server, +trace, sekcja ANSWER i AUTHORITY, status NOERROR, NXDOMAIN, SERVFAIL, dig -x

Dlaczego warto sprawdzać samodzielnie?

Panel pokazuje to, co Państwo wprowadzili. To, co widzi reszta świata, może być inne: być może DNS zarządza inna strona, być może w pamięci podręcznej (cache) znajduje się jeszcze stara odpowiedź. Za pomocą programu do odpytywania zadają Państwo to samo pytanie co przeglądarka czy serwer pocztowy i widzą prawdziwą odpowiedź.

Istnieją trzy powszechnie stosowane programy:

Nie mają Państwo pod ręką okna poleceń? Wtedy mogą Państwo zrobić dokładnie to samo za pomocą internetowego narzędzia dig (lekcja 8.3).

Pierwsze zapytanie za pomocą dig

Proszę otworzyć Terminal (macOS/Linux) i wpisać:

$ dig example.com A

Wynik w skróconej wersji wygląda tak:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41872
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.                  IN      A

;; ANSWER SECTION:
example.com.           2847    IN      A       192.0.2.10

;; Query time: 12 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)

Co należy odczytać:

• status: najważniejsze słowo. Zobacz tabelę poniżej.
• flags: ad oznacza, że resolver sprawdził odpowiedź za pomocą DNSSEC (lekcja 8.1).
• ANSWER SECTION: same rekordy. Kolumny są takie same jak w strefie: nazwa, TTL, klasa, typ, wartość.
• TTL (tutaj 2847): ile sekund ta odpowiedź pozostanie jeszcze w pamięci podręcznej (cache) resolvera. Jeśli w strefie ustawiono 3600, oznacza to, że odpowiedź ma już 753 sekundy. Przy ponownym zapytaniu zobaczą Państwo, jak liczba maleje.
• SERVER: który resolver został zapytany. W domu jest to często Państwa router.

Trzy statusy, które warto znać

Przydatne warianty

Tylko odpowiedź za pomocą +short:

$ dig +short MX example.com
10 mail.example.com.
20 mail2.example.com.

Zapytanie do innego resolvera lub bezpośrednio do serwera nazw za pomocą @. To najważniejsza sztuczka przy rozwiązywaniu problemów. Jeśli zapytają Państwo bezpośrednio autorytatywny serwer nazw, zawsze otrzymają Państwo świeżą odpowiedź, bez pamięci podręcznej:

$ dig +short NS example.com
ns1.hosting.example.
ns2.hosting.example.

$ dig +short A www.example.com @ns1.hosting.example
192.0.2.20

$ dig +short A www.example.com @9.9.9.9
192.0.2.10

Tutaj od razu widać, o co chodzi: serwer nazw podaje już nowy adres (.20), publiczny resolver ma jeszcze w pamięci podręcznej stary (.10). Nie muszą więc Państwo nic robić, wystarczy poczekać, aż upłynie TTL (moduł 6).

Inne typy: proszę umieścić typ za nazwą.

$ dig +short TXT example.com
"v=spf1 a mx include:_spf.hosting.example ~all"
"google-site-verification=AbC123..."

$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

$ dig +short CNAME shop.example.com
shops.platform.example.

Śledzenie całej drogi za pomocą +trace. dig robi wtedy sam to, co robi resolver: najpierw root, potem TLD, potem autorytatywny serwer (lekcja 1.4):

$ dig +trace example.com A
.                 518400  IN  NS  a.root-servers.net.
;; Received 239 bytes from 192.168.1.1#53
com.              172800  IN  NS  a.gtld-servers.net.
;; Received 708 bytes from 198.41.0.4#53(a.root-servers.net)
example.com.      172800  IN  NS  ns1.hosting.example.
;; Received 412 bytes from 192.5.6.30#53(a.gtld-servers.net)
example.com.      3600    IN  A   192.0.2.10
;; Received 57 bytes from 198.51.100.53#53(ns1.hosting.example)

Za pomocą +trace widzą Państwo, które serwery nazw faktycznie przekazuje rejestr. Jest to przydatne, gdy mają Państwo wątpliwości, czy zmiana serwera nazw została już wprowadzona.

Zobaczenie DNSSEC za pomocą +dnssec: otrzymają Państwo dodatkowo podpisy RRSIG. Za pomocą +cd wyłączają Państwo weryfikację, aby sprawdzić, czy SERVFAIL wynika z DNSSEC.

Odwrotny DNS za pomocą -x (lekcja 4.6):

$ dig +short -x 192.0.2.25
mail.example.com.

To samo za pomocą nslookup

nslookup działa na każdym komputerze. Najważniejsze formy:

C:\> nslookup example.com
Server:  router.lan
Address:  192.168.1.1

Non-authoritative answer:
Name:    example.com
Address:  192.0.2.10

C:\> nslookup -type=mx example.com
example.com    MX preference = 10, mail exchanger = mail.example.com

C:\> nslookup -type=txt _dmarc.example.com 9.9.9.9

Drugi adres za nazwą (tutaj 9.9.9.9) to serwer, do którego kierowane jest zapytanie, podobnie jak @ przy dig. "Non-authoritative answer" oznacza jedynie, że odpowiedź pochodzi od resolvera, a nie od autorytatywnego serwera nazw: to normalne. Jeśli nazwa nie istnieje, nslookup zwraca Non-existent domain, co odpowiada NXDOMAIN.

Windows PowerShell: Resolve-DnsName

PS> Resolve-DnsName example.com -Type MX
PS> Resolve-DnsName _dmarc.example.com -Type TXT -Server 9.9.9.9
PS> Resolve-DnsName example.com -Type A -DnsOnly

Czyszczenie własnej pamięci podręcznej (cache)

Narzędzie internetowe widzi już nową odpowiedź, ale Państwa komputer jeszcze nie? Wtedy stara odpowiedź znajduje się w pamięci podręcznej Państwa komputera lub przeglądarki.

• Windows: ipconfig /flushdns w wierszu poleceń.
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder w Terminalu.
• Linux z systemd-resolved: resolvectl flush-caches.
• Przeglądarka: okno prywatne lub telefon przez 4G/5G z wyłączonym wifi.

Pamięci podręcznej dostawcy internetu lub routera nie można wyczyścić samodzielnie; tutaj trzeba poczekać na upłynięcie TTL.

W praktyce: jak to wygląda w panelu

W większości paneli nie można uruchomić dig. Dlatego warto używać dig obok panelu: najpierw sprawdzić w panelu, co zostało wprowadzone, potem za pomocą dig @<Państwa serwer nazw> sprawdzić, czy serwer nazw faktycznie to zwraca, a następnie za pomocą dig @9.9.9.9 sprawdzić, czy widzi to już reszta świata. Moje WebOké ma diagnostykę DNS, która porównuje serwery nazw między sobą; inne firmy mają podobne przyciski "sprawdzania DNS".

Podsumowanie

• dig <nazwa> <typ> zadaje to samo pytanie co przeglądarka lub serwer pocztowy; najpierw proszę przeczytać status.
• NOERROR z odpowiedzią jest dobre, NOERROR bez odpowiedzi oznacza "nazwa istnieje, typ nie", NXDOMAIN oznacza "nazwa nie istnieje", SERVFAIL oznacza "brak wiarygodnej odpowiedzi".
• Za pomocą @server pytają Państwo określony resolver lub bezpośrednio autorytatywny serwer nazw; w ten sposób widać różnicę między błędem a pamięcią podręczną.
• +short, +trace, +dnssec, +cd i -x to warianty, których będą Państwo potrzebować najczęściej.
• nslookup i Resolve-DnsName robią to samo w Windows.

Quiz

Zadanie

Zadanie Z8.2: dig i nslookup. Za pomocą dig, nslookup lub Resolve-DnsName (albo internetowego narzędzia dig) proszę sprawdzić trzy rzeczy:

1. status nazwy, która nie istnieje: bestaat-niet-dnscursus.sidn.nl;
2. rekordy MX dla wikipedia.org, bezpośrednio u jednego z serwerów nazw wikipedia.org (proszę go najpierw znaleźć);
3. TTL, który publiczny resolver zwraca w tej chwili dla rekordu A domeny sidn.nl (proszę zapytać dwa razy, z minutą przerwy, i zapisać obie wartości).

Proszę wpisać odpowiedzi.

Dalsza lektura

Poniższe artykuły opisują kroki w WebOké; polecenia działają wszędzie tak samo.

• Instrukcja DirectAdmin 18.7: Moja domena jeszcze nie działa po transferze lub zmianie
• Jak długo trwa zmiana nameserverów lub DNS i co zrobić, jeśli zmiana nie jest widoczna?
• Wysyłanie poczty z Państwa VPS i konfiguracja reverse DNS