Jak działa DNS i dlaczego domena nie kieruje na VPS

Czym jest DNS i dlaczego domena nie kieruje jeszcze na Twój VPS

DNS (domain name system) zamienia nazwę taką jak example.com na adres IP (internet protocol), na przykład 203.0.113.10. Przeglądarka nie może połączyć się z nazwą. Łączy się z adresem, dlatego każde ładowanie strony rozpoczyna się od zapytania DNS i otrzymania odpowiedzi. Jeśli właśnie zakupiono domenę oraz własny VPS i nic się nie ładuje, prawdziwa jest jedna z dwóch przyczyn: brak rekordu łączącego nazwę z adresem serwera lub rekord istnieje, ale gdzieś na ścieżce przesyłania danych nadal zwracana jest stara odpowiedź.

Obie sytuacje są normalne i żadna z nich nie oznacza awarii. Poniższe sekcje omawiają poszczególne etapy w kolejności ich występowania, zaczynając od tego, który pochłania najwięcej czasu: ustalenia, który panel sterowania faktycznie przechowuje rekordy.

Każda weryfikacja w tym miejscu wykorzystuje dig, który nie jest instalowany domyślnie na świeżym systemie Ubuntu lub Debian.

sudo apt update && sudo apt install -y bind9-dnsutils

Rejestrator, serwery nazw, host DNS: co należy edytować

Te trzy nazwy opisują odrębne funkcje. Ich mylenie jest najczęstszą przyczyną braku efektów wprowadzanych zmian.

• Rejestrator to firma, w której zakupiono domenę. Jego kluczowym zadaniem jest delegacja: informuje on rejestr obsługujący daną domenę najwyższego poziomu (TLD, część .com), które serwery nazw są autorytatywne dla danej domeny.
• Autorytatywne serwery nazw przechowują rzeczywiste rekordy dla danej strefy. Strefa to domena oraz wszystkie nazwy w jej obrębie.
• Host DNS to podmiot obsługujący te serwery nazw. Może to być rejestrator, zewnętrzny dostawca lub bind9 uruchomiony na własnym serwerze.

Zakupu dokonuje się u rejestratora. Edycji dokonuje się u hosta DNS. Jeśli domena została przeniesiona na serwery nazw innego dostawcy, panel DNS rejestratora nadal wyświetla strefę i zapisuje zmiany, jednak nikt w sieci nie odpytuje tej strefy. Rekordy są poprawne, ale nigdy nie są sprawdzane.

Sprawdź, gdzie kierowane są zapytania z sieci:

dig example.com NS +short
dig +trace example.com

Pierwsze polecenie wyświetla serwery nazw odpowiadające obecnie dla domeny. Drugie śledzi łańcuch począwszy od serwerów głównych (root) i wyświetla delegację przekazaną przez serwery TLD, czyli ustawienie kontrolowane przez rejestratora. Jeśli te nazwy należą do dostawcy, którego nie rozpoznajesz, to właśnie ten dostawca obsługuje panel, w którym należy wprowadzić zmiany.

Przebieg pojedynczego zapytania

W proces zaangażowane są cztery strony, z których każda przechowuje kopię uzyskanych informacji.

1. Stub resolver na Twoim komputerze. Nie wykonuje on wyszukiwania. Wysyła zapytanie do jednego skonfigurowanego serwera i uznaje odpowiedź za wiarygodną. W systemie Ubuntu /etc/resolv.conf jest zazwyczaj dowiązaniem symbolicznym do /run/systemd/resolve/stub-resolv.conf i wskazuje na 127.0.0.53, czyli systemd-resolved działający lokalnie z własną pamięcią podręczną.
2. Recursive resolver. Jest to resolver obsługiwany przez Twojego dostawcę usług internetowych (ISP), serwer publiczny, taki jak 1.1.1.1, lub serwer uruchomiony samodzielnie. Wykonuje on właściwą pracę polegającą na znalezieniu odpowiedzi.
3. Serwery root i TLD. Recursive resolver wysyła zapytanie do serwera głównego (root), który nie zna adresu, ale odsyła wskazanie do serwerów .com. Te z kolei odsyłają wskazanie do Twoich serwerów nazw.
4. Autorytatywny serwer nazw. Nie pyta nikogo. Odpowiada na podstawie Twojej strefy i oznacza odpowiedź jako autorytatywną.

