mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-31 06:25:31 +00:00
Code Issues Releases Wiki Activity

updated drafts

Browse Source
This commit is contained in:
Andreas Gustafsson
2002-03-06 19:08:34 +00:00
parent a615e9a446
commit b8b9e2bf5d
10 changed files with 983 additions and 3072 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2092
doc/draft/draft-hibbs-dns-server-mib-00.txt
View File

File diff suppressed because it is too large Load Diff

19
doc/draft/draft-hibbs-dns-server-mib-01.txt Normal file
View File

@@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
R. Hibbs: rbhibbs@pacbell.com

35
doc/draft/draft-ietf-dnsext-axfr-clarify-03.txt → doc/draft/draft-ietf-dnsext-axfr-clarify-04.txt
View File

@@ -1,6 +1,7 @@
INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsext-axfr-clarify-03.txt Nominum Inc.
July 2001
draft-ietf-dnsext-axfr-clarify-04.txt Nominum Inc.
March 2002
DNS Zone Transfer Protocol Clarifications
@@ -49,9 +50,9 @@ Abstract
Expires January 2002 [Page 1]
Expires September 2002 [Page 1]
draft-ietf-dnsext-axfr-clarify-03.txt July 2001
draft-ietf-dnsext-axfr-clarify-04.txt March 2002
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -105,9 +106,9 @@ draft-ietf-dnsext-axfr-clarify-03.txt July 2001
Expires January 2002 [Page 2]
Expires September 2002 [Page 2]
draft-ietf-dnsext-axfr-clarify-03.txt July 2001
draft-ietf-dnsext-axfr-clarify-04.txt March 2002
DNS message size. In the case of a small zone, this can cause the
@@ -161,9 +162,9 @@ draft-ietf-dnsext-axfr-clarify-03.txt July 2001
Expires January 2002 [Page 3]
Expires September 2002 [Page 3]
draft-ietf-dnsext-axfr-clarify-03.txt July 2001
draft-ietf-dnsext-axfr-clarify-04.txt March 2002
any combination of messages with and without a question section.
@@ -217,9 +218,9 @@ draft-ietf-dnsext-axfr-clarify-03.txt July 2001
Expires January 2002 [Page 4]
Expires September 2002 [Page 4]
draft-ietf-dnsext-axfr-clarify-03.txt July 2001
draft-ietf-dnsext-axfr-clarify-04.txt March 2002
send, and slave implementations expect to receive, the zone's SOA RR
@@ -273,9 +274,9 @@ References
Expires January 2002 [Page 5]
Expires September 2002 [Page 5]
draft-ietf-dnsext-axfr-clarify-03.txt July 2001
draft-ietf-dnsext-axfr-clarify-04.txt March 2002
[RFC1035] - Domain Names - Implementation and Specifications, P.
@@ -291,7 +292,7 @@ Author's Address
Andreas Gustafsson
Nominum Inc.
950 Charter Street
2385 Bay Rd
Redwood City, CA 94063
USA
@@ -302,7 +303,7 @@ Author's Address
Full Copyright Statement
Copyright (C) The Internet Society (2000, 2001). All Rights Reserved.
Copyright (C) The Internet Society (2000 - 2002). 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
@@ -329,9 +330,9 @@ Full Copyright Statement
Expires January 2002 [Page 6]
Expires September 2002 [Page 6]
draft-ietf-dnsext-axfr-clarify-03.txt July 2001
draft-ietf-dnsext-axfr-clarify-04.txt March 2002
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
@@ -385,5 +386,5 @@ draft-ietf-dnsext-axfr-clarify-03.txt July 2001
Expires January 2002 [Page 7]
Expires September 2002 [Page 7]

56
doc/draft/draft-ietf-dnsext-obsolete-iquery-02.txt → doc/draft/draft-ietf-dnsext-obsolete-iquery-03.txt
View File

@@ -1,11 +1,15 @@
DNSEXT Working Group David C Lawrence
INTERNET-DRAFT Nominum
<draft-ietf-dnsext-obsolete-iquery-02.txt> December 2001
<draft-ietf-dnsext-obsolete-iquery-03.txt> January 2002
Updates: RFC 1035
Obsoleting IQUERY
Status of this Memo
This document is an Internet-Draft and is in full conformance with
@@ -30,25 +34,27 @@ Status of this Memo
Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org.
This draft expires on 14 June 2002.
This draft expires on 14 July 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All rights reserved.
Copyright (C) The Internet Society (2002). All rights reserved.
Abstract
Based on a lack of working implementations of the IQUERY method
of performing inverse DNS lookups, and because an alternative
mechanism for doing inverse queries of address records has been
successfully used operationally for well over a decade, this
draft proposes that the IQUERY operation be entirely obsoleted.
The IQUERY method of performing inverse DNS lookups, specified in
RFC 1035, has not been generally implemented and has usually been
operationally disabled where it has been implemented. Both reflect
a general view in the community that the concept was unwise and
that the widely-used alternate approach of using PTR queries and
reverse-mapping records is preferable. Consequently, this document
deprecates the IQUERY operation and updates RFC 1035 to declare it
entirely obsolete.
Expires Jun 2002 [Page 1]
Expires Jul 2002 [Page 1]
INTERNET-DRAFT Obsoleting IQUERY June 2001
INTERNET-DRAFT Obsoleting IQUERY January 2002
1 - Introduction
@@ -98,13 +104,13 @@ INTERNET-DRAFT Obsoleting IQUERY June 2001
1.1 - Requirements
The key words "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this
document are to be interpreted as described in RFC2119.
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 RFC 2119.
Expires Jun 2002 [Page 2]
Expires Jul 2002 [Page 2]
INTERNET-DRAFT Obsoleting IQUERY June 2001
INTERNET-DRAFT Obsoleting IQUERY January 2002
1.2 - Updated documents and sections
@@ -153,20 +159,23 @@ INTERNET-DRAFT Obsoleting IQUERY June 2001
6 - Acknowledgments:
Olafur Gudmundsson was the instigator for this action.
Matt Crawford contributed some improved wording.
Matt Crawford, John Klensin and Erik Nordmark contributed some
improved wording.
Expires Jun 2002 [Page 3]
Expires Jul 2002 [Page 3]
INTERNET-DRAFT Obsoleting IQUERY June 2001
INTERNET-DRAFT Obsoleting IQUERY January 2002
References:
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification'', STD 13, RFC 1035, November 1987.
[RFC2119] S. Bradner, ``Key Words for Use in RFCs to Indicate
Requirement Levels'', BCP 14, RFC 2119, March 1997.
7 - Author's Address
David Lawrence
@@ -180,7 +189,7 @@ References:
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright (C) The Internet Society (2002). 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
@@ -211,7 +220,4 @@ Full Copyright Statement
Expires Jun 2002 [Page 4]
Expires Jul 2002 [Page 4]

