Popularne narzędzia

Motyw

Kontrola kondycji DNS

Walidacja domeny w DNS: delegacja w rejestrze, każdy serwer nazw pytany bezpośrednio, SOA, DNSSEC i rekordy poczty. 40 testów, każdy z gotową poprawką.

Poziomy z Zonemaster i RFC · każdy serwer nazw pytany przez TCP · Google Public DNS · RDAP

Idziemy od serwera głównego do rejestru .nl, potem pytamy bezpośrednio każdy serwer nazw domeny sidn.nl · 40 testów · około 3 srejestr .nl → każdy serwer nazw · 40 testów

Wypróbuj
PrzykładNagrano 23 paź 2026 · z naszego serwera.nl3 NSDNSSEC podpisana

Domena sidn.nl przechodzi każdy wykonany test, łącznie z DNSSEC

rejestrator: SIDN·2,9 s

40 zaliczonych

A+: nic powyżej poziomu info. Każdy serwer nazw odpowiedział autorytatywnie i zgadza się z pozostałymi, liczniki mieszczą się w zakresie Zonemaster, a Google Public DNS waliduje łańcuch DNSSEC od roota.

Najpierw problemy

Pytamy przez TCP z naszego serwera na brzegu sieci Cloudflare: root, rejestr .nl i każdy serwer nazw bezpośrednio; Google Public DNS i Cloudflare o rekordy poczty i walidację. Nie prowadzimy logu tego, co sprawdzasz.

Co obejmuje sprawdzanie DNS domeny?

Kontrola kondycji DNS przechodzi drogę, którą resolver znajduje domenę, i testuje każdy krok: delegację w rejestrze, każdy serwer nazw pytany bezpośrednio, to, czy te serwery się zgadzają, rekord SOA, DNSSEC i rekordy poczty. Ta kontrola wykonuje 40 testów w siedmiu grupach i ocenia każdy na poziomie, który wyznacza jego źródło.

Większość narzędzi pyta resolver i ocenia to, co od niego wróci. To ukrywa serwery za nim: resolver odpowiada z tego serwera nazw, który akurat działa, więc zepsuty serwer pozostaje niewidoczny, dopóki nie zawiodą też pozostałe. Tutaj każdy serwer nazw jest pytany przez TCP z wyłączoną rekurencją, kopia rekordów NS w rejestrze jest porównywana z własną kopią strefy, a łańcuch DNSSEC jest weryfikowany od DS w rejestrze do podpisów w strefie.

Używaj jej jako audytu DNS po każdej zmianie: sprawdza rekordy DNS, od których zależy domena, a nie tylko to, czy ładuje się jej strona (samą stronę sprawdza test „Czy strona działa?”). Przycisk Kopiuj raport zamienia wynik w tekstowy raport DNS, który wkleisz do zgłoszenia.

Rooth.root-servers.net
.comRejestr .comh.gtld-servers.net
8 serwerów nazwRoute 53 + NS1
Strefagithub.com
  • DNSSEC7 testówłańcuch zaufania od roota: github.com: koniec na .com (brak DS)
  • Strefa nadrzędna i delegacja6 testówodesłanie z rejestru: 8 nazw · 295 bajtów · glue niepotrzebne
  • Serwery nazw14 testówkażdy serwer pytany bezpośrednio: autorytatywnie: 8 z 8 · przez TCP · EDNS · bez rekurencji
  • Spójność3 testyczy serwery się zgadzają: 2 numery seryjne SOA, po jednym na host DNS · te same MX i SPF
  • SOA4 testyliczniki poniżej minimów Zonemaster: uwagi
  • CAA1 test7 rekordów · dozwolone CA: 4
  • DNS poczty5 testówMX: Microsoft 365 · SPF: 10 z 10 zapytań · DMARC quarantine
