Wprowadzenie: Luka Zaufania w Systemie DNS

System Nazw Domenowych (DNS) jest jednym z najważniejszych i fundamentalnych protokołów internetu, działającym jak globalna, rozproszona książka telefoniczna, która tłumaczy czytelne dla człowieka nazwy domen na adresy IP czytelne dla maszyn. Mimo swojej centralnej roli, oryginalny protokół DNS został zaprojektowany w latach 80. XX wieku z wrodzonym założeniem zaufania. Kiedy Twój komputer pyta resolver DNS o adres IP dla www.example.com, standardowy protokół DNS nie zapewnia żadnego mechanizmu weryfikacji, czy otrzymana odpowiedź jest autentyczna i nie została zmodyfikowana.

Ten brak uwierzytelnienia tworzy znaczącą lukę w zabezpieczeniach. Złośliwi aktorzy mogą wykorzystać tę lukę zaufania poprzez różne ataki, z których najczęstszym jest zatruwanie pamięci podręcznej DNS lub fałszowanie DNS. W takim ataku, atakujący przechwytuje zapytanie DNS i odsyła sfałszowaną odpowiedź, kierując przeglądarkę użytkownika na złośliwy adres IP zamiast na ten legalny. Użytkownik, wierząc, że jest na stronie swojego banku lub poczty e-mail, może nieświadomie przekazać swoje poufne dane uwierzytelniające atakującemu.

Aby załatać tę krytyczną dziurę bezpieczeństwa i wprowadzić kryptograficzne zaufanie do DNS, Internet Engineering Task Force (IETF) opracowała zestaw rozszerzeń znanych jako DNSSEC, czyli Rozszerzenia Bezpieczeństwa Systemu Nazw Domenowych.

Czym jest DNSSEC? Wprowadzenie Autentyczności i Integralności do DNS

DNSSEC nie jest zamiennikiem DNS. Jest to zestaw rozszerzeń, które działają na istniejącej infrastrukturze DNS, aby dodać warstwę bezpieczeństwa. Jego głównym celem nie jest poufność; DNSSEC nie szyfruje zapytań ani odpowiedzi DNS. Zamiast tego, koncentruje się na dwóch krytycznych aspektach bezpieczeństwa:

1. Uwierzytelnianie Pochodzenia Danych: DNSSEC pozwala resolverowi DNS kryptograficznie zweryfikować, czy odpowiedź, którą otrzymał, rzeczywiście pochodzi od legalnego, autorytatywnego serwera nazw dla danej domeny. Potwierdza to, że źródło danych jest autentyczne.
2. Integralność Danych: DNSSEC zapewnia, że dane DNS (rekordy) nie zostały zmodyfikowane w tranzycie między serwerem autorytatywnym a resolverem. Jeśli choćby jeden bit odpowiedzi zostanie zmieniony, weryfikacja się nie powiedzie.

Dzięki tym gwarancjom DNSSEC chroni użytkowników przed przekierowaniem na złośliwe strony. Jeśli resolver ma włączoną walidację DNSSEC i otrzyma odpowiedź, która nie przejdzie weryfikacji kryptograficznej, odrzuci ją i zwróci błąd do klienta, uniemożliwiając użytkownikowi połączenie z potencjalnie fałszywym serwerem.

Jak Działa DNSSEC: Siła Podpisów Cyfrowych

Magia DNSSEC tkwi w zastosowaniu kryptografii klucza publicznego i podpisów cyfrowych do rekordów DNS. Aby włączyć DNSSEC dla domeny (proces zwany „podpisywaniem strefy”), właściciel domeny generuje parę kluczy kryptograficznych:

• Klucz prywatny, który jest przechowywany w tajemnicy na autorytatywnym serwerze nazw.
• Odpowiadający mu klucz publiczny, który jest publikowany publicznie w DNS, aby każdy mógł z niego skorzystać.

Ta para kluczy jest używana do tworzenia i weryfikacji podpisów cyfrowych dla rekordów DNS domeny. Proces ten wprowadza kilka nowych typów rekordów DNS.

Nowe Typy Rekordów DNSSEC

Aby zaimplementować podpisy cyfrowe, DNSSEC dodaje do DNS nowe typy rekordów zasobów.

RRSIG (Resource Record Signature)

Dla każdego zestawu rekordów w strefie (np. wszystkich rekordów A dla danej nazwy hosta), serwer autorytatywny używa swojego klucza prywatnego do utworzenia podpisu cyfrowego. Podpis ten jest następnie publikowany jako rekord RRSIG. Kiedy resolver żąda rekordu (np. rekordu A), serwer zwraca zarówno sam rekord A, jak i odpowiadający mu rekord RRSIG.

DNSKEY (DNS Public Key)

Aby zweryfikować podpis RRSIG, resolver potrzebuje klucza publicznego domeny. Ten klucz publiczny jest publikowany w rekordzie DNSKEY. Resolver pobiera rekord DNSKEY i używa zawartego w nim klucza publicznego do weryfikacji podpisu w rekordzie RRSIG. Pomyślna weryfikacja dowodzi, że rekord nie został zmieniony i pochodzi od właściciela klucza prywatnego.

DS (Delegation Signer)

