Jak konfigurować DNSSEC

Bezpieczny DNS to fundament zaufania w sieci. Mechanizm DNSSEC pozwala chronić użytkowników i aplikacje przed podmianą odpowiedzi DNS, dostarczając kryptograficzne potwierdzenie, że dane pochodzą z autorytatywnego źródła i nie zostały zmienione po drodze. Poniższy poradnik prowadzi krok po kroku od koncepcji i planowania, przez generowanie kluczy oraz podpisywanie stref, po publikację klucza u rejestratora, utrzymanie, rotację i diagnostykę problemów. Znajdziesz tu zarówno zalecenia operacyjne, jak i praktyczne wskazówki dla najpopularniejszych serwerów autorytatywnych. Nawet jeśli korzystasz z gotowego hostingu DNS, zrozumienie zasad działania DNSSEC pomoże ci poprawnie przeprowadzić wdrożenie i uniknąć przestojów. Artykuł zaczyna się od krótkiego wprowadzenia do łańcucha zaufania, następnie omawia plan wdrożenia, szczegóły konfiguracji i podpisywania, publikację danych w systemie rejestracji domen oraz utrzymanie w ruchu produkcyjnym, w tym typowe pułapki i sposoby monitorowania.

Jak działa DNSSEC i łańcuch zaufania

DNSSEC rozszerza klasyczny DNS o cyfrowe podpisy rekordów i publikację publicznych kluczy, które pozwalają weryfikować integralność odpowiedzi. Klient (rezolwer) nie musi ufać samej sieci – weryfikuje odpowiedzi kryptograficznie, a zaufanie jest budowane od strefy głównej poprzez kolejne delegacje, aż do twojej domeny. Ten mechanizm określa się mianem łańcucha zaufania.

Podstawowe pojęcia i elementy:

DNSKEY – rekord zawierający publiczny klucz strefy. W strefie zwykle występują co najmniej dwa typy kluczy: operacyjny i urzędowy.
RRSIG – rekord zawierający podpis kryptograficzny zbioru rekordów tego samego typu (RRset). Rezolwer sprawdza poprawność podpisu na bazie DNSKEY.
NSEC i NSEC3 – mechanizmy kryptograficznego zaprzeczenia istnienia nazwy lub typu rekordu. Dzięki nim można dowieść, że żądany rekord naprawdę nie istnieje.
Delegacja z zabezpieczeniem: w strefie nadrzędnej (np. TLD) umieszcza się rekord DS, będący odciskiem klucza strefy podrzędnej. To DS łączy dwie strefy w łańcuch zaufania.

W praktyce używamy dwóch klas kluczy: KSK (Key Signing Key) i ZSK (Zone Signing Key). ZSK służy do podpisywania rekordów strefy, a KSK – do podpisywania rekordów DNSKEY. Taki podział ułatwia bezpieczne i operacyjnie przewidywalne rotowanie kluczy. KSK bywa przechowywany w bardziej chronionym środowisku, a jego skrót w postaci DS jest publikowany u rejestratora. Rezolwer, otrzymując odpowiedź DNS, weryfikuje ciąg podpisów: RRSIG danego rekordu, następnie RRSIG DNSKEY, aż do zaufanego punktu kotwiczącego w strefie głównej. Jeśli jakikolwiek element jest niespójny, wynik zostaje odrzucony.

Istotna jest także polityka TTL i czasów ważności podpisów. RRSIG mają daty ważności, więc system musi regularnie podpisywać strefę na nowo, zanim podpisy wygasną. Jednocześnie nie powinno się żonglować kluczami zbyt często bez planu, bo ramp-up propagacji DS i DNSKEY w cache rezolwerów zajmuje czas.

Plan wdrożenia: przygotowanie, decyzje i wymagania

Dobre wdrożenie DNSSEC zaczyna się od planu. Kluczowe pytania i decyzje:

Jaki serwer autorytatywny będzie użyty: BIND, Knot DNS, PowerDNS, NSD, a może zarządzany hosting w chmurze? Czy wspiera on podpisywanie online i polityki rotacji?
Jaki algorytm klucza wybrać: ECDSA P-256 (algorytm 13) lub P-384 (14), Ed25519 (15) czy Ed448 (16), a może RSA? Dziś zalecane są ECDSA P-256 lub Ed25519 ze względu na mniejszy rozmiar odpowiedzi i lepszą wydajność.
Podział ról kluczy: ZSK krótszy i rotowany częściej, KSK dłuższy i rotowany rzadziej. Typowe wartości: ZSK ECDSA P-256, KSK ECDSA P-256 lub P-384. Przy RSA – ZSK 1024–2048, KSK 2048–4096 bitów.
Model operacyjny: czy podpisywanie odbywa się online na autoritativie, czy offline z publikacją gotowych plików strefy? Online jest wygodniejsze, offline może być prostsze na początek i bezpieczniejsze dla KSK.
Ramy czasowe i okno zmian: zaplanuj obniżenie TTL strefy przed wdrożeniem (np. z 1 dnia do 5–15 minut), a po stabilizacji podnieś z powrotem.
Kompatybilność i limity: upewnij się, że twoje rekordy mieszczą się w rozsądnych granicach wielkości odpowiedzi (EDNS buffer, fragmentacja). DNSSEC zwiększa rozmiary pakietów.
Obsługa po stronie rejestratora: jakie algorytmy i typy odcisków DS są wspierane (SHA-256 to standard), czy dostępne jest automatyczne pobieranie CDS/CDNSKEY?

Przed wejściem na produkcję przygotuj środowisko testowe z klonem strefy, nawet jeśli to mała domena techniczna. Przećwicz cały cykl: generowanie kluczy, publikacja DNSKEY, uruchomienie podpisywania, publikacja DS, sprawdzenie łańcucha zaufania, wygaśnięcie RRSIG i odnowienie, a na końcu rotację klucza ZSK. Zweryfikuj też, jak działają twoje serwery zapasowe, czy propagują podpisane dane, oraz czy włączona jest funkcja IXFR/AXFR dla rekordów powiązanych z DNSSEC.

Na tym etapie ustal długoterminową politykę: okresy ważności podpisów (np. 7–14 dni), budżet czasu na rotację ZSK (np. co 3 miesiące) i KSK (np. co 1–2 lata), oraz sposób publikacji DS. Rozsądna polityka minimalizuje ryzyko wygaśnięcia podpisów i zapewnia przewidywalność dla zespołu utrzymania.

Generowanie kluczy i podpisywanie strefy w popularnych serwerach

Poniżej przedstawiono skrót działań w najpopularniejszych implementacjach. Szczegóły mogą się różnić zależnie od wersji oprogramowania, ale logika pozostaje taka sama: tworzysz klucze, publikujesz DNSKEY w strefie, włączasz podpisy i utrzymujesz proces odnawiania RRSIG.

BIND (9.16+):

Najprościej użyć polityk dnssec-policy i inline-signing. W named.conf dodaj do strefy: inline-signing yes; auto-dnssec maintain; dnssec-policy „default”; lub zdefiniuj własną politykę z parametrami algorytmu, długości i harmonogramem rotacji.
Alternatywnie wykonaj ręcznie: wygeneruj klucze poleceniami dnssec-keygen (osobno dla ZSK i KSK, np. ECDSAP256SHA256). Następnie użyj dnssec-signzone do podpisania pliku strefy. Opublikuj plik .signed jako aktualną strefę i załaduj przez rndc reload.
Konfigurując NSEC3, wybierz sól i liczbę iteracji rozsądnie. W wielu strefach iteracje 0–2 są wystarczające. Zbyt wiele iteracji nie zwiększa bezpieczeństwa proporcjonalnie do kosztu.

Knot DNS:

Knot wspiera polityki KASP i automatyczne zarządzanie kluczami. Zdefiniuj politykę w konfiguracji (algorytm, role kluczy, NSEC/NSEC3, okres ważności podpisów), przypisz ją do strefy i włącz klucze poleceniem keymgr lub poprzez strefę polityk.
Po dodaniu kluczy i aktywacji polityki, Knot podpisze strefę automatycznie i będzie odnawiać podpisy zgodnie z harmonogramem. Możesz wyeksportować DS z DNSKEY przy użyciu narzędzi Knot lub standardowych narzędzi systemowych.

PowerDNS Authoritative Server:

W trybie z bazą danych (np. MySQL, PostgreSQL) włącz DNSSEC per strefa korzystając z narzędzia pdnsutil. Typowy przepływ: pdnsutil create-zone example.com ns1.example.com; pdnsutil secure-zone example.com; pdnsutil show-zone example.com wyświetli DNSKEY i DS.
Jeśli chcesz NSEC3, włącz go komendą pdnsutil set-nsec3 example.com parameters i zrektyfikuj strefę poleceniem pdnsutil rectify-zone example.com. PowerDNS sam dba o podpisy i regularne odświeżanie RRSIG.

OpenDNSSEC:

To rozwiązanie z osobnym Enforcerem i Signerem, idealne, gdy potrzebujesz centralnie zarządzać wieloma strefami, rotacjami i kluczami, także z integracją z sprzętowymi modułami kryptograficznymi.
Definiujesz polityki w kasp.xml (algorytmy, długości kluczy, okresy). Enforcer generuje i rotuje klucze, Signer podpisuje strefy. Potem publikujesz podpisane strefy na serwerach autorytatywnych (np. NSD, Knot).

Chmury i hosting DNS:

W wielu usługach (np. Cloudflare, Route 53, Google Cloud DNS, Azure DNS) proces ogranicza się do włączenia DNSSEC w panelu, po czym otrzymujesz DS do przekazania rejestratorowi. Pamiętaj, by upewnić się, że typ odcisku to SHA-256 i że rejestrator go przyjmie.
W środowiskach wielodostawcy sprawdź, czy wspierają model multi-signer: każdy operator może podpisywać strefę, ale musi publikować identyczny zestaw DNSKEY, a u rejestratora muszą znaleźć się DS dla wszystkich aktywnych KSK.

Niezależnie od platformy, proces sprowadza się do: wygeneruj ZSK i KSK, opublikuj DNSKEY, włącz podpisywanie, zweryfikuj, a następnie opublikuj DS u rejestratora i ponownie zweryfikuj cały łańcuch.

Publikacja DS u rejestratora i weryfikacja efektów

Gdy strefa jest już podpisana i zawiera DNSKEY oraz RRSIG, czas na publikację rekordu DS w strefie nadrzędnej (zwykle u rejestratora domeny). To decydujący krok: właśnie wtedy strefa staje się częścią globalnego łańcucha zaufania.

Jak pozyskać poprawny DS:

Wyodrębnij DNSKEY KSK ze strefy. W BIND możesz użyć dnssec-dsfromkey, w PowerDNS pdnsutil show-zone pokaże DS, w chmurze DS jest podany w panelu.
Wybierz algorytm odcisku: standard to SHA-256 (typ 2). Unikaj SHA-1 (typ 1). Zwróć uwagę na numer algorytmu KSK (np. 13 dla ECDSA P-256) i key tag.
W panelu rejestratora wprowadź wszystkie wymagane pola: nazwa domeny, key tag, algorytm, typ digestu, wartość digestu. Jeśli rejestrator obsługuje CDS/CDNSKEY, możesz po prostu opublikować odpowiednie rekordy w strefie, a on pobierze dane automatycznie.

Po publikacji DS odczekaj propagację równą co najmniej TTL DS w strefie nadrzędnej. Następnie zweryfikuj:

dig +dnssec twojadomena.tld A – sprawdź, czy odpowiedź ma flagę AD (Authenticated Data) w rezolwerze, który waliduje. Jeśli masz dostęp do delv lub kdig, możesz użyć ich do śledzenia weryfikacji krok po kroku.
DNSViz i Zonemaster – narzędzia wizualizujące łańcuch zaufania, wykrywające niespójności (np. brak DS, niezgodne algorytmy, niewłaściwy key tag, wygasłe RRSIG).
RIPE Atlas lub inne zewnętrzne sondy – upewnij się, że na świecie odpowiedzi też są walidowane z powodzeniem.

W razie problemów: jeśli po dodaniu DS klienci zaczynają widzieć brak odpowiedzi, oznacza to, że walidacja zawodzi i rezolwery odrzucają wyniki. Najczęstsze przyczyny to brak spójności kluczy (publikacja nie tego KSK, który podpisał DNSKEY), niezgodny algorytm DS, lub wygasłe RRSIG. Nie usuwaj pochopnie DS – najpierw przywróć spójność strefy, a jeśli to niemożliwe, przygotuj awaryjną procedurę wyłączenia DNSSEC w kontrolowany sposób.

Utrzymanie, rotacje kluczy i polityki bezpieczeństwa

Po udanym wdrożeniu głównym wyzwaniem staje się utrzymanie. DNSSEC żyje w czasie: podpisy wygasają, klucze się rotują, algorytmy ewoluują. Pierwszą linią obrony jest automatyczne odnawianie podpisów w tle i monitorowanie czasu ich wygaśnięcia. W BIND konfiguruje się sig-validity-interval i jitter, w Knot i OpenDNSSEC polityki KASP narzucają harmonogramy. Upewnij się, że autoritativy mają prawidłowy czas systemowy oraz stabilne źródła entropii.

Rotacja ZSK:

Stosuj metodę pre-publish: dodaj nowy ZSK do DNSKEY, podpisz nim strefę (podwójne RRSIG), odczekaj pełny TTL DNSKEY w cache, a następnie usuń stary ZSK z podpisów i z DNSKEY.
W systemach automatycznych (BIND dnssec-policy, OpenDNSSEC, Knot) te kroki są wykonywane zgodnie z polityką. Mimo to zawsze obserwuj metryki i alerty w czasie przejścia.

Rotacja KSK:

Wymaga operacji w strefie nadrzędnej, bo trzeba zaktualizować DS. Stosuj model double-DS lub pre-publish KSK: najpierw wprowadź nowy KSK do DNSKEY, odczekaj TTL, opublikuj DS dla nowego KSK u rejestratora, odczekaj TTL DS, a dopiero potem usuń stary DS i w końcu stary KSK ze strefy.
Ustal harmonogram z marginesem bezpieczeństwa. Błędy w rotacji KSK najczęściej prowadzą do przestojów, więc wymagają dodatkowej ostrożności oraz planu wycofania zmian.

Zmiana algorytmu:

Wykonaj rotację mieszającą (algorytm overlap): dodaj klucze w nowym algorytmie, podpisuj równolegle, opublikuj DS dla nowego KSK, a po stabilizacji usuń stary algorytm. Zawsze testuj w strefie nieprodukcyjnej.

Parametry podpisów i TTL:

RRSIG zwykle ustawia się na 7–14 dni ważności, odświeżane mniej więcej w połowie okresu. DNSKEY TTL często 1–2 dni, DS TTL w TLD bywa narzucony.
SOA minimum i negative TTL mają wpływ na caching odpowiedzi NXDOMAIN i wyniki NSEC/NSEC3, co może obniżyć lub podnieść obciążenie.

Bezpieczeństwo kluczy: wiele organizacji odsuwa KSK od codziennej eksploatacji, trzymając go offline lub w urządzeniu HSM. Przygotuj kopie zapasowe kluczy w sejfie, z kontrolą dostępu i okresowymi testami odtwarzania. Dobrą praktyką jest także ograniczenie dostępu do materiału kluczowego do niewielkiej grupy osób i dokładny audyt operacji.