Gdzie patrzy każda grupa testów, na prawdziwej drodze github.com (23 października 2026): od roota przez rejestr .com do serwerów nazw strefy w Route 53 i NS1.
Kontrola kondycji DNS dla github.com: ocena A, 40 testów w siedmiu grupach i droga od roota do 8 serwerów nazwKontrola kondycji DNS dla github.com: ocena A, 40 testów w siedmiu grupach i droga od roota do 8 serwerów nazwOcenaTylko z poziomów: brak problemów krytycznych, brak błędów, dwa ostrzeżenia dają A. Pierścień pokazuje wynik, 90 na 100.40 testów, po komórce na każdyPogrupowane tak jak na stronie. Bursztynowe i niebieskie komórki to ostrzeżenia i uwagi; zakreskowane nie mogły zostać wykonane.Najpierw problemyGrupy z czymś do poprawienia otwierają się na górze, a każdy wiersz ma swoje źródło i poprawkę.DrogaSerwer główny, rejestr .com prowadzony przez Verisign, potem każdy serwer nazw pytany bezpośrednio: jego odpowiedź, numer seryjny i EDNS.Łańcuch zaufaniaPas DNSSEC obok drogi: zielony tam, gdzie łańcuch się trzyma, przerywany tam, gdzie się kończy, czerwony tam, gdzie pęka.
Kontrola kondycji DNS dla github.com. Wybierz numer, aby zobaczyć, co pokazuje każda część.

Jak powstaje ocena?

Litera wynika wyłącznie z poziomów tego, co nie przeszło, nigdy z tabeli punktów: każdy problem krytyczny to F, dwa błędy lub więcej to D, jeden błąd albo pięć ostrzeżeń lub więcej to C, trzy lub cztery ostrzeżenia to B, jedno lub dwa ostrzeżenia (albo same uwagi) to A, a nic powyżej poziomu info to A+.

Poziomy pochodzą od przywoływanego źródła: z domyślnego profilu Zonemaster tam, gdzie definiuje on test, a gdzie nie, z MUST lub SHOULD w RFC. Liczba na 100 tylko porządkuje domeny w obrębie jednej litery (100 − 30 za każdy problem krytyczny, 12 za błąd, 4 za ostrzeżenie, 1 za uwagę). Testy, których nasz serwer nie może wykonać, nigdy nie obciążają domeny; gdy nie da się wykonać co najmniej ćwierci z nich, ocena jest oznaczona jako częściowa.

  1. A+100nic powyżej poziomu infoINFO „zdecydowanie nie wskazuje na problem”sidn.nl100
  2. A90–991–2 ostrzeżenia lub tylko uwagiNOTICE „administrator strefy powinien o tym wiedzieć, ale nie musi to być w ogóle problem”github.com90example.com95bücher.de90
  3. B75–893–4 ostrzeżeniaWARNING „w pewnych okolicznościach będzie problemem, ale zwykły użytkownik raczej tego nie zauważy”cloudflare.com87google.com83
  4. C60–741 błąd lub 5 i więcej ostrzeżeńERROR „bardzo prawdopodobnie (lub na pewno) zaszkodzi działaniu strefy”brak w próbce
  5. D45–592 lub więcej błędówdnssec-failed.org55
  6. F0–44dowolny problem krytycznyCRITICAL „można zasadnie uznać, że strefa nie istnieje”domena .com44

wynik = 100 − 30 × krytyczne − 12 × błędy − 4 × ostrzeżenia − 1 × uwagi, w granicach przedziału litery

częściowaco najmniej ćwierć testów nie dało się wykonać z naszego serwera, więc ocena to zaznacza

Skala ocen z domenami, które sprawdziliśmy 23 października 2026, umieszczonymi według zapisanej oceny. Poziomy cytowane za definicjami ważności Zonemaster.

Czy rekordy NS strefy nadrzędnej i podrzędnej się zgadzają?

Powinny: rejestr (strefa nadrzędna) i strefa (podrzędna) publikują każdy własny zestaw NS, a RFC 1912 §2.8 mówi, że mają być takie same. Gdy rejestr wskazuje serwer, który nie odpowiada za strefę, jest to delegacja lame: serwer odpowiada REFUSED albo odpowiada bez flagi autorytatywności (AA).

Resolvery przechodzą do następnego serwera, więc jeden serwer lame kosztuje czas; gdy lame jest każdy wymieniony serwer, domena przestaje się rozwiązywać. Zonemaster ocenia nazwy podane tylko przez rejestr jako błąd (EXTRA_NAME_PARENT), nazwy podane tylko przez strefę jako uwagę, a brak jakiegokolwiek działającego serwera jako problem krytyczny.

