INTERNET-DRAFT Roy Arends
July 13, 2001 Nominum
Expires Januari 2002
Unsigned RRsets in Secure Zones
draft-arends-dnsext-rrsets-00.txt
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.
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on Januari 12, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
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
References
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 NXT b A TXT SIG NXT | a NXT c A NXT NOSIG
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 NXT d A MX SIG NXT | c NXT @ A MX NXT NOSIG
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 NXT b NS KEY SIG NXT | a NXT e KEY NXT NOSIG
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 NXT @ NS KEY SIG NXT | e NXT @ NS KEY SIG NXT
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
following:
1 query: b.test. A
query response:
RCODE : NOERROR
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:
RCODE : NOERROR
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
RRset.
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
delegations.
6. IANA Considerations.
The NOSIG RR type number should be selected by the IANA from the
normal RR type space.
7. Acknowledgements
The work in this draft is based on ideas stated in the [OPTIN] draft.
The goals of these drafts are similar, though both use a different
approach.
The contributions, suggestions and remarks of the following
persons (in alphabetic order) to this draft are acknowledged:
Mats Dufberg
Mark Kosters
David Macka
Dan Massey
Scott Rose
Jakob Schlyter
Funding for the RFC Editor function is currently provided by the
Internet Society.
References
[RFC2535] Eastlake, D., "Domain Name System Security
Extensions", RFC 2535, March 1999.
[RFC3090] Wellington, B., "Secure Dynamic Update", RFC 3007,
November 2000.
[OPTIN] Kosters, M., "DNSSEC Opt-in for Large Zones", Internet-
draft, June 2001.
Author's Address
Roy Arends
1e Atjehstraat 174-2
1094 KX Amsterdam
The Netherlands
Phone: +31-20-663-9306
EMail: Roy.Arends@nominum.com
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
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.