Internet Engineering Task Force N. Kong
Internet-Draft Y. Zhang
Intended status: Informational X. Lee
Expires: August 31, 2010 CNNIC
February 27, 2010
DNSSEC Lookaside Validation Trust Alliance (DLVTA) of Multiple DNSSEC
Lookaside Validation (DLV) Domains
draft-kong-dnsop-dlv-trust-alliance-00
Abstract
This document describes a methodology for constructing DNSSEC
Lookaside Validation Trust Alliance (DLVTA) of multiple DNSSEC
Lookaside Validation (DLV) domains without disrupting the deployment
of standard DNSSEC. The DLVTA allows validating resolvers to
validate DNSSEC-signed data from multiple DLV domains without
maintaining a series of trust anchors for those different DLV domains
in their name server configurations.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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 August 31, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kong, et al. Expires August 31, 2010 [Page 1]
Internet-Draft DLVTA February 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Kong, et al. Expires August 31, 2010 [Page 2]
Internet-Draft DLVTA February 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. The DLVTA DNS Resource Record . . . . . . . . . . . . . . . . 6
4.1. DLVTATI Resource Record . . . . . . . . . . . . . . . . . 6
4.2. DLVTAKI Resource Record . . . . . . . . . . . . . . . . . 7
5. The Validator Behavior using DLVTA . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security considerations . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Kong, et al. Expires August 31, 2010 [Page 3]
Internet-Draft DLVTA February 2010
1. Introduction
DNSSEC [RFC4033] [RFC4034] [RFC4035] authenticates Domain Name System
(DNS) data by building public-key signature chains along the DNS
authentication chain from a trust anchor.
DNSSEC Lookaside Validation (DLV) [RFC4431] [RFC5074] allows the
deployment of DNSSEC in the absence of a signed DNS tree at the root,
Top Level Domain (TLD) and near-top levels. DLV provides an
additional entry point from which to obtain the DNSSEC validation
information.
DLV allows a set of DLV domains to publish secure entry points for
zones that are not their own children as described in [RFC5074]. In
future, there will be multiple DLV domains operated by different
organizations for different zones whose ancestors either aren't
signed or don't publish Delegation Signer (DS) records [RFC4034] for
their children. For example, the DLV domain dlv.example.zone1
targets the zone1 zone, the DLV domain dlv.example.zone2 targets the
zone2 zone, and the DLV domain dlv.example.zone3 targets the zone3
zone. "In the interest of limiting complexity, validators SHOULD NOT
attempt to use DLV to validate data from another DLV domain.", as
described in Section 5 of [RFC5074]. So Users wanting to make use of
DNSSEC would need to know all of these DLV domains beforehand, and
then need to maintain a series of trust anchors in their name server
configurations, corresponding to the different DLV domains that
publish the cryptographic keys they use to sign their zones.
Discovering all of this DLV domains, and maintaining all related
information up to date can turn into a tough task along with the
increase of the number of the DLV domains in the future.
This document describes a methodology for constructing DNSSEC
Lookaside Validation Trust Alliance (DLVTA) of multiple DNSSEC
Lookaside Validation (DLV) domains without disrupting the deployment
of standard DNSSEC. The DLVTA allows validating resolvers to
validate DNSSEC-signed data from multiple DLV domains without
maintaining a series of trust anchors for those different DLV domains
in their name server configurations.
2. Terminology
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 [RFC2119].
Kong, et al. Expires August 31, 2010 [Page 4]
Internet-Draft DLVTA February 2010
3. Architecture
DLVTA allows a set of DLVTA domains to publish trust anchors of DLV
domains that are not their own children. Through a DLVTA domain, a
validator may expect the named DLV domains to be trusted.
The structure of DLVTA is shown in Figure 1.
+--------------+
| DLVTA domain |
+--------------+
^ ^ ^
/ | \
/ | \
/ | \
v v v
+------------+ +------------+ +------------+
|DLV domain 1| |DLV domain 2| |DLV domain n|
+------------+ +------------+ ...... +------------+
| zone 1 | | zone 2 | | zone n |
+------------+ +------------+ +------------+
^ ^ ^ ^
\ . . /
\ . . /
\ . . /
v v v v
+-----------------+ +-----------------+
| validator 1 | | validator n |
+-----------------+ +-----------------+
Figure 1
In the above figure, there are n zones (from zone 1 to zone n), and
each one chooses its own DLV domains (from DLV domain 1 to DLV domain
n). For example, the DLV domain 1 is used by the zone 1, and the DLV
domain n is used by the zone n. All of these DLV domains is
contained within a DLVTA Domain.
Without DLVTA, any validator which only sets one of these DLV domains
(such as the DLV domain 1) as its sole trust anchor can only validate
the DNSSEC-signed data from one zone (zone 1). But through DLVTA,
any validator which sets a DLVTA domain as its trust anchor can
discovery DLV domains within the DLVTA domain, and then obtain any
DNSSEC validation information of zones by these DLV domains. For
example, the validator 1 uses DLV domain 1 as its trust anchor, and
the validator 2 uses DLV domain n as its trust anchor. If both of
them set the DLVTA domain in figure 1 as their trust anchor, they can
obtain the DNSSEC validation information of the zone 2 through DLVTA.
Kong, et al. Expires August 31, 2010 [Page 5]
Internet-Draft DLVTA February 2010
4. The DLVTA DNS Resource Record
The DLVTA DNS resource record can be divided into two kinds, DLVTA
Target Information (DLVTATI) resource record and DLVTA Key
Information (DLVTAKI) resource record. The first one is used to
store the target information of DLV domains within a DLVTA domain,
and the second one is used to store the public key information of DLV
domains within a DLVTA domain.
4.1. DLVTATI Resource Record
The DLVTATI resource record has exactly the same wire and
presentation formats as the NAPTR resource record, defined in
[RFC2915].
The format of the DLVTATI resource record is given below.
Name TTL Class Type Order Preference Flags Service Regexp Replacement
o Name: The domain name to which this resource record refers. The
Name field MUST be the named of the targeted zone by a DLV domain
plus the name of the DLVTA domain.
o TTL: Standard DNS meaning [RFC1035].
o Class: Standard DNS meaning [RFC1035].
o Type: The Type Code [RFC1035] for DLVTATI is XX.
o Order: The Order field is not be used. It SHALL be set to zero.
o Preference: A 16-bit unsigned integer defined by [RFC2915]. Low
numbers SHOULD be processed before high numbers.
o Flags: The Flags field MUST be set to 'u', indicating that the
Regexp field contains a URI.
o Service: The Service field is not be used. It SHALL be set to the
empty string.
o Regexp: The Regexp field specifies a DLV domain within the DLVTA
domain. The value of this field SHOULD be the string !^.*$! (the
six character sequence consisting of an exclamation point, a
caret, a period, an asterisk, a dollar sign, and another
exclamation point), followed by a URI, followed by an exclamation
point (!) character.
Kong, et al. Expires August 31, 2010 [Page 6]
Internet-Draft DLVTA February 2010
o Replacement: The Replacement field is not be used. It SHOULD be
set to a single period ('.').
For example, the DLV domain dlv1.example.zone1, the DLV domain
dlv2.example.zone1, and the DLV domain dlv.example.zone2 belong to a
DLVTA domain dlvta.example.zone3. The DLVTA domain
dlvta.example.zone3 SHOULD have DLVTATI resource records to store the
target information of the DLV domain dlv1.example.zone1, the DLV
domain dlv2.example.zone1, and the DLV domain dlv.example.zone2.
Name TTL Class Type Order Preference Flags Service Regexp Replacement
zone1.dlvta.example.zone3. 86400 IN DLVTATI 0 10 "u" " "
"!^.*$!dlv1.example.zone1!" .
zone1.dlvta.example.zone3. 86400 IN DLVTATI 0 100 "u" " "
"!^.*$!dlv2.example.zone1!" .
zone2.dlvta.example.zone3. 86400 IN DLVTATI 0 10 "u" " "
"!^.*$!dlv.example.zone2!" .
In the example above, both the DLV domain dlv1.example.zone1 and DLV
domain dlv2.example.zone1 target the zone1, but the DLV domain
dlv1.example.zone1 should be used before the DLV domain
dlv2.example.zone1 by validators because of the value of the
Preference field.
4.2. DLVTAKI Resource Record
The DLVTAKI resource record has exactly the same wire and
presentation formats as the DLV resource record, defined in
[RFC4431]. It uses the same IANA-assigned values in the algorithm
and digest type fields as the DS record.
Any DLVTA domain SHOULD store the public key information of DLV
domains within the DLVTATI resource record by the DLVTAKI resource
record.
The Name field MUST be the named of the DLV domain plus the name of
the DLVTA domain.
For example, the DLV domain dlv.example.zone1 and the DLV domain
dlv.example.zone2 belong to a DLVTA domain dlvta.example.zone3. The
DLVTA domain dlvta.example.zone3 SHOULD has a DLVTAKI resource record
to store the public key information of the DLV domain
dlv.example.zone1 and the DLV domain dlv.example.zone2.
Name TTL Class TypeKey Tag Algorithm DigestType Digest
dlv.example.zone1.dlvta.example.zone3. 86400 IN DLVTAKI 29092 5 1 (
Kong, et al. Expires August 31, 2010 [Page 7]
Internet-Draft DLVTA February 2010
224 3B4148AAF0494943209B666DD5C5FC6B200CD )
dlv.example.zone2.dlvta.example.zone3. 86400 IN DLVTAKI 25081 5 1 (
D6C 409078DAAF3C4C5354161E71CA276819DC504 )
5. The Validator Behavior using DLVTA
A validator using DLVTA SHOULD first attempt validation using any
applicable (non-DLV) trust anchors, and then DLV processing occurs
only if the validation fails, as described in [RFC5074]. The DLVTA
processing occurs only after the DLV validation fails, that is to
say, if the DLV validation succeeds (with a result of Secure), DLVTA
processing need not occur.
When DLVTA processing occurs, a validator looks for a closest
enclosing DLVTATI RRset in the DLVTA domain, which is the DLVTATI
RRset with the longest name that matches the query or could be an
ancestor of the QNAME. To find the closest enclosing DLVTATI RRset
for a given query, the validator starts by looking for a DLVTATI
RRset corresponding to the QNAME. For example, assuming there exist
DLVTATI RRsets named zone1.dlvta.example.zone,
sub.zone1.dlvta.example.zone, example.sub.zone1.dlvta.example.zone
within a DLVTA domain dlvta.example.zone. A validator would use the
example.sub.zone1.dlvta.example.zone DLVTATI RRset for validating
responses to a query for example.sub.zone1.
When a validator finds a closest enclosing DLVTATI RRset in the DLVTA
domain, it would regard the URI inside the Regexp field of the
DLVTATI RRset as a DLV domain which targets the zone named by the
Name field (MUST remove the part of the DLVTA domain) of the DLVTATI
RRset. And then it SHOULD use the DLVTAKI which has the same Name
field with the name of the DLV domain plus the name of the DLVTA
domain, as though it were a DS RRset to validate the answer of the
DLV domain using the normal procedures in Section 5 of [RFC4035]. If
the validation succeeds, the validator SHOULD attempt validation
using the DLV domain as described in . [RFC5074].
It's possible that a DLV domain obtained from a DLVTA domain by a
validator is a default trust anchor in its name server
configurations. To avoid the repeat query for the DLV domain, the
validator SHALL ignore it in the process of the DLVTA validation.
The flow of the validator behavior using DLVTA is shown in Figure 2.
Kong, et al. Expires August 31, 2010 [Page 8]
Internet-Draft DLVTA February 2010
+-------------+
| Validator |
+-------------+
|
| +----+
v v | if validation fails
+-------------+ |
| non-DLV |__|
| validation |
+-------------+
if all non-DLV |
validations fail | +----+
or don't exist v v | if validation fails
+-------------+ |
| DLV |__|
| validation |
+-------------+
if all DLV | if all validations fail
validations fail | +-----------------------------------+
or don't exist v v |
+-------------+ +--------------+ |
| DLVTA |-------------->| DLV of DLVTA |--+
| validation | if matched | validation |--+
+-------------+ DLV within +--------------+ |
if all DLVTA | DLVTA exists ^ |
validations fail | +--------+
or don't exist v if validation fails
+-------------+
| END |
+-------------+
Figure 2
6. Examples
NOTE: These are examples only. They are taken from ongoing work and
may not represent the end result of that work. They are here for
pedagogical reasons only.
Assuming zone1, zone2 and zone3 aren't signed by its parent. The DLV
domain dlv.example.zone1 targets the zone1 zone, the DLV domain
dlv.example.zone2 targets the zone2 zone, and the DLV domain
dlv.example.zone3 targets the zone3 zone. The DLVTA domain
dlvta.example.zone1 contains the dlv.example.zone1 and the DLV domain
dlv.example.zone2. The DLVTA domain dlvta.example.zone2 contains the
dlv.example.zone1, DLV domain dlv.example.zone2 and the DLV domain
dlv.example.zone3.
Kong, et al. Expires August 31, 2010 [Page 9]
Internet-Draft DLVTA February 2010
6.1. Example 1
Assuming the validator 1 uses the DLV domain dlv.example.zone1 as a
default trust anchor of DLV, and uses the DLVTA domain
dlvta.example.zone1 as a default trust anchor of DLVTA in its name
server configurations.
o dnssec-lookaside "zone1" trust-anchor "dlv.example.zone1";
o dnssec-lookaside-trust-alliance trust-anchor
"dlvta.example.zone1";
The validator 1 can validate DNSSEC-signed data from zone 1 by its
default DLV (dlv.example.zone1), and it can get the appropriate DLV
(dlv.example.zone2) for zone2 from its default DLVTA
(dlvta.example.zone1). Then the validator 1 can validate DNSSEC-
signed data from zone 2 by DLV (dlv.example.zone2).
6.2. Example 2
Assuming the validator 2 uses the DLV domain dlv.example.zone2 as a
default trust anchor of DLV, and uses the DLVTA domain
dlvta.example.zone2 as a default trust anchor of DLVTA in its name
server configurations.
o dnssec-lookaside "zone2" trust-anchor "dlv.example.zone2";
o dnssec-lookaside-trust-alliance trust-anchor
"dlvta.example.zone2";
The validator 2 can validate DNSSEC-signed data from zone 2 by its
default DLV (dlv.example.zone2). It can get the appropriate DLV
(dlv.example.zone1) for zone1, and DLV (dlv.example.zone3) for zone3
from its default DLVTA (dlvta.example.zone2). Then the validator 2
can validate DNSSEC-signed data from zone 1 by DLV
(dlv.example.zone1), and validate DNSSEC-signed data from zone 3 by
DLV (dlv.example.zone3).
7. IANA Considerations
IANA is requested to assignment the DNS type code XX to the DLVTATI
resource record, and the DNS type code XX to the DLVTAKI resource
record from the Specification Required portion of the DNS Resource
Record Type registry, as defined in [RFC2929].
The DLVTAKI resource record reuses the same algorithm and digest type
registries already used for the DS resource record, currently known
Kong, et al. Expires August 31, 2010 [Page 10]
Internet-Draft DLVTA February 2010
as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
Numbers" registries.
8. Security considerations
For authoritative servers and resolvers that do not attempt to use
DLVTA RRs as part of DNSSEC validation, there are no particular
security concerns.
Validators using DLVTA MUST NOT use a DLVTA record unless it has been
successfully authenticated. Normally, validators will have a trust
anchor for the DLVTA domain and use DNSSEC to validate the data in
it.
For further discussion of the security implications of DNSSEC and
DLV, see [RFC4033], [RFC4034], [RFC4035], [RFC4431], [RFC5074].
9. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000.
[RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning,
"Domain Name System (DNS) IANA Considerations", RFC 2929,
September 2000.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4431] Andrews, M. and S. Weiler, "The DNSSEC Lookaside
Validation (DLV) DNS Resource Record", RFC 4431,
Kong, et al. Expires August 31, 2010 [Page 11]
Internet-Draft DLVTA February 2010
February 2006.
[RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
November 2007.
Authors' Addresses
Ning Kong
CNNIC
4 South 4th Street,Zhongguancun,Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3147
Email: nkong@cnnic.cn
Yuedong Zhang
CNNIC
4 South 4th Street,Zhongguancun,Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 2635
Email: zhangyuedong@cnnic.cn
Xiaodong Lee
CNNIC
4 South 4th Street,Zhongguancun,Haidian District
Beijing, Beijing 100190
China
Phone: +86 10 5881 3020
Email: lee@cnnic.cn
Kong, et al. Expires August 31, 2010 [Page 12]