dig +trace example.com pokazuje ten proces, ponieważ rozpoczyna działanie od poziomu głównego (root) i wyświetla każde przekierowanie zamiast korzystać z pamięci podręcznej. Jest to najszybszy sposób na sprawdzenie, czy delegacja i strefa są ze sobą zgodne.

Rekordy DNS istotne przy prowadzeniu serwera

• A: przypisanie nazwy do adresu IPv4. example.com. A 203.0.113.10. Jest to rekord wskazujący domenę na VPS.
• AAAA: przypisanie nazwy do adresu IPv6, na przykład 2001:db8::10. Publikuj go tylko wtedy, gdy usługa faktycznie nasłuchuje na tym adresie. Klienci w sieciach IPv6 najpierw sprawdzają rekord AAAA, więc adres, na którym nikt nie nasłuchuje, powoduje opóźnienie przy każdej wizycie.
• CNAME: alias z jednej nazwy na drugą. www.example.com. CNAME example.com. kieruje użytkowników www na adres, na który wskazuje domena główna. Rekord CNAME nie może znajdować się w wierzchołku strefy (sama domena example.com), ponieważ wierzchołek musi zawierać własne rekordy SOA (start of authority) oraz NS, a rekord CNAME nie może współdzielić nazwy z żadnym innym rekordem. Dostawcy oferują obejścia pod nazwami takimi jak ALIAS, ANAME lub CNAME flattening.
• MX: miejsce dostarczania poczty dla domeny. Zawiera nazwę hosta oraz priorytet; w pierwszej kolejności sprawdzana jest niższa wartość. Rekord MX musi wskazywać na nazwę posiadającą rekord adresowy. Wskazywanie na CNAME jest nieprawidłowe i niektóre serwery nadawcze odrzucą taką konfigurację.
• TXT: dowolny tekst, używany do weryfikacji i polityk. Tutaj umieszcza się rekordy uwierzytelniania poczty (SPF, DKIM, DMARC), a także token ACME (automatic certificate management environment) służący do wydawania certyfikatów typu wildcard.
• NS: serwery nazw obsługujące strefę. Kopia decydująca o tym, gdzie świat kieruje zapytania, znajduje się w strefie nadrzędnej i pochodzi z delegacji u rejestratora, a nie z kopii wewnątrz własnej strefy.

Dwa szczegóły powodują więcej zamieszania niż same typy rekordów. Nazwa kończąca się kropką jest bezwzględna, więc www.example.com. oznacza dokładnie to i nic więcej. Większość paneli oczekuje nazwy względnej i automatycznie dodaje domenę, więc wpisanie www.example.com w pole nazwy utworzy www.example.com.example.com, co dla nikogo nie będzie poprawne. Drugim szczegółem jest @, co w niemal każdym panelu oznacza wierzchołek strefy: domenę samą w sobie, bez subdomeny.

Skierowanie rekordu A na VPS

Najpierw należy pobrać adres IP, pod którym serwer jest widoczny w Internecie:

curl -4 https://ifconfig.me
ip -brief -4 address show

Następnie należy utworzyć jeden rekord u dostawcy DNS: typ A, nazwa @, wartość równa pobranemu adresowi, TTL (time to live) 300. Należy dodać drugi rekord dla www, używając kolejnego wpisu A z tym samym adresem lub rekordu CNAME wskazującego na domenę główną (apex).

Teraz należy sprawdzić poprawność rozpoznawania nazwy, najlepiej z poziomu lokalnego komputera, a nie z samego serwera:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

Pierwsze polecenie wykorzystuje standardową ścieżkę systemową, uwzględniając pamięć podręczną. Drugie polecenie pomija lokalną pamięć podręczną i odpytuje publiczny serwer rekurencyjny. Trzecie polecenie odpytuje bezpośrednio autorytatywny serwer nazw, dzięki czemu zwraca aktualny stan bez uwzględniania jakiejkolwiek pamięci podręcznej. Jeśli trzecie polecenie zwraca właściwy adres, a pierwsze nie, oznacza to, że konfiguracja DNS jest poprawna, a opóźnienie wynika z przechowywania starej odpowiedzi w pamięci podręcznej.

Rozwiązywanie nazw nie działa

Poprawne rozwiązywanie nazw potwierdza jedynie działanie DNS. Nie świadczy to o stanie serwera WWW. Gdy dig zwróci właściwy adres, należy przetestować połączenie:

curl -I http://example.com

