Internet

DNSSEC: jak działa podpis DNS i czego nie chroni

DNSSEC odpowiada na jedno wąskie pytanie: czy odpowiedź, którą dostał resolver, pochodzi z tej strefy, o którą pytano. Nie szyfruje ruchu, nie ukrywa zapytań i nie naprawi domeny z błędną delegacją.

  • 7 min czytania
Abstrakcyjna ilustracja połączonych węzłów sieciowych, symbolizująca weryfikację i łańcuch zaufania DNSSEC.

DNSSEC odpowiada na jedno wąskie pytanie: czy odpowiedź, którą dostał resolver, pochodzi z tej strefy, o którą pytano. [1] Nie szyfruje ruchu, nie ukrywa zapytań i nie naprawi domeny z błędną delegacją. Mylenie go z HTTPS to źródło większości nieporozumień.

DNS, który ufał każdemu

DNS powstał w latach osiemdziesiątych, gdy internet był mały. Niezabezpieczony kryptograficznie resolver dopasowuje odpowiedź m.in. po adresach i identyfikatorze zapytania, ale nie ma podpisu potwierdzającego, że dane autoryzował właściciel strefy. Historyczne ataki zatruwania cache wykorzystywały możliwość podrobienia pasującej odpowiedzi. Jeśli fałszywe dane trafiły do pamięci podręcznej resolvera, mogły być zwracane kolejnym klientom.

Skutki bywają konkretne: użytkownik trafia na kopię strony banku, a jego poczta – do obcego serwera. Standardy DNSSEC opublikowano w marcu 2005 roku jako RFC 4033, 4034 i 4035 – wymagania, rekordy, zmiany w protokole.

Podpis, nie szyfrowanie

Najważniejsze rozróżnienie brzmi banalnie, ale ma konsekwencje: DNSSEC podpisuje dane, a nie połączenie. ICANN ujmuje to precyzyjnie – podpisywane nie są zapytania i odpowiedzi, lecz dane DNS, których właścicielem jest właściciel strefy. [6] Klucz prywatny zostaje u operatora strefy, publiczny jest jawny.

RFC 4033 wymienia wprost, czego standard nie robi: nie zapewnia poufności, nie różnicuje klientów, nie chroni przed atakami odmowy usługi. Odpowiedź z podpisem jest nadal jawna. Poufność zapytań to osobna warstwa – DoH lub DoT szyfrują transport między klientem a resolverem, ale nie mówią nic o tym, czy dane w strefie są autentyczne. Warstwy są niezależne, choć często łączy się je w praktyce.

  • DNSSEC daje uwierzytelnienie pochodzenia danych i integralność: odpowiedź pochodzi z danej strefy i nie została zmieniona po podpisaniu.
  • DNSSEC nie daje poufności, ochrony przed DoS ani gwarancji, że dane w strefie są merytorycznie poprawne.
  • TLS/HTTPS szyfruje połączenie i pozwala uwierzytelnić serwer w ramach systemu certyfikatów; DNSSEC podpisuje dane DNS. To różne warstwy, które mogą się uzupełniać.

Trzy rekordy, które tworzą podpis

RRSIG – podpis nad zbiorem rekordów

Podpis nie dotyczy pojedynczego rekordu ani zapytania, tylko zbioru rekordów tego samego typu pod tą samą nazwą (RRset). W rekordzie RRSIG znajdziemy podpisany typ, numer algorytmu, znacznik klucza, nazwę podpisującego oraz okno ważności. [2] To ostatnie pole jest częstą przyczyną awarii: podpis, który wygasł, jest traktowany jak nieprawidłowy, nawet jeśli dane są poprawne.

DNSKEY – klucz publiczny strefy

Klucz publiczny leży w strefie. W polu flag liczą się dwa bity: 7 (klucz strefy) i 15 (punkt bezpiecznego wejścia, SEP). Wartość 256 to klucz strefy, 257 – klucz z SEP. RFC 4034 zastrzega, że SEP to tylko wskazówka dla oprogramowania; walidator nie może zmieniać zachowania na podstawie tego bitu. W praktyce dane podpisuje klucz strefy (ZSK), a zestaw DNSKEY – klucz kluczy (KSK).

DS – skrót klucza w strefie nadrzędnej

Rekord DS spina całość. Leży w strefie rodzica, nie dziecka, i zawiera znacznik klucza, numer algorytmu oraz skrót klucza publicznego. Dla example.com rekord DS jest w strefie com. Rodzic nie podpisuje klucza dziecka bezpośrednio – publikuje skrót, a resolver porównuje go z kluczem pobranym ze strefy dziecka.

Obsługiwane algorytmy zmieniają się wraz ze standardami i oprogramowaniem resolverów. Przy wdrożeniu należy sprawdzić aktualne zalecenia IETF oraz zgodność operatora strefy i rejestratora, zamiast kopiować listę z dawnego poradnika. [4] [5]

Łańcuch zaufania: od root do domeny

Resolver nie zna klucza każdej strefy. Zna zaufany punkt początkowy, zwykle klucz root, i buduje zaufanie krok po kroku: root podpisuje DNSKEY strefy TLD, TLD publikuje DS dla domeny, domena podpisuje swoje dane. Każdy element łańcucha potwierdza następny: resolver porównuje skrót DS z kluczem DNSKEY strefy dziecka, a następnie sprawdza podpisy nad jej danymi.

Łańcuch może się urwać w sposób całkowicie legalny. Jeśli strefa nadrzędna nie publikuje DS, delegacja jest niezabezpieczona i walidacja kończy się stanem „insecure”. To nie awaria, tylko decyzja – DNSSEC dla tej gałęzi nic nie wnosi. Osobny przypadek to „wyspa bezpieczeństwa”: strefę podpisaną bez ścieżki do root RFC 4035 każe traktować jak niepodpisaną.

Resolver musi mieć aktualny punkt zaufania dla strefy root i poprawnie obsługiwać dalsze delegacje. Zmiany kluczy i ich automatyczną aktualizację opisuje RFC 5011; w praktyce operator resolvera odpowiada za utrzymanie aktualnych trust anchorów.

Walidacja i SERVFAIL

Walidacja odbywa się w resolverze rekurencyjnym, nie w przeglądarce; aplikacja dostaje co najwyżej bit AD, będący tylko podpowiedzią. Resolver klasyfikuje wynik jako secure, insecure, bogus albo indeterminate: poprawny podpis, brak DS, nieudana weryfikacja danych, które powinny być podpisane.

RFC 4035 w sekcji 5.5 mówi wprost: jeśli żadnego z podpisów nie da się zweryfikować, resolver obsługujący zapytanie rekurencyjne MUSI zwrócić kod RCODE 2, czyli SERVFAIL. [3] Nie ma wariantu „oddam dane z ostrzeżeniem”. Wyjątkiem jest zapytanie z ustawionym bitem CD, w którym klient bierze walidację na siebie.

Jeśli walidacja danych, które powinny być podpisane, nie powiedzie się, resolver nie powinien po cichu zwrócić ich jako poprawnych. To celowe zachowanie: błąd łańcucha zaufania jest widoczny dla użytkownika jako problem z rozwiązywaniem nazwy, a operator może zdiagnozować go narzędziami walidującymi DNSSEC.

Jak odróżnić awarię DNSSEC od innych

  • SERVFAIL dotyczy jednej domeny, a inne działają – podejrzenie pada na jej strefę lub delegację.
  • Zapytanie z +cd zwraca odpowiedź – dane istnieją, zawiodła walidacja.
  • Walidator online, np. DNSViz, pokazuje, gdzie łańcuch pęka: brak DS, niezgodny skrót, wygasły podpis.
  • Najczęstsza pomyłka: DS opublikowany, gdy strefa nie jest jeszcze podpisana, albo zmiana operatora DNS bez przeniesienia kluczy.

Wdrożenie: decyzje, nie kliknięcia

Instrukcje „zaznacz opcję w panelu” starzeją się szybciej niż protokół:

  1. Sprawdź, czy strefa jest podpisana, a nie tylko czy operator deklaruje obsługę DNSSEC.
  2. Sprawdź obsługę DS w TLD i u rejestratora. Bez publikacji DS łańcuch się nie domknie.
  3. Sprawdź algorytmy w aktualnych rejestrach IANA. RFC 9904 wyjaśnia, że bieżące zalecenia kryptograficzne są utrzymywane w tych rejestrach; nie kopiuj list z dawnych poradników.
  4. Zdecyduj o dowodzeniu nieistnienia: NSEC ujawnia nazwy w strefie, NSEC3 (RFC 5155) to utrudnia kosztem większych odpowiedzi i dodatkowej złożoności.
  5. Zaplanuj rotację kluczy i czas życia podpisów. Krótsze okna ważności skracają reakcję na kompromitację, ale zwiększają ryzyko wygaśnięcia.
  6. Publikuj DS, dopiero potem włączaj walidację na własnych resolverach – nigdy w drugą stronę.
  7. Monitoruj: test po każdej zmianie, alert na podpisy bliskie wygaśnięcia, kontrola z zewnątrz, nie tylko z własnej sieci. [7]

Czego DNSSEC nie chroni

  • Poufności zapytań – pytania i odpowiedzi są jawne; to zadanie DoH/DoT.
  • Dostępności – RFC 4033 mówi wprost, że DNSSEC nie chroni przed DoS, a dodaje kosztowną kryptografię po obu stronach.
  • Przejęcia serwera lub klucza prywatnego – podpis poświadcza, że dane opublikował właściciel strefy, nie że serwer jest czysty.
  • Błędów w strefie – literówka w rekordzie A zostanie poprawnie podpisana.
  • Ataku na rejestratora lub rejestr – zmiana delegacji lub DS jest dla DNSSEC legalna, bo pochodzi od uprawnionej strony.
  • Ostatniego odcinka – jeśli klient pyta resolver nieszyfrowanym kanałem, odpowiedź można podmienić po walidacji.
  • Danych nieautorytatywnych – glue i rekordy NS w strefie rodzica nie są podpisane, co RFC 4033 zaznacza wprost.

Kiedy to ma sens

DNSSEC ma sens wtedy, gdy operator strefy potrafi utrzymywać podpisy, a rejestrator poprawnie publikuje rekord DS. Chroni przed częścią fałszywych odpowiedzi DNS, ale błędna delegacja lub wygasły podpis mogą sprawić, że walidujące resolvery odrzucą odpowiedź i zwrócą SERVFAIL.

Przed włączeniem sprawdź, kto odpowiada za klucze, podpisy i delegację oraz jak monitorowane są błędy walidacji. DNSSEC pozwala walidującemu resolverowi odrzucić nieautoryzowane dane DNS, ale wymaga prawidłowej konfiguracji i utrzymania.

Więcej o protokołach i usługach sieciowych znajdziesz w dziale Internet.

Źródła