Secret Key Transaction Authentication for DNS (TSIG) (RFC2845)
Original Publication Date: 2000-May-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
P. Vixie: AUTHOR [+4]
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.
Network Working Group P. Vixie
Request for Comments: 2845 ISC
Category: Standards Track O. Gudmundsson
Updates: 1035 NAI Labs
D. Eastlake 3rd
Secret Key Transaction Authentication for DNS (TSIG)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2000). All Rights Reserved.
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
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 ar...