Jak działa DNSSEC

Łagodne wprowadzenie do DNSSEC

DNSSEC tworzy bezpieczny system nazw domen, dodając podpisy kryptograficzne do istniejących rekordów DNS. Te cyfrowe podpisy są przechowywane w serwerach nazw DNS razem z popularnymi typami rekordów, takimi jak A, AAAA, MX, CNAME itp. Sprawdzając powiązany podpis, możesz zweryfikować, czy zażądany rekord DNS pochodzi z jego autorytatywnego serwera nazw i nie został po drodze zmieniony, w przeciwieństwie do fałszywego rekordu wstrzykniętego podczas ataku typu „man-in-the-middle” .

Aby ułatwić weryfikację podpisu, DNSSEC dodaje kilka nowych typów rekordów DNS:

• RRSIG — zawiera podpis kryptograficzny

• DNSKEY — zawiera publiczny klucz podpisywania

• DS — zawiera funkcję skrótu rekordu DNSKEY

• NSEC i NSEC3 — na potrzeby jednoznacznej odmowy istnienia rekordu DNS

• CDNSKEY i CDS — na potrzeby strefy podrzędnej żądającej aktualizacji rekordów DS w strefie nadrzędnej.

Niniejszy artykuł będzie poświęcony interakcji między rekordami RRSIG, DNSKEY i DS, a także temu, jak dodają warstwę zaufania do serwera DNS.

Zestawy RRset

Pierwszym krokiem zabezpieczania strefy za pomocą DNSSEC jest pogrupowanie wszystkich rekordów tego samego typu w zestaw rekordów zasobu (RRset). Jeśli przykładowo istnieją trzy rekordy AAAA w Twojej strefie na tej samej etykiecie (tj. label.example.com), zostaną pogrupowane w ramach jednego zestawu RRset AAAA.

To właśnie ten pełny zestaw RRset otrzymuje podpis cyfrowy, w przeciwieństwie do poszczególnych rekordów DNS. Oczywiście oznacza to też, że trzeba żądać wszystkich rekordów AAAA ze strefy o tej samej etykiecie i je zatwierdzić, zamiast zatwierdzania tylko jednego z nich.

Klucze podpisywania strefy

Każda strefa w protokole DNSSEC ma parę kluczy podpisywania strefy (ZSK): prywatna część klucza cyfrowo podpisuje każdy zestaw RRset w strefie, podczas gdy część publiczna weryfikuje podpis. Aby włączyć DNSSEC, operator strefy tworzy cyfrowe podpisy dla każdego zestawu RRset, korzystając z prywatnego klucza ZSK, a także przechowuje je w swoim serwerze nazw jako rekordy RRSIG. To jakby powiedzieć: „To są moje rekordy DNS, pochodzą z mojego serwera i powinny tak wyglądać”.

Jednak te rekordy RRSIG są bezużyteczne, jeśli resolwery DNS nie mają sposobu na zweryfikowanie podpisów. Operator strefy musi też udostępnić swój publiczny klucz ZSK, dodając go do swojego serwera nazw w rekordzie DNSKEY.

Gdy resolwer DNSSEC zażąda konkretnego typu rekordu (np. AAAA), serwer nazw również zwróci odpowiedni RRSIG. Resolwer może następnie wyciągnąć rekord DNSKEY zawierający publiczny klucz ZSK z serwera nazw. Łącznie zestaw RRset, RRSIG i publiczny klucz ZSK mogą zatwierdzić odpowiedź.

Jeśli ufamy kluczowi podpisywania strefy w rekordzie DNSKEY, możemy zaufać wszystkim rekordom w strefie. Ale co jeśli klucz podpisywania strefy zostanie naruszony? Potrzebujemy sposobu zatwierdzania publicznego klucza ZSK.

Klucze podpisywania klucza

Oprócz kluczy podpisywania strefy serwery nazw DNSSEC mają również klucze podpisywania klucza (KSK). KSK zatwierdza rekord DNSKEY w dokładnie taki sam sposób, jak nasz klucz ZSK zabezpieczał resztę naszych zestawów RRset w poprzedniej sekcji: podpisuje publiczny klucz ZSK (przechowywany w rekordzie DNSKEY), tworząc RRSIG dla DNSKEY.

