DNSSEC

DNSSEC to rozszerzenie systemu DNS zapewniające kryptograficzną weryfikację autentyczności zwracanych odpowiedzi domenowych.

DNSSEC jako podpisywanie odpowiedzi DNS

DNSSEC, czyli Domain Name System Security Extensions, rozszerza klasyczny system DNS o mechanizmy kryptograficzne pozwalające sprawdzić, czy odpowiedź dotycząca domeny pochodzi z właściwego źródła i nie została zmieniona po drodze. Zwykły DNS tłumaczy nazwę domenową, na przykład example.com, na rekord adresowy, taki jak A lub AAAA, ale sam protokół DNS nie zapewnia kryptograficznego potwierdzenia autentyczności tych danych. DNSSEC dodaje do strefy podpisy cyfrowe oraz rekordy opisujące klucze używane do weryfikacji.

Podpis DNSSEC nie szyfruje treści odpowiedzi. Adres IP, rekord pocztowy MX albo inna informacja DNS pozostaje jawna, podobnie jak w tradycyjnym DNS. Mechanizm służy przede wszystkim do potwierdzenia integralności i pochodzenia danych. Resolver przeprowadzający walidację sprawdza podpis rekordu, dopasowanie klucza oraz ciąg zaufania prowadzący od strefy nadrzędnej do konkretnej domeny. Jeżeli weryfikacja się nie powiedzie, odpowiedź może zostać oznaczona jako niezaufana albo odrzucona.

RRSIG, DNSKEY i DS w łańcuchu zaufania

Najważniejszym rekordem podpisującym dane DNS jest RRSIG. Zawiera on podpis cyfrowy dla określonego zestawu rekordów tego samego typu, zwanego RRsetem, a także między innymi identyfikator klucza, nazwę algorytmu, czas rozpoczęcia i wygaśnięcia ważności podpisu. Rekord DNSKEY publikuje klucz publiczny strefy. Resolver wykorzystuje go do sprawdzenia podpisów RRSIG, ale sam fakt opublikowania DNSKEY nie wystarcza jeszcze do ustanowienia zaufania.

Powiązanie ze strefą nadrzędną zapewnia rekord DS, czyli Delegation Signer. Rekord DS znajduje się w strefie nadrzędnej, na przykład dla domeny przekazanej pod określony serwer autorytatywny, i zawiera skrót klucza DNSKEY oraz identyfikator algorytmu. Resolver może dzięki temu sprawdzić, czy klucz publiczny używany przez strefę podrzędną odpowiada temu, który został zadeklarowany wyżej. Weryfikacja przebiega przez kolejne poziomy hierarchii DNS, począwszy od skonfigurowanego zaufanego klucza dla strefy korzeniowej.

W praktycznej konfiguracji występuje zwykle rozdzielenie ról kluczy. KSK, czyli Key Signing Key, służy do podpisywania kluczy strefy i jest reprezentowany w łańcuchu delegacji przez rekord DS. ZSK, czyli Zone Signing Key, podpisuje właściwe zestawy rekordów w strefie. Taki podział ułatwia rotację klucza używanego codziennie do podpisywania danych bez konieczności częstej zmiany informacji przekazywanej do strefy nadrzędnej. Konkretne procedury rotacji zależą od operatora strefy i używanego oprogramowania DNS.

Walidacja, odpowiedzi negatywne i typowe objawy błędu

DNSSEC obejmuje także potwierdzanie nieistnienia rekordu. W klasycznym DNS brak nazwy lub typu rekordu jest odpowiedzią negatywną, której nie można podpisać tak samo jak istniejącego RRsetu. Do uwierzytelniania takich odpowiedzi stosuje się między innymi rekordy NSEC albo NSEC3. NSEC opisuje uporządkowanie nazw w strefie i pozwala wykazać, że między danymi nazwami nie ma poszukiwanej nazwy. NSEC3 wykorzystuje skrócone nazwy, co ogranicza bezpośrednie ujawnianie pełnej kolejności nazw, chociaż nie zapewnia pełnej poufności zawartości strefy.

Resolver może sygnalizować wynik walidacji przez flagę AD, czyli Authenticated Data, w odpowiedzi zwróconej klientowi. Flaga CD, Checking Disabled, może zostać użyta przez klienta lub narzędzie diagnostyczne do żądania pominięcia sprawdzania przez resolver, ale nie naprawia błędnej konfiguracji DNSSEC i nie tworzy zaufania do danych. W testach przydatne są narzędzia takie jak dig, które pozwalają wyświetlić rekordy DNSKEY, DS, RRSIG, NSEC lub NSEC3 oraz sprawdzić ustawienie flag w odpowiedzi. Sama obecność rekordów nie dowodzi poprawności: trzeba jeszcze zweryfikować zgodność podpisu, zakres ważności czasowej i łańcuch delegacji.

Typowymi przyczynami problemów są nieaktualny rekord DS po zmianie klucza, brak wymaganych podpisów, podpisy RRSIG poza okresem ważności, rozbieżność czasu systemowego albo niezgodne algorytmy kryptograficzne obsługiwane przez używane oprogramowanie. Błąd może pojawić się również po zmianie serwerów autorytatywnych, gdy nowa strefa nie zawiera tych samych kluczy co konfiguracja wskazana przez DS. W efekcie część resolverów zwraca błąd walidacji, mimo że zapytanie wykonane bez sprawdzania DNSSEC może pozornie działać prawidłowo.

Sprawdzanie DNSSEC w konfiguracji komputera i sieci

Analiza problemu powinna rozdzielać trzy elementy: stację roboczą, używany resolver oraz serwery autorytatywne obsługujące domenę. Laptop lub komputer PC zwykle wysyła zapytanie do resolvera skonfigurowanego w systemie, routerze albo sieci firmowej. To resolver decyduje, czy wykonuje walidację DNSSEC, natomiast autorytatywny serwer domeny publikuje rekordy i podpisy. Zmiana adresu DNS w systemie może więc zmienić wynik testu, ale nie usuwa źródłowej niezgodności w delegacji lub strefie.

Podczas diagnostyki warto porównać odpowiedź z kilku resolverów, sprawdzić rekordy A, AAAA i DNSKEY wraz z odpowiadającymi im RRSIG oraz osobno odczytać rekord DS ze strefy nadrzędnej. Należy również zweryfikować datę i czas komputera, ponieważ podpisy mają określony moment rozpoczęcia i zakończenia ważności. Jeżeli błąd występuje tylko na jednym urządzeniu, przyczyną może być lokalny cache, filtr DNS, nieprawidłowa konfiguracja routera albo oprogramowanie zabezpieczające ingerujące w zapytania. Jeżeli ten sam błąd pojawia się w niezależnych resolverach walidujących, bardziej prawdopodobny jest problem po stronie strefy lub delegacji.

Usunięcie usterki wymaga zachowania spójności między kluczami strefy, podpisami rekordów i rekordem DS opublikowanym u rejestru lub operatora domeny. Nie należy kasować DS ani wyłączać walidacji bez ustalenia przyczyny, ponieważ takie działanie może jedynie ukryć problem przed częścią użytkowników. W przypadku naprawy laptopa lub komputera sprawdza się przede wszystkim lokalną konfigurację sieci, rozwiązywanie nazw, czas systemowy, pamięć podręczną DNS oraz wpływ zainstalowanych filtrów. Sama naprawa sprzętowa nie zmieni podpisów DNSSEC, ale może przywrócić prawidłową komunikację z resolverem, jeżeli źródłem problemu jest komputer albo jego konfiguracja.