Walidator składni strefy DNS (BIND)

Sprawdź poprawność pliku strefy DNS (BIND format): rekordy A, AAAA, MX, CNAME, TXT, SOA, NS. Detekcja błędów składni, duplikatów i TTL. Bezpłatnie.

Bezpieczne (SSL)

Przetwarzanie Lokalne

100% Darmowe

Przejdź do narzędzia

Instrukcja

1

Wprowadź dane
Wpisz treść, wklej tekst lub załaduj plik z dysku.
2

Kliknij przycisk
Narzędzie natychmiast przetworzy Twoje dane w przeglądarce.
3

Pobierz wynik
Skopiuj gotowy tekst lub zapisz plik na urządzeniu.

                                                function runTool() {

                                                  return "Wynik gotowy w 0.1s";

                                                }

Ustawienia

Zone

Tryb ścisły Opcja narzędzia

Wynik

BIND Zone File Syntax Checker Report
====================================
Lines: 23
Strict mode: ON
Detected $ORIGIN: example.com.
Detected $TTL: 3600

Summary: 0 error(s), 0 warning(s)

No issues detected. This looks safe to load (still run named-checkzone for final verification).

Oceń to narzędzie:

Powiązane narzędzia

Inne narzędzia, które mogą Ci się przydać

Walidator pliku strefy DNS BIND – błędy zanim na serwer

Błąd w pliku strefy DNS (zone file) może sprawić, że cała domena przestanie działać. Narzędzie parsuje składnię pliku strefy w formacie BIND 9 i wykrywa: błędy typograficzne, nieprawidłowe rekordy, konflikty CNAME, brak SOA/NS i problemy z TTL – zanim wgrasz plik na serwer DNS.

walidator strefy DNS BIND zone file checker plik zone DNS błędy sprawdź DNS zone

Struktura pliku strefy BIND

$ORIGIN example.com. (bazowa domena). $TTL 3600 (domyślny TTL). SOA (Start of Authority): primary NS, email admina, serial, refresh, retry, expire, minimum TTL. NS records: co najmniej 2 serwery autorytatywne. A/AAAA: IPv4/IPv6 hosta. MX: serwery pocztowe z priorytetem. TXT: SPF, DKIM, DMARC, weryfikacje. CNAME: alias (nie może koegzystować z innymi rekordami na tym samym węźle).

Typowe błędy składni

Brak kropki na końcu pełnej nazwy: mail.example.com (błąd) vs mail.example.com. (poprawne). Zły format SOA (kolejność pól). Serial nie zaktualizowany po zmianach (bind nie przeładuje). MX wskazujący na CNAME (zakazane przez RFC). CNAME na apex domeny (@) – zakazane (użyj ALIAS/ANAME). Błędny format IPv6 (podwójny ::).

Rekordy specjalne

SPF: "v=spf1 include:_spf.google.com ~all" jako TXT. DKIM: długi klucz public key podzielony na segmenty (max 255 znaków na string). DMARC: _dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]". CAA: autoryzacja CA do wystawienia certyfikatu SSL.

Narzędzia testowania DNS

named-checkzone (BIND): named-checkzone example.com /etc/bind/db.example.com. named-checkconf: walidacja named.conf. dig +short example.com @ns1.example.com: test po wgraniu. Online: mxtoolbox.com, dnschecker.org. Narzędzie online zastępuje named-checkzone bez instalacji BIND.

Jak walidator sprawdza składnię pliku strefy BIND

Walidator czyta plik strefy linia po linii i rozbija każdy rekord na tokeny: nazwę węzła, klasę (zwykle IN), typ rekordu i dane. Zanim zacznie oceniać treść, rozwija dyrektywy sterujące — $ORIGIN staje się bazą dla nazw względnych, a $TTL domyślną wartością czasu życia dla rekordów, które nie podają własnego TTL. Nazwa zakończona kropką jest traktowana jako pełna (FQDN), a nazwa bez kropki jest doklejana do $ORIGIN. Ten mechanizm decyduje o tym, czy zapis mail.example.com w pliku oznacza host w strefie example.com, czy zupełnie inną nazwę.

W drugim kroku parser składa rekordy wielolinijkowe — pola rekordu SOA mogą być rozdzielone średnikami, zamknięte w nawiasach i rozbite na kilka linii. Walidator pilnuje kompletu i kolejności tych pól: primary NS, adres e-mail administratora, serial, refresh, retry, expire oraz minimum TTL. Każde odstępstwo — brakujący nawias, kropka zamiast małpy w adresie administratora, pomylona kolejność — kończy się błędem składni ze wskazaniem numeru linii, bo taki plik nie wczyta się na serwerze.