github.comzgodne

Rejestr .com
  • ns-520.awsdns-01.net
  • ns-421.awsdns-52.com
  • ns-1707.awsdns-21.co.uk
  • ns-1283.awsdns-32.org
  • dns1–4.p08.nsone.net
Strefa
  • te same 8

odpowiedź z AA: 8 z 8

domena .netniezgodne

Rejestr .net
  • ns1.domaindirect.com
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.com
Strefa
  • ns1.hover.com
  • ns2.hover.com

brak wspólnej nazwy · ns2.domaindirect.com: REFUSED · 2 błędy

domena .comdelegacja lame

Rejestr .com
  • ns63.domaincontrol.comREFUSED
  • ns64.domaincontrol.comREFUSED
Strefa
  • nikt nie odpowiadaSERVFAIL

każdy serwer odpowiada REFUSED · resolvery odpowiadają SERVFAIL · CRITICAL

Trzy delegacje nagrane 23 października 2026. Nazwy dwóch uszkodzonych są zatajone; ich serwery nazw i odpowiedzi są prawdziwe.

Ile serwerów nazw potrzebuje domena?

Co najmniej dwa, a zalecane są trzy. RFC 1034 §4.1 wymaga, aby każda strefa była dostępna na co najmniej dwóch serwerach, a RFC 2182 §5 zaleca trzy dla większości stref na poziomie organizacji. Jeden serwer nazw to w Zonemaster błąd; dwa przechodzą z adnotacją info.

Ważniejsze od liczby jest to, gdzie stoją, dlatego test serwerów nazw patrzy też na ich sieci. Serwery w jednej sieci padają razem: Zonemaster ostrzega, gdy każdy adres leży w jednym systemie autonomicznym (IPV4_ONE_ASN), nawet przy hostach anycast, takich jak Google, Cloudflare czy Akamai, których każdy adres odpowiada z wielu miejsc. Anycast rozkłada obciążenie, ale to wciąż jeden operator.

  • google.com4 NS · 1 siećjedna sieć
  • github.com8 NS · 2 siecirozproszone
  • sidn.nl3 NS · 2 siecirozproszone
  • cloudflare.com5 NS · 1 siećjedna sieć
  • nasa.gov6 NS · 1 siećjedna sieć
  • example.com2 NS · 1 siećjedna sieć

AS1921 ipcomAS13335 CloudflareAS15169 GoogleAS16509 AmazonAS21342 AkamaiAS48283 SIDNAS62597 NS1

„Zaleca się zapewnienie trzech serwerów dla większości stref na poziomie organizacji, przy czym co najmniej jeden musi być dobrze oddalony od pozostałych”. RFC 2182 §5
Jedna kropka na serwer nazw, w kolorze sieci (AS), z której ogłaszany jest jego adres, z testów nagranych 23 października 2026. Jedna sieć to ostrzeżenie Zonemaster IPV4_ONE_ASN, z anycastem czy bez.

Czy wartości rekordu SOA są poprawne?

Jeśli ustawił je duży host DNS, prawie na pewno są w porządku, nawet gdy jakieś narzędzie je oznacza. Refresh, retry i expire sterują tylko serwerami pomocniczymi, które kopiują strefę transferem strefy. Minimum to TTL negatywnego cache (RFC 2308): jak długo resolvery pamiętają, że nazwa nie istnieje.

RIPE-203 (1999) zaleca refresh 86400, retry 7200, expire 3600000 i minimum 172800, przy czym ta ostatnia wartość pochodzi sprzed RFC 2308. Zonemaster ustala niższe minima: refresh 14400 i retry 3600 (uwagi), expire 604800 (jedyne ostrzeżenie), minimum od 300 do 86400 (uwaga). Domyślne wartości Cloudflare, Route 53 i Azure są poniżej minimów dla refresh i retry; 3-dniowy expire Google Cloud DNS to jedyne ostrzeżenie wśród dużych hostów.

