RFC 2931 (rfc2931) - Page 2 of 10

DNS Request and Transaction Signatures ( SIG(0)s)

RFC 2931                       DNS SIG(0)                 September 2000


Table of Contents

   1. Introduction.................................................  2
   2. SIG(0) Design Rationale......................................  3
   2.1 Transaction Authentication..................................  3
   2.2 Request Authentication......................................  3
   2.3 Keying......................................................  3
   2.4 Differences Between TSIG and SIG(0).........................  4
   3. The SIG(0) Resource Record...................................  4
   3.1 Calculating Request and Transaction SIGs....................  5
   3.2 Processing Responses and SIG(0) RRs.........................  6
   3.3 SIG(0) Lifetime and Expiration..............................  7
   4. Security Considerations......................................  7
   5. IANA Considerations..........................................  7
   References......................................................  7
   Author's Address................................................  8
   Appendix: SIG(0) Changes from RFC 2535..........................  9
   Full Copyright Statement........................................ 10

1. Introduction

   This document makes minor but non-interoperable changes to part of
   [RFC 2535], familiarity with which is assumed, and includes
   additional explanatory text.  These changes concern SIG Resource
   Records (RRs) that are used to digitally sign DNS requests and
   transactions / responses.  Such a resource record, because it has a
   type covered field of zero, is frequently called a SIG(0). The
   changes are based on implementation and attempted implementation
   experience with TSIG [RFC 2845] and the [RFC 2535] specification for
   SIG(0).

   Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2
   and 4.3.  No changes are made herein related to the KEY or NXT RRs or
   to the processing involved with data origin and denial authentication
   for DNS data.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].












Eastlake                    Standards Track