Na końcu działa warstwa semantyczna, czyli kontrole zależności między rekordami. Sprawdzana jest obecność SOA i co najmniej dwóch rekordów NS, konflikty CNAME (alias nie może współistnieć z innymi typami w tym samym węźle, a na apex domeny jest zabroniony), MX kierujący na CNAME oraz format IPv6, np. podwójne :: w jednym adresie. Wyniki są dzielone na błędy składni — plik się nie wczyta — i ostrzeżenia: plik przejdzie, ale strefa będzie odpowiadać błędnie.

Przykład: sprawdzenie strefy example.com krok po kroku

Wklejasz zawartość pliku strefy — na przykład strefy example.com z dyrektywami $ORIGIN example.com. oraz $TTL 3600 na początku pliku.
Parser rozwija dyrektywy i nazwy względne. Nazwy bez końcowej kropki są doklejane do $ORIGIN, więc skrót www walidator rozumie jako www.example.com. Zapis mail.example.com bez kropki zostanie zgłoszony jako nazwa względna, czyli nie ten host, o który chodziło.
Kontrola bloku SOA. Rekord SOA musi zawierać primary NS, adres e-mail administratora, serial, refresh, retry, expire i minimum TTL w tej kolejności. Walidator wskazuje numer linii przy każdym odchyleniu, w tym przy niedomkniętym nawiasie.
Weryfikacja rekordów NS i pozostałych typów. Strefa musi mieć co najmniej dwa serwery autorytatywne; A i AAAA wymagają poprawnego formatu IPv4 lub IPv6, MX — priorytetu i nazwy serwera pocztowego, TXT — wartości w cudzysłowie.
Kontrola konfliktów i przypadków zabronionych. Jeśli CNAME dzieli węzeł z rekordem A, MX albo TXT, pojawia się błąd konfliktu. Osobno sprawdzane są: CNAME na apex domeny (@) oraz MX kierujący na alias CNAME.
Poprawiasz plik i uruchamiasz sprawdzanie ponownie. Po dodaniu kończącej kropki w pełnych nazwach, domknięciu nawiasów w SOA i usunięciu konfliktów plik przechodzi bez błędów — dopiero wtedy warto wgrać go na serwer DNS.

Co dokładnie jest sprawdzane w składni

Element składni	Co sprawdza walidator	Skutek przeoczenia
Nazwa FQDN i końcowa kropka	czy pełna nazwa jest zamknięta kropką i nie zostanie doklejona do $ORIGIN	rekord wskazuje inny host niż zamierzony
Blok SOA	komplet pól: primary NS, e-mail admina, serial, refresh, retry, expire, minimum TTL; nawiasy i kolejność	plik nie wczyta się, strefa nie wystartuje
Serial	obecność i format liczby oraz to, czy został podniesiony po zmianach	serwer nie przeładuje strefy mimo poprawnych rekordów
Rekordy NS	co najmniej dwa serwery autorytatywne dla strefy	awaria jednego serwera odcina rozwiązywanie nazw
CNAME w węźle	czy alias CNAME nie współistnieje z innymi typami rekordów	sprzeczne odpowiedzi albo błąd wczytywania strefy
CNAME na apex (@)	czy alias nie jest ustawiony na samą domenę	naruszenie RFC; zamiast tego stosuje się ALIAS/ANAME
MX kierujący na CNAME	czy celem rekordu MX nie jest alias CNAME	zakazane przez RFC, doręczanie poczty zawodzi
TXT i klucz DKIM	czy jeden string nie przekracza 255 znaków i czy długi klucz jest podzielony na segmenty	klucz weryfikacyjny jest obcięty lub nieprawidłowy

Jak używać walidatora strefy w praktyce

Zaczynaj plik od $ORIGIN i $TTL. Bez tych dyrektyw każda nazwa względna i każdy rekord bez własnego TTL są interpretowane inaczej, niż zakładasz, a walidator słusznie to sygnalizuje.
Kończ kropką każdą pełną nazwę. Dotyczy to celów MX, wartości NS, adresów w SOA i nazw w CNAME. To najczęstsze źródło cichych błędów w plikach stref.
Zamykaj SOA w nawiasach. Rozbicie długiego rekordu na kilka linii ułatwia czytanie, ale wymaga domknięcia nawiasu i spójnych separatorów — inaczej parser zatrzyma się na pierwszym polu.
Podnoś serial przed każdym wgraniem. Walidator składni nie zrobi tego za Ciebie; bez zmiany seriala serwery secondary nie pobiorą nowej wersji strefy.
Czytaj ostrzeżenia, nie tylko błędy. Konflikt CNAME czy MX na CNAME potrafi przejść kontrolę składni, a jednocześnie zepsuć działanie domeny i poczty.

Czego walidator nie sprawdzi