refreshZonemaster ≥ 4 godz. · ◆ 1 dzieńretryZonemaster ≥ 1 godz. · ◆ 2 godz.expireZonemaster ≥ 7 dni · ◆ 41,7 dniaminimumZonemaster 5 min – 1 dzień · ◆ 2 dni
Cloudflare2,8 godz.40 min7 dni30 min2 uwagi
Amazon Route 532 godz.15 min14 dni1 dzień2 uwagi
Google Cloud DNS6 godz.1 godz.3 dni5 min1 ostrzeżenie
Azure DNS1 godz.5 min28 dni5 min2 uwagi
GoDaddy8 godz.2 godz.7 dni1 godz.zaliczone
Namecheap BasicDNS12 godz.1 godz.7 dni1 godz.zaliczone
google.com (własne)15 min15 min30 min1 min1 ostrzeżenie · 3 uwagi

poniżej minimum ZonemasterzaliczoneuwagaostrzeżenieRIPE-203 (1999)

Wartości każdego hosta tak, jak podawały je jego strefy przez dig 23 października 2026: Cloudflare, Route 53 i Google Cloud DNS zgadzają się ze swoją dokumentacją; strona pomocy GoDaddy podaje minimum 600, a jego przykładowe strefy podają 3600; nie znaleźliśmy opublikowanych wartości domyślnych Azure DNS ani Namecheap BasicDNS, więc pokazujemy wartości ich stref. Skala logarytmiczna od 1 minuty do 6 tygodni.

Test DNSSEC: DS, DNSKEY i podpisy

Test DNSSEC przechodzi łańcuch zaufania: rekord DS w rejestrze musi być skrótem klucza (DNSKEY) w strefie, ten klucz musi podpisywać zestaw kluczy strefy, a każdy podpis (RRSIG) musi się weryfikować i mieścić w okresie ważności. Ten test sam oblicza skrót i weryfikuje każdy podpis, a potem pyta Google Public DNS, czy strefa przechodzi walidację.

Przerwij dowolne ogniwo, a resolvery walidujące odpowiedzą SERVFAIL: domena zniknie dla wszystkich, którzy z nich korzystają. dnssec-failed.org, strefa testowa celowo utrzymywana w stanie zepsutym, pokazuje dwa przerwania naraz. Algorytmy są oceniane według rejestru IANA (RFC 9904): zalecane są 8, 13 i 15, a 5 i 7, które podpisują z SHA-1, nie mogą już być używane (RFC 9905) i Zonemaster ocenia je jako błąd.

cloudflare.combezpieczny

  1. DS 2371 w .comalgorytm 13 · SHA-256 · 329968…26F2B9
  2. skrót pasuje do klucza 2371
  3. DNSKEY 2371 · KSKflagi 257 · ECDSA P-256 (13)
  4. podpisuje zestaw kluczy · zostało 50,8 dnia z 61 dni
  5. DNSKEY 34505 · ZSKflagi 256 · ECDSA P-256 (13)
  6. podpisuje rekordy · SOA: zostało 1 dzień z 2 dni
  7. Google Public DNSflaga AD ustawiona: bezpieczny

dnssec-failed.orgfałszywy

  1. DS 42069 w .orgalgorytm 13 · SHA-256
  2. brak klucza 42069 w strefie
  3. DNSKEY 50719 · KSKprawdziwy KSK strefy (klucz podpisujący klucze)
  4. jego podpis zestawu kluczy wygasł 112 dni temu
  5. DNSKEY 32784 · ZSKpodpisuje SOA: ważny, zostało 5,7 dnia z 7 dni
  6. nie dociera do niego nic zaufanego
  7. Google Public DNSSERVFAIL; z flagą CD odpowiada: fałszywy (bogus)

Algorytmy podpisu (rejestr IANA, RFC 9904)

  • RECOMMENDED8 RSASHA256 · 13 ECDSAP256SHA256 · 15 ED25519używaj tych
  • MAY14 ECDSAP384SHA384 · 16 ED448dozwolone
  • NOT RECOMMENDED10 RSASHA512Zonemaster WARNING
  • MUST NOT5 RSASHA1 · 7 RSASHA1-NSEC3-SHA1 · 1 · 3 · 6 · 12RFC 9905 · Zonemaster ERROR

oba łańcuchy powyżej podpisują algorytmem 13

