DNSSEC

DNSSEC (Domain Name System Security Extensions) to zestaw rozszerzeń protokołu DNS, które dodają do niego uwierzytelnianie pochodzenia danych i ochronę ich integralności ^[1]. NASK, rejestr domeny .pl, opisuje DNSSEC jako rozszerzenia zapewniające wiarygodność i integralność odpowiedzi otrzymywanych z Internetu ^[2]. Odbiorca, który sprawdza podpisy, wie, że odpowiedź pochodzi od właściwego źródła i nie została zmieniona po drodze ^[2]. DNSSEC nie szyfruje zapytań ani odpowiedzi: brak poufności jest świadomą decyzją projektową ^[1].

Jak działa

DNSSEC opiera się na kryptografii asymetrycznej. Właściciel strefy podpisuje jej rekordy kluczem prywatnym, a klucz publiczny publikuje w samej strefie. RFC 4033 wprowadza cztery nowe typy rekordów ^[1].

Zaufanie przechodzi łańcuchem od korzenia DNS w dół. Według RFC 4033 łańcuch uwierzytelniania to naprzemienny ciąg zbiorów DNSKEY i DS, w którym każde ogniwo poręcza za następne ^[1]. Klucz korzenia uwierzytelnia rekord DS strefy „example.”, ten zawiera skrót (hash) jednego z kluczy DNSKEY tej strefy, a prywatny odpowiednik tego klucza podpisuje dane, na przykład rekordy nazwy „www.example.” ^[1]. Punktem wyjścia jest kotwica zaufania: skonfigurowany w resolverze klucz DNSKEY albo skrót DS ^[1].

RYS. 1Łańcuch zaufania DNSSEC

Resolver walidujący przypisuje odpowiedzi jeden z czterech stanów: bezpieczna (Secure), gdy łańcuch jest pełny i podpisy są poprawne; niezabezpieczona (Insecure), gdy udowodniono brak delegacji podpisanej; fałszywa (Bogus), gdy weryfikacja podpisu się nie powiodła; nieokreślona (Indeterminate), gdy brak kotwicy zaufania ^[1]. Odpowiedź w stanie Bogus resolver odrzuca.

Walidację wykonuje zwykle resolver rekurencyjny dostawcy internetu albo usługi DNS, a nie komputer użytkownika. RFC 4033 opisuje, że prosty resolver systemu operacyjnego, jeśli ufa serwerowi rekurencyjnemu i kanałowi do niego, może odczytać z nagłówka odpowiedzi bit AD, który sygnalizuje, że serwer zweryfikował podpisy ^[1]. Gdy takiego zaufania nie ma, może ustawić w zapytaniu bit CD i sam sprawdzić podpisy ^[1]. Odcinek między komputerem a resolverem nie jest więc chroniony samym DNSSEC; RFC zaznacza, że na tym odcinku potrzebna jest integralność i uwierzytelnienie wiadomości, choć nie poufność ^[1].

Czego DNSSEC nie robi

RFC 4033 wymienia ograniczenia wprost. DNSSEC nie zapewnia poufności i nie chroni przed atakami odmowy usługi ^[1], więc nie zastąpi obrony przed DDoS. Nie zabezpiecza też transferów stref, do których potrzebne są osobne mechanizmy, takie jak TSIG ^[1].

DNSSEC nie chroni też przed przejęciem DNS (DNS hijacking) przez konto u rejestratora. Kto przejmie panel domeny, może podmienić rekordy, klucze i DS, a nowe dane będą poprawnie podpisane.

Wadą uboczną jest ujawnianie nazw w strefie. Sekurak pokazał, że przy NSEC można przejść całą strefę i odczytać skonfigurowane nazwy, a skróty NSEC3, które miały temu zapobiec, da się łamać narzędziem hashcat ^[4]. W przykładzie z artykułu odzyskano 599 z 2441 subdomen prostą maską małych liter ^[4]. Dla atakującego to materiał do mapowania powierzchni ataku.

Znaczenie

Główną korzyścią jest ochrona przed DNS cache poisoning. CERT/CC w notatce o podatności CVE-2008-1447 stwierdził, że bez zmian w protokole, takich jak te wprowadzane przez DNSSEC, środki zaradcze nie mogą całkowicie zapobiec zatruwaniu pamięci podręcznej ^[3]. Resolver walidujący odrzuci sfałszowaną odpowiedź, bo napastnik nie ma klucza prywatnego strefy. Dzięki temu DNSSEC utrudnia też pharming oparty na fałszowaniu odpowiedzi DNS.

Ochrona działa tylko wtedy, gdy spełnione są obie strony: strefa domeny jest podpisana, a resolver użytkownika waliduje podpisy. Brak któregokolwiek z tych warunków daje odpowiedź, której nikt nie sprawdził.

W WordPressie

WordPress nie ma ustawień DNSSEC. Podpisanie strefy odbywa się u operatora DNS domeny, a rekord DS trafia do strefy nadrzędnej, czyli dla domen .pl do rejestru prowadzonego przez NASK ^{[1] [2]}. W praktyce oznacza to włączenie DNSSEC w panelu hostingu lub u dostawcy DNS i przekazanie rekordu DS przez rejestratora.

Kilka zależności wymaga uwagi przy stronie na WordPressie:

• Zmiana dostawcy DNS albo CDN. Przeniesienie strefy do nowego operatora bez aktualizacji rekordu DS zostawia w strefie nadrzędnej skrót starego klucza. Resolvery walidujące uznają wtedy odpowiedzi za fałszywe i strona przestaje się otwierać.
• Ważność podpisów. Podpisy RRSIG mają określony początek i koniec ważności ^[1], więc strefę trzeba regularnie podpisywać ponownie. Zwykle robi to automatycznie operator DNS.
• Warstwy ochrony. DNSSEC chroni nazwę, a TLS z certyfikatem SSL/TLS chroni połączenie. Jedno nie zastępuje drugiego.
• Konto domeny. Rotacja kluczy u operatora nie pomoże, jeśli przejęte zostanie konto u rejestratora; stąd znaczenie uwierzytelniania wieloskładnikowego (MFA) w panelu domeny.

Historia i przykłady

RFC 4033, jeden z podstawowych dokumentów obecnej wersji DNSSEC, opublikowano w marcu 2005 roku ^[1]. Znaczenie DNSSEC wzrosło po ujawnieniu w lipcu 2008 roku podatności CVE-2008-1447 w wielu implementacjach DNS ^[3].

Klucz podpisujący klucze strefy głównej (KSK) jest kotwicą zaufania dla całego łańcucha i co pewien czas jest wymieniany. 11 października 2018 roku ICANN przeprowadził wymianę KSK strefy głównej ^[6]. Kolejną rotację klucza ICANN zaplanował na 11 października 2026 roku; operatorzy resolverów walidujących powinni sprawdzić, czy w konfiguracji kotwic zaufania mają klucz KSK-2024 o identyfikatorze 38696 ^[5].