DNSSEC w prostych słowach

Moduł 8: Bezpieczeństwo i rozwiązywanie problemów · Czas czytania: 11 min

Cel lekcji: Po tej lekcji będą Państwo potrafili w prostych słowach wyjaśnić, co chroni DNSSEC, jak działa łańcuch zaufania i dlaczego przy transferze domeny może coś pójść nie tak.

Kluczowe pojęcia: DNSSEC, podpis (RRSIG), klucz (DNSKEY), rekord DS, łańcuch zaufania, resolver walidujący, SERVFAIL

Problem: skąd wiadomo, że odpowiedź jest prawdziwa?

W module 1 widzieli Państwo, że resolver zadaje serię pytań: do roota, do serwera TLD i do autorytatywnego serwera nazw. Odpowiedź, która wraca, jest przyjmowana za prawdziwą i zapisywana w pamięci podręcznej. Jednak zwykły DNS nie sprawdza, czy ta odpowiedź rzeczywiście pochodzi od właściwego serwera nazw. Atakujący, który zdoła wysłać fałszywą odpowiedź zanim dotrze prawdziwa, może sprawić, że resolver uwierzy, iż example.com znajduje się pod adresem 203.0.113.66, zamiast pod 192.0.2.10. Nazywa się to cache poisoning: pamięć podręczna zostaje "zatruta", a każdy, kto korzysta z tego resolvera, trafia na niewłaściwy serwer.

DNSSEC (DNS Security Extensions) rozwiązuje ten problem, podpisując odpowiedzi. Resolver może wtedy sprawdzić, czy odpowiedź jest prawdziwa i czy nie została zmieniona po drodze.

Co DNSSEC robi, a czego nie robi

To najważniejsza rzecz do zapamiętania:

Podpis działa jak pieczęć na kopercie: każdy może przeczytać list, ale od razu widać, czy ktoś go otworzył.

Trzy elementy

DNSSEC dodaje kilka typów rekordów. Nie muszą ich Państwo sami tworzyć (robi to administrator DNS lub panel), ale warto je znać:

• DNSKEY: publiczny klucz strefy. Dzięki niemu każdy może sprawdzić podpisy.
• RRSIG: podpis dołączony do grupy rekordów. Każda odpowiedź A, MX czy TXT otrzymuje swój RRSIG. Podpis ma datę początku i końca ważności: strefa musi więc być regularnie ponownie podpisywana.
• DS (Delegation Signer): krótki "odcisk palca" klucza Państwa strefy. Nie znajduje się on w Państwa własnej strefie, lecz u rodzica: dla example.com będzie to rejestr .com (Verisign), a dla domeny .nl SIDN (rejestr .nl w Holandii).

Tak wygląda podpisana odpowiedź (skrócona):

$ dig example.com A +dnssec +noall +answer
example.com.  3600  IN  A      192.0.2.10
example.com.  3600  IN  RRSIG  A 13 2 3600 20261119000000 20261029000000 30794 example.com. s7yJ5o...

W rekordzie RRSIG widać między innymi algorytm (13 = ECDSA P-256 z SHA-256), datę końca ważności (19 listopada 2026), datę początku ważności oraz numer klucza (30794).

Łańcuch zaufania

Dlaczego DS znajduje się u rodzica? Ponieważ klucz we własnej strefie niczego nie dowodzi: atakujący mógłby również podesłać własny klucz. Dlatego kontrola przebiega od góry do dołu:

1. Resolver ufa kluczowi roota. Jest on wbudowany w każdy resolver walidujący (tzw. trust anchor).
2. Root ma DS dla .com, podpisany kluczem roota. Dzięki temu resolver wie, jaki klucz powinien mieć .com.
3. Strefa .com ma DS dla example.com, podpisany kluczem .com.
4. Strefa example.com ma rekord DNSKEY pasujący do tego DS, dzięki czemu można zweryfikować wszystkie RRSIG.

Każde ogniwo potwierdza kolejne. Jeśli jedno ogniwo się przerwie, cały łańcuch staje się niewiarygodny.

Resolver walidujący (większość dużych publicznych resolverów i coraz więcej dostawców) sprawdza ten łańcuch. Jeśli się zgadza, otrzymują Państwo odpowiedź. Jeśli nie, resolver nie zwraca odpowiedzi, lecz status błędu SERVFAIL. Dla odwiedzającego strona wygląda wtedy po prostu, jakby "nie istniała", mimo że rekordy mogą być całkowicie poprawne.

Można to zaobserwować samodzielnie na domenie celowo uszkodzonej:

$ dig dnssec-failed.org A @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)

Za pomocą +cd ("checking disabled") proszą Państwo resolver o pominięcie kontroli. Jeśli wtedy otrzymają Państwo odpowiedź, mają Państwo pewność, że problem leży po stronie DNSSEC:

$ dig +cd dnssec-failed.org A @1.1.1.1 +short
96.99.227.255

Domena bez DNSSEC (bez DS u rodzica) nie zwraca SERVFAIL: jest po prostu niepodpisana i jest przepuszczana jako "niezabezpieczona".

Gdzie pojawiają się problemy: transfer domeny i wymiana kluczy

Sam DNSSEC niemal nigdy się nie psuje. Problem pojawia się, gdy DS u rejestratora przestaje pasować do klucza w strefie. Dzieje się tak przede wszystkim:

• Przy transferze serwerów nazw lub dostawcy DNS. Nowy dostawca podpisuje własnym kluczem, ale u rejestru nadal widnieje DS starego dostawcy. Skutek: SERVFAIL dla każdego, kto korzysta z resolvera walidującego. To klasyczny błąd po transferze domeny.
• Przy wymianie klucza, gdy nowy DS nie został (na czas) przekazany do rejestru.
• Gdy podpisy wygasają, bo strefa nie jest już ponownie podpisywana.

Bezpieczna kolejność działań przy transferze wygląda więc tak:

1. Usunąć DS u rejestru (lub poczekać, aż nowy dostawca dostarczy DS, który Państwo dodadzą).
2. Odczekać, aż minie TTL starego DS.
3. Zmienić serwery nazw.
4. Włączyć DNSSEC u nowego dostawcy i zlecić umieszczenie nowego DS u rejestru.

Wielu rejestratorów i paneli reguluje to dziś automatycznie, o ile domena i DNS znajdują się u tego samego dostawcy. Jeśli są u różnych dostawców, DS trzeba przenieść samodzielnie.

Sprawdzenie samodzielne: DNSViz, Zonemaster i internet.nl

Nie muszą Państwo samodzielnie sprawdzać łańcucha za pomocą dig. Istnieją darmowe narzędzia, które robią to za Państwa i pokazują wynik.

