Bezpieczeństwo DNS (DNSSEC)

Wprowadzenie: uwierzytelnianie danych DNS

System Nazw Domenowych (DNS) jest hierarchicznym i rozproszonym systemem nazw, który mapuje czytelne dla człowieka nazwy domen na adresy IP używane przez urządzenia. Oryginalny protokół DNS zaprojektowany w latach 80. XX wieku opierał się na zaufaniu do otrzymywanych odpowiedzi. Gdy komputer pyta resolver DNS o adres IP dla www.example.com, standardowy DNS nie zapewnia mechanizmu sprawdzenia, czy odpowiedź pochodzi z właściwej strefy i nie została zmodyfikowana. DNSSEC dotyczy uwierzytelniania danych dostarczanych przez DNS, więc uzupełnia podstawowy protokół o podpisy i walidację.

Brak uwierzytelniania umożliwia ataki polegające na podstawieniu odpowiedzi. Przykładem jest lub fałszowanie DNS. Atakujący może wysłać odpowiedź wskazującą złośliwy adres IP zamiast adresu właściwego serwera. Użytkownik, przekonany, że otwiera stronę banku lub poczty elektronicznej, może wtedy przekazać atakującemu dane uwierzytelniające.

W odpowiedzi na ten problem Internet Engineering Task Force (IETF) opracowała zestaw rozszerzeń znanych jako , czyli Rozszerzenia Bezpieczeństwa Systemu Nazw Domenowych. Rozszerzenia dodają do DNS mechanizmy kryptograficznej walidacji danych.

Czym jest DNSSEC? Autentyczność i integralność danych

DNSSEC nie zastępuje DNS. Jest zestawem rozszerzeń działających na istniejącej infrastrukturze DNS. Nie zapewnia poufności, ponieważ nie szyfruje zapytań ani odpowiedzi DNS. Walidacja obejmuje zestawy rekordów i wiąże klucz strefy z łańcuchem zaufania. Podpisy RRSIG obejmują podpisane zestawy, a NSEC i NSEC3 dostarczają uwierzytelnionego zaprzeczenia istnienia. DNSSEC zapewnia dwa podstawowe mechanizmy:

Uwierzytelnianie pochodzenia danych: DNSSEC pozwala resolverowi kryptograficznie sprawdzić, czy dane pochodzą z podpisanej strefy właściwej dla danej domeny i mogą zostać powiązane z kotwicą zaufania.
Integralność danych: DNSSEC pozwala sprawdzić, czy dane DNS (rekordy) nie zostały zmodyfikowane podczas przekazywania między serwerem autorytatywnym a resolverem. Zmiana choćby jednego bitu powoduje niepowodzenie weryfikacji podpisu.

Te mechanizmy pozwalają wykryć przekierowanie na złośliwy adres. Jeśli resolver ma włączoną walidację DNSSEC i otrzyma odpowiedź, która nie przejdzie kontroli kryptograficznej, zwykle odrzuci ją i zwróci klientowi błąd.

Jak działa DNSSEC: podpisy cyfrowe

DNSSEC wykorzystuje kryptografię klucza publicznego i podpisy cyfrowe dla danych DNS. Aby włączyć DNSSEC dla domeny, operator strefy wykonuje proces podpisywania strefy i generuje co najmniej jedną parę kluczy kryptograficznych. W praktyce rozdziela się role Klucza Podpisującego Klucz (KSK) i Klucza Podpisującego Strefę (ZSK), choć szczegóły rotacji zależą od operatora:

Klucz prywatny, który operator strefy przechowuje w tajemnicy, a gdy to możliwe, także poza serwerem sieciowym.
Odpowiadający mu klucz publiczny, który jest publikowany publicznie w DNS, aby każdy mógł z niego skorzystać.

Klucze służą do tworzenia i weryfikacji podpisów cyfrowych dla zestawów rekordów DNS domeny. Proces wprowadza kilka nowych typów rekordów DNS, które resolver pobiera razem z danymi potrzebnymi do walidacji.

Typy rekordów DNSSEC

Aby publikować podpisy cyfrowe i dowody negatywne, DNSSEC dodaje do DNS nowe typy rekordów zasobów.