Podobnie jak publiczny klucz ZSK, serwer nazw publikuje publiczny klucz KSK w innym rekordzie DNSKEY, co daje nam zestaw DNSKEY RRset pokazany powyżej. Zarówno publiczny klucz KSK, jak i publiczny klucz ZSK są podpisywane przy użyciu prywatnego klucza KSK. Resolwery mogą następnie korzystać z publicznego klucza KSK do zatwierdzania publicznego klucza ZSK.

Zatwierdzenie dla resolwerów wygląda teraz następująco:

• Poproś o żądany zestaw RRset, co zwraca również odpowiedni rekord RRSIG.

• Poproś o rekordy DNSKEY zawierające publiczne klucze ZSK i KSK, co zwraca również RRSIG dla zestawu DNSKEY RRset.

• Zweryfikuj RRSIG żądanego zestawu RRset za pomocą publicznego klucza ZSK.

• Zweryfikuj RRSIG zestawu DNSKEY RRset za pomocą publicznego klucza KSK.

Oczywiście zestaw DNSKEY RRset i odpowiednie rekordy RRSIG można zapisać w pamięci podręcznej, więc serwery nazw DNS nie są ciągle bombardowane niepotrzebnymi żądaniami.

Dlaczego używamy osobnych kluczy podpisywania strefy i kluczy podpisywania klucza? Jak omówimy w kolejnej sekcji, trudno jest wymienić stary klucz KSK, w przypadku którego nastąpiło naruszenie zabezpieczeń. Z kolei zmiana klucza ZSK jest dużo łatwiejsza. Dzięki temu możemy używać mniejszego klucza ZSK bez narażania bezpieczeństwa serwera, jednocześnie minimalizując ilość danych, jaką serwer musi wysyłać przy każdej odpowiedzi.

Udało nam się teraz ustanowić zaufanie w ramach naszej strefy, lecz DNS jest systemem hierarchicznym, a strefy rzadko działają niezależnie. Sprawy jeszcze bardziej komplikuje to, że klucz podpisywania klucza jest podpisywany przez siebie, więc nie zapewnia dodatkowego poziomu zaufania. Potrzebujemy sposobu na powiązanie zaufania w naszej strefie ze strefą nadrzędną.

Rekordy Deletion Signer

DNSSEC wprowadza rekord Deletion Signer (DS), aby umożliwić przeniesienie zaufania ze strefy nadrzędnej do podrzędnej. Operator strefy korzysta z funkcji skrótu w odniesieniu do rekordu DNSKEY zawierającego publiczny klucz KSK i przekazuje go do strefy nadrzędnej w celu opublikowania rekordu DS.

Za każdym razem, gdy resolwer zostanie odesłany do strefy podrzędnej, strefa nadrzędna również zapewnia rekord DS. Dzięki tym rekordom DS resolwery wiedzą, że w strefie podrzędnej włączony jest protokół DNSSEC. Aby sprawdzić ważność publicznego klucza KSK w strefie podrzędnej, resolwer korzysta w odniesieniu do niego z funkcji skrótu i porównuje go z rekordem DS ze strefy nadrzędnej. Jeśli są zgodne, resolwer może założyć, że publiczny klucz KSK jest nienaruszony, co oznacza, że można ufać wszystkim rekordom w strefie podrzędnej. Właśnie w ten sposób ustanawia się łańcuch zaufania w protokole DNSSEC.

Wszelkie zmiany w kluczu KSK również wymagają zmiany w rekordzie DS w strefie nadrzędnej. Zmiana rekordu DS jest procesem wieloetapowym i może skutkować naruszeniem strefy, jeśli nie zostanie przeprowadzona prawidłowo. Po pierwsze, strefa nadrzędna musi dodać nowy rekord DS, a następnie musi poczekać, aż TTL dla oryginalnego rekordu DS wygaśnie — dopiero wówczas może go usunąć. Właśnie dlatego jest znacznie łatwiej wymieniać klucze ZSK niż klucze KSK.

Wyraźna odmowa istnienia

Jeśli poprosisz system DNS o adres IP domeny, która nie istnieje, zwrócona zostanie pusta odpowiedź — nie ma sposobu na wyraźne powiedzenie: „przepraszam, żądana strefa nie istnieje”. Jest to problem, jeśli chcesz uwierzytelnić odpowiedź, ponieważ nie ma wiadomości do podpisania. DNSSEC naprawia ten problem, dodając typy rekordów NSEC i NSEC3. Obydwa umożliwiają uwierzytelnioną odmowę istnienia.

