Weryfikator DNS

Wykonaj baseline lookup przed każdą zmianą NS, transferem rejestratora lub przełączeniem dostawcy poczty. Zapisz w tickecie A, AAAA, MX, TXT (SPF, DKIM, DMARC), NS i SOA wraz z TTL i znacznikiem czasu. Po cutover powtórz to samo wyszukiwanie i porównaj odpowiedzi linia po linii. Serial SOA u wielu dostawców rośnie przy zmianie pliku strefy — zanotuj go, gdy support twierdzi, że «propagacja zakończona», a laptop nadal pokazuje stare trasy poczty.

Używaj DNS Checker przy wdrożeniu SaaS wymagającego verification TXT, przy debugowaniu deliverability po rotacji SPF lub DKIM, przy potwierdzaniu CAA przed wydaniem certyfikatów lub gdy CDN orange-cloud zmienia odpowiedzi A anycast. Sprawdzanie dns records online jest szybsze niż instalacja bind-utils na zablokowanych laptopach firmowych i pełniejsze niż ping czy nslookup — nigdy nie pokażą MX, TXT i CAA w jednym ustrukturyzowanym widoku. Dla zespołów bez dostępu root to często najszybszy sposób na pełny obraz strefy.

Połącz pełne wyszukiwanie z WHOIS, gdy sama delegacja jest podejrzana: jeśli NS u rejestratora nie pasują do publicznie zwracanych NS, możesz edytować nieaktywny panel DNS, podczas gdy świat nadal odpytuje poprzedniego hosta. Do śladów jednego typu (tylko MX, tylko TXT, tylko NS) narzędzie DIG na tej samej stronie zwraca sekcje answer w stylu resolvera do wklejenia w wątki supportu bez reformatowania.

Jeśli DNS Checker pokazuje wartości inne niż panel sterowania, najpierw porównaj NS. Możesz być w edytorze strefy podrzędnej, podczas gdy apex deleguje gdzie indziej. Odpytaj autorytatywne NS przez DIG @ns1.example.com, gdy rekursywne cache « kłamią » — nasz checker używa skonfigurowanej ścieżki resolvera odzwierciedlającej to, co widzi większość odwiedzających, niekoniecznie plik autorytatywny sekundy po Save.

TTL decyduje, jak długo żyją stare odpowiedzi. Rekord w cache 86400 sekund może do doby znikać z każdego resolvera na świecie nawet po opublikowaniu poprawki. Obniż TTL na stabilnych rekordach 24–48 godzin przed planowaną zmianą, potwierdź niższy TTL przez DNS Checker, zastosuj nowe dane, potem podnieś TTL po stabilizacji.

Zduplikowane rekordy SPF TXT na tym samym owner name całkowicie unieważniają SPF — scal include w jeden ciąg. CNAME na etykiecie z MX lub TXT jest nieważny wg reguł DNS i daje nieprzewidywalne zachowanie resolvera. DMARC bez wyrównanego SPF lub DKIM raportuje błędy, ale ich nie naprawia; traktuj DMARC jako warstwę polityki nad działającymi rekordami auth, nie substytut.

Geograficzny anycast i nazwy proxied CDN mogą zwracać różne odpowiedzi A lub AAAA w zależności od lokalizacji resolvera. To oczekiwane, nie bug propagacji. Debugując routing do origin, porównaj grey-cloud vs orange-cloud w panelu DNS i ponownie uruchom DNS Checker tą samą ścieżką resolvera po każdym przełączeniu.

Poczta przychodząca zależy od priorytetów MX i osiągalnych hostname exchangerów. Reputacja wychodząca — od TXT SPF, DKIM i DMARC pod przewidywalnymi nazwami. DNS Checker grupuje MX i TXT w jednej odpowiedzi, aby potwierdzić, że mail.example.com się rozwiązuje, że na apex jest tylko jeden SPF, że label selector._domainkey publikuje aktualny klucz publiczny i że _dmarc.example.com określa zamierzoną politykę (none, quarantine lub reject).

