Secret Key Transaction Authentication for DNS (TSIG)

The information below is for an old version of the document that is already published as an RFC
Document Type RFC Internet-Draft (dnsext WG)
Authors Donald Eastlake  , ├ôlafur Gu├░mundsson  , Paul Vixie  , Brian Wellington 
Last updated 2013-03-02 (latest revision 2000-03-02)
Stream Internet Engineering Task Force (IETF)
Formats pdf htmlized (tools) htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2845 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
DNSIND Working Group                              Paul Vixie (Ed.) (ISC)
   INTERNET-DRAFT                              Olafur Gudmundsson (NAILabs)
                                             Donald Eastlake 3rd (Motorola)
                                                 Brian Wellington (NAILabs)
   <draft-ietf-dnsext-tsig-00.txt>                               March 2000

   Amends: RFC 1035

             Secret Key Transaction Authentication for DNS (TSIG)

   Status of this Memo

      This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026.

      Internet-Drafts are working documents of the Internet Engineering
      Task Force (IETF), its areas, and its working groups.  Note that
      other groups may also distribute working documents as Internet-

      Internet-Drafts are draft documents valid for a maximum of six months
      and may be updated, replaced, or obsoleted by other documents at any
      time.  It is inappropriate to use Internet-Drafts as reference
      material or to cite them other than as ``work in progress.''

      The list of current Internet-Drafts can be accessed at

      The list of Internet-Draft Shadow Directories can be accessed at


      This protocol allows for transaction level authentication using
      shared secrets and one way hashing.  It can be used to authenticate
      dynamic updates as coming from an approved client, or to authenticate
      responses as coming from an approved recursive name server.

      No provision has been made here for distributing the shared secrets;
      it is expected that a network administrator will statically configure
      name servers and clients using some out of band mechanism such as
      sneaker-net until a secure automated mechanism for key distribution
      is available.

   Expires September 2000                                          [Page 1]
INTERNET-DRAFT                  DNS TSIG                      March 2000

   1 - Introduction

   1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated
   hierarchical distributed database system that provides information
   fundamental to Internet operations, such as name <=> address translation
   and mail handling information.  DNS has recently been extended [RFC2535]
   to provide for data origin authentication, and public key distribution,
   all based on public key cryptography and public key based digital
   signatures.  To be practical, this form of 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 [RFC2535] 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 [RFC2535] 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.
   [RFC2535] 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 [RFC2535] public key based
   mechanisms may be impractical is authenticating dynamic update [RFC2136]
   requests.  [RFC2535] provides for request signatures but with [RFC2535]
   they, like transaction signatures, require computationally expensive
   public key cryptography and complex authentication logic.  Secure Domain
   Name System Dynamic Update ([RFC2137]) 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 [RFC2137].

   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 [RFC2535] does not
   protect glue records and unsigned records unless SIG(0) (transaction
   signature) is used.

   Expires September 2000                                          [Page 2]
INTERNET-DRAFT                  DNS TSIG                      March 2000

   1.5. The authentication mechanism proposed in this document uses shared
Show full document text