Serwery · Strefa DNS dla BIND

Strefa DNS w BIND — kompletny przewodnik z darmowym generatorem

Plik strefy DNS to tekstowy dokument, który mówi autorytatywnemu serwerowi nazw wszystko o Twojej domenie: jakie IP serwuje stronę, który host przyjmuje pocztę, które serwery DNS są odpowiedzialne za odpowiedzi i jak skonfigurowany jest mechanizm antyspoofingowy (SPF, DKIM, DMARC). Ręczne pisanie strefy to zadanie, w którym jedna brakująca kropka kończąca FQDN zamienia example.com. w example.com.example.com. i sypie połowę rekordów, a źle dobrany numer seryjny SOA blokuje aktualizację na slave'ach przez tydzień. Ten przewodnik prowadzi krok po kroku przez działającą konfigurację strefy BIND — SOA, NS, A, MX, rekordy uwierzytelniania poczty i rekord CAA pod Let's Encrypt — wraz z listą błędów, które zjadają popołudnie, gdy pominiesz walidację.

Punktem odniesienia jest RFC 1035 (oryginalna specyfikacja DNS), dokumentacja BIND 9 oraz aktualne best practices dla SPF (RFC 7208) i DMARC (RFC 7489). Przykłady zakładają Ubuntu 22.04/24.04 z BIND 9.18 lub nowszym, ale składnia samego pliku strefy jest identyczna na każdym systemie operacyjnym.

Generator DNS Zone — co robi i komu się przyda

Generator stref DNS na vps-web.com przyjmuje parametry, które zmieniają się między domenami — IP głównego, zapasowego i trzeciego serwera DNS, nazwę domeny apex, IP serwera WWW oraz opcjonalne IP serwera pocztowego — i produkuje dwa pliki: fragment do named.conf.local definiujący strefę dla BIND oraz faktyczny plik strefy db.example.com z prefillowanymi rekordami SOA, NS, MX, A, CNAME, CAA, SPF i DMARC. Wklejasz oba na serwer BIND, uruchamiasz named-checkzone, przeładowujesz i jesteś autorytatywny dla domeny.

Narzędzie jest celowane w administratora, który przenosi domenę z hostowanego panelu DNS na własną infrastrukturę BIND, dewelopera stawiającego nowy VPS i chcącego sensownego startowego pliku strefy zamiast kopiowania ze starych blogów, oraz każdego, kto ma dość zapominania o bumpnięciu numeru seryjnego SOA po każdej edycji. Formularz jest celowo krótki — trzy IP, nazwa domeny, dwa opcjonalne pola — bo cała reszta to albo stała konwencja (interwały refresh/retry/expire, TTL strefy), albo wartość, którą da się wyprowadzić z reszty (adres SOA, alias www, wartość ip4: w SPF).

To, co generator oszczędza, to drobne, ale narastające koszty literówek: kropka znikająca z końca ns1.example.com, rekord SPF kończący się na +all zamiast -all, rekord DMARC bez obowiązkowego prefiksu v=DMARC1. Każda z tych pomyłek to pół godziny debugowania, jeśli nie wyłapiesz jej na pierwszym czytaniu.

Praktyka — budujemy strefę BIND krok po kroku

Co zbudujemy: pełną strefę forward dla example.com na głównym serwerze nazw 213.76.166.194, z dwoma slave'ami, serwerem WWW pod 213.76.166.193, serwerem pocztowym pod 51.75.55.91, opublikowanymi rekordami SPF i DMARC oraz rekordem CAA ograniczającym wydawanie certyfikatów do Let's Encrypt. Cel końcowy: strefa ładuje się czysto pod named-checkzone i poprawnie odpowiada na dig.

Krok 1 — Lokalizacja pliku i deklaracja strefy w BIND

