Internet DRAFT - draft-arends-dnsext-rrsets


INTERNET-DRAFT                                                 Roy Arends
July 13, 2001                                                     Nominum
Expires Januari 2002

                   Unsigned RRsets in Secure Zones

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-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 Internet-Draft will expire on Januari 12, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.


   In order for DNSSEC to be deployed operationally, there needs to
   be a mechanism that allows for unsigned RRsets in a secure zone.
   In the current definition of DNSSEC [RFC 2535], it is allowed to
   have 2 types of unsigned records, i.e. glue address RRsets and
   delegation point NS RRsets. There exists several reasons to
   allow other unsigned RRsets, all related to the scalability and
   maintenance of a secure zone.

   This document describes the reasoning as well as a method to
   allow unsigned RRsets within a secure zone. The method consists
   of extending the use of the NXT record to deal with non-secure
   RRsets as well as for non-existence. This is done by allocating
   a bit in the type-bit-map of the NXT RDATA section.

Table of Contents

   1. Introduction
   2. Rationale
   3. The NOSIG pseudo RR
   4. The NXT RR with NOSIG indication in creation of responses.
   5. Security Considerations.
   6. IANA Considerations.
   7. Acknowledgements
      Author's Address
      Full Copyright Statement

1.  Introduction

   The current DNSSEC standards define that a secure zone is
   completely signed. There are cases where there is no need for a
   fully signed zone. In some cases it is just not possible to have
   or maintain every record signed. To allow administrators to
   gradually adopt DNSSEC, a scheme where unsigned resource records
   are allowed in secure zones eases deployment of DNSSEC.

   Section 2 provides the reasoning why it is be useful to have
   unsigned data in a secured zone.

   Section 3 discusses the NOSIG pseudo RR and use.

   Section 4 discusses the implications on the Overall Security. It
   describes what the implications are when the NOSIG RR is used.

   Section 5 discusses the possible query responses when NOSIG is used.

   Section 6 provides the overall security considerations

   Section 7 notes IANA considerations for allocation of the NOSIG RR

2.  Rationale

Critical versus Informational RR types.

   The DNS contains a wide variety of resource records types. Their
   usage range from critical to informational. DNSSEC was developed
   to allow verification of these resource records. Though the
   verification of critical resource records (A, MX, etc. ) is
   desired, for information records (TXT, HINFO, etc) it may be
   not. The current specification of DNSSEC imposes signatures on
   every authoritative resource record in a zone. It does not
   discriminate between critical and informational records.

Aggregated Signing of dynamic updated RRsets

   When a secure zone allows for secure dynamic update [RFC 3090],
   the server needs to sign every addition to the zone, update the
   previous NXT, and add or update the NXT for that name including
   signatures for the altered or add NXT record, and the added
   resource record or Resource Record Set. In case of deleting a
   resource record, the NXT for that owner name has to be updated
   or deleted and the previous NXT might have to be update as well
   including all signatures for the altered NXT records. The
   proposed scheme allows for addition/deletion of resource records
   through secure dynamic update, while the data remains
   (temporarily) unsigned. The signing of these records can occur
   later, if at all. Of course, the SOA serial needs to be
   increased and thus resigned immediately. A workaround for this
   can be to have multiple SIG(SOA) records for future purposes, to
   avoid online storage of the private key.

An alternative for no-key KEYs.

   A special case are large TLDs. In general, TLD-zones consist
   merely of delegation points. RFC 2535 demands that for every
   delegation, secure or not secure, there must be a KEY RR. When
   DNSSEC is deployed, it is expected that the vast majority of
   delegations are initially unsecured. To relief the TLD of the
   burdon of maintaining KEY material and its overhead
   (sig/nxt/sig) for unsecured subzones, a TLD can use the proposed
   method described in this draft.

Maintaining the Chain of Trust.

   When a domain holder wants to have some subzone secured, it
   currently needs to sign every single RR in its zone as well if
   it wants to maintain the chain of trust from the superzone,
   through the zone, to the subzone. In this case, only the "chain
   of trust" to the subzone needs to be signed, i.e. the delegation
   at the superzone, the apex of the zone, the delegation point to
   the subzone, and the subzone's apex.

3.  The NOSIG pseudo RR

   A NOSIG RR is called a pseudo RR because it exist only in the
   type-bit-map of a NXT RDATA section. A NOSIG RR does not have an
   explicit label nor a RDATA section. It is implied by the NXT
   label and the NXT next-domain part in its RDATA section.

   Its presence indicates that there exists no signed RRsets (there
   may be unsigned RRsets) within a NXT name interval. Its absence
   indicates that there exists no RRsets within a NXT name
   interval, and is exactly the same as the rfc2535 semantics of
   the NXT RR.

   The NOSIG RR has type code XX.