144
doc/draft/draft-ietf-dnsop-inaddr-required-02.txt → doc/draft/draft-ietf-dnsop-inaddr-required-03.txt
View File

@@ -6,24 +6,21 @@
INTERNET-DRAFT D. Senie
Category: BCP Amaranth Networks Inc.
Expires in six months July 2001
Expires in six months March 2002
Requiring DNS IN-ADDR Mapping
draft-ietf-dnsop-inaddr-required-02.txt.
draft-ietf-dnsop-inaddr-required-03.txt
Status of this Memo
This draft, file name draft-ietf-dnsop-inaddr-required-00.txt, is
intended to be become a Best Current Practice RFC. Distribution of
this document is unlimited. Comments should be sent to the Domain
Name Server Operations working group mailing list <dnsop@cafax.se> or
to the author.
This draft, is intended to be become a Best Current Practice RFC.
Distribution of this document is unlimited. Comments should be sent
to the Domain Name Server Operations working group mailing list
<dnsop@cafax.se> or to the author.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
@@ -34,16 +31,20 @@ Status of this Memo
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2000,2001). All Rights Reserved.
Copyright (C) The Internet Society (2000-2002). All Rights Reserved.
Abstract
Mapping of addresses to names has been a feature of DNS. Many sites,
implement it, many others don't. Some applications attempt to use it
as a part of a security strategy. The goal of this document is to
encourage proper deployment of address to name mappings, and provide
guidance for their use.
1. Introduction
@@ -52,13 +53,6 @@ Copyright Notice
address, and address to name mappings are provided for networks. This
practice, while documented, has never been documented as a
requirement placed upon those who control address blocks. This
document fills this gap.
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 RFC 2119.
2. Discussion
@@ -68,9 +62,17 @@ Senie [Page 1]
Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
Internet-Draft Requiring DNS IN-ADDR Mapping March 2002
document fills this gap.
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 RFC 2119 [RFC2119].
2. Discussion
From the early days of the Domain Name Service [RFC 883] a special
domain has been set aside for resolving mappings of IP addresses to
domain names. This was refined in [RFC1035], describing the .IN-
@@ -81,8 +83,9 @@ Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
[RFC2050], which requires regional registries to maintain IN-ADDR
records on the large blocks of space issued to ISPs and others.
ARIN's policy only requires ISPs to maintain IN-ADDR if they have a
/16 or larger allocation [ARIN]. APNIC indicates in their policy
ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger
allocations. For smaller allocations, ARIN can provide IN-ADDR for
/24 and shorter prefixes. [ARIN]. APNIC indicates in their policy
document [APNIC] that those to whom they allocate blocks, and those
further downstream SHOULD maintain IN-ADDR records. RIPE appears to
have the strongest policy in this area [ripe-185] indicating Local
@@ -111,15 +114,6 @@ Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
it maps back to the address originally known. Failure to resolve
matching names is seen as a potential security concern.
Some popular FTP sites will flat-out reject users, even for anonymous
FTP, if the IN-ADDR lookup fails or if the result of the IN-ADDR
lookup when itself resolved, does not match. Some Telnet servers also
implement this check.
Web sites are in some cases using IN-ADDR checks to verify whether
the client is located within a certain geopolitical entity. This is
being employed for downloads of crypto software, for example, where
Senie [Page 2]
@@ -128,9 +122,17 @@ Senie [Page 2]
Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
Internet-Draft Requiring DNS IN-ADDR Mapping March 2002
Some popular FTP sites will flat-out reject users, even for anonymous
FTP, if the IN-ADDR lookup fails or if the result of the IN-ADDR
lookup when itself resolved, does not match. Some Telnet servers also
implement this check.
Web sites are in some cases using IN-ADDR checks to verify whether
the client is located within a certain geopolitical entity. This is
being employed for downloads of crypto software, for example, where
export of that software is prohibited to some locales. Credit card
anti-fraud systems also use these methods for geographic placement
purposes.
@@ -154,7 +156,7 @@ Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
Traceroutes with descriptive IN-ADDR naming proves useful when
debugging problems spanning large areas. When this information is
missing, the traceroutes take longer, and it takes additional steps
to determine who's network is the cause of problems.
to determine which network is the cause of problems.
4. Requirements
@@ -171,14 +173,6 @@ Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
Internet providers and other users to whom a block of addresses are
delegated SHOULD provide for lookup of host names from IP addresses.
This may be provided directly or by delegation to the user of the
address block. The ISP is responsible for one or the other. In the
event of delegation, the user is responsible for resolution.
Only IP addresses not presently in use within a block, or which are
not valid for use (zeros or ones broadcast addresses) are permitted
to have no mapping. It should be noted that due to CIDR, many
addresses which appear to be otherwise valid host addresses may
actually be zeroes or ones broadcast addresses. As such, attempting
@@ -188,9 +182,17 @@ Senie [Page 3]
Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
Internet-Draft Requiring DNS IN-ADDR Mapping March 2002
address block. The ISP is responsible for one or the other. In the
event of delegation, the user is responsible for resolution.
Only IP addresses not presently in use within a block, or which are
not valid for use (zeros or ones broadcast addresses) are permitted
to have no mapping. It should be noted that due to CIDR, many
addresses which appear to be otherwise valid host addresses may
actually be zeroes or ones broadcast addresses. As such, attempting
to audit a site's degree of compliance can only be done with a
knowledge of the internal routing structure of the site. However, any
host which originates an IP packet necessarily will have a valid host
@@ -213,7 +215,7 @@ Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
This document has no negative impact on security. While it could be
argued that lack of PTR record capabilities provides a degree of
anonimity, this is really not valid. Trace routes, whois lookups and
anonymity, this is really not valid. Trace routes, whois lookups and
other sources will still provide methods for discovering identity.
By recommending applications avoid using IN-ADDR as a security
@@ -231,14 +233,6 @@ Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
[RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
an Address Assignment and Aggregation Strategy," RFC 1519, September
1993.
[RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
RFC 2317, March 1998.
[RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
Guidelines", RFC2050, BCP 12, Novebmer 1996.
@@ -248,14 +242,28 @@ Senie [Page 4]
Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
Internet-Draft Requiring DNS IN-ADDR Mapping March 2002
1993.
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
RFC 2026, BCP 9, October 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
Guidelines", RFC2050, BCP 12, Novebmer 1996.
[RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
RFC 2317, March 1998.
[ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
unknown, http://www.arin.net/regserv/initial-isp.html
[APNIC] "Policies for address space management in the Asia Pacific
Region," Approved October 1999, effective January 2000,
[APNIC] "Policies For IPv4 Address Space Management in the Asia
Pacific Region," APNIC-086, Approval pending, 17 December 2001,
http://www.apnic.net/drafts/add-manage-policy.html
[RIPE185] "European Internet Registry Policies and Procedures,"
@@ -283,20 +291,6 @@ Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
@@ -305,3 +299,7 @@ Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
Senie [Page 5]
-----------------------------------------------------------------
Daniel Senie dts@senie.com
Amaranth Networks Inc. http://www.amaranth.com

337
doc/draft/draft-ietf-dnsop-v6-name-space-fragmentation-00.txt
View File

@@ -1,337 +0,0 @@
Internet Draft Johan Ihren
draft-ietf-dnsop-v6-name-space-fragmentation-00.txt Autonomica
January 2002
Expires in six months
IPv4-to-IPv6 migration and DNS name space fragmentation
Status of this Memo
This memo provides information to the Internet community. It does
no specify an Internet standard of any kind. This memo is in full
conformance with all provisions of Section 10 of RFC2026.
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.
Abstract
This memo documents some problems forseen in transitioning from a
IPv4-only DNS hierarchy via a long period of mixture to an
IPv6-mostly situation sometime in the future. The mixture period is
expected to be very long, and hence design choices should very much
take this into account, rather than just regard the transition as a
relatively short period of pain.
The main problem with transition that this paper focus on is what
to do about the name space fragmentation that may result from
certain DNS data only being available over one type of transport
(i.e. v4 or v6) which is thereby likely unavailable to hosts that
can cannot utilize that transport.
Two orthogonal issues are identified and discussed: deployment and
use. The former while technically simple holds certain dangers that
should be avoided. The "use" (as in performing DNS lookups) is much
more complicated, and a roadmap for this is presented.
1. Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD",
"RECOMMENDED", and "MAY" in this document are to be interpreted as
described in RFC 2119 [RFC2119].
The phrase "v4 name server" indicates a name server available over
IPv4 transport. It does not imply anything about what DNS data is
served. Likewise, "v6 name server" indicates a name server
available over IPv6 transport.
2. Introduction to the problem of name space fragmentation
With all DNS data only available over IPv4 transport everything is
simple. IPv4 resolvers can use the intended mechanism of following
referrals from the root and down while IPv6 resolvers have to work
through a "translator", i.e. they have to use a second name server
on a so-called "dual stack" host as a "forwarder" since they cannot
access the DNS data directly. This is not a scalable solution.
With all DNS data only available over IPv6 transport everything
would be equally simple, with the exception of old legacy IPv4 name
servers having to switch to a forwarding configuration.
However, the second situation will not arise in a foreseeable
time. Instead, it is expected that the transition will be from IPv4
only to a mixture of IPv4 and IPv6, with DNS data of theoretically
three categories depending on whether it is available only over
IPv4 transport, only over IPv6 or both.
The latter is the best situation, and a major question is how to
ensure that it as quickly as possible becomes the norm. However,
while it is obvious that some DNS data will only be available over
v4 transport for a long time it is also obvious that it is
important to avoid fragmenting the name space available to IPv4
only hosts. I.e. during transition it is not acceptable to break
the name space that we presently have available for IPv4-only
hosts.
3. Consequences of deploying a "IPv6 root name server"
If and when a root name server that is accessible over IPv6
transport is deployed it will immediately become possible to change
IPv6-only name servers to a "native configuration", i.e. to a
configuration where they follow referrals directly from the root
(which is now accessible to them because of the v6 transport).
However, initially they will typically quite soon get a so-called
"referral" to a name server only available over IPv4 transport, and
this will be impossible to follow, since there is no common
transport available. Therefore the name it is trying to lookup will
not get looked up and the result is that a v6-only name server
cannot lookup the same names that its v4-only counterpart can.
There are two available methods of addressing this problem:
a) ignore it, i.e. don't solve the problem, but put the effort into
helping deployment along so that the problem will shrink over
time.
b) provide some sort of "transport bridging", i.e. create a
fallback mechanism that enables a name server with only one type
of transport to reach a name server only available over the
other transport via some sort of proxy service. See for instance
[DNS-opreq] and [DNS-proxy] for discussions.
Regardless of how this problem is handled it is important to
realize that it only concerns the fragmented name space in
IPv6. I.e. the IPv4 name space is not (yet) fragmented, and a more
important question is possibly how to keep it unfragmented.
4. Policy based avoidance of name space fragmentation.
Today there are only a few DNS "zones" on the public Internet that
are only available over v6 transport, and they can mostly be
regarded as "experimental". However, as soon as there is a root
name server available over v6 transport it is reasonable to expect
that it will become more common with v6-only zones over time.
This would not be a good development, since this will fragment the
previously unfragmented IPv4 name space and there are strong
reasons to find a mechanism to avoid it.
4.1. Requirement of IPv4 address for at least one name server.
To ensure that all zones remain available over IPv4 transport one
method would be to require that nameservers authoritative for a
zone as part of the zone validation process ensure that there are
IPv4 address records available for the name servers of any child
delegations within the zone).
I.e. the future policy would be:
"Every delegation point should have at least one name server
for the child zone reachable over IPv4 transport".
To ensure this the authoritative server will have to lookup the
address records of the name servers that are part of any
"delegation" points in the zone.
I.e. for given the domain EXAMPLE.COM with the following data
$ORIGIN example.com.
child.example.com. IN NS ns.example.com.
child.example.com. IN NS dns.autonomica.se.
ns.example.com. IN A 1.2.3.4
the delegation of CHILD.EXAMPLE.COM is to the two name servers
"ns.example.com" and "dns.autonomica.se". The first name server,
"ns.example.com", obviously has an IPv4 address (as shown by the
"glue" record on the last line).
However, "ns.example.com" may have additional addresses assiciated
with it. Also there is no way for the server loading the zone to
know the address(es) of "dns.autonomica.se". Therefore, to find out
all the publicly available addresses they have to be queried for.
4.2. Zone validation for non-recursive servers.
Non-recursive authoritative servers are name servers that run
without ever asking questions. A change in the zone validation
requirements that force them to query for the addresses of name
servers that are part of delegations in the zone change this, since
they now have to query for these addresses.
However, the main reason that it is important to be able to run
without asking questions is to avoid "caching" possibly bogus
answers. This need can be managed by requiring that a non recursive
name server throw away the looked up address information after
having used it for validation of the delegations in the zone.
4.3. Future requirement of IPv6 address for at least one name server.
The immediate need for clarified policies for delegation is to
ensure that IPv4 name space does not start to fragment. Over time,
however, it is reasonable to expect that it may become important to
add a similar requirement to IPv6 name space.
I.e. an even more refined policy possible at some point in the
future would be:
"Every delegation point should have at least one name server
for the child zone reachable over IPv4 transport (i.e. should
have an A record) and at least one name server reachable over
IPv6 transport (i.e. should have an AAAA record)".
4.4. Implementation issues for new zone validation requirements.
Exactly what action should be taken when a zone does not validate
is not immediately clear. Immediate alternatives include:
a) fail the entire zone
b) load the zone but remove the delegation that failed validation
c) load the entire zone but issue a warning message about the
delegation that failed validation.
A likely implementation will make it configurable what action to
take.
5. Overview of suggested transition method.
By following the steps outlined below it will be possible to
transition without outages or lack of service. The assumption is
that the site has only v4 name servers or possibly v4 name servers
plus v6 name server in a forwarding configuration. All DNS data is
on the v4 name servers.
1) Do not change the method of resolution on any name server.
I.e. v4 servers go to the root and follow referrals while v6
servers go to their translator/forwarder which lookup the name
and return the end result.
2) Start mirroring DNS data into v6 by providing v6 name servers
serving the zones. Add v6 address information to to the zones
and as glue at the parent zone. Note that it is important that
the zone should have the same contents regardless of whether it
is the v4 version or the v6 version. Anything else will lead to
confusion.
4) Wait for the announcement of the DNS root zone being available
from a v6 name server.
5) Ensure that the entire path from the root down to the domain in
question is reachable over both IPv4 and IPv6 transport.
When this is accomplished it it possible to begin a migration of
the lookup of selected services to be available over IPv6
(i.e. typically by adding a AAAA record for a server of some sort).
6. How to deploy DNS hierarchy in v6 space.
The main problem with changing the DNS data so that it will become
available over both IPv6 and IPv4 transport is one of scale. There
are too many name servers and too many DNS zones for any kind of
forced migration to be aven remotely possible.
The way of achieving deployment is by providing domain owner with
a) a reason to deploy
b) a method to deploy
c) a way of verififying the correctness of the resulting configuration
6.1. A reason to deploy.
It is important to the migration process that zones migrate to
become available over v6 transport (as well as v4 transport). But
it is difficult to actually require such deployment too early in
the migration process.
Over time, however, it will become more reasonable to add such a
requirement. One likely method to do this will be by updating the
requirements for proper zone validation as was outlined above.
6.2. How to deploy DNS data.
Assuming the owner of the DNS domain has access to both IPv4 and
IPv6 address space that is globally routed. The steps to take are
then
a) identify all name servers that will serve the DNS domain, with
their IPv4 and/or IPv6 addresses
b) arrange for a suitable method of zone synchronization
c) announce the new set of servers to the parent zone, including
possible new IPv6 glue
It is recommended that the name servers run on single stack
machines, i.e. machines that are only able to utilize either IPv4
transport or IPv6 transport, but not both.
A common recommendation (mostly orthogonal to IPv6 transition
issues) is that authoritative name servers only serve data,
i.e. they do not act as caching resolvers. That way, since they
operate in non-recursive mode, they will not have any cache, and
hence will not be able to give out wrongful answers based upon
errors in the cache.
Since the announced name servers are single stack, the primary
master from which they fetch zone data will typically have to be
dual stack or otherwise some other method of data transfer has to
be arranged.
7. Security Considerations
Much of the security of the Internet relies, often wrongly, but
still, on the DNS. Thus, changes to the characteristics of the DNS
may impact the security of Internet based services.
Although it will be avoided, there may be unintended consequences
as a result of operational deployment of RR types and protocols
already approved by the IETF. When or if such consequences are
identified, appropriate feedback will be provided to the IETF and
the operational community on the efficacy of said interactions.
8. Summary.
The name space fragmentation problem is identified and examined at
some length.
A solution based upon a change in the validation method of
delegation points is suggested. This will both help keep the v4
name space unfragmented and may also help speed up deployment of
DNS hierarchy in v6 space.
9. References
[RFC1034] Domain names - concepts and facilities.
P.V. Mockapetris.
[RFC1035] Domain names - implementation and specification.
P.V. Mockapetris.
[RFC2826] IAB Technical Comment on th Unique DNS Root
[DNS-proxy] draft-durand-dns-proxy-00.txt
Alain Durand
[DNS-opreq] draft-ietf-ngtrans-dns-ops-req-02.txt
Alain Durand
A. Authors' Address
Johan Ihren
Autonomica
Bellmansgatan 30
SE-118 47 Stockholm, Sweden
johani@autonomica.se