Strefy forward na Debianie i Ubuntu mieszkają konwencjonalnie w /etc/bind/zones/, z nazwą pliku w formacie db.<domena>. Samą strefę trzeba zadeklarować w /etc/bind/named.conf.local, żeby BIND wiedział, że jest dla niej autorytatywny.

sudo mkdir -p /etc/bind/zones
sudo chown bind:bind /etc/bind/zones

// /etc/bind/named.conf.local
zone "example.com" {
    type master;
    file "/etc/bind/zones/db.example.com";
    allow-transfer {
        89.117.172.182;
        51.75.55.91;
    };
    also-notify {
        89.117.172.182;
        51.75.55.91;
    };
};

type master czyni ten serwer autorytatywnym dla strefy — slave'y będą ją od niego ściągać. allow-transfer to twarda lista ACL: tylko wymienione IP mogą zażądać pełnego transferu strefy (AXFR), więc bez tej dyrektywy każdy może wykonać dig AXFR example.com @twój-ns i przejść po całym Twoim DNS. also-notify sprawia, że master wysyła komunikat NOTIFY do slave'ów po każdej zmianie strefy — w połączeniu z podbiciem numeru seryjnego wymusza natychmiastowy transfer, zamiast czekania przez czas refresh.

Krok 2 — Nagłówek pliku strefy: $TTL, SOA i sztuczka z e-mailem jako kropką

; /etc/bind/zones/db.example.com
;
; Plik strefy BIND dla example.com
;
$TTL    3600
@   IN  SOA ns1.example.com. root.example.com. (
            2026050701 ; numer seryjny
            3600       ; refresh
            7200       ; retry
            2419200    ; expire
            7200       ; Negative Cache TTL
);

$TTL 3600 ustawia domyślny czas życia rekordu na godzinę — tyle resolvery będą trzymać odpowiedź w cache. Niskie TTL oznacza, że zmiany propagują się szybko, ale ruch DNS rośnie. 3600 to sensowny default; obniż do 300 dzień przed migracją.

@ to skrót dla apexu strefy (example.com.). IN to klasa — Internet, jedyna, której ktokolwiek używa w 2026. SOA (Start of Authority) to najważniejszy rekord w strefie: identyfikuje główny serwer nazw i osobę odpowiedzialną.

Dwa pola po SOA wyglądają nietypowo. ns1.example.com. to nazwa głównego serwera nazw — zwróć uwagę na kropkę na końcu, która czyni ją FQDN; bez kropki BIND dopisałby origin i wyszłoby Ci ns1.example.com.example.com. root.example.com. to adres e-mail administratora strefy, z @ zamienionym na kropkę. Czytaj to jako root@example.com. Ta konwencja istnieje, bo @ jest już znakiem specjalnym w plikach strefy.

Pięć liczb w nawiasach to timery SOA:

Numer seryjny (2026050701) — wersja strefy w formacie RRRRMMDDnn. Slave'y porównują tę liczbę z własną; jeśli na masterze jest wyższa, ściągają strefę. Bumpnij po każdej edycji — bez tego zmiany nie spropagują się.
Refresh (3600) — jak często slave'y sprawdzają u mastera nowy numer seryjny.
Retry (7200) — ile slave czeka przed ponowną próbą po nieudanym refresh.
Expire (2419200) — 28 dni. Jeśli slave nie może się skontaktować z masterem przez ten czas, przestaje odpowiadać autorytatywnie. Rekomendacja RFC 1912 to 2–4 tygodnie.
Negative Cache TTL (7200) — jak długo resolvery cache'ują odpowiedź NXDOMAIN. W starszych dokumentach nazywany „minimum TTL"; redefiniowany przez RFC 2308.

Krok 3 — Rekordy NS i MX

; Rekordy NS
@   IN  NS  ns1.example.com.
@   IN  NS  ns2.example.com.
@   IN  NS  ns3.example.com.

; Rekord MX
@   IN  MX  10 mx.example.com.