Dwa łańcuchy nagrane 23 października 2026: łańcuch cloudflare.com się trzyma; łańcuch dnssec-failed.org pęka na DS i ponownie na wygasłym podpisie.

DNS poczty: MX, SPF i DMARC

Testy poczty czytają to, co czytają serwery odbierające: rekordy MX (lub null MX, który mówi, że domena nie przyjmuje poczty, RFC 7505), jeden rekord SPF w limicie RFC 7208 wynoszącym 10 zapytań DNS i politykę DMARC (RFC 9989, który w maju 2026 zastąpił RFC 7489).

SPF jest obliczany, a nie tylko znajdowany: każdy include jest śledzony i liczony. Rekord github.com potrzebuje dokładnie 10 zapytań plus jednego pustego: jest poprawny, ale bez zapasu. Domena, która nigdy nie wysyła poczty, powinna to zadeklarować: example.com publikuje zestaw dla domeny zaparkowanej, czyli null MX, v=spf1 -all i p=reject. Szczegóły pokażą sprawdzanie SPF i sprawdzanie DMARC.

github.comwysyła i przyjmuje

MX
0 github-com.mail.protection.outlook.comMicrosoft 365 · 1 host · nie alias
SPF
v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.227.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all10 z 10 zapytań DNS1 z 2 pustych zapytań · poprawny, bez zapasu
DMARC
p=quarantine; sp=rejectraporty na 1 adres · subdomeny: reject

example.comzestaw dla domeny zaparkowanej

MX
0 .null MX: nie przyjmuje poczty (RFC 7505)
SPF
v=spf1 -allnie wysyła poczty · 0 zapytań
DMARC
p=reject; sp=rejectwszystko, co podaje się za example.com, jest odrzucane
github.com i example.com tak, jak były opublikowane 23 października 2026.

Sprawdź DNS z wiersza poleceń (dig)

Cztery kroki z dig i delv powtarzają rdzeń tego testu: przejdź delegację od roota, zapytaj jeden serwer nazw bezpośrednio z wyłączoną rekurencją, porównaj DS w rejestrze z kluczami strefy i pozwól resolverowi walidującemu ocenić łańcuch.

Dodaj +tcp, aby zobaczyć to, co widzi nasz serwer; bez niego testujesz UDP, czego narzędzie webowe w sieci Cloudflare zrobić nie może. W nagłówku odpowiedzi aa oznacza odpowiedź autorytatywną; REFUSED lub brak flagi aa u serwera podanego przez rejestr to delegacja lame.

Terminal · dig 9.20

$ dig +trace +tcp github.com NS
;; (skrócone)
com.          172800 IN NS a.gtld-servers.net.   ;; od h.root-servers.net 1
github.com.   172800 IN NS ns-520.awsdns-01.net. ;; od h.gtld-servers.net: 8 NS 2

$ dig @ns-421.awsdns-52.com github.com SOA +norec +tcp
;; flags: qr aa; QUERY: 1, ANSWER: 1 3
github.com.   900 IN SOA ns-1707.awsdns-21.co.uk. awsdns-hostmaster.amazon.com.
              1 7200 900 1209600 86400 4

$ dig @a.gtld-servers.net github.com DS +norec
;; status: NOERROR, ANSWER: 0 ;; brak DS: niepodpisana 5

$ delv @8.8.8.8 cloudflare.com SOA
; fully validated 6
cloudflare.com. 300 IN SOA ns3.cloudflare.com. dns.cloudflare.com.
                2417999975 10000 2400 604800 300
  1. Root odsyła .com do jej 13 serwerów
  2. Zestaw NS github.com w rejestrze, trzymany 2 dni
  3. aa: odpowiedź autorytatywna, nie cache
  4. SOA: numer seryjny 1, potem refresh, retry, expire, minimum
  5. Brak DS w .com: DNSSEC nie ma czego weryfikować
  6. delv zwalidował łańcuch od roota
Prawdziwe odpowiedzi dla github.com i cloudflare.com (23 października 2026), skrócone. Ponumerowane znaczniki odpowiadają objaśnieniom.

Dlaczego narzędzia do sprawdzania DNS dają różne wyniki?