Scenariusze zaawansowane i architektury wielodostawcy

Środowiska wielodostawcze przynoszą elastyczność i odporność, ale komplikują DNSSEC. W modelu multi-signer każdy z operatorów (np. dwóch różnych dostawców DNS) utrzymuje własne klucze i podpisuje strefę. Warunkiem poprawności jest spójny zestaw DNSKEY w strefie i DS w strefie nadrzędnej dla wszystkich aktywnych KSK. Operatorzy muszą wymieniać się publicznymi kluczami i skoordynować harmonogramy rotacji. Jeśli to możliwe, stosuj standard RFC 8901, który opisuje mechanikę współpracy multi-signer.

Automatyzacja publikacji DS: wiele rejestrów skanuje rekordy CDS i CDNSKEY w strefach podrzędnych. Włącz publikację CDS/CDNSKEY w polityce serwera i monitoruj, czy rejestrator pobiera zmiany. To redukuje ręczne kroki i przyspiesza aktualizacje, ale wymaga ostrożności przy błędach – zła publikacja CDS może doprowadzić do automatycznego usunięcia lub zmiany DS. Dlatego wprowadź nadzór i ostrzeżenia, gdy zmieniają się klucze KSK.

Hidden master i anycast: popularnym wzorcem jest ukryty master, który podpisuje strefę i replikuje ją na węzły anycast będące serwerami autorytatywnymi. Upewnij się, że replikacja obejmuje wszystkie rekordy DNSSEC (DNSKEY, RRSIG, NSEC/NSEC3) i że secondaries nie próbują samodzielnie podpisywać strefy, jeśli nie jest to zamierzony model. Przy anycast monitoruj każdy region, bo lokalne problemy z fragmentacją i MTU mogą ujawniać się wybiórczo.

Rozmiar odpowiedzi i transport: DNSSEC zwiększa objętość danych. Zadbaj o EDNS buffer size na rozsądnym poziomie (np. 1232 bajty, by lepiej radzić sobie z PMTU i uniknąć fragmentacji), umożliwiaj fallback do TCP i obserwuj, czy firewalle po drodze nie filtrują powiększonych odpowiedzi. Redukcja wielkości dzięki ECDSA/Ed25519 pomaga ograniczyć ryzyko fragmentacji w porównaniu z RSA.

Denial of existence: wybór NSEC czy NSEC3 wpływa na ekspozycję nazw. NSEC jest prostszy i szybszy, ale ujawnia zakres nazw w strefie. NSEC3 wprowadza mieszanie nazw i może stosować opt-out – przydatne w strefach z wieloma delegacjami, które nie są podpisane. Dla typowych domen firmowych, gdzie zawartość strefy nie jest tajemnicą, NSEC bez iteracji bywa wystarczający i bardziej wydajny.

Migracja między operatorami: przygotuj etap z nakładaniem podpisów. Nowy operator powinien mieć w strefie swój DNSKEY i podpisy zanim stary zostanie wyłączony. DS musi referować KSK, które pozostają aktywne przez cały okres przejściowy. Po potwierdzeniu poprawnej walidacji z każdej strony możesz stopniowo usuwać stare klucze i DS.

Diagnostyka, monitoring i najczęstsze pułapki

Narzędzia operacyjne:

dig +dnssec nazwa A/AAAA/MX/NS – sprawdza flagę AD i obecność RRSIG. Opcje +cd, +trace pomagają śledzić proces bez walidacji oraz z pełnym śledzeniem delegacji.
delv lub kdig +dnssec – dostarczają bardziej szczegółowe wyjaśnienia walidacji i błędów łańcucha.
unbound-host, drill – alternatywy do weryfikacji, szczególnie jeśli masz lokalny walidujący rezolwer.
DNSViz i Zonemaster – wykrywają typowe niespójności, generują raporty przydatne podczas audytów i incydentów.
Monitoring ciągły: w systemach jak Prometheus zbieraj metryki wygasania podpisów, błędów odświeżania, rozmiarów odpowiedzi. W narzędziach typu Icinga/Nagios używaj wtyczek check_dnssec.
RIPE Atlas – mierz z wielu punktów świata, czy odpowiedzi podpisane są walidowane poprawnie.

