Zabezpieczenie transakcji DNS przy wykorzystaniu rekordu TSIG sprawdza się w przypadku konieczności zabezpieczenia serwerów i klientów DNS pozostających pod wspólną pieczą administracyjną. Ilość sekretnych kluczy w systemie rośnie bowiem kwadratowo wraz z rosnąca liczbą komunikujących się hostów, co praktycznie zupełnie wyklucza możliwość wykorzystania TSIG do zabezpieczenia całego DNSu.
DNSSEC jest protokołem opartym o cyfrowe podpisy, który wykorzystuje mechanizmy kryptograficzne bazujące na kluczach publicznych, co potencjalnie stwarza możliwość zabezpieczenia całej drzewiastej struktury systemu DNS. Protokół zabezpiecza informacje DNS przed sfałszowaniem i modyfikacją, oferując dodatkowo możliwość wykorzystania go jako infrastruktury do dystrybucji kluczy publicznych.
Protokół DNSSEC umożliwia zapewnienie integralności i możliwość weryfikacji autentyczności pozyskanych danych. Klient systemu może mieć pewność, że otrzymane przez niego dane są wiarygodne i nie zostały zmienione w trakcie transportu ze źródła. Protokół definiuje zabezpieczanie strefy a nie serwera, dzięki czemu nawet w przypadku złamania zabezpieczeń jednego z serwerów autorytatywnych dla danej strefy, bezpieczeństwo systemu jako całości zostaje zachowane. Klucze prywatne wykorzystywane są tylko w momencie podpisywania rekordów strefy i nie muszą być dostępne on-line, co dodatkowo wzmacnia bezpieczeństwo systemu. Sytuację komplikują nieco dynamiczne update'y, które wymuszają dostępność kluczy prywatnych w serwerze je obsługującym.
Zabezpieczane dane w strefach grupowane są w paczki RRset obejmujące rekordy identyfikowane przez tą samą nazwę, klasę i typ. Podpisywanie zbiorów RRset zamiast pojedynczych rekordów RR jest bardziej optymalne, ponieważ serwer nazw zwykle zwraca całą grupę rekordów w odpowiedzi na zapytanie DNSowe.
Stworzenie podpisu odbywa się zwykle przy wykorzystaniu kombinacji algorytmów SHA-1 i RSA bądź algorytmów SHA-1 i DSA. W pierwszym kroku zostaje obliczony "odcisk palca" grupy rekordów, który następnie zostaje zaszyfrowany prywatnym kluczem strefy. W ten sposób klient systemu ma możliwość zweryfikowania otrzymanych informacji za pomocą publicznego klucza strefy.
Idealnie, tylko jeden klucz publiczny, mianowicie klucz publiczny korzenia DNS, musiałby zostać rozprowadzony bezpiecznym kanałem do wszystkich użytkowników systemu DNS, by zapewnić kompletne zabezpieczenie systemu.
DNSSEC wprowadza do DNSu pięć nowych rekordów związanych z usługami bezpieczeństwa:
DNSKEY - klucz publiczny do weryfikacji podpisów,
RRSIG - podpis grupy rekordów,
DS - wskazanie na klucz podpisujący klucz strefy u potomka,
NSEC - zapewnienie spójności danych strefy i umożliwienie weryfikacji informacji o nieistnieniu rekordu lub o braku zabezpieczeń (wersja opt-in).
Wprowadzenie mechanizmów DNSSEC nie pociąga za sobą żadnych znaczących zmian w protokole DNS. Istniejące serwery cache'ujące oraz resolwery powinny poprawnie działać o ile wspierają one dodane rekordy zasobów. Wyjątkowo, odwołania CNAME w zabezpieczonej strefie nie mogą być autoryzowane, jeżeli dotyczą serwerów nie wspierających mechanizmów bezpieczeństwa.
DNSSEC definiuje dwa nowe bity nagłówka komunikatu DNS, dotychczas niewykorzystywane. Bit AD (dane autentyczne) wskazuje, iż dane otrzymane w sekcji odpowiedzi i zwierzchności zostały zweryfikowane przez serwer stosownie do wykorzystywanych przez niego procedur. Z kolei bit CD (sprawdzanie wyłączone) informuje odpytywany serwer, że także nie zweryfikowane informacje będą zaakceptowane przez resolwer.
Pakiety UDP DNS są ograniczone do 512 bajtów, co stanowi istotne ograniczenie dla komunikatów DNSSEC. Większa objętość odpowiedzi zwiększa prawdopodobieństwo jej obcięcia, którego rezultatem może być ponowienie zapytania przez resolwer, wykorzystując tym razem protokół TCP. Obsługa zapytań TCP jest bardziej czasochłonna, głównie z powodu konieczności zestawiania i zrywania dedykowanego połączenia. Z tego względu DNSSEC wymusza wsparcie dla EDNS0. Najbardziej znaczący bit pola Z nagłówka OPT, tak zwany bit DO (DNSSEC OK), informuje o możliwości zaakceptowania przez klienta odpowiedzi DNSSEC.
2006
