Wprowadzenie mechanizmu podpisu elektronicznego jest możliwe dzięki wykorzystaniu algorytmów kryptograficznych z kluczem publicznym. Rekord DNSKEY służy do przechowywania klucza publicznego w danych strefowych. Strefa ma standardowo przypisany jeden klucz publiczny, który wykorzystywany jest do weryfikowania autorytatywnych danych strefy, podpisanych odpowiadającym mu kluczem prywatnym. Podpisy cyfrowe zestawów rekordów są przechowywane w rekordzie RRSIG. Możliwe jest istnienie wielu kluczy strefy, na przykład, każdy z nich będzie wykorzystywał inny algorytm.
Wraz z wprowadzeniem do DNSSEC rekordu DS pojawił się podział kluczy publicznych na podpisujące klucze (KSK) i podpisujące strefę (ZSK). KSK to klucz podpisujący zbiór rekordów kluczy u wierzchołka strefy, do którego odwołuje się rekord DS u rodzica. ZSK to klucz podpisujący dane strefowe, podpisany przez KSK. Teoretycznie KSK i ZSK mogą być takie samie, jednakże użycie różnych kluczy jest rozwiązaniem bardziej elastycznym, ponieważ umożliwia ustanowienie różnych okresów ważności dla tych dwóch typów kluczy. W takim przypadku klucz podpisujący dane strefowe może być zmieniany znacznie częściej niż klucz podpisujący klucz.
Proponuje się, by klucz podpisujący klucz wyróżnić w celu automatyzacji chociażby procesu wymiany kluczy. Wyróżnienie klucza miałoby nastąpić przez ustawienie odpowiedniego bitu w polu flag klucza, tak zwanego bitu SEP (Secure Entry Point).
Implementacja algorytmu podpisu elektronicznego wymaga, by oprócz rekordu zawierającego publiczny klucz, istniał także rekord przechowujący właściwy, odpowiadający kluczowi, podpis. DNSSEC przewiduje istnienie rekordu podpisu RRSIG dla każdej zabezpieczanej grupy RRset w strefie. Rekord ten musi posiadać nazwę identyczną z nazwą właściciela podpisywanych rekordów, jak również być jego klasy. Czasy TTL dla RRSIG muszą być tożsame z czasami TTL rekordów RRset. Podpis może zostać wygenerowany wyłącznie przy użyciu klucza prywatnego strefy. Dana grupa RRset może posiadać wiele rekordów RRSIG, natomiast sam RRSIG nie jest podpisany.
Zbiór rekordów NS występujący u wierzchołka strefy musi być podpisany w przeciwieństwie do rekordów NS występujących w punktach delegacji. Nie podpisane pozostać muszą również tak zwane rekordy glue.
Weryfikacja podpisów rekordów strefy umożliwia sprawdzenie ich autentyczności. Problem pojawia się jednak przy próbie uwierzytelnienia negatywnej odpowiedzi. Podpisywanie każdej odpowiedzi informującej o nieistnieniu danej nazwy domenowej byłoby niekorzystne z wielu względów. Po pierwsze wymusiłoby używanie on-line prywatnych kluczy wraz z koniecznością ich dystrybucji do SNSów. Po drugie takie odpowiedzi trudno byłoby buforować i zaśmiecałyby one pamięci cache. Biorąc pod uwagę złożoność obliczeniową generowania podpisu, oraz przepełnianie pamięci cache, takie rozwiązanie stwarzałoby korzystne warunki do ataków typu "denial of service". Teoretycznie możliwość uzyskania podpisu dla dowolnie wygenerowanej nazwy ułatwiłoby ewentualną kryptoanalizę i złamanie klucza prywatnego strefy.
Wprowadzenie rekordu NSEC rozwiązało problem podpisywania negatywnych odpowiedzi. NSEC jest pomyślany jako rekord, który rozciąga się w przestrzeni nazw pomiędzy dwiema kolejnymi istniejącymi nazwami. Przenosi on również informację o typie rekordów stowarzyszonych z istniejącą nazwą, co pozwala na weryfikację występowania/braku konkretnych typów rekordów stowarzyszonych z daną nazwą. Rekord NSEC informuje, że żadna legalna nazwa domenowa nie występuje pomiędzy nazwą posiadacza rekordu a nazwą wyszczególnioną w części RDATA rekordu. Rekordy NSEC tworzą łańcuch obejmujący wszystkie nazwy w strefie w określonej kolejności. Użycie rekordów NSEC narzuca konieczność kanonicznej reprezentacji i uporządkowania nazw domenowych w strefie. Muszą być one posortowane alfabetycznie, z zastrzeżeniem, że największy priorytet mają puste etykiety, a cyfry poprzedzają litery. Ostatni rekord NSEC w łańcuchu wskazuje na pierwszą nazwę w strefie.
Klient pytając o nieistniejącą domenę otrzyma w odpowiedzi rekord NSEC dotyczący nazwy domenowej znajdujący się najbliżej szukanej domeny. W przypadku próby pobrania rekordu, który nie istnieje dla danej domeny, serwer zwróci rekord NSEC wyszczególniający dostępne typy rekordów.
Narzędzia DNS automatycznie wyznaczają zawartość rekordów NSEC w trakcie generowania podpisów. Ważne jest, by TTL rekordów NSEC był równy wartości minimalnego TTL w rekordzie SOA strefy. Rekordy NSEC są rzecz jasna podpisywane kluczem prywatnym strefy. Każda nazwa domenowa, z wyjątkiem nazw rekordów glue, musi mieć przypisany rekord NSEC.
Rekord DS jest wykorzystywany do zestawienia łańcucha zaufania pomiędzy strefami DNS. Koncepcja tego rekordu zrodziła się wskutek problemów związanych z wymianą kluczy stref. Wykorzystanie tego rekordu ma ułatwić proces okresowej wymiany kluczy podpisujących strefy, a także pozwolić na dłuższe okresy między aktualizacjami kluczy łańcucha zaufania. Rekord DS może on być uważany za delegującego pozwolenie do podpisywania rekordów strefy u potomka. Jest on wskaźnikiem do następnego klucza w łańcuchu zaufania. Użycie rekordu DS w połączeniu z wykorzystaniem flagi KSK u potomka umożliwia automatyzację całego procesu okresowej wymiany kluczy.
Rekord DS jest specjalnym rekordem występującym tylko u rodzica w punkcie delegacji do zabezpieczonej strefy potomnej. W praktyce może istnieć wiele rekordów DS odnoszących się do jednej delegowanej strefy, gdzie każdy z nich jest powiązany z kluczem podpisującym zbiór rekordów DNSKEY. Rekord DS wskazuje na klucz publiczny potomka zawarty u szczytu jego strefy w rekordzie DNSKEY, który to jest podpisany właściwym mu kluczem prywatnym. Rekordy DS nie mogą występować u wierzchołka strefy ani w miejscach innych niż punkty delegacji. Grupa rekordów DS tego samego właściciela musi być podpisana prywatnym kluczem strefy (rodzica).
W trakcie tworzenia rekordu DS wymagana jest znajomość klucza publicznego potomka, do którego delegowane będzie zezwolenie na weryfikowanie kluczy strefy. Narzuca to konieczność komunikacji pomiędzy rodzicem i potomkiem, która w przypadku konstruowania łańcucha zaufania, jak również w razie konieczności awaryjnej wymiany kluczy, musi być realizowana w sposób bezpieczny.
2011