curl: (6) Could not resolve host: example.com oznacza problem z DNS. curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused nie jest problemem DNS: nazwa została rozwiązana, a pakiet dotarł do celu, co oznacza, że na danym porcie nie działa żadna usługa. Żądanie, które zawiesza się, a następnie kończy przekroczeniem czasu oczekiwania, zazwyczaj oznacza, że firewall odrzucił pakiet po cichu, zamiast go odrzucić z informacją o odmowie. W tym momencie DNS przestaje być przedmiotem analizy, a pierwszeństwo przejmują porty i gniazda nasłuchujące oraz reguły firewalla ufw na VPS. Po nawiązaniu połączenia, dalsza część ładowania strony to działanie protokołu HTTP.

Dlaczego przeglądarka nadal wyświetla stary host

Nic nie jest propagowane. Żaden serwer nie wypycha zmian na zewnątrz. Twój autorytatywny serwer nazw przechowuje nową wartość w momencie jej zapisania, a każda kopia poprzedniej odpowiedzi pozostaje ważna do momentu wygaśnięcia jej własnego licznika czasu. Tym licznikiem jest TTL, wyrażony w sekundach, który rekord posiadał w momencie jego wydania.

Kopie istnieją w większej liczbie miejsc, niż można przypuszczać: w krótkotrwałej pamięci podręcznej przeglądarki, w lokalnym resolverze (stub resolver) na maszynie, w rekurencyjnym resolverze używanym przez daną sieć oraz w każdym resolverze zainstalowanym przez VPN na kliencie. Każdy z nich przechowuje swoją kopię przez czas nie dłuższy niż otrzymany TTL. Dwie osoby w dwóch różnych sieciach mogą widzieć dwie różne odpowiedzi przez wiele godzin i obie maszyny zachowują się poprawnie.

Monitoruj odliczanie w resolverze z pamięcią podręczną:

dig @1.1.1.1 example.com +noall +answer

Uruchom to polecenie dwukrotnie w odstępie kilku sekund. Wartość TTL w odpowiedzi będzie malała. Gdy osiągnie zero, resolver usunie rekord i ponownie zapyta Twój serwer nazw.

Istnieje druga pamięć podręczna, o której prawie nikt nie pamięta: odpowiedzi negatywne. Gdy resolver otrzyma informację, że nazwa nie istnieje, buforuje również ten wynik NXDOMAIN przez czas określony w ostatnim polu rekordu SOA Twojej strefy.

dig example.com SOA +short

Ostatnia liczba w tej linii to negatywny TTL, często wynoszący 3600. Dlatego wyszukiwanie staging.example.com przed jego utworzeniem może ukryć rekord przed Tobą przez pełną godzinę po jego utworzeniu. Najpierw utwórz rekord, a dopiero potem go odpytuj.

Zmiana serwerów nazw jest wolniejsza niż zmiana rekordu, a powód jest natury mechanicznej. Rekordy delegacji w strefie .com są serwowane z TTL wynoszącym 172800 sekund, czyli dwa dni, więc resolver, który zbuforował Twoje stare serwery nazw, może pytać o nie przez tak długi czas. Stąd bierze się zalecenie, aby "poczekać do 48 godzin". Dotyczy ono zmian serwerów nazw, a nie zwykłej edycji rekordów.

Zaplanuj migrację w oparciu o TTL, zamiast z nim walczyć:

1. Zmniejsz TTL rekordu do 300 i zapisz go.
2. Odczekaj czas dłuższy niż stary TTL, aby każda kopia w pamięci podręcznej zawierająca starą wartość wygasła.
3. Zmień adres.
4. Gdy ruch zostanie przeniesiony, zwiększ TTL z powrotem do 3600 lub wyżej, ponieważ niski TTL oznacza, że każdy resolver znacznie częściej odpytuje Twoje serwery nazw.

Aby wyczyścić dane przechowywane przez Twoją własną maszynę:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics wyświetla sekcję pamięci podręcznej z licznikami trafień i chybień, więc zaraz po wyczyszczeniu kolejne wyszukiwanie pojawi się jako chybienie. Przeglądarki przechowują oddzielną pamięć podręczną, co oznacza, że Chrome może nadal używać starej odpowiedzi po opróżnieniu pamięci podręcznej systemu. Wyczyść ją pod adresem chrome://net-internals/#dns. Sprawdź również /etc/hosts, ponieważ pozostawiona tam linia ma pierwszeństwo przed DNS na tej maszynie i tylko na tej maszynie. getent hosts example.com pokazuje odpowiedź, której system rzeczywiście użyje, wliczając w to /etc/hosts.