Po Google Workspace, Microsoft 365 lub onboardingu SMTP relay sprawdź wszystkie cztery rodziny przed wysyłką masową. Działający MX nie oznacza poprawnego SPF — porównaj wychodzące IP SMTP z łańcuchem include SPF i dokumentacją dostawcy. Kopiuj dokładny scalony TXT z checkera zamiast przepisywać z PDF; podzielone w panelu stringi DKIM łączą się w odpowiedziach DNS.

Gdy nagłówki Authentication-Results pokazują spf=fail lub dkim=fail, ponownie odpytaj live TXT przez DNS Checker, popraw strefę, zanotuj TTL i poczekaj na wygaśnięcie cache przed retestem. Użyj Blacklist Checker na IP wysyłających, jeśli deferrals trwają po czystej auth DNS — poprawki DNS to wymagania deliverability, ale nie zastępują pracy nad reputacją IP.

To narzędzie pokazuje rekordy DNS zwracane przez nasz resolver teraz — pełne wyszukiwanie all-records, w tym odpowiedzi TXT pod DKIM i DMARC, pogrupowane według typu z akcjami kopiowania. Służy do weryfikacji konfiguracji, dokumentowania migracji i odpowiedzi « co publiczne drzewo DNS pokazuje dziś dla tej nazwy? » Nie rysuje mapy świata różnic resolverów i nie twierdzi, że testuje pięćdziesiąt globalnych lokalizacji jednocześnie.

Dedykowane checkery propagacji DNS odpytują wiele regionalnych resolverów rekursywnych w czasie i wizualizują, które regiony nadal cacheują stare wartości A, MX lub NS. Taki worldview pomaga po dużych zmianach z wysokim TTL lub swapach NS, gdy support pyta « czy już się propagowało? » DN01 nie replikuje tej mapy — skupiamy się na jednym wysokiej jakości snapshotcie plus historia, dostęp API i narzędzia towarzyszące (DIG, WHOIS, SSL) na tej samej stronie.

Propagacja to nie natychmiastowa teleportacja. To wygasanie starych cache wg TTL plus aktualizacje glue rejestratora przy zmianie NS. Niski TTL w strefie autorytatywnej pomaga przyszłym zmianom szybciej zbiegać, ale nie może retroaktywnie wyczyścić odpowiedzi już w cache na 86400 sekund. Użyj DNS Checker, aby potwierdzić autorytatywną publikację, potem map propagacji, jeśli potrzebujesz geograficznej pewności, że resolvery w wielu regionach wygasły stare dane.

Gdy odpowiedzi różnią się między DNS Checker a mapą propagacji, obie mogą być « poprawne » ze swojego punktu widzenia. Rekursywne resolvery cacheują niezależnie; DNS biurowy, operator mobilny i 8.8.8.8 mogą się różnić do wygaśnięcia TTL. Odpytaj autorytatywne NS bezpośrednio przez DIG, gdy musisz całkowicie ominąć cache — jeśli autorytatywne NS już pokazuje nowy MX, a checker stary, obserwujesz opóźnienie cache, nie nieudany publish.

Wybierz DN01, gdy chcesz wszystkie główne typy rekordów w jednym widoku, zlokalizowany UI w ośmiu językach, lokalną ostatnią historię i udokumentowane API do automatyzacji. Wybierz mapy propagacji, gdy pytanie brzmi konkretnie « które regiony nadal widzą poprzedni IP? » — a nie « czy moje stringi MX i SPF są poprawne? » Jesteśmy uczciwi co do tej granicy: bez fałszywego paska procentu propagacji, bez symulowanej globalnej siatki — tylko dokładne, łatwe do kopiowania dane DNS dla operatorów, którzy muszą wdrażać niezawodne zmiany poczty, webu i certyfikatów. Ta jasna granica oszczędza czas wobec mylących wskaźników « 99% propagacji », gdy MX lub SPF nadal są błędne.