Aktualizujesz rekordy DNS domeny, zapisujesz zmiany i oczekujesz, że nowa witryna internetowa lub usługa poczty elektronicznej będą działać natychmiast. Jednak kolega nadal widzi starą witrynę, narzędzie online pokazuje inny adres, a dostarczanie wiadomości e-mail zachowuje się niejednolicie. To opóźnienie jest powszechnie nazywane Propagacja DNS.
Frazę tę można zinterpretować tak, jakby pojedyncza aktualizacja przemieszczała się przez centralny system Internetu. DNS jest jednak rozproszony. Informacje o domenach są przechowywane i buforowane na serwerach nazw autorytatywnych, rekurencyjnych resolverach, routerach, systemach operacyjnych oraz aplikacjach. Każdy z tych systemów może odświeżać swoje informacje w innym czasie.
Większość zmian w DNS staje się widoczna po wygaśnięciu buforów, gdy resolverzy pobierają świeże rekordy. Czas ten zależy od poprzedniego czasu życia (TTL) rekordu, zachowania resolverów oraz poprawności konfiguracji autorytatywnego DNS. Nie istnieje uniwersalny czas, który gwarantowałby, że każdy użytkownik zobaczy nową odpowiedź.
Ten przewodnik wyjaśnia, co ludzie mają na myśli mówiąc o propagacji DNS, dlaczego zmiany w DNS pojawiają się w różnych odstępach czasu, jak sprawdzić bieżące odpowiedzi domeny oraz co zrobić, gdy aktualizacja nadal wydaje się niekompletna.
Co oznacza propagacja DNS?
Propagacja DNS to powszechny termin określający okres, w którym różni użytkownicy lub serwery rozwiązywania nazw DNS mogą otrzymywać różne odpowiedzi po zmianie rekordów DNS. Użytkownik w jednej sieci może już widzieć nowy adres IP, podczas gdy resolver innego użytkownika nadal zwraca starszy, buforowany adres.
Podstawowa zmiana DNS jest dokonywana na autorytatywnych serwerach nazw dla domeny. Rekurencyjne resolvery pobierają następnie i buforują rekordy dla swoich użytkowników. Resolvere te nie pytają koniecznie ponownie serwerów autorytatywnych za każdym razem, gdy ktoś odwiedza domenę. Mogą ponownie wykorzystać zbuforowaną odpowiedź, dopóki pozostaje ona ważna.
Dlatego „propagację” lepiej zrozumieć jako wygaśnięcie pamięci podręcznej i odświeżanie. Nie ma centralnej kopii, która musiałaby być aktualizowana jednocześnie na każdym urządzeniu podłączonym do Internetu. Autorytatywny rekord może już być poprawny, podczas gdy niektóre resolver'y nadal dostarczają starsze dane z pamięci podręcznej.
Jak działa buforowanie DNS
Gdy przeglądarka musi znaleźć adres IP domeny, zwraca się do systemu operacyjnego w celu rozwiązania nazwy. System operacyjny może mieć już zapisaną w pamięci podręcznej odpowiedź. Jeśli jej nie ma, zwraca się do skonfigurowanego rekurencyjnego resolvera, np. takiego jak ten obsługiwany przez dostawcę internetu, firmę lub publiczną usługę DNS.
Resolver rekurencyjny może również posiadać odpowiedź zapisaną w pamięci podręcznej. Jeśli ta odpowiedź nadal znajduje się w okresie ważności swojej pamięci podręcznej, może zwrócić ją bez kontaktowania się z autorytatywnymi serwerami nazw. Gdy rekord w pamięci podręcznej wygaśnie, resolver może zapytać autorytatywny system DNS i zapisać zaktualizowaną odpowiedź.
Buforowanie skraca czas wyszukiwania i zmniejsza obciążenie infrastruktury DNS. Oznacza to również, że zmiany w rekordach nie są zawsze widoczne dla wszystkich resolverów w tym samym momencie. Poprzednia odpowiedź pozostaje użyteczna dla resolvera do momentu wygaśnięcia jego bufora lub innego odświeżenia go.
Różni użytkownicy mogą korzystać z różnych resolverów rekurencyjnych. Nawet osoby mieszkające w tym samym gospodarstwie domowym mogą widzieć różne wyniki, jeśli ich urządzenia korzystają z różnych usług DNS, sieci VPN, sieci komórkowych lub lokalnych pamięci podręcznych.
Czym jest TTL w DNS?
TTL oznacza Czas życia. Jest to wartość, zwykle mierzona w sekundach, która informuje rekurencyjne serwery DNS, jak długo mogą one buforować rekord DNS przed sprawdzeniem zaktualizowanej odpowiedzi.
Na przykład, TTL 3600 oznacza jedną godzinę. Jeśli resolver pobierze rekord z takim TTL, może zazwyczaj używać odpowiedzi przez do godziny, zanim będzie musiał ją odświeżyć. TTL 300 oznacza pięć minut.
TTL, który ma znaczenie po zmianie, to zwykle TTL starego rekordu, który już został zbuforowany przez resolvery. Obniżenie TTL bezpośrednio przed zmianą rekordu może nie skrócić czasu oczekiwania dla resolverów, które zbuforowały poprzedni, wyższy TTL. Te resolvery mogą nadal używać starej odpowiedzi do momentu wygaśnięcia oryginalnego okresu buforowania.
W przypadku zaplanowanych migracji administratorzy często z wyprzedzeniem zmniejszają wartość TTL, odczekują wystarczająco długo, aby poprzednia wartość TTL wygasła, a następnie wprowadzają zmianę w DNS. Po ustabilizowaniu się zmiany mogą ponownie zwiększyć wartość TTL, aby zmniejszyć liczbę powtarzających się zapytań. Odpowiednie wartości zależą od usługi oraz procesu zmian operatora.
Dlaczego zmiany w DNS zajmują różną ilość czasu?
Najczęstszym powodem jest to, że resolvery mają różne skopiowane dane w pamięci podręcznej. Niektóre mogły już odświeżyć rekord, podczas gdy inne nadal korzystają z nieprzeterminowanej odpowiedzi. Resolver może również stosować własne zachowanie dotyczące odświeżania lub buforować odpowiedzi negatywne, czyli odpowiedzi wskazujące, że dany rekord nie istnieje.
Lokalna pamięć podręczna może dodać kolejną warstwę. Komputer, router, przeglądarka lub aplikacja zabezpieczeń mogą tymczasowo przechowywać informacje DNS. Uruchomienie ponownie przeglądarki lub wyczyszczenie pamięci podręcznej DNS systemu operacyjnego może pomóc w niektórych przypadkach, ale nie zmieni to tego, co nadal jest zbuforowane przez resolver rekurencyjny.
Zmiany dostawcy usług DNS mogą wprowadzać dodatkowe czynniki czasowe. Jeśli zmienisz autorytatywne serwery nazw domeny u rejestratora, resolvery mogą potrzebować odświeżenia informacji o delegacji, a także rekordów obsługiwanych przez te serwery nazw. Jest to zmiana inna niż edycja rekordu A lub AAAA w ramach tej samej usługi hostingu DNS.
Ostatecznie aktualizacja może być niepoprawna w źródle autorytatywnym. Jeśli edytowano niewłaściwy rekord, zmiany nie zostały zapisane, domena korzysta z innych serwerów nazw autorytatywnych lub rekord zawiera błąd składniowy, oczekiwanie nie naprawi podstawowej konfiguracji.
Propagacja DNS vs Aktualizacje autorytatywnego DNS
Autorytatywny serwer DNS dostarcza oficjalne rekordy dla domeny lub strefy. Gdy edytujesz rekord w panelu kontrolnym dostawcy usług DNS, dostawca powinien zaktualizować autorytatywne dane, które udostępnia.
Rekurencyjny resolver dostarcza odpowiedzi DNS urządzeniom klienckim. Może posiadać dane z pamięci podręcznej zebrane przed zmianą. W związku z tym serwer autorytatywny może zwrócić nowy adres, podczas gdy rekurencyjny resolver nadal zwraca starszy.
To rozróżnienie jest przydatne podczas rozwiązywania problemów. Najpierw sprawdź, co zwracają autorytatywne serwery nazw. Jeśli już zawierają oczekiwany rekord, zmiana została opublikowana w źródle, a pozostałe różnice są prawdopodobnie spowodowane buforowaniem lub zachowaniem resolvera. Jeśli autorytatywne serwery nadal zwracają starą wartość lub brak wartości, przeanalizuj konfigurację dostawcy DNS oraz same rekordy.
Zmiana serwerów nazw dodaje kolejną warstwę. Strefa DNS nadrzędna musi wskazywać na przewidziane autorytatywne serwery nazw, a te serwery muszą obsługiwać prawidłową strefę. Poprawny rekord u dostawcy DNS nie jest przydatny, jeśli domena jest delegowana do serwerów nazw innego dostawcy.
Zmiany w DNS a ich skutki
Zmiana A record changes the IPv4 address returned for a hostname. Changing an rekord AAAA zmienia swój adres IPv6. Jeśli oba są obecne, klienci mogą korzystać z dowolnej rodziny adresów w zależności od ich sieci i zachowania połączenia.
Zmiana rekord CNAME zmienia nazwę hosta, do której wskazuje alias. Rozwiązywanie nazw może wtedy wymagać wyszukania docelowej nazwy oraz jej adresu. Zmiana w rekordach dotyczących elementu docelowego może wpłynąć na ostateczny wynik, nawet jeśli sam rekord CNAME pozostaje bez zmian.
Zmiana Domena MX wpływa na to, które serwery pocztowe odbierają e-maile dla domeny. Systemy pocztowe mogą buforować te rekordy, a routowanie poczty może wymagać czasu, aby odzwierciedlić aktualizacje. Przy zmianie dostawcy usług pocztowych administratorzy powinni osobno zweryfikować rekordy MX oraz wszelkie powiązane rekordy uwierzytelniania poczty, takie jak SPF, DKIM lub DMARC.
Zmienia się namesery zmiany, które sprawiają, że dostawca DNS jest autorytatywny dla domeny. Wymaga to prawidłowej delegacji u rejestratora oraz poprawnej konfiguracji strefy u nowego dostawcy. Migracja serwerów nazw powinna być starannie zaplanowana, ponieważ brakujące rekordy u nowego dostawcy mogą spowodować niedostępność stron internetowych, poczty e-mail lub innych usług.
Jak sprawdzić, czy zmiana DNS została wprowadzona
Zacznij od zapytania o domenę z komputera, którego używasz. W systemach Windows, macOS i Linux nslookup jest powszechnie dostępny:
nslookup example.comAby sprawdzić rekord adresu IPv4, użyj:
nslookup -type=A example.comDla IPv6:
nslookup -type=AAAA example.comDla rekordów serwera pocztowego:
nslookup -type=MX example.comNa macOS i Linux, kop dostarcza bardziej szczegółowe dane wyjściowe:
dig example.com AAby wyświetlić tylko sekcję z odpowiedzią:
dig example.com A +noall +answerMożesz zapytać o konkretny rekurencyjny resolver, aby porównać odpowiedzi. Na przykład:
dig @1.1.1.1 example.com AW systemie Windows możesz określić serwer DNS za pomocą:
nslookup example.com 1.1.1.1Zamień example.com z Twoją domeną. Adres resolvera w tych przykładach to tylko jeden z możliwych publicznych resolverów; możesz również skonsultować się z usługą DNS używaną przez Twoją organizację lub dostawcę.
Zapisz resolvera, którego zapytano, odpowiedź oraz czas. Porównanie wyników z wielu resolverów pomaga ustalić, czy różnica jest lokalna dla jednego resolvera, czy występuje szerzej.
Jak zapytać autorytatywny serwer nazw
Aby znaleźć autorytatywne serwery nazw dla domeny, użyj:
dig example.com NSNastępnie zapytaj bezpośrednio o rekord, który zmieniłeś, jeden z tych serwerów nazw:
dig @ns1.example-dns.com example.com AZamień ns1.example-dns.com z autorytatywnym serwerem wymienionym dla Twojej domeny. Jeśli bezpośrednie zapytanie zwraca oczekiwany adres, ale resolver rekurencyjny zwraca starszy, dane autorytatywne zostały zaktualizowane, a resolver może nadal używać skompresowanej odpowiedzi.
Możesz również zapytać kop śledzić proces delegowania:
dig +trace example.comMa to miejsce w hierarchii DNS od korzenia w kierunku autorytatywnych serwerów domeny. Może pomóc w identyfikacji problemów z delegacją, choć jego wynik jest bardziej szczegółowy niż większość podstawowych kontroli wymaga.
Jeśli korzystasz z panelu kontrolnego dostawcy DNS, upewnij się, że domena jest faktycznie delegowana do serwerów nazw wyświetlanych w tym panelu. Rekord może być poprawny w interfejsie jednego dostawcy, podczas gdy publiczna domena wskazuje na innego dostawcę.
Co jeśli niektórzy użytkownicy zobaczą starą stronę internetową?
Najpierw upewnij się, że autorytatywny rekord A lub AAAA ma oczekiwaną wartość. Następnie zapytaj kilka rekurencyjnych resolverów i sprawdź, czy zwracają tę samą odpowiedź. Jeśli dane autorytatywne są poprawne, ale niektóre resolversy zwracają starszy adres, prawdopodobną przyczyną jest buforowanie (cache).
Następnie sprawdź lokalną konfigurację użytkownika. Sieć VPN, firmowy resolver DNS, produkt zabezpieczający, pamięć podręczna przeglądarki lub lokalny plik hosts mogą wpływać na to, jaki adres zostanie zwrócony. Porównaj wynik uzyskany z innej sieci, np. połączenia mobilnego, aby sprawdzić, czy zachowanie się zmienia.
Rozważ również, czy stare i nowe serwery odpowiadają na zapytania. Migracja może wydawać się niespójna, jeśli stary host nadal dostarcza zbuforowaną kopię lub przekierowania działają inaczej. Rekord DNS może być poprawny, podczas gdy stary serwer pozostaje dostępny dla użytkowników, których resolver nie odświeżył jeszcze danych.
Jeśli problem dotyczy tylko IPv4 lub tylko IPv6, porównaj rekordy A i AAAA osobno. Urządzenie może łączyć się przez IPv6, podczas gdy inne używa IPv4. Jedna rodzina adresów może wskazywać na nowy serwer, podczas gdy druga nadal wskazuje na stary.
Co zrobić, jeśli witryna jest niedostępna po zmianie DNS?
Sprawdź, czy autorytatywne serwery nazw domeny są poprawne i dostępne. Następnie zweryfikuj, czy odpowiednie rekordy istnieją na tych serwerach. Jeśli ostatnio zmieniłeś serwery nazw, upewnij się, że nowy dostawca DNS ma wszystkie wymagane rekordy, w tym rekordy dla strony internetowej, poczty e-mail, weryfikacji oraz usług.
Upewnij się, że serwer docelowy jest gotowy do przyjmowania połączeń dla domeny. Aktualizacja DNS zmienia tylko kierunek, w którym są przekierowani klienci. Nie konfiguruje ona serwera WWW, nie instaluje certyfikatu, nie otwiera portu zapory sieciowej ani nie kopiuje plików witryny.
Jeśli DNS zwraca oczekiwany adres IP, ale strona internetowa nadal nie działa, przetestuj serwer i aplikację osobno. Problem może leżeć po stronie serwera WWW, zapory sieciowej, certyfikatu TLS, konfiguracji hostingu lub aplikacji. Wyszukiwanie DNS potwierdza poprawną resolucję nazw; nie potwierdza jednak, że usługa jest zdrowa.
Aby sprawdzić ogólną ścieżkę między Twoim urządzeniem a miejscem docelowym, zapoznaj się z naszym przewodnikiem po używanie traceroute do diagnozowania problemów z połączeniem sieciowymTraceroute i wyszukiwania DNS testują różne części połączenia, dlatego są przydatne w połączeniu podczas zawężania zakresu problemu.
Negatywne buforowanie i wyniki „Nie znaleziono rekordu”
Resolwery mogą buforować informację o tym, że rekord nie istnieje. Nazywa się to negatywnym buforowaniem. Jeśli resolver zapytał o nazwę przed utworzeniem rekordu, może tymczasowo nadal zwracać odpowiedź „nie znaleziono”, nawet po dodaniu rekordu.
Negatywne buforowanie również ma ustawiony czas życia (TTL), oparty na informacjach zawartych w rekordzie SOA strefy oraz zasadach resolvera. Dokładne zachowanie może się różnić. Jeśli nowo utworzona subdomena nie rozwiązuje się natychmiast, najpierw sprawdź autorytatywny serwer nazw. Jeśli zwróci on nowy rekord, poczekaj na wygaśnięcie negatywnych cache'ów i porównaj wyniki innych resolverów.
Odpowiedź „record not found” może również oznaczać, że rekord został dodany do niewłaściwej strefy, nazwa hosta została wpisana niepoprawnie lub domena korzysta z innych autorytatywnych serwerów nazw. Przed założeniem, że problem wynika wyłącznie z opóźnień w propagacji, upewnij się co do pełnej nazwy hosta, typu rekordu oraz dostawcy DNS.
Jak zaplanować migrację DNS
Przed wprowadzeniem zmian w rekordach dla usługi produkcyjnej, wypisz wszystkie nazwy hostów i rekordy, od których usługa ta zależy. Strona internetowa może korzystać z rekordów A i AAAA, podczas gdy poczta elektroniczna zależy od rekordów MX, SPF, DKIM oraz DMARC. Aplikacje mogą również polegać na rekordach weryfikacyjnych lub służących do odkrywania usług.
Jeśli zmiana jest zaplanowana, z wyprzedzeniem skróć odpowiedni czas TTL i odczekaj co najmniej poprzedni okres TTL przed przełączeniem celu. Przygotuj nowy serwer lub dostawcę przed aktualizacją DNS. Przetestuj bezpośrednio tam, gdzie to możliwe, i upewnij się, że certyfikaty, reguły zapory sieciowej, ustawienia aplikacji oraz usługi pocztowe są gotowe.
Po zmianie sprawdź autorytatywne odpowiedzi oraz kilka rekurencyjnych resolverów. Monitoruj dostępność witryny internetowej, dostarczanie wiadomości e-mail oraz błędy aplikacji. Przez czas przejścia utrzymuj starą usługę w stanie dostępnym, o ile jest to możliwe, ponieważ niektórzy użytkownicy mogą nadal z niej korzystać, zanim wygasną wygasłe odpowiedzi z pamięci podręcznej.
Po ustabilizowaniu się nowej konfiguracji przywróć odpowiednią wartość TTL. Utrzymywanie bardzo niskiego TTL przez długi czas może zwiększyć liczbę zapytań DNS bez znaczącej korzyści dla usługi, która rzadko ulega zmianom.
Powszechne nieporozumienia dotyczące propagacji DNS
Jednym z powszechnych nieporozumień jest przekonanie, że każda zmiana w DNS trwa dokładnie 24 lub 48 godzin. Nie istnieje stały, uniwersalny czas oczekiwania. Rzeczywiste opóźnienie zależy od poprzednich wartości TTL, buforowania przez resolvery, zmian delegacji oraz poprawności konfiguracji serwerów autorytatywnych.
Kolejne nieporozumienie polega na przekonaniu, że czyszczenie pamięci podręcznej przeglądarki aktualizuje DNS we wszystkich miejscach. Może ono wyczyścić informacje przechowywane na tym urządzeniu, ale nie może wyczyścić pamięci podręcznej zdalnego resolvera rekurencyjnego. Podobnie restart routera może wyczyścić jego lokalną pamięć podręczną, ale nie zmienia rekordów autorytatywnych.
Kolejne nieporozumienie polega na przekonaniu, że DNS checker pokazujący różne odpowiedzi dowodzi, iż domena jest uszkodzona. Różne odpowiedzi mogą wystąpić podczas zaplanowanej migracji, szczególnie gdy resolvery mają w pamięci podręcznej dane pobrane w różnych momentach. Ważne pytanie brzmi: czy rekordy autorytatywne są poprawne i czy pozostałe różnice są zgodne z poprzednim czasem życia (TTL).
Ostatecznie propagacja DNS nie konfiguruje usługi docelowej. Poprawny adres IP może nadal prowadzić do niedostępnej strony internetowej, jeśli serwer, zapora sieciowa, certyfikat TLS lub aplikacja nie są gotowe.
Często zadawane pytania dotyczące propagacji DNS
Jak długo trwa propagacja DNS?
Nie ma jednego, gwarantowanego czasu. Niektóre zmiany pojawiają się szybko, podczas gdy inne pozostają niekonsekwentne do momentu wygaśnięcia rekordów w pamięci podręcznej. Poprzedni czas TTL, zachowanie resolvera oraz to, czy serwery nazw uległy zmianie, wpływają na czas propagacji.
Czy obniżenie wartości TTL powoduje natychmiastową zmianę?
Nie. Obniżenie wartości TTL wpływa na przyszłe buforowanie po tym, jak resolverzy pobiorą nowy TTL. Resolvery, które już zbuforowały stary rekord, mogą nadal go używać do momentu wygaśnięcia jego poprzedniego TTL.
Dlaczego sprawdzacze DNS pokazują różne wyniki?
Mogą one odpytywać różne rekurencyjne serwery DNS z różnych lokalizacji. Te serwery mogą mieć różne odpowiedzi w pamięci podręcznej, odświeżać je w różnych odstępach czasu lub otrzymywać różne odpowiedzi ze względu na geograficzne polityki DNS.
Czy powinienem wyczyścić pamięć podręczną DNS mojego komputera?
Może pomóc, gdy Twoje urządzenie ma w pamięci podręcznej starą odpowiedź. Nie czyści cache'u utrzymywanego przez dostawcę internetu, resolver firmowy lub publiczną usługę DNS.
Dlaczego moja strona internetowa się rozwiązuje, ale nadal nie ładuje się?
DNS może zwracać prawidłowy adres, podczas gdy serwer docelowy lub aplikacja ma problem. Sprawdź osobno serwer WWW, zapora sieciową, certyfikat TLS oraz konfigurację hostingu.
Czy zmiany serwerów nazw mogą trwać dłużej niż zmiany rekordów?
Mogą one obejmować dodatkowe informacje o delegacji na poziomie rejestratora i nadrzędnego strefy DNS. Nowy dostawca musi również udostępniać kompletną i poprawną strefę. Zweryfikuj zarówno delegację, jak i rekordy na nowych serwerach autorytatywnych.
Zmiany w DNS mogą pojawiać się w różnych momentach, ponieważ serwery nazw autorytatywne i rekurencyjne resolvery pełnią różne role, a resolvery buforują odpowiedzi zgodnie z wartościami TTL. Użytkownik może widzieć stary adres, podczas gdy inny już otrzymuje nowy.
Aby przeprowadzić badanie, najpierw sprawdź autorytatywne serwery nazw, a następnie porównaj odpowiedzi z kilku rekurencyjnych resolverów. Potwierdź typ rekordu, nazwę hosta, TTL oraz delegację serwerów nazw. Jeśli DNS zwraca oczekiwany adres, ale usługa pozostaje niedostępna, sprawdź serwer docelowy i aplikację jako oddzielne elementy problemu.
Zrozumienie działania buforowania ułatwia planowanie i rozwiązywanie problemów ze zmianami w DNS. Aby poznać więcej podstaw sieciowych, kontynuuj lekturę naszych przewodników po Adresy IP, domyślne bramki przejścia, i traceroute.