DNSSEC: co to jest, jak działa i dlaczego warto go włączyć

DNSSEC (Domain Name System Security Extensions) to mechanizm, który podpisuje rekordy DNS kryptograficznie i pozwala odbiorcy zweryfikować, czy odpowiedź serwera DNS nie została podmieniona po drodze. Bez DNSSEC zwykły DNS wysyła rekordy bez żadnego podpisu, więc atakujący w sieci (ISP, publiczne WiFi, kompromisowany router) może podmienić adres IP banku na adres swojego serwera phishingowego. DNSSEC dodaje warstwę kryptograficzną, która taki atak wykrywa i blokuje.

Dlaczego klasyczny DNS jest podatny

Standardowy DNS powstał w 1983 roku, gdy nikt nie myślał o atakach. Działa na UDP (port 53), bez szyfrowania i bez weryfikacji nadawcy. Twój komputer pyta serwer DNS: „jaki jest IP mbank.pl”, serwer odpowiada „194.204.152.34” i komputer to akceptuje, bo nie ma jak inaczej. Atak DNS spoofingu polega na tym, że ktoś wcina się między twój komputer a prawdziwy serwer DNS i wysyła sfałszowaną odpowiedź szybciej niż prawdziwa.

Klasyczny scenariusz: jesteś w kawiarni, łączysz się z otwartym WiFi, atakujący w tej samej sieci uruchamia narzędzie typu Ettercap albo Bettercap. Wpisujesz „mbank.pl” w przeglądarce, fałszywa odpowiedź DNS przychodzi pierwsza, twój komputer łączy się z serwerem atakującego, dostajesz idealnie wyglądającą stronę logowania mBanku, wpisujesz dane, są kradzione. DNSSEC sprawia, że twój resolver odrzuca taką sfałszowaną odpowiedź, bo brakuje jej prawidłowego podpisu.

Jak działa podpisywanie rekordów

DNSSEC opiera się na klasycznej kryptografii klucza publicznego. Właściciel domeny generuje parę kluczy: prywatny (trzymany w tajemnicy) i publiczny (udostępniany w DNS jako rekord DNSKEY). Każdy rekord w strefie (A, AAAA, MX, CNAME, TXT) jest podpisywany kluczem prywatnym i podpis ląduje obok jako rekord RRSIG. Resolver klienta pobiera rekord plus podpis plus klucz publiczny z DNSKEY i weryfikuje, że podpis się zgadza.

Druga warstwa zaufania to łańcuch (chain of trust). Klucz publiczny twojej domeny musi być potwierdzony przez serwer wyższego poziomu (rejestrator domeny PL, czyli NASK), który podpisuje twój klucz swoim. Klucz NASK z kolei jest podpisany przez root zone DNS (ICANN). Resolver przechodzi cały łańcuch od root do twojej domeny i jeśli któryś podpis się nie zgadza, odpowiedź jest odrzucana z błędem SERVFAIL.

Rekordy DNSSEC: DNSKEY, RRSIG, DS, NSEC

Strefa z DNSSEC zawiera kilka nowych typów rekordów. DNSKEY przechowuje klucz publiczny strefy. Zwykle masz dwa: ZSK (Zone Signing Key) podpisuje rekordy w strefie, KSK (Key Signing Key) podpisuje klucz ZSK. Rozdzielenie pozwala częściej rotować ZSK bez zmiany powiązania z rejestratorem.

RRSIG to podpis rekordu. Każdy rekord A, MX, TXT ma swój RRSIG obok. Resolver pobiera oba i weryfikuje podpis kluczem z DNSKEY. DS (Delegation Signer) to hash twojego klucza KSK, ale przechowywany w strefie nadrzędnej (u rejestratora). To ten rekord łączy twoją strefę z łańcuchem zaufania. NSEC i NSEC3 to mechanizm „udowodnij, że ten rekord nie istnieje”, potrzebny by atakujący nie mógł sfałszować odpowiedzi NXDOMAIN.

Jak włączyć DNSSEC dla swojej domeny