RRSIG (Resource Record Signature): Dla każdego zestawu rekordów w strefie, na przykład wszystkich rekordów A dla danej nazwy, serwer autorytatywny używa klucza prywatnego do utworzenia podpisu cyfrowego. Podpis jest publikowany jako rekord RRSIG. Zawiera między innymi algorytm, identyfikator klucza oraz okres ważności podpisu. Gdy resolver żąda rekordu A, serwer zwraca zestaw rekordów A oraz odpowiadający mu rekord RRSIG.
DNSKEY (DNS Public Key): Aby zweryfikować podpis RRSIG, resolver potrzebuje klucza publicznego strefy. Klucz jest publikowany w rekordzie DNSKEY. Resolver pobiera DNSKEY i używa zawartego w nim klucza do sprawdzenia podpisu RRSIG. Strefa może publikować kilka rekordów DNSKEY o różnych rolach i identyfikatorach. Pomyślna weryfikacja dowodzi, że zestaw danych pasuje do podpisu powiązanego z tą strefą.
DS (Delegation Signer): Rekord DSzawiera skrót rekordu DNSKEY w strefie podrzędnej. Operatorzy często używają go do wskazania Klucza Podpisującego Klucz, lecz rekord zawiera także identyfikator klucza i algorytm skrótu. Rekord DS znajduje się w strefie domeny nadrzędnej, zamiast w strefie delegowanej. Na przykład DS dla 'example.com' jest publikowany w strefie '.com'. Skrót wiąże klucz DNSKEY domeny podrzędnej z podpisaną delegacją w strefie nadrzędnej i pozwala kontynuować łańcuch walidacji.
NSEC/NSEC3 (Next Secure): DNSSEC musi także zapewniać „uwierzytelnione zaprzeczenie istnienia”, czyli dowód, że nazwa lub typ rekordu nie występuje w strefie. Rekord NSEC porządkuje nazwy i typy rekordów w strefie. Może też pokazać, że istniejąca nazwa nie ma żądanego typu rekordu. Dla zapytania o nieistniejącą nazwę, np. 'nieistniejacy.example.com', serwer może zwrócić NSEC pokazujący lukę między dwiema istniejącymi nazwami. Późniejsza wersja, NSEC3, zachowuje ten mechanizm, lecz używa skrótów nazw, aby utrudnić „przechodzenie strefy” (zone walking), czyli wyliczanie nazw przez podążanie za łańcuchem NSEC. NSEC3 utrudnia taką enumerację, lecz jej całkowicie nie eliminuje.

Łańcuch walidacji: sprawdzanie krok po kroku

Poniższe kroki pokazują, jak resolver walidujący DNSSEC sprawdza odpowiedź dla 'www.example.com'.

Rozpoczęcie od znanej kotwicy zaufania: Resolver walidujący rozpoczyna od wstępnie skonfigurowanej kotwicy zaufania, powiązanej z kluczem publicznym strefy głównej DNS („.”).
Zapytanie do serwera głównego:Resolver pyta serwer główny o delegację dla '.com'. Odpowiedź zawiera rekordy NS, rekord DS oraz podpisy RRSIG odpowiednich zestawów. Resolver używa kotwicy zaufania i klucza DNSKEY strefy głównej do sprawdzenia tych danych, a następnie może walidować klucz strefy '.com'.
Zapytanie do serwera TLD:Resolver pyta serwer '.com' o delegację dla 'example.com'. Serwer '.com' zwraca rekord DS i podpisujący go rekord RRSIG. Resolver pobiera DNSKEY strefy '.com' i używa zweryfikowanej delegacji ze strefy głównej do sprawdzenia tego podpisu. Poprawna walidacja wiąże klucz TLD z kolejnym rekordem DS.
Zapytanie do serwera autorytatywnego:Resolver pyta autorytatywny serwer 'example.com' o rekord A dla 'www.example.com'. Serwer zwraca zestaw rekordów A i odpowiadający mu podpis RRSIG.
Walidacja ostatecznej odpowiedzi:
- Resolver prosi serwer 'example.com' o klucz publiczny strefy, czyli rekord DNSKEY.
- Oblicza skrót odpowiedniego DNSKEY i porównuje go ze zweryfikowanym rekordem DS otrzymanym ze strefy '.com'. Zgodność pozwala użyć klucza strefy 'example.com' do dalszej walidacji.
- Na koniec używa tego klucza do weryfikacji podpisu RRSIG dołączonego do zestawu rekordów A. Prawidłowy podpis potwierdza zgodność danych z podpisaną strefą.

Proces przebiega w dół hierarchii DNS od kotwicy zaufania i tworzy łańcuch powiązań możliwy do kryptograficznej walidacji. Przerwanie podpisanego powiązania powoduje wynik walidacji wskazujący problem z odpowiedzią.

Rola DNSSEC

DNSSEC zabezpiecza dane używane przez podstawową infrastrukturę internetu. Wdrożenie obejmuje trzy elementy, które muszą współdziałać:

Podpisywanie stref: Operatorzy stref podpisują je, generując klucze i tworząc niezbędne rekordy DNSSEC (RRSIG, DNSKEY, DS).
Walidacja przez Resolvery: Resolvery DNS, na przykład używane przez ISP lub publiczne usługi DNS, takie jak Google $8.8.8.8$ , muszą być skonfigurowane do walidacji DNSSEC. Podpisanie strefy daje ochronę dopiero wtedy, gdy resolver sprawdza podpisy.
Obsługa wyniku przez aplikację: Aplikacja może otrzymać od lokalnego interfejsu DNS informację o wyniku walidacji. Sama walidacja zwykle odbywa się w resolverze rekursywnym.

Strefa główna DNS, strefy TLD i wiele domen korzystają z podpisów DNSSEC, a wiele publicznych resolverów wykonuje ich walidację. Jeśli strefa nie ma łańcucha DS, resolver może traktować ją jako niesygnowaną zgodnie z lokalną konfiguracją. Walidator sprawdza także okres ważności podpisu i obsługiwany algorytm. DNSSEC uwierzytelnia dane i potwierdza ich integralność. DoH (DNS over HTTPS) oraz DoT (DNS over TLS) chronią poufność transportu przez szyfrowanie zapytań, więc pełnią inną funkcję.