datatracker.ietf.org
Sign in
Version 5.6.4.p1, 2014-10-20
Report a bug

DNS Security (DNSSEC) Opt-In
RFC 4956

Document type: RFC - Experimental (July 2007; Errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4956 (Experimental)
Responsible AD: Mark Townsley
Send notices to: <ogud@ogud.com>, <okolkman@ripe.net>

Network Working Group                                          R. Arends
Request for Comments: 4956                                       Nominet
Category: Experimental                                        M. Kosters
                                                               D. Blacka
                                                          VeriSign, Inc.
                                                               July 2007

                      DNS Security (DNSSEC) Opt-In

Status of This Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   In the DNS security (DNSSEC) extensions, delegations to unsigned
   subzones are cryptographically secured.  Maintaining this
   cryptography is not always practical or necessary.  This document
   describes an experimental "Opt-In" model that allows administrators
   to omit this cryptography and manage the cost of adopting DNSSEC with
   large zones.

Arends, et al.                Experimental                      [Page 1]
RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007

Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definitions and Terminology  . . . . . . . . . . . . . . . . .  3
   3.  Experimental Status  . . . . . . . . . . . . . . . . . . . . .  4
   4.  Protocol Additions . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Server Considerations  . . . . . . . . . . . . . . . . . .  6
       4.1.1.  Delegations Only . . . . . . . . . . . . . . . . . . .  6
       4.1.2.  Insecure Delegation Responses  . . . . . . . . . . . .  6
       4.1.3.  Dynamic Update . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Client Considerations  . . . . . . . . . . . . . . . . . .  7
       4.2.1.  Delegations Only . . . . . . . . . . . . . . . . . . .  7
       4.2.2.  Validation Process Changes . . . . . . . . . . . . . .  7
       4.2.3.  NSEC Record Caching  . . . . . . . . . . . . . . . . .  8
       4.2.4.  Use of the AD bit  . . . . . . . . . . . . . . . . . .  8
   5.  Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Transition Issues  . . . . . . . . . . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Implementing Opt-In Using "Views" . . . . . . . . . . 15

Arends, et al.                Experimental                      [Page 2]
RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007

1.  Overview

   The cost to cryptographically secure delegations to unsigned zones is
   high for large delegation-centric zones and zones where insecure
   delegations will be updated rapidly.  For these zones, the costs of
   maintaining the NextSECure (NSEC) record chain may be extremely high
   relative to the gain of cryptographically authenticating existence of
   unsecured zones.

   This document describes an experimental method of eliminating the
   superfluous cryptography present in secure delegations to unsigned
   zones.  Using "Opt-In", a zone administrator can choose to remove
   insecure delegations from the NSEC chain.  This is accomplished by
   extending the semantics of the NSEC record by using a redundant bit
   in the type map.

2.  Definitions and Terminology

   Throughout this document, familiarity with the DNS system (RFC 1035
   [1]), DNS security extensions ([4], [5], and [6], referred to in this
   document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090
   [10]) is assumed.

   The following abbreviations and terms are used in this document:

   RR:  is used to refer to a DNS resource record.

   RRset:  refers to a Resource Record Set, as defined by [8].  In this
      document, the RRset is also defined to include the covering RRSIG
      records, if any exist.

   signed name:  refers to a DNS name that has, at minimum, a (signed)
      NSEC record.

   unsigned name:  refers to a DNS name that does not (at least) have an
      NSEC record.

   covering NSEC record/RRset:  is the NSEC record used to prove
      (non)existence of a particular name or RRset.  This means that for

[include full document text]