To rozwiązuje kluczowy problem zaufania. Skąd wiemy, że klucz publiczny w rekordzie DNSKEY jest autentyczny? Ustanawiamy łańcuch zaufania, podobny do certyfikatów TLS. Rekord DS to skrót (kryptograficzny odcisk palca) klucza publicznego domeny (konkretnie jej Klucza Podpisującego Klucz). Ten rekord DS nie jest umieszczany w pliku strefy danej domeny, ale w pliku strefy jej domeny nadrzędnej. Na przykład, rekord DS dla 'example.com' byłby przechowywany na serwerach TLD '.com'. Tworzy to bezpieczne powiązanie: serwery '.com' poświadczają autentyczność klucza publicznego 'example.com'.

NSEC/NSEC3 (Next Secure)

DNSSEC musi nie tylko udowodnić, że istniejące dane są autentyczne, ale także zapewnić „uwierzytelnione zaprzeczenie istnienia”. Musi być w stanie udowodnić, że nazwa domeny nie istnieje. Rekord NSEC łączy wszystkie rekordy w strefie w posortowanej kolejności, tworząc kompletny łańcuch. Jeśli zapytasz o nieistniejącą domenę, np. 'nieistniejacy.example.com', serwer może zwrócić rekord NSEC, który udowadnia, że nie ma rekordów między dwoma istniejącymi. Późniejsza wersja, NSEC3, zapewnia tę samą funkcjonalność, ale używa skrótów nazw rekordów, aby zapobiec „przechodzeniu strefy” (zone walking), technice, w której atakujący mógłby łatwo wylistować wszystkie rekordy w strefie, podążając za łańcuchem NSEC.

Łańcuch Zaufania w Działaniu: Walidacja Krok po Kroku

Prześledźmy, jak resolver walidujący DNSSEC weryfikuje odpowiedź dla 'www.example.com'.

1. Rozpoczęcie od Znanej Kotwicy Zaufania: Resolver walidujący rozpoczyna z prekonfigurowanym kluczem publicznym, któremu bezwarunkowo ufa: kluczem publicznym strefy głównej DNS („.”). To jest jego kotwica zaufania.
2. Zapytanie do Serwera Głównego: Resolver pyta serwer główny o serwery nazw dla '.com'. Serwer główny odpowiada rekordami NS i rekordem RRSIG (podpisem dla tych rekordów NS). Resolver używa swojego zaufanego klucza głównego do weryfikacji tego podpisu. Teraz ufa serwerom '.com'.
3. Zapytanie do Serwera TLD: Resolver pyta serwer '.com' o serwery nazw dla 'example.com'. Wraz z rekordami NS, prosi o rekord DS dla 'example.com'. Serwer '.com' zwraca rekord DS i podpisujący go rekord RRSIG. Resolver pobiera klucz publiczny (DNSKEY) strefy '.com' i używa go do weryfikacji podpisu na rekordzie DS. Teraz ufa, że rekord DS jest autentyczny.
4. Zapytanie do Serwera Autorytatywnego: Resolver teraz pyta autorytatywny serwer 'example.com' o rekord A dla 'www.example.com'. Serwer zwraca rekord A i odpowiadający mu podpis RRSIG.
5. Walidacja Ostatecznej Odpowiedzi:
   • Resolver prosi serwer 'example.com' o jego klucz publiczny (rekord DNSKEY).
   • Tworzy skrót tego otrzymanego klucza publicznego i porównuje go z zaufanym rekordem DS, który otrzymał od serwerów '.com'. Jeśli się zgadzają, resolver ufa teraz kluczowi publicznemu 'example.com'.
   • Na koniec używa tego zaufanego klucza publicznego 'example.com' do weryfikacji podpisu RRSIG, który przyszedł z rekordem A. Jeśli ten podpis jest ważny, resolver może być pewien, że rekord A jest autentyczny i nie został zmieniony.

Ten proces krok po kroku, poruszający się w dół hierarchii DNS od zaufanego korzenia, tworzy nierozerwalny łańcuch zaufania, który waliduje ostateczną odpowiedź.

Rola DNSSEC Dzisiaj

DNSSEC jest krytyczną technologią do zabezpieczania podstawowej infrastruktury internetu. Jego wdrożenie to proces składający się z trzech części:

• Podpisywanie Stref: Właściciele domen muszą podpisać swoje strefy, generując klucze i tworząc niezbędne rekordy DNSSEC (RRSIG, DNSKEY, DS).
• Walidacja przez Resolvery: Resolvery DNS (takie jak te w ISP lub publiczne usługi DNS, jak Google $8.8.8.8$) muszą być skonfigurowane do przeprowadzania walidacji DNSSEC. Jest to kluczowy krok, ponieważ podpisanie strefy nie ma żadnego efektu, jeśli nikt nie sprawdza podpisów.
• Świadomość Aplikacji: Ostatecznie, aplikacje klienckie (jak przeglądarki) muszą być świadome wyniku walidacji dostarczonego przez resolver.

Obecnie strefa główna DNS, wszystkie domeny najwyższego poziomu (TLD) i wiele głównych domen jest podpisanych. Główne publiczne resolvery DNS domyślnie przeprowadzają walidację. Chociaż DNSSEC stanowi istotny fundament, pojawiają się również inne technologie zabezpieczające DNS, takie jak DoH (DNS over HTTPS) i DoT (DNS over TLS), które szyfrują same zapytania, zapewniając prywatność oprócz autentyczności i integralności dostarczanych przez DNSSEC.