DNSSEC: uwierzytelnianie odpowiedzi DNS

W 2008 roku badacz Dan Kaminsky ujawnił krytyczny atak na resolwery DNS. Atak wykorzystywał niewielkie, 16-bitowe pole identyfikatora transakcji w odpowiedziach DNS. Zalewając resolver sfałszowanymi odpowiedziami zawierającymi losowe identyfikatory transakcji, atakujący mógł statystycznie dopasować prawidłowy identyfikator transakcji, zanim nadeszła prawdziwa odpowiedź. Zatruta pamięć podręczna przekierowuje wszystkich użytkowników tego resolvera do serwerów kontrolowanych przez atakującego przez wiele tygodni, aż pamięć podręczna wygaśnie.

DNSSEC (DNS Security Extensions) dodaje kryptograficzne uwierzytelnianie do odpowiedzi DNS. Każdemu zestawowi rekordów DNS w strefie podpisanej za pomocą DNSSEC towarzyszy podpis cyfrowy. Resolwery przeprowadzające walidację sprawdzają te podpisy przed zaakceptowaniem rekordów. Sfałszowana lub zmodyfikowana odpowiedź będzie miała nieprawidłowy podpis i zostanie odrzucona. DNSSEC chroni przed zatruwaniem pamięci podręcznej i fałszowaniem odpowiedzi, ale nie szyfruje zapytań DNS.

DNSSEC korzysta z hierarchii dwóch kluczy dla każdej strefy. Zone Signing Key (ZSK) służy do codziennego podpisywania poszczególnych zestawów rekordów DNS. Key Signing Key (KSK) podpisuje wyłącznie zestaw rekordów DNSKEY, który zawiera klucze publiczne zarówno ZSK, jak i KSK. ZSK można często zmieniać, na przykład co miesiąc, natomiast KSK zmienia się rzadziej, na przykład raz w roku, ponieważ skrót KSK musi zostać zarejestrowany w strefie nadrzędnej, a zmiana tego klucza jest złożona operacyjnie.

Każdy podpisany zestaw rekordów DNS (nazywany RRset) ma odpowiadający mu rekord RRSIG zawierający podpis kryptograficzny tego zestawu. Gdy resolver żąda rekordu DNS, odpowiedź zawiera zarówno rekord, jak i jego RRSIG. Resolver weryfikuje RRSIG za pomocą klucza publicznego strefy. Podpis obejmuje zawartość rekordu, jego typ, klasę i czas wygaśnięcia, zapobiegając zarówno modyfikowaniu rekordów, jak i ponownemu użyciu starych, ważnych podpisów.

Łańcuch zaufania w DNSSEC jest tworzony za pomocą rekordów Delegation Signer (DS). Gdy strefa deleguje obsługę do strefy podrzędnej, strefa nadrzędna publikuje rekord DS zawierający skrót KSK strefy podrzędnej. Resolver, który ufa strefie nadrzędnej, może sprawdzić, czy skrót KSK strefy podrzędnej odpowiada rekordowi DS, ustanawiając zaufanie do podpisów tej strefy. Łańcuch ten rozciąga się od głównej strefy DNS przez domeny najwyższego poziomu aż do stref poszczególnych domen.

Każda strefa podpisana za pomocą DNSSEC publikuje swoje publiczne klucze podpisywania w rekordach DNSKEY. Zwykle występują dwa rekordy DNSKEY: jeden dla ZSK i jeden dla KSK. Skrót klucza publicznego KSK jest rejestrowany jako rekord DS w strefie nadrzędnej, zakotwiczając zaufanie do strefy w jej strefie nadrzędnej. Skrót KSK głównej strefy DNS jest zapisany na stałe w resolverach przeprowadzających walidację jako ostateczny punkt zaufania, nazywany Root Zone Trust Anchor.

Walidacja DNSSEC rozpoczyna się w głównej strefie, której punkt zaufania KSK jest zapisany na stałe w resolverach. Rekord DNSKEY głównej strefy służy do weryfikacji jej RRSIG, który uwierzytelnia rekordy DS dla domen najwyższego poziomu, takich jak .com. Rekord DNSKEY strefy .com weryfikuje jej RRSIG dotyczący rekordów DS poszczególnych domen. Ten łańcuch weryfikacji kryptograficznej rozciąga się od głównej strefy do żądanej domeny, zapewniając uwierzytelnienie każdego ogniwa.

Gdy resolver przeprowadzający walidację DNSSEC otrzymuje odpowiedź, wykonuje pełną weryfikację łańcucha zaufania. Pobiera rekordy DNSKEY, weryfikuje podpisy RRSIG, śledzi rekordy DS aż do głównego punktu zaufania i sprawdza czasy wygaśnięcia podpisów. Jeśli walidacja się nie powiedzie, resolver zwraca błąd SERVFAIL zamiast potencjalnie sfałszowanych rekordów. Większość głównych publicznych resolverów, w tym 1.1.1.1 firmy Cloudflare i 8.8.8.8 firmy Google, przeprowadza walidację DNSSEC.

Wdrażanie DNSSEC przebiega powoli mimo korzyści związanych z bezpieczeństwem. Zmiana kluczy wymaga koordynacji między operatorami stref a rejestrami stref nadrzędnych. Błąd podczas zmiany KSK może sprawić, że cała strefa stanie się niedostępna. Zmiana głównego klucza KSK ICANN w 2019 roku wymagała wieloletnich przygotowań. Rozmiar strefy znacznie wzrasta z powodu podpisów. Operatorzy muszą wdrożyć automatyczną zmianę kluczy i monitorowanie. Te złożoności operacyjne skłoniły wielu mniejszych operatorów domen do unikania DNSSEC.

Częstym błędnym przekonaniem jest to, że DNSSEC zapewnia prywatność zapytań DNS. Tak nie jest. DNSSEC uwierzytelnia wyłącznie odpowiedzi; zapytania i odpowiedzi nadal są przesyłane w postaci jawnej jako pakiety UDP przez port 53. Każdy, kto monitoruje sieć, może nadal zobaczyć każdą odpytywaną nazwę domeny. DNS-over-TLS (DoT) i DNS-over-HTTPS (DoH) zapewniają prywatność zapytań, szyfrując ruch DNS. DNSSEC i DoH/DoT wzajemnie się uzupełniają: pierwsze zapewnia autentyczność, a drugie poufność.

W 2024 roku około 90 procent głównej strefy DNS i głównych domen najwyższego poziomu było podpisanych za pomocą DNSSEC. Jednak podpisanych jest tylko około 20–30 procent poszczególnych nazw domen. Obsługa walidacji DNSSEC przez przeglądarki i aplikacje jest nierównomierna. Korzyści z DNSSEC są największe w połączeniu z DANE (DNS-Based Authentication of Named Entities), które wykorzystuje DNSSEC do publikowania odcisków certyfikatów TLS i pozwala klientom weryfikować certyfikaty bez polegania wyłącznie na urzędach certyfikacji (CA).

DNSSEC dodaje do odpowiedzi DNS podpisy kryptograficzne, aby zapobiegać zatruwaniu pamięci podręcznej i fałszowaniu odpowiedzi. ZSK podpisują zestawy rekordów, KSK podpisują rekordy DNSKEY, a rekordy DS łączą zaufanie między strefami nadrzędnymi i podrzędnymi. Walidacja rozpoczyna się od zapisanego na stałe Root Zone Trust Anchor. DNSSEC nie szyfruje ruchu DNS; DoH i DoT zapewniają prywatność, a DNSSEC autentyczność. Złożoność operacyjna, w tym zmiana kluczy, spowolniła powszechne wdrażanie tego rozwiązania.