Globalne narzędzie do sprawdzania DNSKEY
Rekord zasobu DNSKEY to kryptograficzny fundament DNSSEC (Domain Name System Security Extensions). Podstawowy protokół DNS z definicji nie jest szyfrowany i jest bezstanowy (stateless), co czyni go wysoce podatnym na ataki typu cache poisoning oraz spoofing Man-in-the-Middle (MitM). DNSSEC rozwiązuje ten problem dołączając matematyczne, kryptograficzne podpisy do odpowiedzi DNS. Rekord DNSKEY działa jak repozytorium kluczy publicznych; przechowuje zakodowane w Base64 klucze publiczne, których zdalne resolvery używają do sprawdzenia, czy Payload rekordów A lub MX faktycznie pochodzi od autorytatywnego serwera nazw i nie został po drodze sfałszowany.
Architektura kluczy ZSK i KSK
Standardowa implementacja DNSSEC wdraża dwa odrębne klucze, aby zrównoważyć bezpieczeństwo z wydajnością operacyjną. Zone Signing Key (ZSK) to mniejszy, mniej obciążający klucz kryptograficzny używany do szybkiego podpisywania poszczególnych rekordów (A, TXT, CNAME) w strefie. Ponieważ obsługuje zbiorcze (bulk) podpisywanie, ZSK jest często rotowany (np. co 30 dni), aby zapobiec złamaniu go metodą brute-force. Key Signing Key (KSK) jest znacznie silniejszym, mocno strzeżonym kluczem. Jego jedynym celem jest podpisywanie samego klucza ZSK. Oddzielając te klucze od siebie, administratorzy mogą rotować ZSK lokalnie na serwerze nazw, bez potrzeby ciągłego komunikowania się z nadrzędnym rejestrem TLD.
Łańcuch zaufania (Chain of Trust) i rekordy DS
Publikacja rekordu DNSKEY w strefie jest bezużyteczna, jeśli nie istnieje weryfikowalna ścieżka zaufania sięgająca aż do korzenia Internetu (root). Gdy KSK generuje podpis, matematyczny hash tego KSK jest przesyłany do rejestratora domeny jako rekord DS (Delegation Signer). Rejestrator publikuje ten rekord DS w nadrzędnej strefie TLD (np. w rejestrze dla domeny .com). Kiedy rekursywny resolver odpytuje o Twoją domenę, pobiera rekord DS z rejestru nadrzędnego, aby uwierzytelnić KSK, używa KSK, aby uwierzytelnić ZSK, a następnie używa ZSK, aby uwierzytelnić ostateczny adres IP. Jeśli choć jedno ogniwo w tym łańcuchu kryptograficznym zostanie zerwane, cała walidacja zakończy się niepowodzeniem.
Katastrofalne przestoje związane z błędem SERVFAIL
Zarządzanie rekordami DNSKEY wymaga absolutnej precyzji. Protokół DNSSEC jest domyślnie zaprojektowany tak, aby zamykać ruch w razie błędu ("fail closed"). Jeśli zautomatyzowany skrypt dokona rotacji klucza ZSK na serwerze, ale powiązany z nim publiczny rekord DNSKEY nie zostanie zaktualizowany w globalnej strefie, podpisy kryptograficzne nie będą do siebie pasować. Dostawcy usług internetowych oraz publiczne resolvery, takie jak Google (8.8.8.8) i Cloudflare (1.1.1.1), zinterpretują to jako aktywny cyberatak. Natychmiast porzucą one odpowiedź DNS i zwrócą klientowi błąd krytyczny o statusie SERVFAIL, co skutecznie wymaże domenę z Internetu do czasu ręcznego zsynchronizowania kluczy lub całkowitego wyłączenia DNSSEC na poziomie rejestratora.