Nie testuje działającej strefy. Narzędzie analizuje wyłącznie tekst pliku — nie odpytuje serwerów autorytatywnych i nie potwierdzi, czy plik został wgrany, czy strefa została przeładowana.
Nie weryfikuje delegacji. Poprawna składnia nie oznacza, że serwery NS są wpisane u rejestratora i że strefa nadrzędna kieruje na właściwe adresy.
Nie ocenia treści merytorycznej. Walidator nie wie, czy adresy A, AAAA, MX oraz wpisy SPF, DKIM i DMARC są aktualne i zgodne z Twoją infrastrukturą — sprawdza tylko ich format.
Obsługuje format BIND 9. Pliki z niestandardowymi dyrektywami lub rozszerzeniami innych implementacji DNS mogą dawać fałszywe błędy, mimo że wczytają się na docelowym serwerze.

Najczęstsze pytania

Co to jest serial number i dlaczego jest ważny?

Serial w rekordzie SOA: monotonicznie rosnąca liczba (np. YYYYMMDDNN: 2024060801). Secondary DNS serwery sprawdzają serial – jeśli primary ma wyższy, pobierają aktualizację (AXFR/IXFR). Bez inkrementacji seriala: zmiany nie propagują się na secondary serwery!

Ile TTL ustawić dla rekordów?

TTL krótki (300s = 5min): gdy planujesz zmianę – łatwy rollback. Wada: więcej zapytań do DNS. TTL długi (86400s = 1 dzień): mniejszy ruch, szybsze odpowiedzi (cache). Zalecenia: A/AAAA = 3600s, MX = 3600s, TXT/SPF = 300-3600s, NS = 86400s. Przed migracją: zmień TTL na 300s na 2 dni przed migracją.

Dlaczego CNAME nie może być na apex (root) domenie?

RFC 2181: CNAME nie może koegzystować z innymi typami rekordów. Apex domeny (example.com.) musi mieć SOA i NS rekordy – więc CNAME jest niemożliwe. Rozwiązanie: ALIAS (PowerDNS), ANAME (Route 53) lub redirect HTTP. Cloudflare CNAME Flattening rozwiązuje ten problem transparentnie.

Jak sprawdzić propagację DNS po zmianie?

dig example.com @8.8.8.8 (Google DNS). dig example.com @1.1.1.1 (Cloudflare). dnschecker.org: 20+ lokalizacji na raz. Czas propagacji: min TTL poprzedniego rekordu (może być kilka godzin do doby). "Propagacja DNS" to mit – to wygasanie cache, nie aktywne rozsyłanie.

Jak skonfigurować DNSSEC?

DNSSEC podpisuje cyfrowo rekordy DNS. named-keygen generuje klucze ZSK i KSK. Pliki strefy: signed zone + RRSIG + DNSKEY + DS. Konfiguracja BIND: dnssec-enable yes; dnssec-validation yes. Alternatywa: Cloudflare One-Click DNSSEC (przejmuje signing).

Dlaczego brak kropki na końcu nazwy psuje strefę?

Nazwa bez końcowej kropki jest traktowana jako względna i zostaje doklejona do $ORIGIN. Zapis mail.example.com bez kropki zamieni się więc w mail.example.com.example.com. — host, którego nie ma, i rekord przestaje działać zgodnie z zamysłem.

Czy CNAME może wskazywać na apex domeny?

Nie. Rekord CNAME na apex (@) jest zakazany przez RFC, bo wyklucza współistnienie SOA i NS w tym samym węźle. W takich przypadkach stosuje się mechanizmy typu ALIAS lub ANAME, jeśli dostawca DNS je udostępnia.

Jak zapisać długi klucz DKIM, żeby plik strefy się wczytał?

Klucz publiczny dzieli się na segmenty i każdy zamyka w cudzysłowie — pojedynczy string nie może przekroczyć 255 znaków. Walidator wychwyci zarówno przekroczenie limitu, jak i brak cudzysłowu.

Walidator zgłasza MX wskazujący na CNAME — czy to na pewno błąd?

To niezgodność z RFC, nie tylko ostrzeżenie stylistyczny. Cel rekordu MX powinien być nazwą z rekordem A lub AAAA; wskazanie aliasu CNAME powoduje problemy z doręczaniem poczty i jest traktowane jako błąd konfiguracji.

Czy po poprawieniu pliku trzeba zmienić serial w SOA?

Tak. Serial to licznik wersji strefy — bez jego podniesienia serwery secondary nie uznają pliku za nowszy i nie pobiorą zmian. Sam poprawny składniowo plik nie wystarczy, żeby strefa się zaktualizowała.

Powiązane narzędzia: wyszukiwarka WHOIS, walidator robots.txt i DNS lookup.