Semantics of NXT

   The NXT resource record is used to securely indicate that RRs
   with an owner name in a certain name interval do not exist in a
   zone and to indicate what RR types are present for an existing
   name. The owner name of the NXT RR is an existing name in the
   zone. It's RDATA is a "next" name and a type bit map. Thus the
   NXT RRs in a zone create a chain of all of the literal owner
   names in that zone, including unexpanded wildcards but omitting
   the owner name of glue address records unless they would
   otherwise be included. The presence of the NXT RR means that no
   name between its owner name and the name in its RDATA area
   exists and that no other types exist under its owner name.

Semantics of NXT + NOSIG

   When the NOSIG RR type is present in the type bit map of a NXT
   RR, the semantics of the NXT RR are slightly shifted. The
   NXT+NOSIG indicates that RRsets with an signed owner name
   (instead of any owner name) in a certain name interval does not
   exist in a zone. The type-bit-map indicates what RRsets are
   signed (instead of exist) for a name.

   Note that in general, only names which have some RRset signed
   will have a NXT RR, regardless whether the NOSIG type is present
   in the type bit map. This clarification is _no_ update of the
   NXT semantics of RFC 2535. In RFC 2535 this was implicated
   because a zone consists purely of signed RR sets, the NXT name
   always had a signed RR associated with it.

   When NXT + NOSIG is used, delegation point NS RRset MUST NOT
   appear in the type bit map as they will never be signed. Also
   SIG MUST NOT appear in the type bit map. SIG records contain
   signatures for RRsets, and are never signed.

    discussion point: because of the behaviour of NXT+NOSIG wrt SIG
    records, a NXT has either SIG or NOSIG but NEVER both RR type
    (a SIG is never signed itself). This could of course mean that
    instead of defining a NOSIG RR type, NOSIG is implied by the
    absence of SIG in a type bit map. With rfc 2535 semantics,
    there will ALWAYS be an indication in the type bit map that a
    SIG exists, so absence of a SIG could imply NOSIG (as in NO SIG
    implies eh, NOSIG :-)

Usage in general

   When a NXT + NOSIG is present in a zone, it indicates that there
   might be unsigned RRsets in its name interval and that there
   might be unsigned RRsets for the NXT name. The type bit map
   indicates which signed RRsets are present for the NXT owner name

Special usage for informational or non-critical RRs.

   A domain holder can choose not to have its non-critical RRs
   signed. These RRs might be for instance HINFO or TXT records,
   but also A records that have is not critical for the day to day
   operation of the infrastructure.

Examples of NOSIG usage for informational or non-critical RRs.

   The following RRsets gives an example of the NXT+NOSIG
   usage versus the rfc2535 NXT usage.

   without NOSIG           | with NOSIG

   a A   rdata             | a A   rdata
   a SIG (A)               | a SIG (A)
   a TXT "Our Mailserver"  | a TXT "Our Webserver"
   a SIG (TXT)             |
   a HINFO rdata           | a HINFO rdata
   a SIG (HINFO)           |
   a SIG (NXT)             | a SIG NXT

   b A   rdata             | b A   rdata
   b SIG (A)               |
   b TXT "Test Server"     | b TXT "Test Server"
   b SIG (TXT)             |
   b NXT A TXT SIG NXT     |
   b SIG (NXT)             |

   c MX 10 a               | c MX 10 a
   c MX 20 c               | c MX 20 c
   c SIG (MX)              | c SIG (MX)
   c A rdata               | c A rdata
   c SIG (A)               | c SIG (A)
   c SIG (NXT)             | c SIG (NXT)

   d A rdata               | d A rdata
   d SIG (A)
   d TXT "Bob's laptop"    | d TXT "Bob's laptop"
   d TXT "DHCP assigned A" | d TXT "DHCP assigned A"
   d SIG(TXT)              |
   d NXT @ A TXT SIG NXT   |
   d SIG(NXT)              |

   For name b and d, nothing is signed, for name c, everything is
   signed, for name a, there exist unsigned RR.