348
doc/draft/draft-ietf-dnsop-v6-name-space-fragmentation-01.txt Normal file
View File

@@ -0,0 +1,348 @@
Internet Draft Johan Ihren
draft-ietf-dnsop-v6-name-space-fragmentation-01.txt Autonomica AB
March 2002
Expires in six months
IPv4-to-IPv6 migration and DNS namespace fragmentation
Status of this Memo
This memo provides information to the Internet community. It does
no specify an Internet standard of any kind. This memo is still not
in full conformance with all provisions of Section 10 of RFC2026.
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.
Abstract
This memo documents some problems forseen in transitioning from a
IPv4-only DNS hierarchy via a long period of mixture to an
IPv6-mostly situation sometime in the future. The mixture period is
expected to be very long, and hence design choices should very much
take this into account, rather than just regard the transition as a
relatively short period of pain.
The main problem with transition that this paper focus on is what
to do about the namespace fragmentation that may result from
certain DNS data only being available over one type of transport
(i.e. v4 or v6) which is thereby likely unavailable to hosts that
can cannot utilize that transport.
Two orthogonal issues are identified and discussed: deployment and
use. The former while technically simple holds certain dangers that
should be avoided. The "use" (as in performing DNS lookups) is much
more complicated, and a suggested roadmap for this is presented.
1. Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD",
"RECOMMENDED", and "MAY", when used un uppercase, in this document
are to be interpreted as described in RFC 2119 [RFC2119].
The phrase "v4 name server" indicates a name server available over
IPv4 transport. It does not imply anything about what DNS data is
served. Likewise, "v6 name server" indicates a name server
available over IPv6 transport. In general this document only
discuss transport issues and does not care exactly what is
transported.
2. Introduction to the problem of namespace fragmentation
With all DNS data only available over IPv4 transport everything is
simple. IPv4 resolvers can use the intended mechanism of following
referrals from the root and down while IPv6 resolvers have to work
through a "translator", i.e. they have to use a second name server
on a so-called "dual stack" host as a "forwarder" since they cannot
access the DNS data directly. This is not a scalable solution.
With all DNS data only available over IPv6 transport everything
would be equally simple, with the exception of old legacy IPv4 name
servers having to switch to a forwarding configuration.
However, the second situation will not arise in a foreseeable
time. Instead, it is expected that the transition will be from IPv4
only to a mixture of IPv4 and IPv6, with DNS data of theoretically
three types of availability, depending on whether it is available
only over IPv4 transport, only over IPv6 or both.
The latter is the best situation, and a major question is how to
ensure that it as quickly as possible becomes the norm. However,
while it is obvious that some DNS data will only be available over
v4 transport for a long time it is also obvious that it is
important to avoid fragmenting the namespace available to IPv4
only hosts. I.e. during transition it is not acceptable to break
the namespace that we presently have available for IPv4-only hosts.
2.1. Namespace fragmentation vs. unreachability.
Something that is presently not clear is whether it is actually
necessary to provide access to the "Internet namespace" as defined
by what is visble on the public v4 Internet also on v6 transport.
The reason for the unclarity is that if one regards "the Internet"
as the largest set of nodes that have a mutual 1-1 reachability for
any pair of nodes over IP and adjust the "Internet namespace" to
fit this set, then there is by definition no need to bridge or do
any special tricks (since they can all reach each other anyhow).
On the other hand, if we regard "the Internet" as the set of nodes
that share a namespace that we can refer to as "the Internet
namespace" regardless of whether they can all reach each other or
not, then we have to ensure that this namespace is accessible to
every node, regardless of its available transport.
It is out of scope for this document to make a choice between the
two alternatives, and therefore the rest of this document has to
work from the assumption that the same namespace should, if
possible, be made available to all nodes that claim to be part of
the Internet.
3. Consequences of deploying a "IPv6 root name server"
If and when a root name server that is accessible over IPv6
transport is deployed it will immediately for the first time become
possible to change IPv6-only name servers to a "native
configuration", i.e. to a configuration where they follow referrals
directly from the root (which is now accessible to them because of
the v6 transport).
However, initially they will typically quite soon get a referral to
a name server only available over IPv4 transport, and this will be
impossible to follow, since there is no common transport available.
Therefore the name it is trying to lookup will not get resolved and
the result is that the v6-only name server cannot lookup the same
set of domain names that its v4-only counterpart can.
This is fragmentation of the namespace.
Regardless of how this problem is handled it is important to
realize that at first it will only concern the namespace as viewed
from an IPv6-host. I.e. the IPv4 namespace will not (initially) be
fragmented, and an important question is possibly how to keep it
unfragmented.
4. A taxonomy of alternatives to avoid fragmentation.
4.1. Ignore the problem.
It is possible to ignore the fragmentation issue. Whether that is
an acceptable choice or not has to be very carefully considered. Is
it reasonable to allow v4 only hosts to over time lose access to
parts of the Internet namespace just because they are not
"IPv6-aware"?
4.2. DNS transport bridging.
By providing some sort of "DNS transport bridging", i.e. create a
fallback mechanism that enables a name server with only one type of
transport to reach a name server only available over the other
transport via some sort of proxy service it would be possible to
unify the DNS zones available on each transport into a common
namespace.
The general consensus is that it is not possible to design such a
bridging solution that works in both directions. However, it may be
possible to design one that allows v6 clients to query v4 servers.
See for instance [DNS-opreq] and [DNS-proxy] for more detailed
discussions.
4.3. Policy based avoidance of fragmentation.
Today there are only a limited number of DNS zones on the public
Internet that are only available over v6 transport, and they can
mostly be regarded as "experimental". However, as soon as there is
a root name server available over v6 transport it is reasonable to
expect that it will become more common with v6-only zones over
time.
Such a development would erode the Internet namespace as viewed
from an v4-only client. There are obviously strong reasons to find
a mechanism to avoid this happening.
4.3.1. Requirement of zone reachability over IPv4 transport.
To ensure that all zones remain available over IPv4 transport one
method would be to require that nameservers authoritative for a
zone as part of the zone validation process ensure that there are
IPv4 address records available for the name servers of any child
delegations within the zone).
I.e. the future policy could be:
"Every delegation point delegated to nameservers available
over v6 transport should have the same availability
requirements for servers over both v4 and v6 transport as v4
only zones have over v4 transport.
I.e. if the parent requires "multiple nameservers" for a child,
then the requirement becomes "multiple nameservers available over
v4 transport plus multiple nameservers available over v6 transport"
I.e. for given the domain EXAMPLE.COM with the following data
$ORIGIN example.com.
child.example.com. IN NS ns.example.com.
child.example.com. IN NS dns.autonomica.se.
ns.example.com. IN A 1.2.3.4
the delegation of CHILD.EXAMPLE.COM is to the two name servers
"ns.example.com" and "dns.autonomica.se". The first name server,
"ns.example.com", obviously has an IPv4 address (as shown by the
"glue" record on the last line).
However, "ns.example.com" may have additional addresses assiciated
with it. Also there is no way for the server loading the zone to
know the address(es) of "dns.autonomica.se". Therefore, to find out
all the publicly available addresses they have to be queried for.
To ensure this the authoritative server will have to lookup the
address records of the name servers that are part of any
"delegation" points in the zone. However, this operation is very
costly for large, delegation-dense zones and therefore it is likely
that compromises a la
* only validate on the master (this is likely always good practice)
* validate as an offline process (i.e. not part of the zone loading)
* only validate at time of delegation
* never validate
Clearly, as validation is relaxed the amount of errors will
increase, so the sum of pain as usual remains mostly constant.
4.3.2. Zone validation for non-recursive servers.
Non-recursive authoritative servers are name servers that run
without ever asking questions. A change in the zone validation
requirements that force them to query for the addresses of name
servers that are part of delegations in the zone change this, since
they now have to query for these addresses.
However, the main reason that it is important to be able to run
without asking questions is to avoid "caching" possibly bogus
answers. This need can be managed by requiring that a non recursive
name server throw away the looked up address information after
having used it for validation of the delegations in the zone.
4.3.3. Future requirement of zone reachability over IPv6 transport.
The immediate need for clarified policies for delegation is to
ensure that IPv4 namespace does not start to fragment. Over time,
however, it is reasonable to expect that it may become important to
add a similar requirement to IPv6 namespace.
I.e. an even more refined policy possible at some point in the
future would be:
"Every delegation point should have at least one name server
for the child zone reachable over IPv4 transport (i.e. should
have an A record) and at least one name server reachable over
IPv6 transport (i.e. should have e.g. an AAAA record)".
4.3.4. Implementation issues for new zone validation requirements.
Exactly what action should be taken when a zone does not validate
is not immediately clear. Immediate alternatives include:
a) fail the entire parent zone (the extreme case, not suggested)
b) load the zone but remove the delegation that failed validation
(also drastic, and not suggested)
c) load the entire zone but issue a warning message about the
delegation that failed validation (more reasonable)
Implementations should make it configurable what action to take. In
the case of registries that have a business realtion to the child
zone it is also in principle possible to work on the deployment of
child zones over v6 transport by cost diffentiation for the
customer.
5. Overview of suggested transition method.
By following the steps outlined below it will be possible to
transition without outages or lack of service. The assumption is
that the site has only v4 name servers or possibly v4 name servers
plus v6 name server in a forwarding configuration. All DNS data is
on the v4 name servers.
1) Do not change the method of resolution on any (recursive) name
server. I.e. v4 servers go to the root and follow referrals
while v6 servers go to their translator/forwarder which lookup
the name and return the end result.
2) Start serving authoritative DNS data on v6 transport by
providing name servers with v6 transport serving the zones. Add
v6 address information to to the zones and as glue at the parent
zone. Note that it is of crucial importance that the zone should
have the same contents regardless of whether it is the v4
version or the v6 version. Anything else will lead to confusion.
4) Wait for the announcement of the DNS root zone being available
from a v6 name server.
5) Ensure that the entire path from the root down to the domain in
question is reachable over both IPv4 and IPv6 transport.
When this is accomplished it it possible to begin a migration of
the lookup of selected services to be available over IPv6
(i.e. typically by adding a IPv6 address record, eg. AAAA record,
for a server of some sort).
6. Security Considerations
Much of the security of the Internet relies, often wrongly, but
still, on the DNS. Thus, changes to the characteristics of the DNS
may impact the security of Internet based services.
Although it will be avoided, there may be unintended consequences
as a result of operational deployment of RR types and protocols
already approved by the IETF. When or if such consequences are
identified, appropriate feedback will be provided to the IETF and
the operational community on the efficacy of said interactions.
7. Summary.
The namespace fragmentation problem is identified and examined at
some length.
A solution based upon a change in the validation method of
delegation points is suggested. This will both help keep the v4
namespace unfragmented and may also help speed up deployment of
DNS hierarchy in v6 space.
9. References
[RFC1034] Domain names - concepts and facilities.
P.V. Mockapetris.
[RFC1035] Domain names - implementation and specification.
P.V. Mockapetris.
[RFC2826] IAB Technical Comment on th Unique DNS Root
[DNS-proxy] draft-durand-dns-proxy-00.txt
Alain Durand
[DNS-opreq] draft-ietf-ngtrans-dns-ops-req-02.txt
Alain Durand
A. Authors' Address
Johan Ihren
Autonomica
Bellmansgatan 30
SE-118 47 Stockholm, Sweden
johani@autonomica.se

