Czym jest DNSSEC?
DNSSEC (Domain Name System Security Extensions) dodaje podpisy cyfrowe do zestawów rekordów DNS. Resolver weryfikujący może użyć prawidłowych podpisów i łańcucha zaufania, aby uwierzytelnić podpisane dane i wykryć nieautoryzowane zmiany. DNSSEC nie szyfruje zapytań ani odpowiedzi DNS.Jak działa DNSSEC
Łańcuch zaufania (przykład z podziałem kluczy):
Root Zone (.)
├── Root KSK (kotwica zaufania) podpisuje root DNSKEY RRset
└── Root ZSK podpisuje autorytatywne RRsety strefy root, w tym DS RRset po stronie strefy nadrzędnej dla .com
└── Skrót DS pasuje do .com KSK
├── .com KSK podpisuje .com DNSKEY RRset
└── .com ZSK podpisuje autorytatywne RRsety strefy .com, w tym DS RRset po stronie strefy nadrzędnej dla example.com
└── Skrót DS pasuje do example.com KSK
├── example.com KSK podpisuje example.com DNSKEY RRset
└── example.com ZSK podpisuje autorytatywne RRsety strefy example.com
Resolver weryfikuje podpisy i skróty DS, zaczynając od kotwicy zaufania dla strefy root
Typy rekordów DNSSEC
| Rekord | Zastosowanie | Opis |
|---|---|---|
| RRSIG | Podpis | Podpis kryptograficzny każdego zestawu rekordów |
| DNSKEY | Klucz publiczny | Publiczne klucze podpisujące strefę (KSK i ZSK) |
| DS | Delegation Signer | Skrót KSK strefy podrzędnej w strefie nadrzędnej |
| NSEC/NSEC3 | Uwierzytelnione zaprzeczenie | Potwierdza, że rekord nie istnieje |
Typy kluczy
| Klucz | Zastosowanie | Częstotliwość rotacji |
|---|---|---|
| KSK (Key Signing Key) | Podpisuje rekordy DNSKEY | Zależnie od polityki; zob. uwagę poniżej |
| ZSK (Zone Signing Key) | Podpisuje pozostałe autorytatywne RRsety | Zależnie od polityki; zob. uwagę poniżej |
Terminy rotacji zależą od roli KSK i polityki operatora. W przypadku KSK powiązanego rekordem DS w strefie nadrzędnej [RFC 6781 §3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) opisuje rok jako rozsądny okres, jeśli wybrano regularną rotację. KSK używany jako kotwica zaufania wymaga koordynacji z resolverami weryfikującymi i może mieć znacznie dłuższy okres obowiązywania ([RFC 6781 §3.2.2](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.2.2)).
Po stronie strefy nadrzędnej delegacyjne RRsety NS i powiązane z nimi RRsety glue pozostają niepodpisane ([RFC 4035 §2.2](https://www.rfc-editor.org/rfc/rfc4035.html#section-2.2)).
Czas rotacji ZSK zależy od TTL rekordów DNSKEY i RRSIG, propagacji zmian w strefie oraz tego, jak długo podpisy utworzone przez wycofywany klucz mogą pozostawać w pamięci podręcznej resolverów. [RFC 7583 §3.2.1](https://www.rfc-editor.org/rfc/rfc7583.html#section-3.2.1) opisuje interwały oczekiwania związane z TTL i propagacją. W przypadku ZSK używanego online, gdy ryzyko kompromitacji jest stosunkowo wysokie, [RFC 6781 §3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) wskazuje miesiąc jako rozsądny zamierzony okres użytkowania. To warunkowa wskazówka, nie uniwersalny termin.
Rotacja KSK strefy głównej 11 października 2026 r.
ICANN podaje termin rotacji KSK strefy głównej na 11 października 2026 r. Sprawdź, czy w konfiguracji kotwic zaufania Twojego resolvera weryfikującego DNSSEC znajduje się KSK-2024 (tag klucza 38696). Nie zakładaj, że automatyczna aktualizacja kotwic zaufania zakończyła się powodzeniem. Jeśli klucza brakuje, potwierdź, że automatyczne aktualizacje są włączone, i postępuj zgodnie z instrukcjami dostawcy resolvera dotyczącymi aktualizacji kotwic zaufania. Aktualne informacje znajdziesz we [wskazówkach ICANN dotyczących rotacji KSK strefy głównej](https://www.icann.org/resources/pages/ksk-rollover-en).
Proces walidacji DNSSEC
1. Klient wysyła do resolvera DNS zapytanie o rekord A domeny example.com
2. Resolver pobiera rekord A oraz podpis RRSIG
3. Resolver pobiera DNSKEY, aby zweryfikować RRSIG
4. Resolver sprawdza rekord DS względem DNSKEY
5. Łańcuch jest kontynuowany aż do strefy głównej, a każdy poziom zostaje zweryfikowany
6. Jeśli wszystkie podpisy są prawidłowe, odpowiedź zostaje uwierzytelniona
Co walidacja DNSSEC może pomóc wykryć
Te kontrole wymagają podpisanych RRsetów, resolvera weryfikującego i nieprzerwanego łańcucha zaufania. Danych niepodpisanych ani danych ze stref niezabezpieczonych nie można uwierzytelnić.
| Zagrożenie | Przykład | Ochrona DNSSEC |
|---|---|---|
| Zatrucie pamięci podręcznej | Sfałszowane dane DNS wstawione do pamięci podręcznej resolvera | Resolver weryfikujący może odrzucić dane, które nie przechodzą weryfikacji podpisu lub łańcucha zaufania. |
| Modyfikacja odpowiedzi | Zmiana podpisanego zestawu rekordów DNS podczas przesyłania | Zmienione dane nie przechodzą weryfikacji podpisu. |
| Podszywanie się pod DNS | Podrobiona odpowiedź dla podpisanej strefy | Resolver weryfikujący może odrzucić odpowiedź, która nie przechodzi walidacji. |
Względy implementacyjne
- Wydajność: Większe odpowiedzi z powodu podpisów (~1000-4000 bytes vs ~100 bytes)
- Zarządzanie kluczami: Wymaga bezpiecznego generowania, przechowywania i rotacji kluczy
- Podpisywanie strefy: Po zmianie rekordów strefę trzeba podpisać ponownie
- Obsługa przez resolver: Klienci potrzebują resolverów weryfikujących DNSSEC
Dobre praktyki
1. Wybierz algorytm podpisu DNSSEC: [Rejestr algorytmów DNSSEC IANA](https://www.iana.org/assignments/dns-sec-alg-numbers) zaleca ECDSAP256SHA256 (algorytm 13) do podpisywania i walidacji. Algorytm ECDSAP384SHA384 (14) może być odpowiedni w zastosowaniach wymagających 192-bitowego poziomu bezpieczeństwa; przed zmianą algorytmu sprawdź, czy obsługują go resolvery ([RFC 9904](https://www.rfc-editor.org/rfc/rfc9904.html), [RFC 8624 §3.1](https://www.rfc-editor.org/rfc/rfc8624.html#section-3.1)).
2. Automatyzuj rotację kluczy: Używaj narzędzi takich jak OpenDNSSEC do obsługi cyklu życia kluczy
3. Monitoruj wygaśnięcie: Podpisy RRSIG mają okresy ważności
4. Testuj przed wdrożeniem: Weryfikuj strefę za pomocą narzędzi takich jak dnsviz.net
5. Planuj sytuacje awaryjne: Dokumentuj procedury wymiany kluczy
Gdy resolver weryfikujący sprawdza łańcuch zaufania, DNSSEC uwierzytelnia pochodzenie i integralność podpisanych danych DNS. Nie potwierdza to wiarygodności witryny ani serwera pod zwróconym adresem.