DNSViz (https://dnsviz.net/) rysuje cały łańcuch w formie obrazka. Oto jak z niego korzystać:

1. Na stronie głównej wpisać nazwę domeny w polu wyszukiwania (samą nazwę, bez https:// i bez www) i kliknąć Go.
2. DNSViz pokazuje ostatnią analizę. Jeśli jest nieaktualna albo właśnie wprowadzili Państwo zmianę, kliknąć Update now. Po kilku sekundach pojawi się obrazek.
3. Obrazek czyta się od góry do dołu: na górze root (.), poniżej TLD (na przykład nl), na dole Państwa domena. Każda strefa to ramka.

Co widać na obrazku:

Łańcuch śledzi się tak: DS (u rodzica) wskazuje na DNSKEY (w Państwa strefie), a ten DNSKEY składa podpis RRSIG pod rekordami. To dokładnie ten sam łańcuch, o którym mowa w tej lekcji, tylko narysowany.

Kolory mówią, czy wszystko się zgadza:

• Niebieski: bezpieczny (secure). Łańcuch przebiega nieprzerwanie od roota do tego elementu.
• Czarny: niepodpisany (insecure). Nie ma DS, więc nie ma czego sprawdzać. To nie jest błąd, domena po prostu nie używa DNSSEC.
• Czerwony: uszkodzony (bogus). DS nie pasuje do klucza albo podpis się nie zgadza. Resolver walidujący zwróci wtedy SERVFAIL.
• Fioletowy (przy podpisie): podpis wygasł lub jeszcze nie jest ważny. Strefa nie jest już ponownie podpisywana.
• Żółty: ostrzeżenie, na przykład serwer nazw, który odpowiada niepoprawnie, albo algorytm nieznany narzędziu.
• Szary i przerywany: odwołanie do klucza, który nie istnieje. Jeśli widzą Państwo przerywany DNSKEY pod DS, oznacza to, że u rodzica wciąż znajduje się DS starego klucza: klasyczny błąd po transferze domeny.

Obok elementu może znajdować się trójkąt (ostrzeżenie) lub okrągły znak błędu. Proszę najechać na niego kursorem lub spojrzeć na listę pod obrazkiem: tam opisano słownie, na czym polega problem.

Proszę spróbować z sidn.nl (wszystko niebieskie) oraz z dnssec-failed.org (czerwony, z przerywanym kluczem pod DS).

Inne narzędzia pokazujące to samo z innej perspektywy:

• Zonemaster (https://zonemaster.net/): sprawdza całą Państwa strefę tak, jak robi to rejestr, w tym DNSSEC. Wynikiem jest lista z kolorami zielonym (dobrze), pomarańczowym (ostrzeżenie) i czerwonym (błąd).
• internet.nl (https://internet.nl/): test strony internetowej i poczty e-mail pokazuje między innymi, czy DNSSEC dla Państwa domeny i serwerów pocztowych jest w porządku, za pomocą zielonych znaczników lub czerwonych krzyżyków.
• Verisign DNSSEC Debugger (https://dnssec-debugger.verisignlabs.com/): przechodzi przez łańcuch krok po kroku i przy każdym kroku stawia zielony znacznik lub czerwony krzyżyk. Przydatne, gdy szukają Państwo konkretnego błędu.

Proszę korzystać z nich po każdej zmianie związanej z DNSSEC, a zwłaszcza przed transferem domeny i po nim. Proszę dać narzędziu chwilę na ponowną analizę: również te narzędzia działają z pamięcią podręczną i TTL.

W praktyce: jak to wygląda w panelu

W Moje WebOké włączają Państwo DNSSEC dla domeny w sekcji DNSSEC/DANE; panel tworzy klucze i wysyła DS do rejestru. W DirectAdmin oraz u zewnętrznych dostawców, takich jak Cloudflare, funkcja ta nazywa się zwykle "Włącz DNSSEC"; Cloudflare pokazuje wtedy rekord DS, który trzeba samodzielnie wprowadzić u rejestratora. Inne panele działają podobnie: zawsze jest krok "utworzenie kluczy" (u dostawcy DNS) oraz krok "DS u rejestru" (u rejestratora).

Podsumowanie

• DNSSEC podpisuje odpowiedzi DNS, dzięki czemu resolver może sprawdzić, czy są prawdziwe. Niczego nie szyfruje.
• DNSKEY to klucz, RRSIG to podpis, DS to odcisk palca u rodzica.
• Kontrola przebiega jak łańcuch od roota do Państwa domeny. Jeśli jedno ogniwo się przerwie, resolver walidujący zwraca SERVFAIL.
• Niemal wszystkie problemy wynikają z tego, że DS u rejestru przestaje pasować, często po transferze domeny.
• Za pomocą dig +cd sprawdzą Państwo, czy problem wynika z DNSSEC.
• DNSViz rysuje łańcuch: niebieski oznacza bezpieczny, czarny niepodpisany, czerwony uszkodzony. Zonemaster, internet.nl i Verisign DNSSEC Debugger to dobre drugie źródła opinii.

Quiz

Zadanie

Zadanie Z8.1: Obserwacja DNSSEC. Proszę sprawdzić, która z dwóch domen ma poprawnie skonfigurowany DNSSEC, a która została celowo uszkodzona: sidn.nl oraz dnssec-failed.org. Dla obu proszę odpytać rekord DS oraz rekord A przez resolver walidujący (na przykład 1.1.1.1 lub 9.9.9.9), za pomocą dig lub narzędzia online. Proszę podać: numer klucza (key tag, pierwsza liczba) rekordu DS dla sidn.nl oraz status, jaki otrzymują Państwo dla dnssec-failed.org.

Zadanie Z8.1b: Odczytywanie DNSViz. Proszę przeanalizować nlnetlabs.nl w DNSViz (https://dnsviz.net/, wpisać nazwę i kliknąć Go; kliknąć Update now, jeśli analiza jest nieaktualna). Proszę odczytać obrazek i podać: (1) status nlnetlabs.nl (bezpieczny, niepodpisany lub uszkodzony), (2) numer algorytmu rekordów DNSKEY (widoczny w każdym owalu jako alg=), (3) ile owali DNSKEY znajduje się w strefie nlnetlabs.nl, (4) numer klucza (id=) szarego, wypełnionego DNSKEY, na który wskazuje DS, oraz (5) status, jaki DNSViz podaje dla dnssec-failed.org. Kontrola pobiera te same dane na żywo.

Zadanie O8.1: Ocena trzech demonstracyjnych stref DNSSEC. Przygotowaliśmy trzy strefy demonstracyjne: signed-demo.dnspractice.com (poprawny łańcuch), broken-demo.dnspractice.com (celowo uszkodzona) oraz unsigned-demo.dnspractice.com (niepodpisana). Proszę sprawdzić dla każdej strefy, czy jest bezpieczna, uszkodzona czy niepodpisana, na przykład za pomocą DNSViz lub dig +dnssec (proszę zwrócić uwagę na flagę AD, a przy SERVFAIL spróbować również +cd). Proszę wybrać poniżej odpowiedź dla każdej strefy.

Dalsza lektura

Poniższe artykuły opisują kroki w panelach WebOké; u innych dostawców przyciski mogą nosić inne nazwy.

• Podręcznik WebOké 5.8: DNSSEC i DANE
• Czym jest DNSSEC?
• Aktywacja DNSSEC
• Strona internetowa lub poczta e-mail nie działają po przeniesieniu lub zmianie DNS: prosimy sprawdzić Państwa domenę