Jak sprawdzić propagację DNS

Skąd bierze się to czekanie

Wyobraź sobie łańcuch, który przemierza zapytanie. Twoje urządzenie pyta resolver rekurencyjny, prowadzony przez Twojego dostawcę internetu albo przez publicznego dostawcę. Jeśli ten resolver ma zapisaną w pamięci podręcznej świeżą odpowiedź, zwraca ją bez pytania kogokolwiek. Dopiero gdy pamięć podręczna wygaśnie, schodzi w dół do serwerów root, rejestru domeny najwyższego poziomu, a na końcu do Twoich autorytatywnych serwerów nazw, które przechowują edytowany przez Ciebie rekord.

Więc gdy zmieniasz rekord A, nowa wartość istnieje w sekundzie, w której zapisuje ją Twój dostawca DNS. Każdy resolver wciąż trzymający starą odpowiedź nadal ją podaje, dopóki jego kopia nie wygaśnie. TTL, time to live, to liczba w sekundach dołączona do rekordu, mówiąca resolverom, jak długo mogą go przechowywać w pamięci podręcznej. Rekord z TTL 3600 może być serwowany z pamięci podręcznej przez godzinę od pobrania, więc godzina to najgorszy przypadek dla resolvera, który pobrał go tuż przed Twoją edycją.

Dlatego dwie osoby w tym samym biurze mogą widzieć różne wyniki, i dlatego wyczyszczenie własnej pamięci podręcznej nikomu innemu nie pomaga. Nie ma żadnego globalnego rozprzestrzeniania, na które trzeba czekać, jest tylko wiele niezależnych liczników odliczających do zera w różnych momentach.

Jak sprawdzić z wielu resolverów

Ręczny sposób to zadanie tego samego pytania kilku resolverom i porównanie ich odpowiedzi:

dig +short example.com @8.8.8.8      # Google Public DNS
dig +short example.com @1.1.1.1      # Cloudflare
dig +short example.com @9.9.9.9      # Quad9
dig +short example.com               # Twój własny resolver
dig +short example.com @ns1.yourdns.example  # autorytatywny: źródło prawdy

Zapytanie autorytatywne jest tym najważniejszym. Jeśli zwraca nową wartość, Twoja zmiana jest poprawna i kompletna, a wszystko inne to już kwestia cache'owania. Jeśli zwraca starą wartość, zmiana się nie zapisała, edytowałeś niewłaściwą strefę albo serwery nazw domeny nie są tymi, o których myślisz.

Aby zobaczyć pozostały czas w pamięci podręcznej, a nie tylko samą wartość, pomiń +short i odczytaj kolumnę TTL:

dig example.com @8.8.8.8 | grep -A1 "ANSWER SECTION"

Liczba przed typem rekordu odlicza w miarę starzenia się zapisanej kopii, co mówi Ci dokładnie, jak długo jeszcze ten resolver będzie serwował starą odpowiedź. Na Windows nslookup example.com 8.8.8.8 wykonuje to porównanie bez dodatkowych narzędzi. Internetowe narzędzie do sprawdzania DNS, które odpytuje z wielu lokalizacji naraz, robi to samo szybciej i obejmuje też resolvery, do których nie dotrzesz z własnej maszyny.

Dlaczego może to trwać godzinami

• Rządzi stary TTL, nie nowy. Jeśli rekord miał TTL 86400 i obniżasz go w trakcie zmiany, resolvery, które zapisały stary rekord, wciąż mają prawo do pełnego dnia. Obniżenie TTL pomaga tylko przy następnej zmianie.
• Niektóre resolvery ignorują krótkie TTL. Wielu dostawców internetu wymusza własne minimum, zwykle godzinę lub więcej, niezależnie od tego, co mówi Twój rekord.
• Zmiany serwerów nazw są wolniejsze. Rekordy NS na poziomie rejestru często mają TTL liczony w dniach, więc zmiana dostawcy DNS rzeczywiście może zająć jeden do dwóch dni, zanim ustabilizuje się wszędzie.
• Cache'owanie negatywne też się liczy. Jeśli nazwa nie istniała, gdy ktoś ją sprawdzał, odpowiedź "nie istnieje" również jest zapisywana w pamięci podręcznej, na okres ustalony przez pole minimum w rekordzie SOA strefy.
• Łańcuchy pamięci podręcznych. Przeglądarka cache'uje DNS, system operacyjny cache'uje DNS, a przed publicznym resolverem może stać firmowy. Każda warstwa dodaje własne opóźnienie.
• Długo utrzymywane połączenia. Aplikacje, które rozwiązały nazwę hosta raz przy starcie, używają tego adresu do restartu, niezależnie od tego, co mówi teraz DNS.

Jak przyspieszyć następną zmianę

1. Najpierw obniż TTL, potem poczekaj. Zmniejsz TTL rekordu do 300 sekund i zostaw to przynajmniej na czas równy długości starego TTL, zanim wprowadzisz właściwą zmianę. Do tego czasu każda zapisana kopia niesie już krótką wartość.
2. Wprowadź zmianę. Przy TTL 300 sekund większość resolverów podchwytuje ją w ciągu pięciu minut.
3. Utrzymuj stary serwer odpowiadającym w trakcie nakładania się. Nie wyłączaj go w chwili, gdy DNS jest zaktualizowany. Zostaw go działającym, dopóki nie ustanie do niego ruch, a migracja przejdzie niezauważona.
4. Zweryfikuj z autorytatywnymi serwerami nazw i kilkoma publicznymi resolverami, zanim uznasz sprawę za zakończoną.
5. Podnieś z powrotem TTL, gdy zmiana się ustabilizuje, żeby normalny ruch znów korzystał z cache'owania.

Dla zmiany serwerów nazw nie ma skrótu, bo TTL rejestru nie jest Twoim do ustawienia. Zaplanuj dzień lub dwa i przez cały ten czas utrzymuj u obu dostawców DNS identyczne rekordy, żeby nie miało znaczenia, którego zapyta resolver.

Po ustabilizowaniu się zmiany

Ręczne sprawdzenie kilku resolverów mówi Ci, jak daleko rozeszła się zmiana w chwili, gdy patrzysz, co jest przydatne podczas migracji i bezużyteczne przez resztę czasu. Warte wyłapania są późniejsze awarie: rekord, który zmienia się niezauważenie, serwer nazw, który przestaje odpowiadać, strefa, która wygasa. Ciągłe monitorowanie DNS odpytuje z wielu lokalizacji według harmonogramu i alarmuje, gdy odpowiedź przestaje pasować do tego, jaka powinna być, co wyłapuje też przypadek "działa stąd, nie działa stamtąd", którego pojedyncze zapytanie nie zobaczy. Uruchom teraz zapytanie za pomocą narzędzia do zapytań DNS. Jeśli strona jest dla Ciebie nieosiągalna, ale gdzie indziej działa dobrze, poradnik czy strona nie działa dla wszystkich, czy tylko dla mnie pokazuje, co robić dalej.