W piątek administrator przenosi strefę firmowej domeny do nowego operatora DNS i sprawdza z laptopa, że strona działa. W poniedziałek część klientów zgłasza, że witryna nie odpowiada, a u innych wszystko jest w porządku. Przyczyną jest rekord DS, który w strefie .pl nadal wskazuje klucz starego operatora: resolvery sprawdzające podpisy uznają nowe odpowiedzi za fałszywe i odmawiają ich podania.
W cyberbezpieczeństwie DNSSEC bywa przedstawiany jako zabezpieczenie domeny, a dokładniej jest podpisem pod odpowiedziami DNS: potwierdza, skąd pochodzą, ale ich nie ukrywa i nie obroni przed kimś, kto zaloguje się do panelu rejestratora. Włączenie go dla domeny .pl wymaga współpracy operatora DNS i rejestratora, a pomyłka w kolejności kroków odcina domenę od części użytkowników.
Czym jest DNSSEC i jak działa łańcuch zaufania?
DNSSEC (Domain Name System Security Extensions) to zestaw rozszerzeń protokołu DNS, który pozwala sprawdzić, że odpowiedź pochodzi od właściciela strefy i nie została zmieniona po drodze. Rdzeń specyfikacji tworzą RFC 4033, 4034 i 4035 z marca 2005 r. Dokument RFC 9364 z lutego 2023 r. (BCP 237) zbiera całą rodzinę w jednym miejscu.
Operator podpisuje każdy zestaw rekordów strefy, a podpis trafia do rekordu RRSIG; klucze publiczne strefy leżą w rekordach DNSKEY. Strefa nadrzędna przechowuje rekord DS, czyli kryptograficzny skrót klucza strefy podrzędnej. Według NASK taki łańcuch biegnie aż do strefy root, której klucz pełni rolę powszechnie uznanego punktu zaufania (trust anchor).
Resolver walidujący sprawdza ten łańcuch od góry: klucz root potwierdza DS strefy .pl, klucz .pl potwierdza DS Twojej domeny, a klucz domeny potwierdza podpisy rekordów. Jeśli któreś ogniwo nie pasuje, odpowiedź nie przechodzi weryfikacji. Dlatego błąd w rekordzie DS w strefie nadrzędnej odcina całą domenę od resolverów walidujących.
Strefy zwykle rozdzielają klucz podpisujący rekordy (ZSK) od klucza podpisującego zestaw DNSKEY (KSK), którego skrót trafia do rekordu DS. RFC 4033 zaznacza, że to podział wyłącznie operacyjny i jeden klucz może pełnić obie role.
Przed czym chroni DNSSEC?
DNSSEC chroni przed podmianą odpowiedzi DNS: resolver walidujący odrzuci rekord, którego podpis nie zgadza się z kluczem z łańcucha zaufania. RFC 4033 opisuje to jako uwierzytelnienie pochodzenia i ochronę integralności danych DNS. Atakujący może wysłać fałszywą odpowiedź, ale nie podrobi podpisu bez klucza prywatnego strefy. Dzięki rekordom NSEC to samo dotyczy odpowiedzi przeczących: nie da się „wyłączyć” rekordu, udając, że nie istnieje.
Najbardziej oczywistym przykładem jest zatruwanie DNS, czyli wprowadzanie fałszywych rekordów do pamięci podręcznej resolvera. Bez DNSSEC resolver nie ma kryptograficznego sposobu, by odróżnić prawdziwy adres banku od podstawionego. Z DNSSEC rekord bez ważnego podpisu nie trafi do użytkownika. Spośród technik, które słownik zbiera pod hasłem atak na DNS, podpisy obejmują właśnie te, które polegają na podrabianiu odpowiedzi.
Ochrona działa tylko wtedy, gdy obie strony robią swoje: strefa jest podpisana, a resolver sprawdza podpisy. Szacunki przytoczone w RFC 9364 (luty 2023 r.) mówiły o mniej niż 10% podpisanych domen używanych przez strony WWW i o walidacji mniej więcej jednej trzeciej zapytań do resolverów rekurencyjnych. Podpisana domena chroni więc tych użytkowników, których resolver waliduje, i nikogo poza nimi.
Czego DNSSEC nie chroni?
DNSSEC nie zapewnia poufności: RFC 4033 stwierdza wprost, że rozszerzenia nie szyfrują danych, a sekcja o bezpieczeństwie dodaje, że to świadoma decyzja projektowa. Treść zapytań i odpowiedzi pozostaje jawna dla każdego, kto widzi ruch.
Ten sam dokument wylicza kolejne granice. DNSSEC nie chroni przed odmową usługi, a obsługa podpisów otwiera dodatkową klasę ataków DoS, opartą na kosztownych operacjach kryptograficznych. Łańcuch rekordów NSEC pozwala wyliczyć wszystkie nazwy w strefie, co ułatwia rozpoznanie infrastruktury. Niepodpisane pozostają też dane w miejscu delegacji, czyli rekordy NS i glue w strefie nadrzędnej.
Najważniejszej granicy nie znajdziesz jednak w RFC, bo wynika z samej definicji. DNSSEC potwierdza, że rekord podpisano kluczem strefy, a nie że właściciel domeny chciał go zmienić. Kto przejmie konto w panelu rejestratora albo operatora DNS, ten zmieni rekordy, które operator podpisujący strefę automatycznie opatrzy ważnym podpisem, albo podmieni serwery nazw i usunie rekord DS. Dla resolvera wszystko będzie poprawne. Dlatego dostęp do panelu rejestratora i operatora DNS chroni się uwierzytelnianiem wieloskładnikowym (MFA) i ogranicza do wąskiej listy osób, a o możliwość zablokowania zmian w domenie warto zapytać rejestratora.
Z tego samego powodu DNSSEC nie odróżnia domeny uczciwej od łudząco podobnej. Atakujący, który zarejestruje nazwę z literówką, może ją podpisać tak samo jak prawdziwy bank. Podpis mówi, kto odpowiada za strefę, a nie czy warto jej ufać.
Najważniejsze:
- DNSSEC podpisuje odpowiedzi DNS i pozwala wykryć ich podmianę po drodze.
- Nie szyfruje zapytań, nie chroni przed DoS i nie ukrywa nazw w strefie.
- Nie obroni domeny, gdy atakujący zaloguje się do panelu rejestratora lub operatora DNS.
- Działa tylko dla użytkowników, których resolver sprawdza podpisy.
Czym DNSSEC różni się od szyfrowania DNS?
DNSSEC podpisuje dane, a DNS over TLS i DNS over HTTPS szyfrują kanał między komputerem a resolverem, więc rozwiązują dwa różne problemy. DNS over TLS opisuje RFC 7858 z maja 2016 r., a DNS over HTTPS — RFC 8484 z października 2018 r. Oba ukrywają treść zapytania przed obserwatorem w sieci lokalnej albo u dostawcy łącza.
Szyfrowanie nie mówi jednak nic o tym, czy odpowiedź jest prawdziwa. Jeśli resolver ma w pamięci zatruty rekord, zaszyfrowany kanał dostarczy fałszywy adres równie sprawnie jak prawdziwy. DNSSEC działa odwrotnie: odpowiedź widzi każdy, ale nikt nie zmieni jej niezauważenie.
Oba mechanizmy spotykają się na ostatnim odcinku. Jeśli komputer użytkownika sam nie sprawdza podpisów, ufa resolverowi, który ustawia w odpowiedzi flagę AD. RFC 4033 zaznacza, że kanał między nimi nie potrzebuje poufności, ale potrzebuje integralności i uwierzytelnienia wiadomości. Tę lukę zamyka dopiero chroniony kanał do zaufanego resolvera walidującego.
Jak sprawdzić, czy domena ma włączony DNSSEC?
Najszybciej sprawdzisz to, szukając rekordu DS domeny w strefie nadrzędnej i flagi AD w odpowiedzi resolvera walidującego. Wystarczy narzędzie dig z pakietu narzędzi BIND.
Polecenie dig DS przyklad.pl +short zwraca rekord DS ze strefy .pl. Pusta odpowiedź oznacza, że łańcuch zaufania nie dochodzi do Twojej domeny: strefa nie jest podpisana albo nikt nie przekazał skrótu klucza do rejestru. Polecenie dig przyklad.pl SOA +dnssec pokazuje, czy obok rekordów przychodzą podpisy RRSIG, a flaga ad w nagłówku odpowiedzi znaczy, że resolver sprawdził cały łańcuch. Brak flagi bywa winą resolvera, który nie waliduje — wtedy test trzeba powtórzyć z innego.
RFC 4033 opisuje cztery stany danych w oczach resolvera walidującego: bezpieczne (secure), niezabezpieczone (insecure), nieprawidłowe (bogus) i nieokreślone (indeterminate). Stan „bogus” resolver sygnalizuje błędem serwera (SERVFAIL). Jeśli domena zwraca ten błąd, a odpowiada poprawnie z opcją +cd, która wyłącza sprawdzanie podpisów, winna jest konfiguracja DNSSEC.
Jak włączyć DNSSEC dla domeny .pl?
Dla domeny .pl DNSSEC włącza się w dwóch miejscach: operator DNS podpisuje strefę, a rejestrator przekazuje do NASK skrót klucza, który trafia do strefy .pl jako rekord DS. Według instrukcji NASK skrót przekazuje się za pośrednictwem rejestratora obsługującego domenę. Wyjątkiem są nazwy w domenie .gov.pl, dla których skrót składa się bezpośrednio w NASK wnioskiem o zmianę delegacji.
Jeśli rejestrator jest jednocześnie operatorem DNS, oba kroki często załatwia jeden panel. Jeśli strefę obsługuje ktoś inny, liczy się kolejność: najpierw podpisana strefa i sprawdzone podpisy, dopiero potem rekord DS u rejestratora. Odwrotna kolejność spowoduje, że resolvery walidujące zaczną odrzucać odpowiedzi.
Przed wdrożeniem trzeba też zdecydować, kto trzyma klucze. Gdy podpisuje operator, firma zależy od jego procedur. Gdy podpisuje sama, na przykład na serwerach BIND (NASK zaleca najnowszą stabilną wersję), bierze na siebie wymianę kluczy i pilnowanie terminów podpisów.
Jaki algorytm podpisu wybrać?
Dla nowej strefy wybierz algorytm 13 (ECDSA P-256 z SHA-256), 8 (RSA/SHA-256) albo 15 (Ed25519): wszystkie trzy RFC 9904 z listopada 2025 r. oznacza jako zalecane do podpisywania, a NASK przyjmuje je w rekordach DS. RFC 9904 zastąpił RFC 8624 i przeniósł listę zaleceń do rejestrów IANA, więc o statusie algorytmu rozstrzyga rejestr, a nie starszy poradnik.
Według tego samego dokumentu algorytmy 5 (RSASHA1) i 7 (RSASHA1-NSEC3-SHA1) nie są zalecane do podpisywania, a algorytmy 1 (RSA/MD5) i 3 (DSA) mają status zakazanych. Dla skrótu w rekordzie DS zalecany jest SHA-256, a SHA-1 nie może być używany do delegacji. Strefa podpisana kiedyś algorytmem 5 albo 7 działa, ale wymaga planu migracji.
NASK pisze, że w praktyce najczęściej stosuje się algorytm 8 z kluczami RSA o długości co najmniej 2048 bitów, i radzi rozważyć algorytm 13: przy porównywalnym poziomie bezpieczeństwa daje mniejsze sygnatury. Zastrzega, że uniwersalnej rekomendacji nie ma.
Zmiana algorytmu w działającej strefie to osobna operacja. RFC 9904 odsyła do RFC 6781 i RFC 7583 i ostrzega, że jednoczesna zmiana algorytmu skrótu w rekordzie DS i wymiana klucza KSK kończy się błędami walidacji. Najpierw zmienia się więc algorytm DS, a dopiero potem klucz.
Co może pójść nie tak przy wdrożeniu DNSSEC?
Największym ryzykiem DNSSEC jest własny błąd konfiguracji: RFC 4033 ostrzega, że przez błędy w konfiguracji resolvery walidujące mogą uznać całe prawidłowe strefy za nieosiągalne. Atakujący nie jest do tego potrzebny.
Stan „bogus” powodują między innymi brakujące albo wygasłe podpisy i algorytmy, których resolver nie obsługuje. Wygasłe podpisy pojawiają się na przykład wtedy, gdy przestanie działać automatyka ponownego podpisywania: strefa się nie zmienia, ale podpisy tracą ważność i domena znika dla części internetu. Monitoring terminów ważności podpisów jest więc tak samo potrzebny jak monitoring certyfikatów TLS.
Drugie źródło awarii to wymiana kluczy. NASK opisuje typowe metody: dla kluczy ZSK najczęściej wcześniejszą publikację nowego klucza (Pre-Publish), a dla KSK metodę podwójnego podpisu (Double Signature). Sam rejestr w dokumencie „DNSSEC Polityka i Zasady Postępowania” (wersja 2.0 z 12 marca 2020 r.) deklaruje wymianę kluczy ZSK strefy .pl co 6 miesięcy, a KSK co 12 miesięcy.
Trzecie ryzyko to zmiana operatora DNS, czyli scenariusz ze wstępu. NASK ostrzega, że błąd przy zmianie delegacji podpisanej domeny przerywa łańcuch zaufania i resolver nie zwraca adresu IP. Rejestr formułuje zasadę: błędy walidacji są groźniejsze niż brak walidacji, więc z dwojga złego lepiej na krótko zostawić strefę niezabezpieczoną. Gdy dotychczasowy operator nie współpracuje, procedura NASK zaczyna się od usunięcia rekordu DS, który wraca po zmianie delegacji i wymianie kluczy.
Czy przepisy wymagają DNSSEC?
Według stanu na 14 listopada 2026 r. ani dyrektywa NIS2, ani rozporządzenie wykonawcze Komisji (UE) 2024/2690 nie wymieniają DNSSEC z nazwy. Rozporządzenie wymaga jednak od części podmiotów stosowania najlepszych praktyk w zakresie bezpieczeństwa DNS.
NIS2 obejmuje w załączniku I, w sektorze infrastruktury cyfrowej, dostawców usług DNS (z wyłączeniem operatorów głównych serwerów nazw) i rejestry nazw TLD. Rozporządzenie 2024/2690 zgodnie z art. 1 dotyczy m.in. dostawców usług DNS, rejestrów TLD, dostawców chmury i ośrodków przetwarzania danych oraz dostawców usług zarządzanych, także w zakresie bezpieczeństwa. Jego załącznik w pkt 6.7.2 lit. l wymaga od nich stosowania najlepszych praktyk w zakresie bezpieczeństwa DNS.
Co jest najlepszą praktyką, przepis nie mówi. RFC 9364 mówi to jednak wprost: korzystanie z DNSSEC jest najlepszą bieżącą praktyką uwierzytelniania pochodzenia danych DNS, a żadne RFC ze ścieżki standardów nie oferowało do chwili jego publikacji innej metody. Dostawca usług zarządzanych, którego domeny nie są podpisane, powinien więc mieć przygotowane uzasadnienie na pytanie audytora.
W Polsce te same podmioty, jeśli są kluczowe lub ważne, wskazuje art. 8b ust. 1 ustawy o krajowym systemie cyberbezpieczeństwa, dodany nowelizacją z 23 stycznia 2026 r. (Dz.U. 2026 poz. 252): mają stosować środki z rozporządzenia 2024/2690. Pozostałych firm ani dyrektywa, ani rozporządzenie nie zobowiązują do DNSSEC wprost. Dla nich to decyzja oparta na ryzyku: im więcej klientów polega na domenie przy logowaniu, płatnościach i poczcie, tym większa korzyść z podpisu.
Jak zaplanować wdrożenie DNSSEC krok po kroku?
Wdrożenie DNSSEC planuje się jako proces z właścicielem każdego etapu, bo wymaga współpracy rejestratora, operatora DNS i działu IT, a luka między nimi wystarczy do awarii.
| Etap | Kto odpowiada | Co sprawdzić przed przejściem dalej | Typowy błąd | Dowód wykonania |
|---|---|---|---|---|
| Inwentaryzacja domen | właściciel domen i IT | rejestrator i operator DNS każdej domeny, obsługa DNSSEC i przekazywania DS | domeny pozostawione u dawnego rejestratora | lista domen z rejestratorem, operatorem i kontaktem |
| Decyzja o kluczach | IT i bezpieczeństwo | kto generuje i przechowuje klucze, jak wygląda ich wymiana | wiedza o kluczach tylko u jednego administratora | opisana procedura wymiany kluczy |
| Podpisanie strefy | operator DNS | algorytm zalecany w rejestrze IANA (8, 13 lub 15), podpisy przy wszystkich rekordach | algorytm 5 lub 7 z dawnej instrukcji | wynik dig … +dnssec z rekordami RRSIG |
| Przekazanie DS | rejestrator | DS zgodny z aktualnym KSK, skrót SHA-256 | DS ze skrótem SHA-1 albo do nieaktywnego klucza | rekord DS widoczny w strefie .pl |
| Test walidacji | IT | flaga ad z resolvera walidującego, brak SERVFAIL | test z resolvera, który nie waliduje | zapis testu z datą |
| Monitoring | IT | terminy ważności podpisów, zgodność DS i DNSKEY | o awarii informują klienci | alert przed wygaśnięciem podpisów |
| Zmiana operatora lub rejestratora | właściciel domeny i obaj operatorzy | procedura NASK: nowy DS przed zmianą delegacji, odczekanie czasów TTL | zmiana serwerów nazw bez aktualizacji DS | plan zmiany z terminami |
Najwięcej uwagi wymaga ostatni wiersz: zmiana operatora zdarza się rzadko, więc procedura z terminami TTL musi istnieć na piśmie, zanim będzie potrzebna.
Najważniejsze:
- Najpierw podpisana i sprawdzona strefa, potem rekord DS u rejestratora.
- Algorytm wybieraj według aktualnego rejestru IANA, nie według starych poradników.
- Monitoruj terminy podpisów i miej procedurę zmiany operatora DNS.
Jak nFlo może pomóc w bezpieczeństwie sieci?
nFlo nie jest rejestratorem domen ani operatorem DNS, więc DNSSEC włączasz u swojego rejestratora i operatora. W ramach usługi bezpieczeństwo sieci nFlo audytuje i zabezpiecza infrastrukturę, którą firma już ma: segmentację sieci, architekturę Zero Trust, ochronę przed DDoS, bezpieczeństwo routingu BGP oraz zapory i systemy IPS/IDS.
Podpis odpowiedzi DNS nie zastąpi pozostałych warstw ochrony sieci. Te warstwy, od segmentacji po ochronę przed DDoS, opisujemy w dziale sieci i networking. Jeśli chcesz sprawdzić, jak zabezpieczona jest sieć Twojej firmy, skontaktuj się z nami.
Co jeszcze warto wiedzieć o DNSSEC?
Czy DNSSEC szyfruje zapytania DNS?
Nie. RFC 4033 stwierdza, że rozszerzenia DNSSEC nie zapewniają poufności: podpisują dane, ale ich nie ukrywają. Szyfrowanie kanału między komputerem a resolverem zapewniają DNS over TLS (RFC 7858) i DNS over HTTPS (RFC 8484).
Czy DNSSEC chroni przed phishingiem?
Częściowo. Chroni przed podmianą odpowiedzi dla prawdziwej domeny, jeśli resolver użytkownika waliduje podpisy. Nie chroni przed domeną łudząco podobną, którą zarejestrował atakujący, bo taką domenę również można podpisać.
Czy każdy rejestrator domen .pl obsługuje DNSSEC?
Nie musi. Obsługę DNSSEC i przekazywanie rekordów DS do NASK trzeba sprawdzić u konkretnego rejestratora, bo to on przekazuje skrót klucza do rejestru. NASK zaleca, by przed transferem domeny upewnić się, że nowy rejestrator oferuje przekazywanie rekordów DS.
Co się stanie, jeśli podpisy DNSSEC wygasną?
Resolvery walidujące uznają odpowiedzi za nieprawidłowe, bo RFC 4033 wymienia wygasłe podpisy wśród przyczyn stanu „bogus”. Zwracają wtedy błąd serwera i domena przestaje się dla ich użytkowników rozwiązywać.
Czy DNSSEC jest obowiązkowy?
Według stanu na 14 listopada 2026 r. ani dyrektywa NIS2, ani rozporządzenie wykonawcze Komisji (UE) 2024/2690 nie wymieniają DNSSEC z nazwy. Rozporządzenie wymaga jednak od m.in. dostawców usług DNS, chmury i usług zarządzanych stosowania najlepszych praktyk bezpieczeństwa DNS.
