Propagacja DNS: co naprawdę dzieje się po zmianie

Często można przeczytać, że „zmiany w DNS mogą rozchodzić się do 48 godzin”. Brzmi to tak, jakby zmiana wędrowała po internecie od serwera do serwera. Tak nie jest. DNS niczego nikomu nie wysyła. Zwykle już chwilę po tym, jak dostawca DNS zapisze zmianę, jego serwery autorytatywne odpowiadają nową wartością. Czekasz na coś innego: aż wygasną kopie w pamięci podręcznej (cache). Kiedy wiesz, które to kopie i jak długo żyją, możesz zaplanować zmianę tak, żeby nikt jej nie odczuł.

Serwery autorytatywne i resolwery

W każdym zapytaniu DNS biorą udział dwa rodzaje serwerów:

• Serwery autorytatywne przechowują Twoją strefę — to serwery wymienione w rekordach NS domeny, zwykle utrzymywane przez dostawcę DNS. Ich odpowiedzi mają ustawioną flagę AA (Authoritative Answer, RFC 1035, sekcja 4.1.1).
• Resolwery rekurencyjne wyszukują odpowiedzi w imieniu klientów: resolwer Twojego dostawcy internetu albo firmy, publiczne usługi takie jak 8.8.8.8 (Google) czy 1.1.1.1 (Cloudflare), a także resolwer, z którego korzysta serwer poczty odbiorcy. Przechodzą od serwerów głównych (root) przez serwery domeny najwyższego poziomu (TLD) do Twoich serwerów autorytatywnych — i zapamiętują to, czego się dowiedziały.

Do tego własne, mniejsze pamięci podręczne mają systemy operacyjne, przeglądarki i niektóre aplikacje.

Gdy serwer poczty sprawdza Twój rekord SPF, pyta własny resolwer. Jeśli ten pobrał rekord 20 minut temu, odpowie z pamięci, w ogóle nie łącząc się z Twoimi serwerami.

TTL: jak długo odpowiedź może być przechowywana

Każdy rekord ma czas życia (TTL) wyrażony w sekundach:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.example.net -all"

RFC 1034, sekcja 3.6 definiuje TTL jako limit czasu, przez który rekord może pozostawać w pamięci podręcznej. Resolwer, który pobrał ten rekord, może go używać najwyżej przez godzinę, odliczając pozostały czas; dopiero potem zapyta Twoje serwery ponownie.

W praktyce ważne są dwie konsekwencje:

• Liczy się stary TTL. Resolwery, które zapamiętały rekord przed zmianą, trzymają go przez TTL obowiązujący wtedy. Obniżenie TTL razem ze zmianą nie skraca czekania.
• TTL to górna granica, nie gwarancja. Resolwery mogą ustalić własną górną granicę TTL i traktować większe wartości tak, jakby były jej równe (RFC 2181, sekcja 8). Google Public DNS pisze na przykład w swoim FAQ, że rekordy w pamięci są na ogół ograniczone do sześciu godzin, nawet jeśli faktyczny TTL jest dłuższy. Resolwer może też usunąć rekord wcześniej, na przykład gdy zapełni się jego pamięć podręczna.

Część resolwerów stosuje też serve-stale (RFC 8767): jeśli w chwili wygaśnięcia rekordu żaden z Twoich serwerów autorytatywnych nie odpowiada, mogą dalej podawać wygasłe dane, zamiast zwracać błąd. To kolejny powód, by nie wyłączać starych serwerów DNS zaraz po przeprowadzce do nowego dostawcy.

Pamięć odpowiedzi negatywnych: dlaczego nowy rekord „nie istnieje”

Resolwery zapamiętują także odpowiedź „nie ma takiego rekordu”. Według RFC 2308 pamiętanie odpowiedzi negatywnych nie powinno już być traktowane jako opcjonalna funkcja resolwera. Dokument rozróżnia dwa przypadki:

• NXDOMAIN — nazwa w ogóle nie istnieje. Odpowiedź jest zapamiętywana dla nazwy, niezależnie od typu rekordu.
• NODATA — nazwa istnieje, ale nie ma rekordów żądanego typu. Odpowiedź jest zapamiętywana dla nazwy i tego typu.

Odpowiedź negatywna nie zawiera rekordu, który mógłby nieść TTL, dlatego serwer autorytatywny dołącza rekord SOA strefy. TTL odpowiedzi negatywnej to mniejsza z dwóch wartości: TTL samego rekordu SOA i jego pola MINIMUM (RFC 2308, sekcje 3 i 5):

example.com.  3600  IN  SOA  ns1.example.net. hostmaster.example.com. (
                2026102401 ; serial
                7200       ; refresh
                3600       ; retry
                1209600    ; expire
                1800 )     ; minimum: czas pamiętania odpowiedzi negatywnych

W tej strefie odpowiedź „nie istnieje” może być pamiętana przez 1800 sekund. Widać to w zapytaniu o nazwę, której jeszcze nie ma — status: NXDOMAIN i rekord SOA w sekcji authority, z odliczanym TTL:

$ dig TXT _dmarc.example.com
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4711
;; AUTHORITY SECTION:
example.com.  1800  IN  SOA  ns1.example.net. hostmaster.example.com. 2026102401 7200 3600 1209600 1800

To klasyczna pułapka przy nowych rekordach. Sprawdzasz, czy istnieje _dmarc.example.com — nie istnieje — tworzysz go, a kolejne sprawdzenia dalej pokazują brak. Resolwer pamięta wcześniejsze „nie ma takiej nazwy”, dopóki nie minie TTL odpowiedzi negatywnej. Tak samo bywa z selektorem DKIM sprawdzonym przed opublikowaniem klucza albo z rekordem _mta-sts, którego serwer nadawcy szukał tuż przed jego opublikowaniem.

Dlaczego różne resolwery pokazują różne odpowiedzi

Stara wartość w jednym resolwerze i nowa w drugim to podczas zmiany stan normalny:

• Każda pamięć podręczna została wypełniona w innym momencie. Resolwer, który pobrał rekord minutę przed zmianą, trzyma starą wartość prawie przez cały TTL; ten, który pobrał go chwilę po zmianie, ma już nową.
• Jeden publiczny resolwer to wiele pamięci. Duże publiczne resolwery odpowiadają z wielu lokalizacji pod jednym adresem anycast, a każda lokalizacja ma własną pamięć podręczną. Zapytania do 8.8.8.8 mogą więc zwracać różne wartości, dopóki nie wygaśnie każda kopia.
• Twoje serwery autorytatywne mogą przez chwilę się różnić. Serwery podrzędne (secondary) kopiują strefę z serwera głównego po powiadomieniu (RFC 1996) albo gdy upłynie czas odświeżania z rekordu SOA (RFC 1034, sekcja 4.3.5). Do tego czasu podają poprzednią wersję — porównaj numer seryjny SOA na każdym z nich.
• Niektóre odpowiedzi zależą od miejsca. Sieci CDN i usługi geo-DNS celowo zwracają różne adresy w różnych regionach. Rekordów związanych z pocztą zwykle to nie dotyczy, ale wyjaśnia, dlaczego rekordy A strony WWW bywają różne.

Jak zaplanować zmianę w DNS

Przy zmianie istniejącego rekordu — nowe serwery MX, zmieniony rekord SPF, rotacja klucza DKIM:

1. Sprawdź obecny TTL na serwerach autorytatywnych.
2. Obniż TTL z wyprzedzeniem — na przykład do 300 sekund — i odczekaj co najmniej tyle, ile wynosił stary TTL, żeby wszystkie pamięci podręczne zdążyły pobrać rekord z krótkim TTL. Dokładnie to zaleca RFC 1034: obniżyć TTL przed przewidywaną zmianą, a potem przywrócić poprzednią wartość.
3. Wprowadź zmianę i sprawdź, czy serwery autorytatywne zwracają nową wartość.
4. Nie wyłączaj starej konfiguracji przez co najmniej jeden TTL. Nadawcy z zapamiętanym rekordem MX wciąż dostarczają pocztę na stary serwer, a odbiorcy z zapamiętanym kluczem DKIM wciąż weryfikują podpisy starym kluczem.
5. Przywróć wyższy TTL, gdy zmiana jest potwierdzona.

