Podróż zapytania DNS

Moduł 1: Czym jest DNS? · Czas czytania: 8 min

Cel lekcji: Po tej lekcji będą Państwo potrafili wyjaśnić krok po kroku, jak resolver znajduje odpowiedź i gdzie po drodze odpowiedzi są zapamiętywane.

Pojęcia kluczowe: resolver (rekurencyjny), serwer root, serwer TLD, autorytatywny serwer nazw, odesłanie (delegacja), pamięć podręczna (cache)

Dwa rodzaje serwerów DNS

W lekcji 1.1 widzieli Państwo, że DNS jest podzielony: nikt nie wie wszystkiego. Jak zatem przeglądarka znajduje adres www.example.com? Współpracują w tym dwa rodzaje serwerów:

• Autorytatywne serwery nazw (ang. authoritative) znają odpowiedź dla swojego własnego fragmentu. Serwery nazw example.com znają rekordy example.com. Nie wyszukują niczego dla innych.
• Resolvery (zwane też resolverami rekurencyjnymi) wyszukują odpowiedź w Państwa imieniu. Pytają tak długo, aż ją uzyskają. Państwa dostawca internetu ma własny resolver, istnieją też publiczne resolvery, takie jak Quad9, Cloudflare czy Google.

Państwa komputer sam niemal niczego nie wyszukuje. Posiada niewielki stub resolver, który przekazuje zapytanie do resolvera w Państwa sieci i otrzymuje z powrotem odpowiedź.

Podróż krok po kroku

Załóżmy, że resolver niczego jeszcze nie zapamiętał, a Państwo pytają o rekord A dla www.example.com.

1. Państwa komputer pyta resolver: "Jaki jest rekord A dla www.example.com?"
2. Resolver pyta serwer root. Każdy resolver ma wbudowaną listę adresów serwerów root. Serwer root nic nie wie o example.com, ale wie, kto zarządza domeną .com. Odpowiada odesłaniem: "W tej sprawie proszę zwrócić się do serwerów nazw com: a.gtld-servers.net, b.gtld-servers.net i tak dalej."
3. Resolver pyta serwer nazw .com. Ten również nie zna adresu IP www.example.com, ale wie, jakie serwery nazw ma example.com. Znowu odesłanie: "Proszę zapytać ns1.hosting.example lub ns2.hosting.example."
4. Resolver pyta serwer nazw domeny example.com. Jest on autorytatywny dla tej domeny i udziela odpowiedzi: "www.example.com ma rekord A 192.0.2.10."
5. Resolver przekazuje odpowiedź do Państwa komputera. Przeglądarka łączy się z 192.0.2.10.

Odesłanie z wyższego poziomu do serwerów nazw niższego poziomu nazywa się delegacją. Root deleguje .com do Verisign, .com deleguje example.com do serwerów nazw wskazanych przez abonenta domeny. Dla domeny .nl przebiega to dokładnie tak samo, z tą różnicą, że root odsyła wówczas do serwerów nazw .nl (SIDN, na przykład ns1.dns.nl). Zobaczą to Państwo sami w zadaniu na końcu tej lekcji. Dlatego tak ważne jest, aby serwery nazw w rejestrze się zgadzały (lekcja 2.1).

Pamięć podręczna: nie za każdym razem cała podróż

Gdyby każdy resolver przy każdym zapytaniu zaczynał od nowa od serwera root, otrzymywałby on niewyobrażalną ilość zapytań. Tak się jednak nie dzieje, ponieważ resolver zapamiętuje odpowiedzi przez pewien czas. Ta pamięć nazywana jest pamięcią podręczną (cache).

Jak długo wolno zapamiętywać odpowiedź, określa sama odpowiedź: wartość TTL (time to live), podawana w sekundach. TTL równy 3600 oznacza: tę odpowiedź można zapamiętać na godzinę. Zapamiętywane są również odesłania. Resolver, który właśnie dowiedział się, jakie serwery nazw ma .com, nie musi pytać o to ponownie serwera root przy kolejnym zapytaniu.

Jeśli ktoś inny u tego samego dostawcy minutę później zapyta o www.example.com, resolver odpowie od razu z pamięci podręcznej. Bez podróży, bez czekania.

Pamięci podręczne znajdują się w wielu miejscach:

• w resolverze Państwa dostawcy internetu lub w publicznym resolverze, z którego Państwo korzystają;
• w systemie operacyjnym (Windows, macOS, telefon);
• w przeglądarce;
• czasem w routerze.

Jest to szybkie i efektywne, ale ma pewną konsekwencję, z którą spotkają się Państwo później nieraz: jeśli zmienią Państwo rekord, pamięci podręczne nadal będą podawać starą odpowiedź, aż upłynie ich TTL. Dlatego jedna osoba już widzi zmianę, a inna jeszcze nie. Moduł 6 omawia to szczegółowo.

Serwery root

Istnieje 13 nazw serwerów root: od a.root-servers.net do m.root-servers.net. Zarządza nimi dwanaście różnych organizacji. Za każdą nazwą kryje się na całym świecie wiele serwerów, w setkach miejsc, które współdzielą ten sam adres (nazywa się to anycast). Państwa resolver automatycznie trafia do najbliższego z nich. Tak samo działają serwery nazw TLD, na przykład dla .com i .nl. Dzięki temu DNS jest szybki i nadal działa, gdy gdzieś awarii ulegnie jakiś serwer.

Gdzie coś może pójść nie tak

Znając przebieg tej podróży, łatwiej będzie Państwu rozpoznać przyczynę problemów:

• Delegacja jest nieprawidłowa. U rejestru wskazane są serwery nazw, które nie znają (już) danej domeny. Resolver utyka wówczas na kroku 4. Odpowiedzią jest błąd albo nie ma odpowiedzi w ogóle.
• Serwer autorytatywny udziela innej odpowiedzi, niż Państwo oczekują. Rekord został wówczas zmieniony w innym miejscu niż tam, gdzie znajdują się serwery nazw (lekcja 2.1).
• Pamięć podręczna wciąż zawiera starą odpowiedź. Wówczas nic nie jest zepsute. Trzeba poczekać, aż upłynie TTL, albo wyczyścić własną pamięć podręczną.
• DNSSEC się nie zgadza. Resolver walidujący sprawdza po drodze podpisy. Jeśli łańcuch się nie zgadza, odmawia on udzielenia odpowiedzi (lekcja 8.1).

Za pomocą narzędzia dig +trace mogą Państwo sami odtworzyć tę podróż, od serwera root aż do serwera autorytatywnego. Nauczą się Państwo tego w lekcji 8.2. Takie możliwości dają też narzędzia online.

Podsumowanie

• Autorytatywne serwery nazw znają odpowiedź dla własnej domeny; resolvery wyszukują odpowiedź w Państwa imieniu.
• Resolver zaczyna od serwera root, otrzymuje odesłanie do TLD, następnie do serwerów nazw domeny, i tam otrzymuje odpowiedź.
• Takie odesłanie nazywane jest delegacją.
• Odpowiedzi są zapamiętywane w pamięciach podręcznych tak długo, jak wskazuje TTL; dlatego zmiany nie są widoczne wszędzie natychmiast.
• Istnieje 13 nazw serwerów root, ale dzięki anycast stoi za nimi na całym świecie wiele serwerów.

Quiz

Zadanie

Zadanie Z1.4: Śledzenie podróży. Prześledź podróż dla www.sidn.nl za pomocą dig +trace www.sidn.nl lub narzędzia online, które pokazuje trasę (trace). Proszę wskazać: (1) jeden serwer nazw domeny nl., który napotkają Państwo po drodze, (2) jeden autorytatywny serwer nazw domeny sidn.nl.

Dalsza lektura

Te artykuły opisują sytuację u WebOké. U innych dostawców działa to w podobny sposób.

• Instrukcja DirectAdmin 5.11: Kiedy zmiana zacznie działać? Czas oczekiwania i TTL @@OMSCHRIJWING@@ Dowiedz się, czym jest TTL, ile czasu zajmuje widoczność zmiany w DNS oraz jak przyspieszyć jej wprowadzenie.
• Jak długo trwa zmiana nameserverów lub DNS i co zrobić, jeśli zmiana nie jest widoczna?