449 lines
14 KiB
Plaintext
449 lines
14 KiB
Plaintext
|
||
|
||
Network Working Group M. Kosters
|
||
Internet-Draft Network Solutions, Inc.
|
||
Expires: May 18, 2001 November 17, 2000
|
||
|
||
|
||
DNSSEC Opt-in for Large Zones
|
||
draft-kosters-dnsext-dnssec-opt-in-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 May 18, 2001.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2000). All Rights Reserved.
|
||
|
||
Abstract
|
||
|
||
In order for DNSSEC to be deployed operationally with large zones
|
||
and little operational impact, there needs to be included a
|
||
mechanism that allows for the separation of secure versus unsecure
|
||
views of zones. This needs to be done in a transparent fashion that
|
||
allows DNSSEC to be deployed in an incremental manner. This
|
||
document proposes the use of an extended RCODE to signify that a
|
||
DNSSEC-aware requestor may have to re-query for the information, if
|
||
and only if, the delegation is not yet secure. Thus, one can
|
||
maintain two views of the zone and expand the DNSSEC zone as demand
|
||
warrants.
|
||
|
||
|
||
|
||
|
||
|
||
Kosters Expires May 18, 2001 [Page 1]
|
||
|
||
Internet-Draft DNSSEC Opt In November 2000
|
||
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
3. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
|
||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
|
||
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
|
||
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 8
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Kosters Expires May 18, 2001 [Page 2]
|
||
|
||
Internet-Draft DNSSEC Opt In November 2000
|
||
|
||
|
||
1. Introduction
|
||
|
||
DNS is an unsecure system. The key features that gives DNS its power
|
||
can also be its chief weaknesses. One feature is the facility to
|
||
delegate branches of information from one set of servers to another.
|
||
Currently, this is done in a non-cryptographically verified way that
|
||
allows spoofing attacks. For example, Eugene Kashpureff exploited
|
||
this vulnerability to redirect www.netsol.com and www.internic.net
|
||
to his own website. If this delegated information had been
|
||
cryptographically verified, this attack would not have been able to
|
||
occur.
|
||
|
||
In recent years, there has been much work within the IETF regarding
|
||
DNS security. There are a number of RFCs that integrate public key
|
||
technology within DNS to enable cryptographically-verified answers.
|
||
To this end, three new resource record types (RR's) have been
|
||
defined:
|
||
|
||
o KEY -- a public key of the zone
|
||
o SIG - a signature of an accompanying RR
|
||
o NXT - a negative response record
|
||
|
||
Within the zone, each authoritative RR will have accompanying SIG
|
||
RR's that can be verified with the KEY RR of the zone. Each KEY RR
|
||
can be verified hierarchically with a SIG RR from the direct parent
|
||
zone. For unsecure delegations, a null-KEY RR is inserted in the
|
||
parent zone. Finally, NXT RR's and their accompanying SIG RR's are
|
||
issued in the case of a negative reply.
|
||
|
||
As a zone maintainer, transitioning to a secure zone has a high
|
||
overhead in the following areas:
|
||
|
||
KEY RR
|
||
At a delegation point, the zone maintainer needs to place a NULL
|
||
key and accompanying SIG RR's when the child zone is not known to
|
||
be secure.
|
||
NXT RR
|
||
Each delegation needs to be lexigraphically ordered so that a NXT
|
||
RR can be generated and signed with SIG RR's. For large zone
|
||
operators, generating the zone file is a very time consuming
|
||
process. In the resolution process, NXT lookups require that the
|
||
server replace efficient hash structures with a lexigraphically
|
||
ordered search structure which degrades lookup performance. This
|
||
lookup performance is a critical element for a high-query rate
|
||
DNS server.
|
||
|
||
Thus, the net effect is when one initially secures a zone as defined
|
||
in RFC2535[4], the net overhead is massive because of the following
|
||
factors:
|
||
|
||
|
||
Kosters Expires May 18, 2001 [Page 3]
|
||
|
||
|
||
1. Zone ordering and maintenance for large zones is difficult and
|
||
expensive.
|
||
2. Adding null-KEY RR's, NXT RR's and their accompanying SIG RR's
|
||
for unsecure delegations will consume large amounts of memory
|
||
(6x the current memory requirements).
|
||
3. Having a less efficient look-up algorithm to provide answers to
|
||
queries will degrade overall performance.
|
||
4. Very little initial payoff (anticipate only a small fraction of
|
||
delegations to be signed. This equates to less than 1% over the
|
||
first six months).
|
||
5. Unsecured delegations are more expensive at the parent than
|
||
secure delegations (NULL KEY).
|
||
|
||
2. Rationale
|
||
|
||
As DNSSEC is initially deployed, it is anticipated that DNSSEC
|
||
adoption will be slow to materialize. It is also anticipated that
|
||
DNSSEC security resolution will be top down. Thus for DNSSEC to be
|
||
widely adopted, the root zone and GTLD zones will need to be signed.
|
||
Based on the implications previously listed, a large zone maintainer
|
||
such as the administrator of COM, needs to create an infrastructure
|
||
that is an order of magnitude larger than its current state with
|
||
very little initial benefit.
|
||
|
||
This document proposes an alternative opt-in approach that minimizes
|
||
the expense and complexity to ease adoption of DNSSEC for large
|
||
zones by allowing for an alternate view of secured only delegations.
|
||
|
||
3. Protocol Additions
|
||
|
||
The opt-in proposal allows for a zone operator to maintain two views
|
||
of its delegations - one being non-DNSSEC and the other being
|
||
DNSSSEC aware. The non-DNSSEC view will have all delegations - both
|
||
secured and non-secured. The DNSSEC aware view will only have
|
||
secured delegations. It is assumed that neither view will have any
|
||
innate knowledge of the other's delegations. Thus, the cost of
|
||
securing a zone is proportional to the demand of its delegations
|
||
with the added benefit of no longer having to maintain NULL KEY RRs
|
||
for unsecure delegations.
|
||
|
||
To determine which view each DNS query packet is to be queried
|
||
against, there is a simple algorithm to be followed:
|
||
|
||
1. The DNSSEC view is to be queried when the DO bit is set within
|
||
the EDNS0 OPT meta RR as indicated in [6].
|
||
2. The DNSSEC view is to be queried when the query type is SIG,
|
||
KEY, or NXT and the RRs added match the query name and query
|
||
type.
|
||
If the query does not follow either case (1) or (2), the non-DNSSEC
|
||
view MUST be consulted by default.
|
||
|
||
|
||
|
||
Kosters Expires May 18, 2001 [Page 4]
|
||
|
||
Internet-Draft DNSSEC Opt In November 2000
|
||
|
||
|
||
Since the DNSSEC view will have a subset of the actual delegations
|
||
of that zone, it will not be able to respond to an unsecured
|
||
delgation. To that end, a new extended RCODE MUST be set within the
|
||
EDNS OPT RR for the resolver to retry again with the DO bit not set.
|
||
This RCODE is referred to as "RETRY-NO-SEC" (RS). In the context of
|
||
the EDNS0 OPT meta-RR, the RS value will be determined by IANA.
|
||
Setting the RS RCODE in a response indicates to the resolver that
|
||
the resolver is retrying the query again without the DO bit set. The
|
||
behavior of the authority and additional records section being
|
||
populated should be the same using the RS RCODE as the the RCODE
|
||
being set to NXDOMAIN. Therefore, the resolver will be able to
|
||
verify that the answer does not exist within the secure zone since
|
||
the NXT RR will be sent in the Authority section. To avoid caching,
|
||
the server SHOULD set the TTL on the NXT RR to 0.
|
||
|
||
Example:
|
||
|
||
Consider a zone with the secure names 3, 6, and 9, and unsecure
|
||
names 2, 4, 5, 7, and 8.
|
||
|
||
Unsecured zone Contents:
|
||
|
||
@ SOA
|
||
2 NS
|
||
3 NS
|
||
4 NS
|
||
5 NS
|
||
6 NS
|
||
7 NS
|
||
8 NS
|
||
9 NS
|
||
|
||
Secured zone Contents:
|
||
@ SOA, SIG SOA, NXT(3), SIG NXT
|
||
3 NS, SIG NS, NXT(6), SIG NXT
|
||
6 NS, SIG NS, NXT(9), SIG NXT
|
||
9 NS, SIG NS, NXT(@), SIG NXT
|
||
|
||
1. Query for 5 RR type A with EDNS0 DO bit set, the response would
|
||
return with the extended RCODE RS bit set:
|
||
|
||
|
||
RCODE=RS
|
||
Authority Section:
|
||
SOA, SIG SOA, 3 NXT(6), SIG NXT
|
||
Additional Section:
|
||
KEY, SIG KEY
|
||
|
||
|
||
|
||
|
||
Kosters Expires May 18, 2001 [Page 5]
|
||
|
||
Internet-Draft DNSSEC Opt In November 2000
|
||
|
||
|
||
The source would then retry without the EDNS0 DO bit set which
|
||
would return an answer as defined in RFC1035[2].
|
||
|
||
2. Query for 55 RR type A with EDNS0 DO bit set, the response would
|
||
return with the extended RCODE RS bit set:
|
||
|
||
|
||
RCODE=RS
|
||
Authority Section:
|
||
SOA, SIG SOA, 3 NXT(6), SIG NXT
|
||
Additional Section:
|
||
KEY, SIG KEY
|
||
|
||
|
||
The source would then retry without the EDNS0 DO bit set which
|
||
would return an answer as defined in RFC1035[2].
|
||
|
||
3. Query for 33 RR type KEY without EDNS DO bit set. The response
|
||
would return with an answer as defined in RFC2535[4].
|
||
|
||
4. Query for 3 RR type A, with EDNS0 DO bit set, the response would
|
||
be the same as defined in RFC2535[4].
|
||
|
||
|
||
4. Security Considerations
|
||
|
||
This draft is different and separate from RFC2535[4] in that it
|
||
allows for secured delegation paths to exist but does not allow for
|
||
secure answers to unsecured delegations at the parent level.
|
||
Increased exposure will be marginal given that the children are
|
||
unsecure.
|
||
|
||
5. IANA Considerations
|
||
|
||
Allocation of the most significant bit of the RCODE field in the
|
||
EDNS0 OPT meta-RR is required.
|
||
|
||
6. Acknowledgements
|
||
|
||
This document is based on a rough draft by Brian Wellington, and
|
||
input from Olafur Gudmundsson.
|
||
|
||
References
|
||
|
||
[1] Mockapetris, P.V., "Domain names - concepts and facilities",
|
||
RFC 1034, STD 13, Nov 1987.
|
||
|
||
[2] Mockapetris, P.V., "Domain names - implementation and
|
||
specification", RFC 1035, STD 13, Nov 1987.
|
||
|
||
|
||
Kosters Expires May 18, 2001 [Page 6]
|
||
|
||
Internet-Draft DNSSEC Opt In November 2000
|
||
|
||
|
||
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
||
Levels", RFC 2119, BCP 14, March 1997.
|
||
|
||
[4] Eastlake, D., "Domain Name System Security Extensions", RFC
|
||
2535, March 1999.
|
||
|
||
[5] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
|
||
August 1999.
|
||
|
||
[6] Conrad, D. R., "Indicating Resolver Support of DNSSEC (work in
|
||
progress)", August 2000.
|
||
|
||
|
||
Author's Address
|
||
|
||
Mark Kosters
|
||
Network Solutions, Inc.
|
||
505 Huntmar Park Drive
|
||
Herndon, VA 22070
|
||
US
|
||
|
||
Phone: +1 703 948-3362
|
||
EMail: markk@netsol.com
|
||
URI: http://www.netsol.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Kosters Expires May 18, 2001 [Page 7]
|
||
|
||
Internet-Draft DNSSEC Opt In November 2000
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2000). 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.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Kosters Expires May 18, 2001 [Page 8]
|
||
|