Przy nowym rekordzie nie trzeba niczego obniżać — wystarczy nie pytać o nazwę, zanim powstanie. Jeśli ktoś już o nią pytał, odczekaj TTL odpowiedzi negatywnej z rekordu SOA albo poproś duże publiczne resolwery o usunięcie kopii: Google Public DNS ma stronę Flush Cache, a Cloudflare stronę Purge Cache. Wyczyszczenie pamięci podręcznej we własnym systemie (ipconfig /flushdns w Windows) pomaga tylko Twojemu komputerowi.

Zmiana serwerów nazw działa inaczej. Rekordy NS delegujące domenę znajdują się w strefie nadrzędnej (.com, .pl itd.), z TTL ustalonym przez rejestr, którego nie możesz obniżyć. Dopóki stara delegacja nie wygaśnie z pamięci resolwerów, część z nich będzie pytać starego dostawcę DNS. Przed przełączeniem skopiuj całą strefę do nowego dostawcy, a u starego utrzymuj tę samą, aktualną strefę jeszcze przez kilka dni.

Jak sprawdzić zmianę

Narzędzie Propagacja DNS porównuje odpowiedzi kilku publicznych resolwerów z odpowiedziami serwerów autorytatywnych Twojej domeny. Wpisz dokładnie tę nazwę, której dotyczyła zmiana — example.com dla MX lub SPF, _dmarc.example.com dla DMARC, selector1._domainkey.example.com dla klucza DKIM — i zacznij czytać wynik od strony autorytatywnej:

Co widzisz	Co to znaczy	Co zrobić
Serwery autorytatywne zwracają starą wartość albo nic	Zmiana nie działa: nie została zapisana, trafiła do złej strefy albo została wprowadzona u dostawcy, który nie jest autorytatywny	Sprawdź rekordy NS domeny i edytuj strefę tam, gdzie wskazują
Serwery autorytatywne różnią się między sobą	Serwer podrzędny nie pobrał nowej wersji strefy	Porównaj numery seryjne SOA; jeśli to trwa, zgłoś się do dostawcy DNS
Serwery autorytatywne są w porządku, część resolwerów ma starą wartość	Pamięć podręczna	Odczekaj, aż minie stary TTL
Serwery autorytatywne są w porządku, resolwery twierdzą, że nazwa nie istnieje	Zapamiętana odpowiedź negatywna	Odczekaj TTL odpowiedzi negatywnej albo wyczyść pamięć publicznych resolwerów

Pamiętaj, że takie narzędzie widzi każdy publiczny resolwer z miejsca, w którym samo działa. Resolwer serwera poczty konkretnego odbiorcy ma własną pamięć, do której nie zajrzy żadne zewnętrzne narzędzie.

W terminalu zapytaj serwer autorytatywny bezpośrednio — bez rekurencji, szukając flagi aa — i porównaj z publicznym resolwerem:

dig +short NS example.com
dig +norecurse @ns1.example.net TXT _dmarc.example.com
dig @1.1.1.1 TXT _dmarc.example.com +noall +answer

W Windows:

Resolve-DnsName _dmarc.example.com -Type TXT -Server ns1.example.net
Resolve-DnsName _dmarc.example.com -Type TXT -Server 1.1.1.1

W wyniku dig druga kolumna odpowiedzi resolwera to pozostały TTL — czas, po którym ten resolwer zapyta ponownie. Gdy rekordy już działają, do sprawdzeń związanych z pocztą użyj wyszukiwania MX i narzędzi do sprawdzania poszczególnych rekordów.