Certyfikaty typu wildcard są weryfikowane za pomocą rekordu TXT

Urząd certyfikacji (CA) sprawdza kontrolę nad nazwą przed wystawieniem certyfikatu. Wyzwanie HTTP-01 udostępnia plik przez port 80 pod konkretną nazwą hosta, co sprawdza się w przypadku pojedynczej nazwy. Certyfikat typu wildcard obejmuje *.example.com, czyli otwarty zbiór nazw hostów, z których CA nie może pobrać pliku, dlatego Let's Encrypt wystawia certyfikaty wildcard wyłącznie poprzez wyzwanie DNS-01. Należy opublikować rekord TXT w _acme-challenge.example.com zawierający token dostarczony przez CA; kontrola nad strefą stanowi dowód własności.

To sprawia, że dostawca DNS staje się częścią procesu odnawiania certyfikatu. Certbot musi tworzyć i usuwać ten rekord TXT przy każdym odnowieniu bez udziału użytkownika, dlatego wymaga API oraz odpowiedniej wtyczki dla danego dostawcy. Gdy weryfikacja kończy się niepowodzeniem, typowy komunikat to DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com, co oznacza, że CA wysłało zapytanie, zanim rekord stał się widoczny: albo nie został on zapisany, albo odpowiedź negatywna była nadal w pamięci podręcznej. Pełna procedura znajduje się w przewodniku dotyczącym certyfikatów wildcard z wyzwaniem DNS-01.

Gdy VPN przejmuje systemowy resolver

Klient VPN (virtual private network) zazwyczaj zastępuje systemowy resolver w czasie aktywnego połączenia. Jest to konieczne, ponieważ wysyłanie zapytań do sieci lokalnej ujawnia nazwy wszystkich odwiedzanych witryn. Jest to poprawne zachowanie, które jednak może zawodzić w dwóch przypadkach.

Jeśli tunel zostaje nawiązany, a rozwiązywanie nazw przestaje działać przy zachowaniu łączności z adresami IP, oznacza to, że resolver zainstalowany przez klienta jest nieosiągalny z wnętrza tunelu. Polecenie ping 1.1.1.1 kończy się powodzeniem, a curl https://example.com zwraca curl: (6) Could not resolve host: example.com. Jeśli natomiast tunel działa, ale zapytania nadal trafiają do sieci lokalnej, ruch jest tunelowany, podczas gdy lokalny resolver rejestruje każdą wyszukiwaną nazwę.

resolvectl status

Polecenie to wyświetla resolver używany przez każde łącze, co pozwala sprawdzić, który z nich został zainstalowany przez tunel i czy jest to resolver zamierzony. Tunel WireGuard ustawia ten parametr za pomocą linii DNS = w konfiguracji klienta, a sekcja naprawa DNS, gdy WireGuard przejmuje resolver szczegółowo omawia przypadki systemd-resolved oraz resolvconf.

Kody odpowiedzi i ich znaczenie

• NXDOMAIN: serwer autorytatywny informuje, że nazwa nie istnieje. Należy sprawdzić pisownię, zweryfikować, czy sufiks domeny nie został zdublowany oraz upewnić się, że edytowano strefę, na którą wskazuje delegacja.
• NOERROR z pustą sekcją ANSWER SECTION: nazwa istnieje, ale nie posiada rekordu typu, o który wysłano zapytanie. Zapytanie o AAAA w sytuacji, gdy istnieje tylko A, skutkuje właśnie taką odpowiedzią.
• SERVFAIL: resolver podjął próbę, ale nie uzyskał odpowiedzi. Dwie najczęstsze przyczyny to brak odpowiedzi ze strony serwerów autorytatywnych oraz niepowodzenie walidacji DNSSEC (domain name system security extensions). Należy przeprowadzić test za pomocą dig @1.1.1.1 example.com A +cd, co wyłącza walidację. Jeśli odpowiedź z +cd oraz SERVFAIL pojawia się bez tej flagi, oznacza to problem z podpisami, co często zdarza się po przeniesieniu serwera nazw, gdy w strefie nadrzędnej nadal widnieje stary rekord DS (delegation signer).
• REFUSED: serwer, do którego skierowano zapytanie, odmawia udzielenia odpowiedzi. Zazwyczaj wynika to z użycia dig w odniesieniu do serwera autorytatywnego dla domeny, której ten serwer nie obsługuje.
• ;; connection timed out; no servers could be reached: narzędzie dig nie nawiązało połączenia z resolverem. Wskazuje to na problem sieciowy lub problem z resolverem po stronie użytkownika, zatem przyczyna nie leży w samej domenie.