NSEC zwraca rekordy typu „następny bezpieczny”. Weźmy przykładowo serwer nazw, który definiuje rekordy AAAA dla interfejsów api, blogów i stron www. Jeśli zażądasz rekordu dla sklepu internetowego, zwrócony zostanie rekord NSEC zawierający adres www, co oznacza, że nie ma rekordów AAAA między sklepem a www, gdy rekordy są sortowane alfabetycznie. Dzięki temu wiesz, że sklep nie istnieje. A ponieważ rekord NSEC jest podpisany, możesz zweryfikować odpowiadający mu RRSIG w taki sam sposób, jak w przypadku dowolnego zestawu RRset.

Niestety to rozwiązanie umożliwia każdemu przechodzenie przez strefę i zbieranie każdego rekordu bez możliwości dowiedzenia się, który dokładnie jest poszukiwany. Jest to potencjalne zagrożenie bezpieczeństwa, jeśli administrator strefy liczył na to, że zawartość strefy pozostanie prywatna. Więcej informacji na temat tego problemu zawiera część DNSSEC: trudności i rozważania, a także unikalne rozwiązanie Cloudflare zawarte w części DNSSEC — prawidłowe podejście.

Łańcuch zaufania

OK, mamy więc sposób na ustanowienie zaufania w ramach strefy i powiązanie go ze strefą nadrzędną, ale jak możemy zaufać rekordowi DS? Cóż, rekord DS jest podpisany podobnie jak dowolny inny zestaw RRset, co oznacza, że ma odpowiedni RRSIG w strefie nadrzędnej. Cały proces zatwierdzania powtarza się do momentu uzyskania publicznego klucza KSK w strefie nadrzędnej. Aby to zweryfikować, musimy przejść do rekordu DS strefy nadrzędnej, a następnie do kolejnych elementów łańcucha zaufania.

Jednak gdy w końcu dotrzemy do głównej strefy DNS, mamy problem: nie ma nadrzędnego rekordu DNS, w odniesieniu do którego można dokonać zatwierdzenia. Właśnie w tym miejscu zobaczymy bardzo ludzką stronę globalnego Internetu.

W ramach ceremonii podpisywania serwerów głównych kilka wybranych osób z całego świata zajmuje się podpisywaniem głównego zestawu DNSKEY RRset w sposób bardzo publiczny i podlegający szczegółowym audytom. W ramach ceremonii tworzony jest rekord RRSIG, który może być używany do weryfikowania publicznych kluczy KSK i ZSK głównego serwera nazw. Zamiast ufać publicznemu kluczowi KSK z powodu nadrzędnego rekordu DS, zakładamy, że jest prawidłowy, ponieważ ufamy procedurom bezpieczeństwa dotyczącym uzyskiwania dostępu do prywatnych kluczy KSK.

Umiejętność ustanowienia zaufania między strefą podrzędną a nadrzędną jest integralną częścią protokołu DNSSEC. Jeśli dowolna część łańcucha zostanie uszkodzona, nie możemy ufać rekordom, których żądamy, ponieważ atak typu „man-in-the-middle” mógłby zmienić rekordy i przekierować nas do dowolnego innego adresu IP.

Podobnie jak w przypadku HTTPS, DNSSEC dodaje warstwę zabezpieczeń, umożliwiając uwierzytelniane odpowiedzi w protokole, który bez tego pozostaje niezabezpieczony. Podczas gdy HTTPS szyfruje ruch, aby żadna osoba podsłuchująca nie mogła śledzić Twoich aktywności w Internecie, DNSSEC jedynie podpisuje odpowiedzi, aby fałszerstwa były wykrywalne. DNSSEC zapewnia rozwiązanie faktycznego problemu bez potrzeby stosowania szyfrowania.

Celem Cloudflare jest maksymalne uproszczenie stosowania protokołu DNSSEC. Wszyscy klienci Cloudflare mogą dodawać DNSSEC do swoich zasobów internetowych, używając przełącznika w celu włączenia tego protokołu i przesyłając rekord DS (który wygenerujemy automatycznie) do swojego rejestratora: Dowiedz się więcej na temat tego, jak uzyskać DNSSEC.

Opublikowaliśmy również internetową wersję roboczą przedstawiającą zautomatyzowany sposób, w jaki rejestry i rejestratory mogą przesyłać rekordy DS w imieniu naszych klientów. Dzięki temu firma Cloudflare będzie mogła automatycznie włączyć protokół DNSSEC dla naszej całej społeczności. Wkrótce będziemy mogli zdradzić więcej informacji.