Rekordy NS listują wszystkie serwery nazw autorytatywne dla strefy. Muszą zgadzać się z tym, co ustawione u rejestratora („glue" w domenie nadrzędnej) — niezgodność produkuje delegację, której część resolverów będzie obsługiwać, a część odrzuci. Prawie zawsze chcesz co najmniej dwa rekordy NS dla redundancji; trzy to komfort.

MX 10 mx.example.com. deklaruje serwer pocztowy. 10 to priorytet — przy wielu rekordach MX serwery pocztowe próbują w kolejności od najniższego numeru. Jeden MX wystarcza w większości przypadków; backup MX dodawaj tylko wtedy, gdy masz gdzie kolejkować i forwardować pocztę.

Krok 4 — Rekordy A i CNAME dla strony

; Rekordy hostów
@   IN  A       213.76.166.193
www IN  CNAME   @

@ IN A 213.76.166.193 kieruje apex (example.com) na IPv4 serwera WWW. Jeśli serwujesz też IPv6, dodaj równoległy rekord AAAA.

www IN CNAME @ czyni www.example.com aliasem apexu. @ po prawej stronie rozwija się do example.com., więc www zwraca ten sam rekord A co apex. CNAME-y oszczędzają aktualizację dwóch miejsc, gdy zmienia się IP WWW.

Częsta pułapka: CNAME można położyć na www, ale nigdy na samym apexie. RFC 1912 zabrania CNAME na apexie strefy, bo apex musi zawierać rekordy SOA i NS, a CNAME nie może koegzystować z innymi typami rekordów na tej samej nazwie. Jeśli musisz aliasować apex (klasyczne: „goła domena" wskazująca na CDN), potrzebujesz rozszerzenia specyficznego dla dostawcy — ALIAS albo ANAME, a nie klasycznego CNAME.

Krok 5 — Glue records: rekordy A dla ns1, ns2, ns3

; Rekordy A serwerów nazw (glue)
ns1 IN  A   213.76.166.194
ns2 IN  A   89.117.172.182
ns3 IN  A   51.75.55.91

To są tak zwane glue records (rekordy klejące). Jeśli Twoje serwery nazw mieszkają wewnątrz domeny, którą obsługują (typowy układ — ns1.example.com jest autorytatywny dla example.com), pojawia się problem jajka i kury: żeby znaleźć serwer nazw, resolver musi go zapytać. Glue records to rozwiązują, bo są dołączane do odpowiedzi referral z domeny nadrzędnej — resolver dostaje IP bez rekurencyjnego zapytania. Upewnij się, że te IP są identyczne z odpowiadającymi rekordami u rejestratora — to tam mieszka glue z poziomu domeny .com.

Krok 6 — SPF, DMARC i CAA: nowoczesne rekordy dla poczty i TLS

; Rekord A i CAA dla serwera pocztowego
mx  IN  A       51.75.55.91
mx  IN  CAA     0 issue "letsencrypt.org"

; Rekord SPF
@   IN  TXT     "v=spf1 ip4:51.75.55.91 -all"

; Rekord DMARC
_dmarc IN TXT   "v=DMARC1; p=reject; adkim=r; aspf=r;"

Rekord A dla mx daje serwerowi pocztowemu adres — to host, na który wskazuje rekord MX.

mx IN CAA 0 issue "letsencrypt.org" to rekord Certification Authority Authorization, zdefiniowany w RFC 8659. Mówi: tylko Let's Encrypt może wystawiać certyfikaty dla tej nazwy. Publiczne CA są zobowiązane sprawdzać CAA przed wystawieniem certyfikatu, więc próba wystawienia z DigiCert byłaby odrzucona. 0 to pole flags; issue to tag. Dodaj issuewild, jeśli chcesz osobno kontrolować wystawianie wildcardów.

Rekord SPF to zwykły wpis TXT na apexie. v=spf1 ip4:51.75.55.91 -all mówi: poczta z example.com jest legalna tylko z 51.75.55.91, wszystko inne ma być twardo odrzucone. -all (hard fail) jest ostrzejsze niż ~all (soft fail) — zacznij od ~all, dopóki ustalasz, kto faktycznie wysyła pocztę w Twoim imieniu. Co krytyczne: w jednej domenie może istnieć tylko jeden rekord SPF. Jeśli dodasz drugi TXT zaczynający się od v=spf1, serwery odbiorcze albo wybiorą losowo jeden z nich, albo odrzucą oba — zależnie od implementacji.

Rekord DMARC mieszka pod _dmarc.example.com i mówi serwerom odbiorczym, co zrobić, gdy SPF lub DKIM nie zgadza się alignmentem. p=reject to najostrzejsza polityka — odrzuć niedopasowaną pocztę. adkim=r i aspf=r to tryby relaxed alignment. Dla zupełnie nowej konfiguracji Google rekomenduje zacząć od p=none, monitorować raporty przez 48–72 godziny przez tag rua= i dopiero potem podnosić do quarantine i reject.

DKIM nie jest tu generowany, bo klucz publiczny pochodzi z serwera pocztowego (Postfix/OpenDKIM albo Twojego dostawcy). Dodasz go osobno jako rekord TXT pod selector._domainkey.example.com, gdy serwer pocztowy poda wartość.

Krok 7 — Walidacja i przeładowanie

sudo named-checkzone example.com /etc/bind/zones/db.example.com
sudo named-checkconf
sudo systemctl reload bind9

named-checkzone parsuje plik strefy tak samo jak BIND i zgłasza literówki, zanim położą serwer. named-checkconf waliduje składnię named.conf.local. Reload (a nie restart) ponownie wczytuje strefę bez zrzucania zapytań w locie. Po reloadzie zweryfikuj:

dig +short SOA example.com @127.0.0.1
dig +short MX example.com @127.0.0.1
dig +short TXT example.com @127.0.0.1

Numer seryjny w odpowiedzi SOA powinien zgadzać się z tym, co wpisałeś w pliku. Jeśli się nie zgadza — BIND nie podniósł edycji, najczęściej dlatego, że zapomniałeś bumpnąć numer seryjny.

Częste błędy i pułapki

Brak kropki kończącej FQDN

Bug numer jeden w plikach strefy. ns1.example.com. (z kropką) to FQDN; ns1.example.com (bez kropki) dostaje doklejony origin i staje się ns1.example.com.example.com.. named-checkzone czasami to wyłapuje jako not a valid hostname, ale tylko czasami — jeśli wynikowa nazwa jest składniowo legalna, BIND załaduje strefę i Twoje zapytania będą po cichu zwracać śmieci.

Niezaktualizowany numer seryjny SOA

Edycje w pliku strefy są niewidoczne, dopóki numer seryjny nie wzrośnie. Slave'y porównują numery i pobierają nową kopię tylko wtedy, gdy nowy jest wyższy. Konwencja RRRRMMDDnn (np. 2026050701 dla pierwszej edycji 7 maja 2026) trzyma porządek na lata; zwykłe inkrementowanie liczb całkowitych też działa, ale łatwo się gubi.

Dwa rekordy SPF w jednej domenie

RFC 7208 mówi wprost: domena MUSI publikować maksymalnie jeden rekord SPF (v=spf1). Dodanie drugiego to najczęstsza przyczyna nagłego znikania poczty, gdy platforma marketingowa „uprzejmie" każe Ci dodać swoje SPF. Zamiast tego — scal: jeden rekord, wiele mechanizmów include:.

; poprawnie: jeden rekord, wiele źródeł
@   IN  TXT  "v=spf1 ip4:51.75.55.91 include:_spf.google.com -all"

Rekord CAA blokujący certbota

Jeśli opublikujesz CAA 0 issue "letsencrypt.org" i potem spróbujesz wystawić certyfikat z innego CA (DigiCert, ZeroSSL, itd.), wystawienie kończy się błędem CAA record for example.com prevents issuance. Naprawa: albo dodaj kolejną linię issue dla tego CA, albo zdejmij ograniczenie. Sytuacja odwrotna: jeśli masz rekordy CAA, które nie obejmują Let's Encrypt, a używasz klienta certbot, Detail: CAA record for example.com prevents issuance to dokładnie ten błąd, który zobaczysz w logu.

CNAME na apexie strefy

Wpisanie @ IN CNAME ... jest niezgodne z RFC 1912, bo apex ma już rekordy SOA i NS, a CNAME nie może dzielić nazwy z innymi typami rekordów. BIND zrzuca CNAME and other data i odmawia załadowania strefy. Rozwiązania: użyj rekordu A/AAAA na apexie albo zastosuj specyficzny dla dostawcy ALIAS/ANAME, jeśli koniecznie chcesz wskazać apex na nazwę hosta.

`named[NNNN]: zone example.com/IN: loading from master file db.example.com failed: file not found`

Ścieżka w named.conf.local nie zgadza się z faktyczną lokalizacją pliku strefy albo BIND nie ma do niego dostępu. Sprawdź ścieżkę, właściciela (bind:bind na Debianie/Ubuntu) i AppArmor: profil BIND-a na Ubuntu pozwala czytać tylko z wąskiego zbioru katalogów. Jeśli położyłeś strefy w nietypowym miejscu, edytuj /etc/apparmor.d/usr.sbin.named i przeładuj AppArmor.

Rekord DMARC bez obowiązkowego prefiksu `v=DMARC1; p=...`

Parsery DMARC zatrzymują się na pierwszym niepoprawnym tagu, więc rekord typu p=reject; v=DMARC1; rua=... jest całkowicie ignorowany. Kolejność ma znaczenie: v=DMARC1 musi być pierwszy, p= drugi. Dokumentacja Google Workspace pisze o tym wprost — warto przeczytać raz, zanim opublikujesz pierwszy DMARC.

Niezgodność glue między rejestratorem a strefą

Jeśli rejestrator ma ns1.example.com → 1.2.3.4, a Twój plik strefy ma ns1 IN A 5.6.7.8, resolvery dostaną sprzeczne odpowiedzi, a walidacja DNSSEC (jeśli ją włączysz) po prostu padnie. Aktualizuj obie strony razem i zweryfikuj na czystym resolverze przez dig +trace example.com.

FAQ — najczęściej zadawane pytania

Jaki format powinien mieć numer seryjny SOA?

Konwencja prawie uniwersalna to RRRRMMDDnn, gdzie nn zaczyna się od 01 i inkrementuje dla każdej edycji w tym samym dniu. Pierwsza edycja 7 maja 2026 daje 2026050701. Format jest czystą konwencją — BIND potrzebuje liczby całkowitej, która rośnie — ale format z datą trzyma zmiany samodokumentujące i chroni przed przypadkowym zmniejszeniem przy wielu adminach edytujących strefę.

Jak sprawić, żeby zmiana propagowała się szybciej niż TTL?

Obniż $TTL (oraz TTL per-rekord na wszystkim, co planujesz zmieniać) przed zmianą, odczekaj co najmniej stary TTL, dopiero potem zmieniaj rekord. Jeśli $TTL było 3600, a obniżyłeś do 300, nowy TTL działa tylko dla resolverów, które pobiorą rekord po wygaśnięciu starego. Migrację planuj z co najmniej 24-godzinnym wyprzedzeniem zmiany TTL.

Czy mogę mieć CNAME na apexie domeny?

Nie, nie w klasycznym DNS. RFC 1912 zabrania tego, bo apex musi trzymać rekordy SOA i NS, a CNAME nie może koegzystować z innymi typami rekordów na tej samej nazwie. Jeśli musisz wskazać example.com (a nie www.example.com) na nazwę hosta — na przykład endpoint CDN — potrzebujesz ALIAS lub ANAME, czyli niestandardowych rekordów implementowanych przez niektórych dostawców (Cloudflare, Route 53), które rozwijają się po stronie serwera DNS w momencie zapytania.

Ile rekordów MX powinienem mieć?

Jeden MX wystarcza w większości konfiguracji — serwer pocztowy, który faktycznie obsługujesz. Backup MX z wyższym priorytetem dodawaj tylko, jeśli masz gdzie wiarygodnie kolejkować i forwardować pocztę — źle skonfigurowany backup MX to znany magnes na spam, bo spamerzy celują w hosty o wysokim priorytecie, licząc na luźniejsze filtrowanie.

Czy potrzebuję własnego serwera DNS, czy wystarczą nameservery rejestratora?

Dla większości domen darmowy DNS u rejestratora wystarcza. Własny BIND uruchamiasz, gdy chcesz pełnej kontroli nad transferami stref, bardzo niskich TTL, split-horizon DNS (różne odpowiedzi dla klientów wewnętrznych i zewnętrznych) albo podpisywania DNSSEC na własnych warunkach. Pełną konfigurację serwera pokrywa generator BIND 9 na vps-web.com.

Co oznacza Negative Cache TTL w rekordzie SOA?

To czas, przez który resolver cache'uje odpowiedź NXDOMAIN („taka nazwa nie istnieje") dla dowolnej nazwy w Twojej strefie. Ustaw niżej, jeśli planujesz dodać nowe subdomeny i chcesz, żeby pojawiły się szybko; wyżej, jeśli strefa jest stabilna i chcesz odciążyć serwery. Zdefiniowany przez RFC 2308 — starsze źródła nazywają go „minimum TTL", co bywa mylące.

Jak przetestować, czy plik strefy faktycznie działa?

Trzy polecenia, w kolejności: named-checkzone example.com /etc/bind/zones/db.example.com parsuje plik, named-checkconf waliduje named.conf.local, a dig SOA example.com @127.0.0.1 (po reloadzie) potwierdza, że BIND go serwuje. Dla widoczności zewnętrznej odpytaj zewnętrzny resolver: dig SOA example.com @1.1.1.1, gdy propagacja zdąży się rozejść.

Czy mogę użyć tego samego pliku strefy dla IPv4 i IPv6?

Tak. Dodaj rekordy AAAA obok rekordów A — ten sam plik strefy, te same nazwy, inny typ rekordu. @ IN AAAA 2001:db8::1 to odpowiednik IPv6 dla @ IN A 192.0.2.1. Resolvery wspierające IPv6 będą preferować AAAA; pozostałe spadną do A.

Czy DMARC powinno być od razu ustawione na `p=reject`?

Nie. Zacznij od p=none i tagu rua=mailto:dmarc-reports@example.com, żeby zbierać raporty agregatowe przez co najmniej tydzień. Raporty pokażą, którzy legalni nadawcy wysyłają pocztę pod Twoją domeną, ale nie są wpisani do SPF ani nie podpisują DKIM-em. Gdy to posprzątasz, podnieś do p=quarantine na parę tygodni, potem do p=reject. Przeskoczenie fazy rozgrzewki to najszybszy sposób na ciche utratę legalnej poczty.

Następne kroki

Pełną strefę z Twoimi parametrami wygenerujesz w generatorze stref DNS na vps-web.com — wypełnij formularz, wklej output do /etc/bind/zones/db.<twoja-domena> i odpal named-checkzone.

Tematy, które naturalnie wynikają z tego artykułu:

Generator VirtualHost dla Apache2 — gdy DNS już kieruje domenę na Twój serwer WWW, musi tam czekać działający vhost.

Jeśli wolisz wideo, zajrzyj na mój kanał YouTube — praktyczna administracja Linuksem, Proxmox i self-hosted infrastructure.

Strefa DNS dla BIND