Bo porównują z różnymi liczbami. Klasyczne narzędzia oznaczają domyślne wartości dostawców: intoDNS nazywa expire google.com równy 1800 sekund „NOT OK” i zgłasza błąd przy dwóch numerach seryjnych github.com, które są normalne przy dwóch hostach DNS. Zonemaster ocenia numery seryjne jako ostrzeżenie i rozpoznaje null MX; nasza własna pierwsza wersja myliła się w obu przypadkach.

Widzą też sieć z różnych miejsc. Zonemaster (AFNIC i szwedzka fundacja Internetstiftelsen) pyta przez UDP i TCP, po IPv4 i IPv6. Ten test działa na brzegu sieci Cloudflare: pyta tylko przez TCP, nie łączy się po IPv6 i nie może połączyć się z własnymi adresami Cloudflare, więc takie serwery odczytuje przez 1.1.1.1, a ich testy oznacza jako nie testowano, nigdy jako niezaliczone. Jako alternatywa dla intoDNS pokazuje źródło każdego poziomu zamiast gołego OK lub NOT OK.

PrzypadekintoDNSZonemasterDNS Robot v1Ten test
github.comdwa numery seryjne SOA (dwa hosty DNS)błąd“Looks like your nameservers do not agree on the SOA serial.”ostrzeżenieMULTIPLE_SOA_SERIALSniezaliczony“Serial mismatch detected: 1656468023 vs 1.”ostrzeżeniewyjaśnione: jeden numer seryjny na host DNS
google.comexpire w SOA: 1800 snie OK“Your SOA EXPIRE number is: 1800. That is NOT OK”ostrzeżenieEXPIRE_MINIMUM_VALUE_LOWERniezaliczony“too low (min recommended: 14 days)”ostrzeżeniez objaśnieniem, na co wpływa expire
example.compusty rekord MX (0 .)błąd“0 No A Record (no glue either)”informacjaZ09_VALID_NULL_MXzaliczony“Found 1 MX record(s)”zaliczonynull MX rozpoznany
cloudflare.comretry w SOA: 2400 s—brak cytatuuwagaRETRY_MINIMUM_VALUE_LOWERniezaliczony“too high (max recommended: 15min)”uwagadomyślna wartość Cloudflare
cloudflare.compodpisana DNSSECniesprawdzanebrak testu DNSSECzaliczonyDNSSEC02 · 05 · 08: łańcuch zweryfikowanyostrzega“DNSSEC does not appear to be enabled for this domain.”zaliczonyDS → KSK → RRSIG zweryfikowane, Google waliduje
Te same domeny w czterech narzędziach. Wyniki intoDNS i v1 cytowane z ich stron i odpowiedzi z 22–23 października 2026; poziomy Zonemaster z jego specyfikacji testów. Ostatnia kolumna to ten test: alternatywa dla intoDNS, która ocenia każde ustalenie na poziomie wyznaczonym przez jego źródło.

Kontrola kondycji DNS: pytania

Czym jest kontrola kondycji DNS?

Kontrola kondycji DNS, czyli walidacja DNS, sprawdza, czy DNS domeny jest skonfigurowany tak, aby cały internet mógł do niej dotrzeć: delegację w rejestrze, każdy serwer nazw, rekord SOA, DNSSEC i rekordy poczty. Każde ustalenie jest oceniane według tego, jak bardzo może zaszkodzić, od info do krytycznego, a ten walidator DNS pokazuje regułę, którą stosuje (test Zonemaster lub sekcję RFC), oraz poprawkę.

Czy walidacja domeny to to samo co sprawdzanie DNS?

Nie zawsze. „Walidacją domeny” nazywa się też sprawdzenie, które urząd certyfikacji wykonuje przed wystawieniem certyfikatu DV, oraz rekord TXT, o który prosi Google Workspace lub Microsoft 365, aby potwierdzić, że domena jest twoja. Ten walidator sprawdza DNS domeny: delegację, serwery nazw, SOA, DNSSEC i rekordy poczty. W sprawie certyfikatu zajrzyj do testu certyfikatu SSL.

Czym jest delegacja lame i jak ją naprawić?