ping: example.com: Temporary failure in name resolution to ten sam typ błędu, zgłaszany przez glibc zamiast przez dig.

Czy warto uruchamiać własne serwery nazw na VPS?

Jest to możliwe. bind9, knot lub nsd obsłużą strefę z poziomu serwera, co pozwala poznać mechanizmy DNS lepiej niż w przypadku jakiegokolwiek panelu zarządzania. Zastrzeżenia mają charakter praktyczny. Domena powinna posiadać co najmniej dwa serwery nazw w odrębnych sieciach, dlatego pojedynczy VPS staje się pojedynczym punktem awarii dla każdej usługi w domenie, w tym poczty elektronicznej. Serwery nazw zdefiniowane wewnątrz domeny, którą obsługują, wymagają rekordów typu glue u rejestratora. Jest to adres ns1.example.com przechowywany w strefie nadrzędnej, bez którego proces wyszukiwania nie może się rozpocząć. Gdy resolver nie może połączyć się z serwerem nazw, nie następuje przekierowanie na stronę WWW: cała domena staje się niedostępna dla użytkownika. Dla większości osób bezpieczniejszym wyborem jest hosting DNS z API. Uruchomienie buforującego resolvera na VPS na potrzeby własnych maszyn to inne zadanie, wiążące się z o wiele mniejszym ryzykiem.

FAQ

Dlaczego zmiana DNS jeszcze się nie rozpropagowała?

Nic się nie propaguje. Autorytatywne serwery nazw przechowują nową wartość w momencie jej zapisania, a każdy resolver, który już wysłał zapytanie, korzysta z kopii w pamięci podręcznej do czasu wygaśnięcia otrzymanego TTL. Należy odpytać serwer autorytatywny bezpośrednio za pomocą dig @ns1.your-dns-host.net example.com A +short. Jeśli zwróci on nowy adres, zmiana jest aktywna, a reszta zależy od pamięci podręcznej. W przypadku zmiany serwerów nazw, a nie samych rekordów, należy założyć znacznie dłuższy czas oczekiwania, ponieważ delegacje TLD są wydawane z dwudniowym TTL.

Jak sprawdzić, których serwerów nazw faktycznie używa domena?

dig example.com NS +short wyświetla serwery nazw odpowiadające obecnie dla domeny, a dig +trace example.com pokazuje łańcuch odwołań od roota, w tym delegację przekazaną przez serwery TLD. Jeśli te nazwy nie należą do dostawcy, którego panel był edytowany, tam leży błąd. Należy albo edytować rekordy u dostawcy wskazanego w delegacji, albo zmienić delegację u rejestratora, aby wskazywała na właściwe miejsce.

Domena się rozwiązuje, ale strona nadal się nie ładuje. Co teraz?

Działanie DNS kończy się w momencie, gdy dig example.com A +short zwraca adres serwera. Po tym etapie problem dotyczy połączenia. Jeśli curl -I http://example.com zwraca Connection refused, oznacza to, że na danym porcie nikt nie nasłuchuje. Żądanie, które zawiesza się do czasu przekroczenia limitu czasu, oznacza, że firewall odrzucił pakiet. Należy sprawdzić, czy serwer WWW działa i jest powiązany z adresem publicznym, a następnie zweryfikować firewall na serwerze oraz zewnętrzny firewall sieciowy w panelu sterowania dostawcy.

Dlaczego nie mogę umieścić rekordu CNAME w domenie głównej?

Rekord CNAME oznacza, że nazwa jest aliasem innej nazwy, a nazwa posiadająca CNAME nie może zawierać żadnych innych rekordów. Domena główna musi posiadać rekordy SOA oraz NS, aby istnieć jako strefa, więc nie może być jednocześnie rekordem CNAME. Należy użyć rekordu A zawierającego adres w domenie głównej lub skorzystać z funkcji dostawcy oferowanej jako ALIAS, ANAME lub CNAME flattening, która przechowuje nazwę i odpowiada na zapytania adresem, na który ta nazwa aktualnie wskazuje.