Procedura zależy od tego, gdzie trzymasz strefę DNS. Najczęściej krok po kroku wygląda tak: w panelu zarządzania DNS (u dostawcy hostingu, w panelu rejestratora, w Cloudflare) klikasz „Włącz DNSSEC” albo „Generate DNSSEC”. Dostawca generuje klucze i dokłada rekordy DNSKEY plus RRSIG do twojej strefy. Następnie kopiujesz wartości DS (algorytm, hash, key tag) i wklejasz w panelu rejestratora domeny.

Po wprowadzeniu DS u rejestratora propagacja trwa od 24 do 48 godzin. Sprawdzisz status na dnssec-analyzer.verisignlabs.com albo dnsviz.net wpisując swoją domenę. Zielony łańcuch od root przez TLD do twojej domeny oznacza, że DNSSEC działa. Czerwony znak (BOGUS, broken chain) oznacza że coś się rozjechało: rotacja klucza bez aktualizacji DS, niezgodność algorytmów, błąd hashowania.

Cloudflare, Hetzner, OVH, Hostinger: DNSSEC u największych

Cloudflare obsługuje DNSSEC od 2014 roku. W panelu DNS jednym kliknięciem włączasz, panel pokazuje wartości DS do skopiowania. Hetzner, OVH i Hostinger podobnie. AWS Route 53 wymaga ręcznej rotacji kluczy KSK i obsługi przez API. Najprostsza ścieżka: rejestrator i DNS u tego samego dostawcy. Wtedy wszystko (DNSKEY w strefie i DS u rejestratora) ustawia się automatycznie i nie musisz nic ręcznie kopiować.

Sprawdzenie po fakcie wymaga resolvera, który weryfikuje DNSSEC. Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1) i Quad9 (9.9.9.9) weryfikują DNSSEC domyślnie. Twój domowy router prawdopodobnie nie. Jeśli router nie weryfikuje, korzystasz z DNS dostawcy, który niekoniecznie weryfikuje, więc DNSSEC istnieje, ale nikt go nie sprawdza po twojej stronie. Zmień DNS w routerze na 1.1.1.1 albo 9.9.9.9 i masz weryfikację end-to-end.

Co DNSSEC chroni, a czego nie

DNSSEC chroni przed jednym konkretnym atakiem: podmianą odpowiedzi DNS w drodze (DNS spoofing, cache poisoning). Daje gwarancję, że IP, które dostałeś dla mbank.pl, faktycznie pochodzi z autorytatywnego serwera mBanku. Nie chroni jednak przed niczym innym. Nie szyfruje ruchu DNS (każdy w sieci wciąż widzi, jakie domeny odwiedzasz). Nie blokuje phishingu na podobnej domenie (mbank.pl vs mbank-bezpieczne.pl). Nie zastępuje HTTPS/TLS, bo to dwie różne warstwy.

Pełen obraz to: DNSSEC weryfikuje że dostałeś prawidłowy adres IP, HTTPS weryfikuje że na tym IP siedzi prawdziwy serwer, plus szyfruje całą komunikację. Do szyfrowania samego DNS służą inne protokoły: DoH (DNS over HTTPS) i DoT (DNS over TLS), które dodatkowo ukrywają, jakie domeny odpytujesz. DNSSEC plus DoT plus HTTPS to pełen, nowoczesny stack ochrony połączenia.

Wady i koszty DNSSEC

Pierwszy minus: rozmiar odpowiedzi DNS rośnie. Klasyczny rekord A to ~50 bajtów, z RRSIG i DNSKEY rośnie do 500-1500 bajtów. Stare resolwery i firewalle, które zakładały małe pakiety UDP, mogą mieć problem (fragmentacja, blokowanie). Drugi minus: klucze trzeba rotować. ZSK co 30-90 dni, KSK co 1-2 lata. Zaniedbanie rotacji nie jest dziurą bezpieczeństwa, ale dobra praktyka.

Trzeci minus: błąd konfiguracji oznacza, że twoja domena znika z internetu dla resolwerów weryfikujących DNSSEC. Nie ma „soft failure”, jest BOGUS i SERVFAIL. To dlatego DNSSEC był długo niszowy: jedna pomyłka i e-commerce stoi. W ostatnich latach automatyzacja u dostawców (Cloudflare, OVH) zlikwidowała większość ryzyka. Czwarty: niewielkie obciążenie CPU na podpisywaniu i weryfikacji, w praktyce niewidoczne na nowoczesnym sprzęcie.