TSIG

I když dotazy na DNS mohou být uskutečněny anonymně (viz DNSSEC), aktualizace DNS musí být ověřeny, protože dělají trvalé změny do systému DNS. Použití klíče sdíleného klientem a DNS serverem zajišťuje ověření požadavku. Díky tomu aktualizační požadavek může procházet nezabezpečeným kanálem (internetem). Jako prevence proti zlomyslným uživatelům sítě, kteří by se snažili zjistit tajný klíč a provádět vlastní úpravy, je použito hašování.

Součástí protokolu TSIG je časová značka (anglicky timestamp), která znemožňuje opakované použití zachycené komunikace. Proto se po DDNS serverech a TSIG klientech vyžaduje, aby jejich čas byl přesný. Protože DNS servery jsou připojeny k síti, je možné pro seřízení času využít protokol NTP.

Aktualizace DNS, stejně jako dotazy jsou normálně přenášeny pomocí UDP, protože vyžaduje nižší režii než TCP. DNS servery ovšem podporují jak UDP tak TCP požadavky.

Aktualizace, jak je specifikováno v RFC 2136, je sada instrukcí pro DNS server. Ty zahrnují hlavičku, oblast aktualizace, předpoklady, které musí být splněny, a záznamy k aktualizaci. TSIG přidává konečný záznam, který obsahuje časovou známku a haš požadavku. Obsahuje také jméno tajného klíče, který byl použit k podepsání požadavku. RFC 2535 obsahuje doporučenou podobu pro jméno.

Odpověď na úspěšnou TSIG aktualizaci bude také podepsána TSIG záznamem. Neúspěchy nejsou podepsány, aby se předešlo úniku jakýchkoli informací spojených s TSIG klíči pomocí speciálně vytvořených aktualizačních sond.

Nsupdate Dokáže využít TSIG pro aktualizaci DNS záznamu.

TSIG záznam má stejný formát jako ostatní dotazy v aktualizačním požadavku. Význam polí je popsán v RFC 1035.

I přes to, že TSIG je široce rozvinut, je s ním spojeno několik problémů:

• Vyžaduje distribuci tajných klíčů všem hostům, kteří musí provádět aktualizace.
• HMAC-MD5 má pouze 128 bitů.
• Neexistují úrovně správy. Jakýkoli host s tajným klíčem může provést aktualizaci.

Jako výsledek bylo navrženo mnoho alternativ:

• RFC 2137 specifkuje aktualizační metodu s použitím veřejného klíče a DNS záznamu. Klient držící odpovídající privátní klíč může podepsat aktualizační požadavek. Tato metoda odpovídá DNSSEC metodě pro zabezpečené dotazy. Nicméně tato metoda zastarává dokumentem RFC 3007.
• V roce 2003, RFC 3645 navrhl rozšíření TSIG pro použití Generic Security Service (GSS) metody bezpečné výměny klíčů, což eliminovalo potřebu manuální distribuce klíčů všem TSIG klientům. Metoda šíření veřejných klíčů jako DNS záznamů je specifikována v RFC 2930, s GSS jako jednou z možností. Modifikovaný GSS-TSIG (používající Windows Kerberos Server) byl implementován Microsoft Windows Active Directory servery a klienty jako Secure Dynamic Update. V kombinaci s mizerně nastaveným DNS (bez zóny zpětného vyhledávání) využívajícím RFC 1918 adresování, zpětné DNS aktualizace využívající toto ověřovací schéma jsou přesměrovány na kořenové DNS servery a zvyšují tak provoz. Proto existuje anycast skupina, která odvádí provoz od kořenových DNS serverů
• RFC 2845, definující TSIG, specifikuje pouze jednu povolenou hašovací funkci HMAC-MD5, která už není považována za vysoce bezpečnou. Od roku 2006 kolují návrhy na nahrazení RFC 3174 Secure Hash Algorithm (SHA1) hašováním, které by nahradilo MD5. 160 bitů generovaných SHA1 by mělo být bezpečnějších než 128 bitů generovaných MD5.
• RFC 2930, definující TKEY, DNS záznam automaticky šíří klíče z DNS serverů ke klientům.
• RFC 3645, definující GSS-TSIG, používající gss-api a TKEY k automatickému šíření klíčů v gss-api módu.
• DNSCurve Návrh velmi podobný TSIG.

• Broido, Nemeth, claffy. "Spectroscopy of DNS Update Traffic", CAIDA, 2002.

V tomto článku byl použit překlad textu z článku TSIG na anglické Wikipedii.