662
doc/draft/draft-ietf-enum-e164-gstn-np-02.txt → doc/draft/draft-ietf-enum-e164-gstn-np-03.txt
View File

File diff suppressed because it is too large Load Diff

294
doc/draft/draft-schlyter-appkey-01.txt → doc/draft/draft-schlyter-appkey-02.txt
View File

@@ -1,11 +1,11 @@
Network Working Group J. Schlyter
Internet-Draft Carlstedt Research &
Expires: May 11, 2002 Technology
November 10, 2001
Expires: August 7, 2002 Technology
February 6, 2002
Storing application public keys in the DNS
draft-schlyter-appkey-01.txt
draft-schlyter-appkey-02.txt
Status of this Memo
@@ -22,17 +22,17 @@ Status of this Memo
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 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 11, 2002.
This Internet-Draft will expire on August 7, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
@@ -50,28 +50,29 @@ Abstract
Schlyter Expires May 11, 2002 [Page 1]
Schlyter Expires August 7, 2002 [Page 1]
Internet-Draft Application public keys in DNS November 2001
Internet-Draft Application public keys in DNS February 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The APPKEY resource record . . . . . . . . . . . . . . . . . 3
2.1 The APPKEY RDATA format . . . . . . . . . . . . . . . . . . 4
2.1.1 The protocol field . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Version number octet . . . . . . . . . . . . . . . . . . . . 4
2.1.3 Algorithm number specification . . . . . . . . . . . . . . . 5
2.2 Text representation of APPKEY RRs . . . . . . . . . . . . . 5
2.3 Owner names for APPKEY RRs . . . . . . . . . . . . . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . 5
4. Security considerations . . . . . . . . . . . . . . . . . . 5
5. IANA considerations . . . . . . . . . . . . . . . . . . . . 5
References . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . 7
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Comments on the KEY RR . . . . . . . . . . . . . . . . . . . . 3
2.1 The flag field . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 The protocol field . . . . . . . . . . . . . . . . . . . . . . 3
3. The APPKEY resource record . . . . . . . . . . . . . . . . . . 3
3.1 The APPKEY RDATA format . . . . . . . . . . . . . . . . . . . 4
3.2 Algorithm number specification . . . . . . . . . . . . . . . . 4
3.3 Text representation of APPKEY RRs . . . . . . . . . . . . . . 4
3.4 Owner names for APPKEY RRs . . . . . . . . . . . . . . . . . . 4
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
5. Security considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5
References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7
@@ -105,28 +106,29 @@ Table of Contents
Schlyter Expires August 7, 2002 [Page 2]
Schlyter Expires May 11, 2002 [Page 2]
Internet-Draft Application public keys in DNS November 2001
Internet-Draft Application public keys in DNS February 2002
1. Introduction
The Domain Name System Security Extensions (DNSSEC) as described in
RFC 2535 [4] specifies the KEY resource record (RR). The KEY RR is
RFC 2535 [3] specifies the KEY resource record (RR). The KEY RR is
specified for use both for storing keys used by the DNSSEC
infrastructure itself and for storing keys used by non-DNSSEC
infrastructure applications (e.g. TLS [2], email and IPsec). The
issues with combining these two uses in one RR are further discussed
in draft-ietf-dnsext-restrict-key-for-dnssec-00 [11].
in a draft called "Limiting the Scope of the KEY Resource Record"
[10].
The protocol field in the KEY RR is only 8-bit and thus limited to
256 different protocols. As there is no way of separating different
version of a specific protocol, incompatible versions of a single
protocol requires multiple protocol values. A larger protocol field
together with the possibility to specify a version of the protocol
could solve this issue.
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 RFC 2119 [1].
2. Comments on the KEY RR
2.1 The flag field
The KEY RR includes a flag field that specifies key usage, what kind
of entity the key is associated with and various other flags. As
@@ -135,108 +137,73 @@ Internet-Draft Application public keys in DNS November 2001
application might need is hard to do, the usability of this field is
questionable.
2.2 The protocol field
The protocol field in the KEY RR is only 8-bit and thus limited to
256 different protocols. As there is no way of separating different
version of a specific protocol, incompatible versions of a single
protocol requires multiple protocol values. A larger protocol field
together with the possibility to specify a version of the protocol
could solve this issue.
A problem with multiple applications storing their public keys at a
single owner name and thus creating a very large RR set has been
identified. A possible solution for this could be to use a generic
protocol value [10] indicating that the actual protocol used is
protocol value [9] indicating that the actual protocol used is
indicated in the owner name using a SRV-like encoding. Although this
would indeed solve the problem with large RR sets when querying for
an application key, it could also make the protocol field lose its
value in practice as new applications would not require a new
protocol value. The author believes that combining unique protocol
values with SRV-like encode of protocol would be a better solution,
solving both the issue with large RR sets and a large number of
possible applications.
protocol value.
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 RFC 2119 [1].
2. The APPKEY resource record
3. The APPKEY resource record
The APPKEY resource record (RR) is used to store a application public
Schlyter Expires August 7, 2002 [Page 3]
Internet-Draft Application public keys in DNS February 2002
key that is associated with a Domain Name System (DNS) name.
The RR type code for the APPKEY RR is TBA.
Schlyter Expires May 11, 2002 [Page 3]
Internet-Draft Application public keys in DNS November 2001
An APPKEY RR is, like any other RR, authenticated by a SIG RR.
2.1 The APPKEY RDATA format
3.1 The APPKEY RDATA format
The RDATA for an APPKEY RR consists of a protocol field, a version
number octet, the algorithm number octet and the public key itself.
The format is as follows:
The RDATA for an APPKEY RR consists of an algorithm number octet and
the public key itself. The format is as follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol | version | algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
| algorithm | /
+---------------+ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
The meaning of the APPKEY RR owner name, protocol field, version
number octet and algorithm number octet are described in the sections
below. The format of the public key is algorithm dependent.
The meaning of the APPKEY RR owner name and algorithm number octet
are described in the sections below. The format of the public key is
algorithm dependent.
APPKEY RRs do not specify their validity period but their
authenticating SIG RR(s) do as described in RFC 2535 [4].
authenticating SIG RR(s) do as described in RFC 2535 [3].
2.1.1 The protocol field
The protocol field specifies what protocol the public key is to be
used for. The following values of the protocol field are available:
Value Protocol
----- --------
0x0000 reserved
0x0001 - 0xFEFF available for assignment by IANA
0xFF00 - 0xFFFE experimental uses
0xFFFF any protocol
0xFFFF indicates that the key can be used in connection with any
protocol. Use of this value is discouraged and the use of unique
protocol values for different protocols is encouraged.
2.1.2 Version number octet
The version number octet is defined by the protocol specified in the
protocol field. It is up to the application implementing the
specified protocol to interpret the value of this octet.
Any document specifying how a protocol uses APPKEY MUST specify how
Schlyter Expires May 11, 2002 [Page 4]
Internet-Draft Application public keys in DNS November 2001
to specify and interpret the version number octet.
2.1.3 Algorithm number specification
3.2 Algorithm number specification
The algorithm number used is the same as defined for the KEY RR
described in RFC 2535 [4].
described in RFC 2535 [3].
2.2 Text representation of APPKEY RRs
3.3 Text representation of APPKEY RRs
The RDATA portion of an APPKEY RR has the protocol field, version
number octet and algorithm number octet represented as unsigned
integers.
The RDATA portion of an APPKEY RR has the algorithm number octet
represented as unsigned integers.
The public key fields is represented in base 64 [9] and may be
The public key fields is represented in base 64 [8] and may be
divided up into any number of white space separated substrings, down
to single base 64 digits, which are concatenated to obtain the full
public key. These substrings can span lines using the standard
@@ -244,50 +211,46 @@ Internet-Draft Application public keys in DNS November 2001
have internal sub-fields, these do not appear in the master file
representation.
2.3 Owner names for APPKEY RRs
3.4 Owner names for APPKEY RRs
The owner name of the APPKEY RR is defined per application. This can
be, but is not limited to, the domain name of the host the
application is running at (e.g. host.example.com) or a name matching
the SRV RR [6] for the service (e.g. _ssh._tcp.host.example.com).
The owner name of the APPKEY RR is defined per application and SHOULD
be defined in such a way that it is possible to query for a single
3. Applicability Statement
Schlyter Expires August 7, 2002 [Page 4]
Internet-Draft Application public keys in DNS February 2002
application APPKEY. This can be, but is not limited to, the domain
name of the host the application is running at (e.g.
host.example.com) combined with a protocol identifier. A name
matching the SRV RR [5] for the service (e.g.
_service._protocol.host.example.com) could be a good starting point
for this naming.
4. Applicability Statement
The APPKEY resource record (RR) are only intended for storage of
public keys - private keys MUST NOT be stored in an APPKEY RR.
The APPKEY RR is not intended for storage of certificates and a
separate certificate RR, defined in RFC 2538 [5], has been developed
separate certificate RR, defined in RFC 2538 [4], has been developed
for that purpose.
4. Security considerations
5. Security considerations
Public keys from an APPKEY RR, SHOULD NOT be trusted unless the
APPKEY was authenticated by a trusted SIG RR. Applications that do
not validate the signatures by themselves are advised to use TSIG [7]
or SIG(0) [8] to protect the transport between themselves and the
not validate the signatures by themselves are advised to use TSIG [6]
or SIG(0) [7] to protect the transport between themselves and the
name server doing the signature validation.
5. IANA considerations
6. IANA considerations
IANA needs to allocate a RR type code for APPKEY from the standard RR
Schlyter Expires May 11, 2002 [Page 5]
Internet-Draft Application public keys in DNS November 2001
type space.
Protocol values 0x0000 and 0xFFFF are reserved.
Protocol values 0x0001 through 0xFEFF are allocated based on
"Specification Required" as defined in RFC 2434 [3].
XXX should the protocol values be divided into different ranges for
IETF Standard Action, IETF consensus and Specification Required ?
type space. No other IANA services are required by this document.
References
@@ -298,44 +261,40 @@ References
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1999.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[4] Eastlake, D., "Domain Name System Security Extensions", RFC
[3] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[5] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
[4] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
Domain Name System (DNS)", RFC 2538, March 1999.
[6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
[5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[7] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
Schlyter Expires August 7, 2002 [Page 5]
Internet-Draft Application public keys in DNS February 2002
[6] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[8] Eastlake, D., "DNS Request and Transaction Signatures (
[7] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.
[9] Josefsson, S., "Base Encodings", work in progress draft-
josefsson-base-encoding-02, May 2001.
[8] Josefsson, S., "Base Encodings", work in progress draft-
josefsson-base-encoding-03, November 2001.
[10] Lewis, E., "DNS KEY Resource Record Generic Protocol Value",
[9] Lewis, E., "DNS KEY Resource Record Generic Protocol Value",
work in progress draft-lewis-dnsext-key-genprot-00, July 2001.
[11] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
[10] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
Record", work in progress draft-ietf-dnsext-restrict-key-for-
Schlyter Expires May 11, 2002 [Page 6]
Internet-Draft Application public keys in DNS November 2001
dnssec-00, November 2001.
dnssec-01, January 2002.
Author's Address
@@ -360,6 +319,7 @@ Appendix A. Acknowledgements
Edward Lewis
Dan Massey
@@ -370,30 +330,14 @@ Appendix A. Acknowledgements
Schlyter Expires August 7, 2002 [Page 6]
Schlyter Expires May 11, 2002 [Page 7]
Internet-Draft Application public keys in DNS November 2001
Internet-Draft Application public keys in DNS February 2002
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright (C) The Internet Society (2002). 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
@@ -442,6 +386,6 @@ Acknowledgement
Schlyter Expires May 11, 2002 [Page 8]
Schlyter Expires August 7, 2002 [Page 7]

68
doc/draft/draft-schlyter-pkix-dns-00.txt → doc/draft/draft-schlyter-pkix-dns-01.txt
View File

@@ -1,13 +1,13 @@
Network Working Group J. Schlyter
PKIX Working Group J. Schlyter
Internet-Draft Carlstedt Research &
Expires: May 3, 2002 Technology
Expires: August 29, 2002 Technology
L. Johansson
Stockholm University
November 2, 2001
February 28, 2002
DNS as X.509 PKIX Certificate Storage
draft-schlyter-pkix-dns-00
draft-schlyter-pkix-dns-01
Status of this Memo
@@ -24,17 +24,17 @@ Status of this Memo
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 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 3, 2002.
This Internet-Draft will expire on August 29, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
@@ -50,9 +50,9 @@ Abstract
Schlyter & Johansson Expires May 3, 2002 [Page 1]
Schlyter & Johansson Expires August 29, 2002 [Page 1]
Internet-Draft DNS PKIX storage November 2001
Internet-Draft DNS PKIX storage February 2002
Table of Contents
@@ -106,9 +106,9 @@ Table of Contents
Schlyter & Johansson Expires May 3, 2002 [Page 2]
Schlyter & Johansson Expires August 29, 2002 [Page 2]
Internet-Draft DNS PKIX storage November 2001
Internet-Draft DNS PKIX storage February 2002
1. Introduction
@@ -132,10 +132,13 @@ Internet-Draft DNS PKIX storage November 2001
2. Storing PKIX certificates in DNS
A PKIX certificate is published in DNS using the CERT RR [5] for a
given domain name which MUST be equal to the dnsName component of the
subjectAltName extension in the certificate. Multiple certificates
may be present for each domain name and all SHOULD have the same
subject DN.
given domain name which SHOULD be equal to the dnsName component of
the subjectAltName extension in the certificate. Multiple
certificates may be present for each domain name and all SHOULD have
the same subject DN. If the domain name does not match the dnsName
component of the subjectAltName extension the client SHOULD notify
the user of this and allow the user to decide weather to allow the
use of the certificate or not.
When constructing a certificate path for validation the client MAY
use the AuthorityKeyIdentifier and SubjectKeyIdentifier extensions to
@@ -159,12 +162,9 @@ Internet-Draft DNS PKIX storage November 2001
Schlyter & Johansson Expires August 29, 2002 [Page 3]
Schlyter & Johansson Expires May 3, 2002 [Page 3]
Internet-Draft DNS PKIX storage November 2001
Internet-Draft DNS PKIX storage February 2002
3. Certificate lookup algorithm
@@ -172,7 +172,7 @@ Internet-Draft DNS PKIX storage November 2001
Given a certificate with a non-empty issuerAltName extension of type
dnsName, perform a DNS lookup of the corresponding domain name with
the class IN and type CERT. For each of the certificates returned
that are of type PKIX, implementations MUST verify that the
that are of type PKIX, implementations SHOULD verify that the
subjectAltName in the certificate contains a component of type
dnsName with the same domain name as the one where the certificate
was published using the DNS.
@@ -218,9 +218,9 @@ References
Schlyter & Johansson Expires May 3, 2002 [Page 4]
Schlyter & Johansson Expires August 29, 2002 [Page 4]
Internet-Draft DNS PKIX storage November 2001
Internet-Draft DNS PKIX storage February 2002
Authors' Addresses
@@ -237,9 +237,14 @@ Authors' Addresses
Leif Johansson
Stockholm University
IT and Media Unit
Frescati Hagvag 8
Stockholm SE-106 91
Sweden
Phone: +46 8 16 45 41
EMail: leifj@it.su.se
URI: http://www.it.su.se
Appendix A. Acknowledgements
@@ -250,6 +255,7 @@ Appendix A. Acknowledgements
Niklas Hallqvist
Edward Lewis
@@ -268,20 +274,14 @@ Appendix A. Acknowledgements
Schlyter & Johansson Expires August 29, 2002 [Page 5]
Schlyter & Johansson Expires May 3, 2002 [Page 5]
Internet-Draft DNS PKIX storage November 2001
Internet-Draft DNS PKIX storage February 2002
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright (C) The Internet Society (2002). 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
@@ -330,6 +330,6 @@ Acknowledgement
Schlyter & Johansson Expires May 3, 2002 [Page 6]
Schlyter & Johansson Expires August 29, 2002 [Page 6]