Dokument RFC 2845 definiuje protokół uwierzytelniania transakcji DNS przy wykorzystaniu jednokierunkowej funkcji skrótu z kluczem HMAC-MD5. Protokół może zostać wykorzystany do autoryzacji dynamicznych update'ów jako pochodzących od zaufanego klienta czy tez weryfikacji odpowiedzi od rekurencyjnego serwera odpowiedzialnego za rozwiązywanie nazw klientowi.
DNSSEC rozszerza DNS o procedury pozwalające na wprowadzenie usług uwierzytelniania i nienaruszalności. Protokół oparty jest o cyfrowe podpisy i wykorzystuje mechanizmy kryptograficzne bazujące na kluczach publicznych. Obecnie, biorąc pod uwagę złożoność i niedojrzałość DNSSEC, używanie tego protokołu jest co najmniej niewygodne.
Tam gdzie użycie DNSSEC jest kłopotliwe (z różnych względów) bądź wręcz niemożliwe, z pomocą przychodzi mechanizm autoryzacji transakcji przy pomocy rekordów TSIG. Wykorzystanie rekordu TSIG pozwala na:
zabezpieczenie komunikacji pomiędzy stub-resolwerem (bez cache'u) a serwerem cache'ującym,
autoryzację dynamicznych update'ów,
zabezpieczenie transferu całych stref,
zabezpieczenie komunikacji między klientem a lokalnym serwerem,
zabezpieczenie komunikacji pomiędzy serwerem cache'ującym a wybranymi serwerami nazw.
Rekord TSIG jest nowym typem RR o kodzie 250. TSIG to w istocie meta-rekord, ponieważ nie może on być umieszczany w pamięci cache elementów systemu. Rekord TSIG są obliczane dynamicznie dla każdej transakcji DNS i to wyróżnia je wśród innych rekordów.
Rekordy TSIG są skojarzone z jednym łańcuchem żądania-odpowiedzi DNS, zatem przechowywanie czy ich retransmisja nie ma sensu, bowiem rekord TSIG jest porzucany natychmiast po wykorzystaniu go do weryfikacji wiadomości. Wyznaczenie wartości rekordu TSIG następuje zaraz po przygotowaniu właściwej wiadomości DNS. Obliczany skrót obejmuje całą wiadomość plus część samego rekordu TSIG (tak zwane zmienne TSIG) zawierającą między innymi informacje o czasie utworzenia skrótu i czasowym zakresie jego ważności. Zawarcie tych informacji umożliwia skuteczną ochronę przeciw atakom odtworzeniowym. Obliczony skrót stanowi jedno z pól rekordu TSIG. Cały rekord jest umieszczany w sekcji danych dodatkowych wiadomości DNS, po czym nagłówek wiadomości jest stosownie modyfikowany. Jeżeli wiadomość przekraczałaby dozwoloną wielkość po dołączeniu do niej TSIG, serwer musi skonstruować ją tak, by zawierała tylko zapytanie klienta i rekord TSIG oraz miała ustawioną odpowiednią flagę. Klient otrzymując taką odpowiedź powinien ponowić zapytanie używając TCP. W celu weryfikacji odpowiedzi serwera, klient musi przechować wartość obliczonego skrótu nadanej wiadomości oczekując na odpowiedź.
Rekord TSIG w odebranej wiadomości musi być ostatnim i nie może występować wielokrotnie. Zaraz po otrzymaniu wiadomości TSIG jest kopiowany w bezpieczne miejsce i usuwany z DNS. Wiąże się to z koniecznością aktualizacji odpowiednich pól nagłówka wiadomości. Z tak przygotowanej wiadomości obliczany jest skrót, który następnie porównywany jest z tym odebranym w rekordzie TSIG. W przypadku, gdy skróty nie są jednakowe, wiadomość musi zostać porzucona, a nadawca powiadomiony o problemie; jednocześnie incydent powinien zostać odnotowany w logach systemowych. Weryfikacji podlega również czas utworzenia wiadomości. Jeśli czas nadejścia wiadomości wypada poza dozwolonym przedziałem serwer odsyła komunikat błędu i loguje zdarzenie, podczas gdy klient ogranicza się tylko do rejestracji błędu. Dodatkowo serwer pamięta czas nadania ostatniej odebranej poprawnie informacji i odrzuca wszystkie wiadomości podpisane tym samym kluczem z czasem nadania mniejszym od wspomnianego. W trakcie przetwarzania rekordów TSIG mogą pojawić się błędy związane z nie rozpoznaniem klucza użytego do obliczenia skrótu. W takim wypadku serwer wysyła komunikat o błędzie i rejestruje błąd.
Serwer generując odpowiedź na podpisane zapytanie klienta, tworzy skrót z konkatenacji skrótu zapytania klienta, swojej odpowiedzi DNS oraz zmiennych rekordu TSIG. Serwer nie może odpowiedzieć podpisanym komunikatem na nie podpisaną wiadomość.
Poziom bezpieczeństwa oferowany przez protokół jest uzależniony między innymi od zabezpieczenia kluczy służących do podpisywania wiadomości DNS. Klucze stanowią bardzo ważny element systemu i powinny zostać zabezpieczone przy wykorzystaniu wszystkich dostępnych środków. Szczególne kroki powinny zostać poczynione, jeżeli do maszyny przechowującej klucze ma dostęp wielu użytkowników. Problemem może być zabezpieczenie resolwerów, których konfiguracja jest dostępna dla wszystkich użytkowników. Zaleca się, by w przypadku wielodostępnej maszyny skonfigurować na niej odpowiednio zabezpieczony serwer cache'ujący, z którym użytkownicy systemu mieliby się kontaktować lokalnie za pośrednictwem stub resolwera.
Długość i jakość stosowanych kluczy jest krytyczna dla poziomu bezpieczeństwa. Zalecane jest użycie mocnych losowych kluczy o długości przynajmniej równej długości generowanego skrótu (16 bajtów w przypadku HMAC-MD5).
Wreszcie dystrybucja kluczy nie jest sprawą banalną. Konieczne staje się wypracowanie odpowiednich procedur transportu kluczy pomiędzy elementami systemu. Do czasu opracowania zautomatyzowanego mechanizmu bezpiecznej dystrybucji kluczy, na administratorze systemu będzie spoczywać odpowiedzialność za transfer kluczy oraz odpowiednie skonfigurowanie serwerów i klientów.
2006