Typowe usterki i ich przyczyny:

Nagłe NXDOMAIN lub SERVFAIL po dodaniu DS – zwykle DS wskazuje niewłaściwy KSK, brak zgodności algorytmu lub wygasłe RRSIG DNSKEY. Rozwiązanie: sprawdź key tag, algorytm, powtórz publikację DS, odśwież podpisy.
Brak flagi AD mimo poprawnych podpisów – rezolwer, z którego korzystasz, nie wykonuje walidacja lub ma ją wyłączoną. Spróbuj z innym rezolwerem, np. publicznym, który waliduje.
Rozbieżności między serwerami autorytatywnymi – jeden z secondary nie dostał świeżych podpisów albo podpisał strefę samodzielnie innym kluczem. Upewnij się, że tylko master odpowiada za podpisy, a secondaries replikują komplet danych.
Wygasłe RRSIG – proces odświeżania nie nadąża lub węzeł miał problemy z czasem. Sprawdź NTP, obciążenie i logi.
Zbyt duże odpowiedzi i fragmentacja – przejdź na ECDSA/Ed25519, ogranicz dodatkowe rekordy, rozważ podział rekordów TXT lub stosuj minimalny buffer EDNS.
Błędy w rotacji KSK – brak drugiego DS podczas przejścia lub zbyt szybkie usunięcie starego DS. Stosuj harmonogram z buforami równymi co najmniej TTL DS i DNSKEY.

Procedury awaryjne i wycofanie:

Jeśli musisz tymczasowo wyłączyć DNSSEC, najpierw usuń DS u rejestratora, odczekaj TTL DS, a dopiero potem usuń podpisy i DNSKEY ze strefy. Odwrotna kolejność spowoduje masowe błędy walidacji.
Miej gotową checklistę zmian, z krokami do wykonania i punktami kontrolnymi (publikacja DNSKEY, weryfikacja RRSIG, publikacja DS, walidacja, monitoring), aby skrócić czas reakcji i uniknąć pomyłek.

Walidujące rezolwery po stronie użytkowników: możesz włączyć walidację na własnych serwerach BIND lub Unbound. Współczesne implementacje automatycznie zarządzają zaufaną kotwicą dla strefy głównej (RFC 5011). Testuj regularnie, czy flaga AD pojawia się dla twoich stref, aby wychwycić problemy zanim zrobią to klienci.

Podsumowując, konfiguracja DNSSEC to nie jednorazowa czynność, lecz proces obejmujący planowanie, wdrożenie i ciągłe utrzymanie. Po zrozumieniu podstaw i zbudowaniu dyscypliny operacyjnej staje się ona przewidywalna i stabilna. Najważniejsze kroki, które warto mieć w stałym obiegu: wybór algorytmu i polityki, generowanie i bezpieczne przechowywanie kluczy, regularne odświeżanie podpisów, uważna publikacja DS, testy i monitoring, a wreszcie okresowe rotacje. Wdrożenia oparte o polityki i automatyzacja ograniczają ryzyko błędów ludzkich, a właściwe narzędzia i alerty pomagają szybko wykrywać anomalie. Jeśli dopiero zaczynasz, rozważ start na mniejszej strefie testowej, sprawdź każdy etap i dopiero potem przeprowadź produkcję. Gdy poprawnie wykonasz powyższe kroki, twoja domena stanie się odporna na podmiany rekordów DNS i gotowa na dalsze etapy wzmacniania bezpieczeństwa, jak DANE czy MTA-STS. Dzięki temu użytkownicy, aplikacje i partnerzy biznesowi zyskają wymierne korzyści w postaci integralności i autentyczności informacji publikowanych w DNS.