Special usage at delegation points.

   Delegation point NS records are never signed in a secured zone.
   For a secure zone to indicate whether a subzone is considered
   secured or not, there must be a signed RRset present for that
   name other then the NS RRset. RFC 2535 states that for an
   unsecured subzone, there must be a "no-key" KEY RRset present. A
   "no-key" KEY is indicated by setting bit 0 and bit 1 in the flag
   field of the KEY's RDATA.

   The NOSIG RR type gives an alternative to this requirement.

   As said, the no-key's function is merely to have a verifiable
   substance at a delegation point to indicate a subzone is not
   secure. Because the NOSIG RR type allows for unsigned RRsets to
   exist within a name interval, delegation point NS with no other
   signed material (no-key's) can exist.

   This adds efficiency for some large delegation zones. In RFC
   2535 there was the requirement of having a signed no-key KEY RR,
   a SIG(KEY), a NXT, and a SIG(NXT) for every unsecured subzone.
   With this scheme, multiple unsigned subzones can be covered with
   a single NXT.

Examples of NOSIG at delegation points

   The following signed delegations gives an example of the
   NXT+NOSIG usage versus the rfc2535 NXT usage.

   without NOSIG           | with NOSIG
   a NS  rdata             | a NS  rdata
   a KEY real-key          | a KEY real-key
   a SIG(KEY)              | a SIG(KEY)
   a SIG(NXT)              | a SIG(NXT)

   b NS rdata              | b NS rdata
   b KEY no-key            |
   b SIG(KEY)              |
   b NXT c NS KEY SIG NXT  |
   b SIG(NXT)              |

   c NS rdata              | c NS rdata
   c KEY no-key            |
   c SIG(KEY)              |
   c NXT d NS KEY SIG NXT  |
   c SIG(NXT)              |

   d NS rdata              | d NS rdata
   d KEY no-key            |
   d SIG(KEY)              |
   d NXT c NS KEY SIG NXT  |
   d SIG(NXT)              |

   e NS rdata              | e NS rdata
   e KEY real-key          | e KEY real-key
   e SIG(KEY)              | e SIG(KEY)
   e SIG(NXT)              | e SIG(NXT)

   Delegation points a and e are secure. points b, c and d are not.

4. The NXT RR with NOSIG indication in creation of responses.

   When a query-response contains usigned RRsets in the answer
   section, the NXT+NOSIG must appear in the authority section.

   When a query-response contains a referral to an unsecured zone,
   and there exists no no-key for the referral, the NXT+NOSIG must
   appear in the authority section

   Given the following records in a secure zone:

   a A rdata            ; signed A record
   a SIG (A)            ;
   a NXT c A NXT NOSIG  ; NXT denies other signed RRsets
   a SIG (NXT)          ;

   b A rdata            ; unsigned A record

   c NS rdata           ; Secured delegation point
   c DS rdata           ;
   c SIG (DS)           ;
   c NXT @ DS NXT NOSIG ; NXT denies other signed RRsets
   c SIG (NXT)          ;

   d NS rdata           ; Unsecure delegation point

   The current set of query-responses is extended with the

   1 query:     b.test. A
     query response:
     ANSWER   : b.test. A rdata
     AUTHORITY: a.test. NXT c.test. A NXT NOSIG
                a.test. SIG (NXT)

   2 query:     d.test. A
     query response:
     ANSWER   : -------
     AUTHORITY: d.test. NS rdata
                c.test. NXT test. DS NXT NOSIG
                c.test. SIG (NXT)

   Query response 1 contains the unsigned b.test. A record.
   Query response 2 is a referral to an unsecured zone.

5.  Security Considerations.

   Using NOSIG to allow for unsigned RRsets in a secure zone have
   the following implications on the overall security:

   1. There is the possibility for a malicious user to let a secure
      resolver believe that a non-existent unsigned RRset exist.
      This is a very rare case. If that would be a problem for a
      domain, use NXT w/o NOSIG instead, as it does not allow for
      unsigned RRsets within a name interval.

   2. There is the possibility for a malicious user to let a secure
      resolver believe that an existent unsigned RRset does not
      exist.  If that would be a problem for a domain, sign the the

   3. There is the possibility for a malicious user to let a secure
      resolver believe that a non-existent unsigned subzone exist.
      This is a very rare case. If that would be a problem for a
      domain, use no-key instead.

   4. There is the possibility for a malicious user to let a secure
      resolver believe that an existent unsigned subzone does not
      exist. This is no different in the no-key scheme, because the
      NS RR itself are never signed, and might be forged to point
      to a non existent nameserver.

   Using NOSIG has no impact on signed RRsets and signed

6.  IANA Considerations.

   The NOSIG RR type number should be selected by the IANA from the
   normal RR type space.

7.  Acknowledgements

   The contributions, suggestions and remarks of the following
   persons (in alphabetic order) to this draft are acknowledged:

      Mats Dufberg
      Scott Rose
      Jakob Schlyter

   Funding for the RFC Editor function is currently provided by the
   Internet Society.


   [RFC2535] Eastlake, D., "Domain Name System Security
             Extensions", RFC 2535, March 1999.

   [RFC3090] Wellington, B., "Secure Dynamic Update", RFC 3007,
             November 2000.

Author's Address

   Roy Arends
   1e Atjehstraat 174-2
   1094 KX Amsterdam
   The Netherlands

   Phone: +31-20-663-9306

Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished
   to others, and derivative works that comment on or otherwise
   explain it or assist in its implementation may be prepared,
   copied, published and distributed, in whole or in part, without
   restriction of any kind, provided that the above copyright
   notice and this paragraph are included on all such copies and
   derivative works.  However, this document itself may not be
   modified in any way, such as by removing the copyright notice or
   references to the Internet Society or other Internet
   organizations, except as needed for the purpose of developing
   Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or
   as required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will not
   be revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided