RFC 2845 (rfc2845) - Page 2 of 15

Secret Key Transaction Authentication for DNS (TSIG)

RFC 2845                        DNS TSIG                        May 2000


   security generally requires extensive local caching of keys and
   tracing of authentication through multiple keys and signatures to a
   pre-trusted locally configured key.

   1.2. One difficulty with the [RFC 2535] scheme is that common DNS
   implementations include simple "stub" resolvers which do not have
   caches.  Such resolvers typically rely on a caching DNS server on
   another host.  It is impractical for these stub resolvers to perform
   general [RFC 2535] authentication and they would naturally depend on
   their caching DNS server to perform such services for them.  To do so
   securely requires secure communication of queries and responses.
   [RFC 2535] provides public key transaction signatures to support this,
   but such signatures are very expensive computationally to generate.
   In general, these require the same complex public key logic that is
   impractical for stubs.  This document specifies use of a message
   authentication code (MAC), specifically HMAC-MD5 (a keyed hash
   function), to provide an efficient means of point-to-point
   authentication and integrity checking for transactions.

   1.3. A second area where use of straight [RFC 2535] public key based
   mechanisms may be impractical is authenticating dynamic update
   [RFC 2136] requests.  [RFC 2535] provides for request signatures but
   with [RFC 2535] they, like transaction signatures, require
   computationally expensive public key cryptography and complex
   authentication logic.  Secure Domain Name System Dynamic Update
   ([RFC 2137]) describes how different keys are used in dynamically
   updated zones.  This document's secret key based MACs can be used to
   authenticate DNS update requests as well as transaction responses,
   providing a lightweight alternative to the protocol described by
   [RFC 2137].

   1.4. A further use of this mechanism is to protect zone transfers.
   In this case the data covered would be the whole zone transfer
   including any glue records sent.  The protocol described by [RFC 2535]
   does not protect glue records and unsigned records unless SIG(0)
   (transaction signature) is used.

   1.5. The authentication mechanism proposed in this document uses
   shared secret keys to establish a trust relationship between two
   entities.  Such keys must be protected in a fashion similar to
   private keys, lest a third party masquerade as one of the intended
   parties (forge MACs).  There is an urgent need to provide simple and
   efficient authentication between clients and local servers and this
   proposal addresses that need.  This proposal is unsuitable for
   general server to server authentication for servers which speak with
   many other servers, since key management would become unwieldy with





Vixie, et al.               Standards Track