Delegacja lame to serwer nazw wymieniony przez rejestr, który nie odpowiada za twoją domenę: mówi REFUSED albo odpowiada bez autorytetu. Napraw ją tam, gdzie jest niezgodność: dodaj strefę u tego hosta DNS albo zmień serwery nazw u rejestratora na te, które mają strefę. Jeśli każdy wymieniony serwer jest lame, domena w ogóle się nie rozwiązuje.

Mój host DNS używa anycastu. Skąd ostrzeżenie o jednej sieci?

Bo jeden operator to jeden punkt awarii. Anycast pozwala każdemu adresowi odpowiadać z wielu miejsc, co chroni przed awarią jednej lokalizacji, ale nie przed awarią samego dostawcy ani błędem w jego konfiguracji. Dlatego Zonemaster utrzymuje IPV4_ONE_ASN na poziomie ostrzeżenia, a RFC 2182 prosi o serwery w różnych sieciach. Drugi host DNS w innej sieci usuwa to ostrzeżenie.

Liczniki SOA są oznaczone. Czy muszę je zmienić?

Zwykle nie. Refresh, retry i expire mają znaczenie tylko dla serwerów pomocniczych, które kopiują twoją strefę transferem strefy; duże hosty, takie jak Cloudflare i Route 53, nie używają ich dla twojej strefy, a ich domyślne wartości są w porządku. Jedynie expire poniżej tygodnia Zonemaster uznaje za ostrzeżenie. Zmieniaj wartości tylko wtedy, gdy sam prowadzisz serwer główny i pomocnicze.

Dlaczego niektóre testy są oznaczone jako „nie testowano”?

Bo nasz serwer nie mógł ich wykonać, a nie dlatego, że coś jest nie tak. Działa w sieci Cloudflare, z której nie da się otworzyć połączenia z własnymi adresami Cloudflare, pyta tylko przez TCP i nie łączy się po IPv6. Takie serwery odczytuje zamiast tego przez resolver Cloudflare 1.1.1.1. Nietestowane testy nigdy nie obniżają oceny; gdy jest ich co najmniej ćwierć, ocena jest oznaczona jako częściowa.

Dlaczego moje serwery nazw podają różne numery seryjne SOA?

Albo serwer pomocniczy jeszcze nie nadrobił zmiany, albo domena korzysta z dwóch hostów DNS, które nie przekazują sobie strefy, więc każdy trzyma własny numer seryjny. To drugie jest normalne: serwery Route 53 domeny github.com podają 1, a jej serwery NS1 1656468023. Zonemaster oznacza każdą różnicę jako ostrzeżenie; my wyjaśniamy, który to przypadek.

Czy to test DNSSEC i czy brak DNSSEC obniża ocenę?

Tak: porównuje DS w rejestrze z kluczami strefy i weryfikuje każdy podpis, a potem pyta Google Public DNS. Niepodpisana strefa to jedno ostrzeżenie Zonemaster (DS07_NOT_SIGNED), więc ocena zostaje co najwyżej na poziomie A. Zepsuty łańcuch jest znacznie gorszy niż żaden: resolvery walidujące odrzucają domenę, a ten błąd obniża ocenę do C lub niżej.

Jak często sprawdzać DNS domeny?

Po każdej zmianie serwerów nazw, DNSSEC lub rekordów poczty oraz przed przeprowadzką do nowego hosta DNS lub rejestratora i po niej. Poza tym wystarczy raz w miesiącu, aby wyłapać wygasający podpis, serwer nazw, który przestał odpowiadać, albo zmianę w rejestrze, której nie robiłeś. Każdy wynik ma własny link, więc możesz porównywać kolejne testy.

Czy przechowujecie domeny, które sprawdzam?

Nie. Test działa na naszym serwerze na brzegu sieci Cloudflare i pyta root, rejestr, twoje serwery nazw, Google Public DNS oraz resolver Cloudflare; nic nie jest zapisywane w logach razem z twoim adresem. Gotowy wynik jest przechowywany przez 10 minut, aby powtórka lub udostępniony link odpowiadały od razu, a potem usuwany. Twoje serwery nazw dostają od naszego serwera około 20 pytań na test.

Powiązane narzędzia DNS