ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

updated drafts

Browse Source
This commit is contained in:
Andreas Gustafsson
2001-07-30 23:30:09 +00:00
parent 9261ca5fc8
commit 50851586b6
11 changed files with 1792 additions and 1698 deletions
Download Patch File Download Diff File Expand all files Collapse all files

308
doc/draft/draft-ietf-dnsext-aaaa-a6-00.txt → doc/draft/draft-ietf-dnsext-aaaa-a6-01.txt
View File

@@ -1,11 +1,13 @@
Internet Engineering Task Force Jun-ichiro itojun Hagino
INTERNET-DRAFT IIJ Research Laboratory
Expires: November 27, 2001 May 27, 2001
Expires: January 19, 2002 July 19, 2001
Comparison of AAAA and A6 (do we really need A6?)
draft-ietf-dnsext-aaaa-a6-00.txt
draft-ietf-dnsext-aaaa-a6-01.txt
Status of this Memo
@@ -22,26 +24,23 @@ 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/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.
Distribution of this memo is unlimited.
The internet-draft will expire in 6 months. The date of expiration will
be November 27, 2001.
be January 19, 2002.
Abstract
At this moment, there are two resource record types defined for holding
IPv6 address in the DNS database; AAAA [Thomson, 1995] and A6 [Crawford,
2000] . AAAA has been used for IPv6 network operation since 1996.
Questions arose whether we really need A6 or not, or whether it is
really possible to migrate to A6 or not. Some says AAAA is enough and
A6 is not necessary. Some says A6 is necessary and AAAA should get
At this moment, there are two DNS resource record types defined for
holding IPv6 address in the DNS database; AAAA [Thomson, 1995] and A6
[Crawford, 2000] . AAAA has been used for IPv6 network operation since
1996. Questions arose whether we really need A6 or not, or whether it
is really possible to migrate to A6 or not. Some says AAAA is enough
and A6 is not necessary. Some says A6 is necessary and AAAA should get
deprecated.
The draft tries to understand pros and cons between these two record
@@ -56,10 +55,10 @@ working group minutes for more details.
HAGINO Expires: November 27, 2001 [Page 1]
HAGINO Expires: January 19, 2002 [Page 1]
DRAFT Comparison of AAAA and A6 May 2001
DRAFT Comparison of AAAA and A6 July 2001
1. A brief summary of the IPv6 resource record types
@@ -115,10 +114,10 @@ records. Here is an example taken from RFC2874:
HAGINO Expires: November 27, 2001 [Page 2]
HAGINO Expires: January 19, 2002 [Page 2]
DRAFT Comparison of AAAA and A6 May 2001
DRAFT Comparison of AAAA and A6 July 2001
$ORIGIN X.EXAMPLE.
N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
@@ -174,22 +173,23 @@ and as resolver libraries. On the contrary, the author knows of only
one DNS server/resolver implementation that supports A6; BIND9.
HAGINO Expires: November 27, 2001 [Page 3]
HAGINO Expires: January 19, 2002 [Page 3]
DRAFT Comparison of AAAA and A6 May 2001
DRAFT Comparison of AAAA and A6 July 2001
Almost all of the IPv6-ready operating systems ship with BIND4 or BIND8
resolver library. Even for the implementations that use resolver
library other than BIND, they only support AAAA. Therefore, they cannot
query A6 records (unless aplications gets linked with BIND9 libraries
explicitly).
resolver library. [need to check situations with resolver libraries
based on non-BIND code] Therefore, they cannot query A6 records (unless
applications gets linked with BIND9 libraries explicitly).
2.2. IPv6 network
IPv6 network has been deployed widely since 1996. Though many of the
participants consider it to be experimental, commercial IPv6 services
has been deployed since around 1999, especially in asian countries.
has been deployed since around 1999, especially in Asian countries.
Even today, there are numerous IPv6 networks operated just as serious as
IPv4.
2.3. DNS database
@@ -223,21 +223,21 @@ non-fragmented A6 records, and AAAA synthesis.
AAAA records have been used on IPv6 network (also known as 6bone) since
it has started in 1996 and has been working just fine ever since. AAAA
record is a straight extension of A records; it needs a single query-
record is a straight extension of A record; it needs a single query-
response roundtrip to resolve a name into an IPv6 address.
A6 was proposed to add network renumbering friendliness to AAAA. With
AAAA, a full 128bit IPv6 address needs to be supplied in a DNS resource
record. Therefore, in the event of network renumber, administrators
need to update the whole DNS zone file with the new IPv6 address
prefixes. We will discuss the issues with renumbering in a dedicated
HAGINO Expires: November 27, 2001 [Page 4]
HAGINO Expires: January 19, 2002 [Page 4]
DRAFT Comparison of AAAA and A6 May 2001
DRAFT Comparison of AAAA and A6 July 2001
prefixes. We will discuss the issues with renumbering in a dedicated
section.
3.2. Fragmented A6 records
@@ -257,22 +257,29 @@ there will be more query roundtrips. There are only few possibilities
to query fragments in parallel. In the above example, we can resolve
A.NET.IP6.C.NET and A.NET.IP6.D.NET in parallel, but not others.
If the DNS record TTL is smaller than the communication delays between
the querier and the DNS servers, the querier will not be able to
reassemble a complete IPv6 record. With the following records, you
cannot reassemble an IPv6 address if the delay is larger than 1 second.
By the time you get the topmost 64 bits in the address, the lowermost 64
bits get invalidated. If the querier tries to query lowermost 64 bits
again, the querier can go into an infinite loop (see the section on
security considration). [BIND 9.2.0snap: resolver does not go into
infinite loop, meaning that BIND 9.2.0snap resolver does not really
honor DNS record TTL during A6 reassembly]
At this moment, there is very little documents available, regarding to
the relationship between DNS record TTL and the query delays. For
example, if the DNS record TTL is smaller than the communication delays
between the querier and the DNS servers, what should happen?
; resolver can go into an infinite loop if RTT > 1 second
$ORIGIN X.EXAMPLE.
$TTL 1
N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
SUBNET-1.IP6 A6 0 2345:00C1:CA11:1::
o If we compute DNS record TTL based on the wallclock on the DNS server
side, the DNS records are already expired and the querier will not be
able to reassemble a complete IPv6 record. Worse, by setting up
records with very low TTL, we can let recursive DNS resolvers to go
into infinite loop by letting them chase a wrong A6 chain (see the
section on security considration) [BIND 9.2.0snap: resolver does not
go into infinite loop, meaning that BIND 9.2.0snap resolver does not
really honor DNS record TTL during A6 reassembly].
o If we compute it starting from the time the querier got the record, we
will have some jitter in TTL computation among multiple queriers. If
the query delays are long enough, the querier would end up having
inconsistent A6 fragments, and the IPv6 address can be bogus after
reassembly. With record types other than A6, we had no such problem,
since we have never tried to reassemble an address out of multiple DNS
records (with CNAME chain chasing a similar problem can arise, but the
failure mode is much simpler to diagnose as the records are considered
as an atomic entity).
Some says that caches will avoid querying fragmented A6s again and
again. However, most of the library resolver implementations do not
@@ -281,6 +288,14 @@ nameserver will not be decreased by the cached records. The TTL problem
(see above) is unavoidable for the library resolver without cache. [XXX
will they interpret TTL field? BIND8 resolver does not]
HAGINO Expires: January 19, 2002 [Page 5]
DRAFT Comparison of AAAA and A6 July 2001
If some of the fragments are DNSSEC-signed and some are not, how should
we treat that address? RFC2874 section 6 briefly talks about it, not
sure if complete answer is given.
@@ -289,14 +304,6 @@ It is much harder to implement A6 fragment reassemble code, than to
implement AAAA record resolver. AAAA record resolver can be implemented
as a straight extension of A record resolver.
HAGINO Expires: November 27, 2001 [Page 5]
DRAFT Comparison of AAAA and A6 May 2001
o It is much harder to design timeout handling for the A6 reassembly.
There would be multiple timeout parameters, including (1) communcation
timeout for a single A6 fragment, (2) communcation timeout for the
@@ -318,9 +325,9 @@ In RFC2874, a suggestion is made to use limited number of fragments per
an IPv6 address. However, there is no protocol limitation defined. The
lack makes it easier for malicious parties to impose DoS attacks using
lots of A6 fragments (see the section on security consideration). [BIND
9.2.0snap: The implementation limits the number of fragments to be
smaller than 16; It is not a protocol limitation but an implementation
choice. Not sure if it is the right choice or not]
9.2.0snap: The implementation limits the number of fragments within an
A6 chain to be smaller than 16; It is not a protocol limitation but an
implementation choice. Not sure if it is the right choice or not]
With fragmented A6 records, in multi-prefix network configuration, it is
not possible for us to limit the address on the DNS database to the
@@ -331,6 +338,23 @@ to do so. It becomes mandatory for us to define the whole IPv6 address
by using ``A6 0'' for N.X.EXAMPLE, and in effect, the benefit of A6
(renumber friendliness) goes away.
HAGINO Expires: January 19, 2002 [Page 6]
DRAFT Comparison of AAAA and A6 July 2001
; with the following record we would advertise both records
$ORIGIN X.EXAMPLE.
N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
@@ -349,13 +373,6 @@ by using ``A6 0'' for N.X.EXAMPLE, and in effect, the benefit of A6
A6 resource record type and A6 fragment/reassembly were introduced to
help administrators on network renumber. When network gets renumbered,
the administrator needs to update A6 fragment for the higher address
HAGINO Expires: November 27, 2001 [Page 6]
DRAFT Comparison of AAAA and A6 May 2001
bits (prefixes) only. Again, we will discuss the issues with
renumbering in a dedicated section.
@@ -368,7 +385,7 @@ fragmented A6 records when we find a need for A6.
>From the packet format point of view, the approach has no benefit
against AAAA. Rather, there is a one-byte overhead to every
(unfragmented) A6 record compared to an AAAA record.
(unfragmented) A6 record compared to a AAAA record.
If the nameserver/resolver programs hardcode A6 processing to handle no
fragments, there will be no future possibility for us to introduce
@@ -387,14 +404,22 @@ At this moment, end hosts support AAAA records only. Some people would
like to see A6 deployment in DNS databases even with the lack of end
hosts support. To workaround the deployment issues of A6, the following
approach is proposed in IETF50 dnsext working group slot. It is called
``AAAA synthesis'':
``AAAA synthesis'' [Austein, 2001] :
HAGINO Expires: January 19, 2002 [Page 7]
DRAFT Comparison of AAAA and A6 July 2001
o Deploy A6 DNS records worldwide. The proposal was not specific about
whether we would deploy fragmented A6 records, or non-fragmented A6
records (``A6 0'').
o When a host queries AAAA record to a DNS server, the DNS server
queries A6 fragments, reassemble it, and respond with an AAAA record.
queries A6 fragments, reassemble it, and respond with a AAAA record.
The approach needs to be diagnosed/specified in far more detail. For
example, the following questions need to be answered:
@@ -409,12 +434,6 @@ o Which nameserver should synthesize the AAAA record, in the DNS
recursize query chain? Is the synthesis mandatory for every DNS
server implementation?
HAGINO Expires: November 27, 2001 [Page 7]
DRAFT Comparison of AAAA and A6 May 2001
o What should we do if the A6 reassembly takes too much time?
o What should we do about DNSSEC signatures?
@@ -445,7 +464,14 @@ o Query AAAA records.
o Query A records.
o Sort the result based on destination address ordering rule. An
example of the ordering rule is presented as a draft [Draves, 2000] .
example of the ordering rule is presented as a draft [Draves, 2001] .
HAGINO Expires: January 19, 2002 [Page 8]
DRAFT Comparison of AAAA and A6 July 2001
o Contact the destination addresses in sequence.
@@ -467,13 +493,6 @@ connectivity today. If ISPs do assign static IPv6 address block to the
customers, there is no need to renumber customer network that frequently
(unless the customer decides to switch the upstream ISPs that often).
NOTE: Roaming dialup users, like those who carry laptop computers
HAGINO Expires: November 27, 2001 [Page 8]
DRAFT Comparison of AAAA and A6 May 2001
worldwide, seems to have a different issue from stationary dialup users.
See [Hagino, 2000] for more discussions.
@@ -494,17 +513,32 @@ presentation by JINMEI Tatsuya regarding to site renumbering experiment.
It is recommend to read through the IETF49 minutes and slides. [XXX
Fred Baker had a draft on this - where?] For the network renumbering to
be successful, no configuration files should have hardcoded (numeric) IP
addresses. It is a very hard requrement to meet. We fail to satisfy
addresses. It is a very hard requirement to meet. We fail to satisfy
this in many of the network renumbering events, and the failure causes a
lot of troubles.
At this moment there is no mechanism defined for ISPs to renumber
downstream customers at will. Router renumbering protocol [Crawford,
2000] is defined only for a single administrative domain (customers will
not want to share IPsec authentication key for routers, with the
upstream ISP). Even though it may sound interesting for ISPs, it would
cause a lot of (social and political) issues in doing so, so the author
would say it is rather unrealistic to pursue this route.
downstream customers at will. Even though it may sound interesting for
ISPs, it would cause a lot of (social and political) issues in doing so,
so the author would say it is rather unrealistic to pursue this route.
The only possible candidate, router renumbering protocol [Crawford,
2000] does not really fit into the situation. The protocol is defined
using IPsec authentication over site-local multicast packets. It would
be cumbersome to run router renumbering protocol across multiple
HAGINO Expires: January 19, 2002 [Page 9]
DRAFT Comparison of AAAA and A6 July 2001
administrative domains, as (1) customers will not want to share IPsec
authentication key for routers with the upstream ISP, and (2) customer
network will be administered as a separate site from the upstream ISP
(Even though router renumbering protocol could be used with unicast
addresess, it is not realistic to assume that we can maintain the list
of IPv6 addresses for all the routers in both customers' and ISPs'
networks).
A6 was designed to help administators update zone files during network
renumbering events. Even with AAAA, zone file modification itself is
@@ -516,7 +550,10 @@ renumbering the network. With A6, we need to sign upper bits only with
DNSSEC keys. Therefore, A6 will impose less zone signing cost on the
event of network renumbering. As seen above, it is questionable if we
renumber network that often, so it is questionable if A6 brings us an
overall benefit.
overall benefit. Note, however, even if we use A6 to facilitate more
frequent renumbering and lower signing cost, all glue records has to be
installed as non-fragmented A6 records (``A6 0''), and required to be
signed again on renumbering events.
5. Security consideration
@@ -526,13 +563,6 @@ a brief summary:
o There will be a higher delay imposed by query/reply roundtrips for
fragmented A6 records. This could affect every services that relies
HAGINO Expires: November 27, 2001 [Page 9]
DRAFT Comparison of AAAA and A6 May 2001
upon DNS records.
o There is no upper limit defined for the number of A6 fragments for
@@ -554,17 +584,24 @@ We would like to go into more details for some of these.
When a DNS server is configured for AAAA synthesis, malicious parties
can impose DoS attacks using the interaction between DNS TTL and query
HAGINO Expires: January 19, 2002 [Page 10]
DRAFT Comparison of AAAA and A6 July 2001
delays. The attack can chew CPU time and/or memory, as well as some
network bandwidth on a victim nameserver, by the following steps:
o Bad guy configures a record with very complex A6 chain, onto some
nameservers. (bad guy has to have controls over the servers). The
nameservers can be located anywhere in the world. The A6 chain should
have a very low TTL (like 1 or 0 seconds). The attack works better if
we have higher delays between the victim nameservers and the
o A bad guy configures a record with very complex A6 chain, onto some
nameservers. (the bad guy has to have controls over the servers).
The nameservers can be located anywhere in the world. The A6 chain
should have a very low TTL (like 1 or 0 seconds). The attack works
better if we have higher delays between the victim nameservers and the
nameservers that serve A6 fragments.
o Bad guy queries the record using AAAA request, to the victim
o The bad guy queries the record using AAAA request, to the victim
nameserver.
o The victim nameserver will try to reassemble A6 fragments. During the
@@ -574,6 +611,10 @@ o The victim nameserver will try to reassemble A6 fragments. During the
(more traffic). The server can go into an infinite loop, if it tries
to query the expired A6 fragments again.
Note, however, this problem could be considered as a problem in
recursize resolvers in general (like CNAME and NS chasing); A6 and AAAA
synthesis makes the problem more apparent, and more complex to diagnose.
To remedy this problem, we have a couple of solutions:
(1) Deprecate A6 and deploy AAAA worldwide. If we do not have A6, the
@@ -584,14 +625,6 @@ To remedy this problem, we have a couple of solutions:
(3) Impose a protocol limitation to the number of A6 fragments.
HAGINO Expires: November 27, 2001 [Page 10]
DRAFT Comparison of AAAA and A6 May 2001
(4) Do not query the expired records in A6 chain again. In other words,
implement resolvers that ignore TTL on DNS records. Not sure if it
is the right thing to do.
@@ -610,15 +643,22 @@ believes that we need to pick one of them.
Given the unlikeliness of frequent network renumbering, the author
believes that the A6's benefit in lower zone signing cost is not
significant. The benefit of A6 (in zone signing cost) is much less than
HAGINO Expires: January 19, 2002 [Page 11]
DRAFT Comparison of AAAA and A6 July 2001
the expected complication that will be imposed by A6 operations.
>From the above discussions, the author suggests to keep AAAA and
deprecate A6. The author believes that A6 can cause a lot of problem
than the benefits it may have. A6 will make IPv6 DNS operation more
complicated and vulnerable to attacks. AAAA is proven to work right in
our IPv6 network operation since 1996. AAAA has been working just fine
in existing IPv6 networks, and the author believes that it will in the
coming days.
deprecate A6 (move A6 document to historic state). The author believes
that A6 can cause a lot of problem than the benefits it may have. A6
will make IPv6 DNS operation more complicated and vulnerable to attacks.
AAAA is proven to work right in our IPv6 network operation since 1996.
AAAA has been working just fine in existing IPv6 networks, and the
author believes that it will in the coming days.
@@ -633,9 +673,13 @@ M. Crawford, C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6
Address Aggregation and Renumbering" in RFC2874 (July 2000).
ftp://ftp.isi.edu/in-notes/rfc2874.txt.
Draves, 2000.
Richard Draves, "Default Address Selection for IPv6," Internet Draft
(November 2000). work in progress material.
Austein, 2001.
R. Austein, "Tradeoffs in DNS support for IPv6" in draft-ietf-dnsext-
ipv6-dns-tradeoffs-00.txt (July 2001). work in progress material.
Draves, 2001.
Richard Draves, "Default Address Selection for IPv6" in draft-ietf-
ipngwg-default-addr-select-04.txt (May 2001). work in progress material.
Hagino, 2000.
Jun-ichiro Hagino and Kazu Yamamoto, "Requirements for IPv6 dialup PPP
@@ -644,13 +688,6 @@ work in progress material.
Crawford, 2000.
Matt Crawford, "Router Renumbering for IPv6" in RFC2894 (August 2000).
HAGINO Expires: November 27, 2001 [Page 11]
DRAFT Comparison of AAAA and A6 May 2001
ftp://ftp.isi.edu/in-notes/rfc2894.txt.
Thomson, 1998.
@@ -663,6 +700,15 @@ Change history
none.
HAGINO Expires: January 19, 2002 [Page 12]
DRAFT Comparison of AAAA and A6 July 2001
Acknowledgements
The draft was written based on discussions in IETF IPv6 and dnsext
@@ -705,5 +751,17 @@ Author's address
HAGINO Expires: November 27, 2001 [Page 12]
HAGINO Expires: January 19, 2002 [Page 13]

106
doc/draft/draft-ietf-dnsext-ad-is-secure-02.txt → doc/draft/draft-ietf-dnsext-ad-is-secure-03.txt
View File

@@ -1,7 +1,7 @@
DNSEXT Working Group Brian Wellington
INTERNET-DRAFT Olafur Gudmundsson
<draft-ietf-dnsext-ad-is-secure-02.txt> June 2001
<draft-ietf-dnsext-ad-is-secure-03.txt> July 2001
Updates: RFC 2535
@@ -32,7 +32,7 @@ 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 December 18, 2001.
This draft expires on January 17, 2002.
Copyright Notice
@@ -50,9 +50,9 @@ Abstract
Expires December 2001 [Page 1]
Expires January 2002 [Page 1]
INTERNET-DRAFT AD bit set on secure answers June 2001
INTERNET-DRAFT AD bit set on secure answers July 2001
1 - Introduction
@@ -70,7 +70,7 @@ INTERNET-DRAFT AD bit set on secure answers June 2001
This draft proposes to redefine the AD bit such that it is only set
if all data in the response has been cryptographically verified.
Thus, a response containing properly delegated insecure data will not
have AD set, as will a response from a server configured without
have AD set, neither will a response from a server configured without
DNSSEC keys. As before, data which failed to verify will not be
returned. An application can then use the value of the AD bit to
determine if the data is secure or not.
@@ -101,16 +101,18 @@ INTERNET-DRAFT AD bit set on secure answers June 2001
"The AD bit MUST NOT be set on a response unless all of the RRsets in
the answer and authority sections of the response are Authenticated."
"The AD bit SHOULD be set if and only if all RRs in the answer
section and any relevant negative response RRs in that authority
Expires December 2001 [Page 2]
Expires January 2002 [Page 2]
INTERNET-DRAFT AD bit set on secure answers June 2001
INTERNET-DRAFT AD bit set on secure answers July 2001
section are Authenticated."
AD should be set if and only if all RRs in the answer section, and
any relevant negative response RRs in the authority section are
Authenticated.
@@ -122,12 +124,13 @@ INTERNET-DRAFT AD bit set on secure answers June 2001
authentication such as TSIG[RFC2845] or SIG(0)[RFC2931], and the
resolver policy is that it can trust the server.
A DNS server following this modified specification will only set the
AD bit when it has cryptographically verified the data in the answer.
In the case of a primary server for a secure zone, the data MAY be
considered Authenticated, depending on local policy. Secondary
servers SHOULD NOT consider data Authenticated unless the zone was
transfered securely or the data was verified.
Any DNS server supporting the OK bit MUST support this definition of
the AD bit. A DNS server following this modified specification will
only set the AD bit when it has cryptographically verified the data
in the answer. In the case of a primary server for a secure zone,
the data MAY be considered Authenticated, depending on local policy.
Secondary servers SHOULD NOT consider data Authenticated unless the
zone was transfered securely or the data was verified.
3 - Interpretation of the AD bit
@@ -140,7 +143,29 @@ INTERNET-DRAFT AD bit set on secure answers June 2001
This document redefines a bit in the DNS header. If a resolver
trusts the value of the AD bit, it must be sure that the server is
using the updated definition.
using the updated definition, which is any server supporting the OK
bit.
Expires January 2002 [Page 3]
INTERNET-DRAFT AD bit set on secure answers July 2001
5 - IANA Considerations:
@@ -159,14 +184,6 @@ References:
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC
2535, March 1999.
Expires December 2001 [Page 3]
INTERNET-DRAFT AD bit set on secure answers June 2001
[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
``Secret Key Transaction Authentication for DNS (TSIG)'', RFC
2845, May 2000.
@@ -198,6 +215,14 @@ Full Copyright Statement
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
Expires January 2002 [Page 4]
INTERNET-DRAFT AD bit set on secure answers July 2001
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
@@ -218,5 +243,36 @@ Full Copyright Statement
Expires December 2001 [Page 4]
Expires January 2002 [Page 5]

143
doc/draft/draft-ietf-dnsext-axfr-clarify-02.txt → doc/draft/draft-ietf-dnsext-axfr-clarify-03.txt
View File

@@ -1,7 +1,6 @@
INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsext-axfr-clarify-02.txt Nominum Inc.
June 2001
draft-ietf-dnsext-axfr-clarify-03.txt Nominum Inc.
July 2001
DNS Zone Transfer Protocol Clarifications
@@ -50,9 +49,9 @@ Abstract
Expires December 2001 [Page 1]
Expires January 2002 [Page 1]
draft-ietf-dnsext-axfr-clarify-02.txt June 2001
draft-ietf-dnsext-axfr-clarify-03.txt July 2001
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -74,7 +73,9 @@ draft-ietf-dnsext-axfr-clarify-02.txt June 2001
If the master server is unable or unwilling to provide a zone
transfer, it MUST respond with a single DNS message containing an
appropriate RCODE other than NOERROR.
appropriate RCODE other than NOERROR. If the master is not
authoritative for the requested zone, the RCODE SHOULD be 9
(NOTAUTH).
Slave servers should note that some master server implementations
will simply close the connection when denying the slave access to the
@@ -101,16 +102,17 @@ draft-ietf-dnsext-axfr-clarify-02.txt June 2001
A master MAY transmit multiple answer RRs per response message up to
the largest number that will fit within the 65535 byte limit on TCP
Expires January 2002 [Page 2]
draft-ietf-dnsext-axfr-clarify-03.txt July 2001
DNS message size. In the case of a small zone, this can cause the
entire transfer to be transmitted in a single response message.
Expires December 2001 [Page 2]
draft-ietf-dnsext-axfr-clarify-02.txt June 2001
Slaves MUST accept messages containing any number of answer RRs. For
compatibility with old slaves, masters that support sending multiple
answers per message SHOULD be configurable to revert to the
@@ -156,17 +158,18 @@ draft-ietf-dnsext-axfr-clarify-02.txt June 2001
response SHOULD have a question section identical to that in the
request. Subsequent messages SHOULD NOT have a question section,
though the final message MAY. The receiving slave server MUST accept
Expires January 2002 [Page 3]
draft-ietf-dnsext-axfr-clarify-03.txt July 2001
any combination of messages with and without a question section.
3.5. The authority section
Expires December 2001 [Page 3]
draft-ietf-dnsext-axfr-clarify-02.txt June 2001
The master server MUST transmit messages with an empty authority
section. Slaves MUST ignore any authority section contents they may
receive from masters that do not comply with this requirement.
@@ -175,7 +178,8 @@ draft-ietf-dnsext-axfr-clarify-02.txt June 2001
The additional section MAY contain additional RRs such as transaction
signatures. The slave MUST ignore any unexpected RRs in the
additional section.
additional section. It MUST NOT treat additional section RRs as zone
data.
4. Zone data
@@ -210,29 +214,30 @@ draft-ietf-dnsext-axfr-clarify-02.txt June 2001
RFC1034 states that "The first and last messages must contain the
data for the top authoritative node of the zone". This is not
consistent with existing practice. All known master implementations
send, and slave implementations expect to receive, the zone's SOA RR
as the first and last record of the transfer. Any other RRs at the
zone's apex are transmitted only once.
Therefore, the quoted sentence is hereby changed to read "The first
Expires December 2001 [Page 4]
Expires January 2002 [Page 4]
draft-ietf-dnsext-axfr-clarify-02.txt June 2001
draft-ietf-dnsext-axfr-clarify-03.txt July 2001
and last RR transmitted must be the SOA record of the zone".
send, and slave implementations expect to receive, the zone's SOA RR
as the first and last record of the transfer.
Therefore, the quoted sentence is hereby superseded by the sentence
"The first and last RR transmitted must be the SOA record of the
zone".
The initial and final SOA record MUST be identical, with the possible
exception of case and compression. In particular, they MUST have the
same serial number.
same serial number. The slave MUST consider the transfer to be
complete when, and only when, it has received the message containing
the second SOA record.
The transmission order of all other RRs in the zone is undefined.
Each of them MUST be transmitted exactly once. As some older masters
do not comply with this requirement, slaves SHOULD silently ignore
duplicate RRs for interoperability.
Each of them SHOULD be transmitted only once, and slaves MUST ignore
any duplicate RRs received.
6. Security Considerations
@@ -256,14 +261,23 @@ Acknowledgements
Many people have contributed input and commentary to earlier versions
of this document, including but not limited to Bob Halley, Dan
Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Levon Esibov,
Mark Andrews, Michael Patton, Peter Koch, and Sam Trenholme.
Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz,
Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
Trenholme, and Brian Wellington.
References
[RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
November 1987.
Expires January 2002 [Page 5]
draft-ietf-dnsext-axfr-clarify-03.txt July 2001
[RFC1035] - Domain Names - Implementation and Specifications, P.
Mockapetris, November 1987.
@@ -271,14 +285,6 @@ References
S. Bradner, BCP 14, March 1997.
[RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P.
Expires December 2001 [Page 5]
draft-ietf-dnsext-axfr-clarify-02.txt June 2001
Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.
Author's Address
@@ -320,6 +326,14 @@ Full Copyright Statement
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
Expires January 2002 [Page 6]
draft-ietf-dnsext-axfr-clarify-03.txt July 2001
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
@@ -330,5 +344,46 @@ Full Copyright Statement
Expires December 2001 [Page 6]
Expires January 2002 [Page 7]

557
doc/draft/draft-ietf-dnsext-delegation-signer-00.txt
View File

@@ -1,557 +0,0 @@
DNSEXT Working Group Olafur Gudmundsson
INTERNET-DRAFT May 2001
<draft-ietf-dnsext-delegation-signer-00.txt>
Updates: RFC 1035, RFC 2535, RFC 3008.
Delegation Signer record in parent.
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
Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org
This draft expires on November 30, 2001.
Copyright Notice
Copyright (C) The Internet Society (2001). All rights reserved.
Abstract
One of the biggest problems in DNS occur when records of the same type
can appear on both sides of an delegation. If the contents of these
sets differs clients can get confused. RFC2535 KEY records follows
the same model as for NS records, parent is responsible for the
records but the child is responsible for the contents. This document
Gudmundsson Expires November 2001 [Page 1]
INTERNET-DRAFT Delegation Signer Record May 2001
proposes to store a different record in the parent that specifies
which one of the child's keys can sign the child's KEY set. This
change is not backwards compatible with RFC2535 but simplifies DNSSEC
operation.
1 - Introduction
Familiarity with the DNS system [RFC1035], DNS security extensions
[RFC2535] and DNSSEC terminology [RFC3090] is important.
When the same data can reside in two administratively different DNS
zones sources it is common that the data gets out of sync. NS record
in a zone indicates that there is a delegation at this name and the NS
record lists the authorative servers for the real zone. Based on
actual measurements 10-30% of all delegations in the Internet have
differing NS sets at parent and child. There are number of reasons for
this including lack of communication between parent and child, and
bogus nameservers are listed to meet registrar requirements.
DNSSEC [RFC2535,RFC3008,RFC3090] specifies that child must have its
KEY set signed by the parent to create a verifiable chain of KEYs.
There is some debate, where the signed KEY set should reside,
parent[Parent] or child[RFC2535]. If the KEY set resides at the child,
frequent communication is needed between the two to transmit keysets
up to parent and signatures down to child. If the KEY set resides at
the parent[Parent] the communication is reduced having only child send
updated key sets to parent. DNSSEC requires that the parent store NULL
key set for unsecure children, this complicates resolution process as
in many cases as servers for both parent and child need to be queried
for KEY set.
Further complication of the DNSSEC KEY model is that KEY record is
used to store DNS zone keys and public keys for other protocols. This
can lead to large key sets at delegation points. There are number of
potential problems with this.
1. KEY set may become quite large if many applications/protocols store
their keys at the zone apex. Example of protocols are IPSEC, HTTP,
SMTP, SSH etc.
2. Key set may require frequent updates,
3. Probability of compromised/lost keys increases and triggers
emergency key rollover.
4. Parent may refuse sign key sets with NON DNS zone keys.
5. Parent may not have QoS on key changes that meets child's
expectations.
Given these and other reasons there is good reason to explore
alternatives to using only KEY records to create chain of trust.
Gudmundsson Expires November 2001 [Page 2]
INTERNET-DRAFT Delegation Signer Record May 2001
Some of these problems can be reduced or eliminated by operational
rules or protocol changes. To reduce the number of keys at apex, rule
to require applications to store their KEY records at the SRV name for
that application is one possibility. Another is to restrict KEY record
to DNS keys only and create a new type for all non DNS keys. Third
possible solution is to ban the storage of non DNS related keys at
zone apex. There are other possible solutions but they are outside the
scope of this draft.
1.1 - Delegation Signer Record model
This draft proposes an alternative to the KEY record chain of trust,
that uses a special record that can only reside at the parent. This
record will identify the key(s) that child will use to self sign its
KEY set.
The chain of trust is now established by verifying the parent KEY set,
the DK set from the parent and then the KEY set at the child. This is
cryptographically equivalent to just using KEY records.
Communication between the parent and child is reduced as the parent
only needs to know of changes in DNS zone KEY records used to sign the
apex KEY set. If other KEY records are stored at the zone apex, the
parent does not to be aware of them.
If child wants to have frequent key rollover for its DNS keys it is
possible to do that without communicating to the parent, in this case
the child uses on strong key to sign its apex KEY set and other
smaller keys to sign the zone for a short time.
This approach has the advantage that communication between the parent
and child is kept to a minimum and the child is the authority for the
KEY set with full control over the contents. The load on the parent
is reduced and it can maintain its zone as it sees fit.
The main disadvantage of this approach is to double the number of
signatures that need to be verified for the each KEY set. The
advantage on the other hand is that child only needs to update data in
parent when it changes DNS signing key.
Gudmundsson Expires November 2001 [Page 3]
INTERNET-DRAFT Delegation Signer Record May 2001
1.2 - Reserved words
The key words "CAN", "MUST", "MUST NOT", "SHOULD", "DOES NOT" and
"MAY" in this document are to be interpreted as described in RFC2119.
2 - DK (Delegation KEY signer) record:
2.1 Protocol change
DK record MUST only appear at a delegation in the parent zone. The
record lists the child's keys that CAN sign the child's key set.
Insecure delegation MUST NOT have a DK record, the presence of DK
record SHOULD be considered a hint that the child might be secure.
Resolver MUST only trust KEY records that match a DK record.
NOTE: It has been suggested that NULL DK record for insecure children
is better than no record. The advantage is to have authenticated
denial of child's security status, the drawback is for large
delegating zones there will be many NULL DK records.
WG please comment on which approach is better.
Updates RFC2535 sections 2.3.4 and 3.4, as well as RFC3008 section
2.7: Delegating zones MUST NOT store KEY records for delegations. The
only records that can appear at delegation in parent are NS, SIG, NXT
and DK.
Zone MUST self sign its apex KEY set, it SHOULD sign it with a key
that corresponds to a DK record in the parent.
If child apex KEY RRset is not signed with one of the keys specified
in the DK record the child is locally secure[RFC3090] and SHOULD only
be considered secure the resolver has been instructed to trust the key
used, via preconfiguration.
Authorative server answering a query, that has the OK bit set[OKbit],
MUST include the DK set in the additional section if the answer is a
referral and there is space. Caching servers MAY return the DK record
in the additional section under the same condition.
Gudmundsson Expires November 2001 [Page 4]
INTERNET-DRAFT Delegation Signer Record May 2001
2.1.1 - Comments on protocol change
DK record is the first DNS record to be only stored at the upper side
of a delegation. NS records appear at both sides as do SIG and NXT.
All other records can only appear at the lower side. This will cause
some problems as servers authorative for parent may reject DK record
even if the server understands unknown types. Similarly a nameserver
acting as a authorative for child and as a caching recursive server
may never return the DK record. A caching server does not care from
which side DK record comes from and thus should not have to be changed
if it supports unknown types.
Secure resolvers need to know about the DK record and how to interpret
it. In the worst case, introducing the DK record, doubles the
signatures that need to be checked to validate a KEY set, this is a
small price to pay to have a cleaner delegations structure.
Over the years there has been various discussions on that the
delegation model in DNS is broken as there is no real good way to
assert if delegation exists. In RFC2535 version of DNSSEC the
authentication of a delegation is the NS bit in the NXT bitmap at the
delegation point. Something more explicit is needed and the DK record
addresses this for secure delegations.
2.2 Wire format of DK record
There are two possible ways to represent the DK record at the parent
and this draft presents both for discussion, the WG is expected to
select one and only one. The two formats is either to reuse the RDATA
definition of the KEY record and the other one is to store an
identifier of the key.
2.2.1 Compact DK format
The DK record consists of algorithm, size, key tag and SHA-1 digest of
the public key KEY record allowed to sign the child's delegation.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key tag | size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | SHA-1 digest |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
Gudmundsson Expires November 2001 [Page 5]
INTERNET-DRAFT Delegation Signer Record May 2001
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+
The key tag is calculated as specified in RFC2535, the size is the
size of the public key in bits as specified in the document specifying
the algorithm. Algorithm MUST be an algorithm number assigned in the
range 1..251. The SHA-1 digest is calculated over the canonical name
of the delegation followed by the RDATA of the KEY record.
2.2.1.1 Justifications for fields
The algorithm and size fields are here to allow resolvers to quickly
identify the candidate KEY records to examine. Key Tag is to allow
quick check if this is a good candidate. The key tag is redundant but
provides some greater assurance than SHA-1 digest on its own. SHA-1 is
a strong cryptographic checksum, it is hard for attacker to generate a
KEY record that has the same SHA-1 digest. Making sure that the KEY
record is a valid public key is much harder. Combining the SHA-1 all
the checks, the task of the attacker is as hard breaking the public
key. Even if someone creates a database of all SHA-1 key hashes seen
so far, the addition of the name renders that database useless for
attacks.
2.2.2 Verbose DK format
The RDATA of the DK record is identical to the KEY record as specified
in RFC2535 sections 3.1, 3.1.2, 3.1.3 and 3.2.
2.3 Presentation format of DK record
Only one of these subsections will be used in RFC.
Gudmundsson Expires November 2001 [Page 6]
INTERNET-DRAFT Delegation Signer Record May 2001
2.3.1 Presentation format for the compact DK record
The presentation format of DK record consists of 2 numbers, followed
by either the name of the signature algorithm or the algorithm number.
The digest is to be presented in hex.
2.3.2 Presentation format for the verbose DK record
Identical to KEY record.
2.4 Justifications for each format
2.4.1 Justification for compact format
This format allows concise representation of the keys that child will
use, thus keeping down the size of the answer for the delegation,
reducing the probability of packet overflow. The SHA-1 hash is strong
enough to uniquely identify the key. This is similar to PGP footprint.
Each DK record has RDATA size of 25, regardless of the size of the
keys, keeping the answers from the parent smaller than if public key
was used. The smallest currently defined KEY record RDATA is 70 bytes.
Compact DK format is also better suited to list trusted keys for
islands of security in configuration files.
2.4.2 Justifications for verbose format
Even though this format results in larger DK set the effect on
implementations is smaller. Supporting I/O for DK record type is a
matter of reusing the code for reading/writing KEY records. For
finding DK to KEY matches simple compare will do, instead of digesting
the public KEYS.
3 Resolver Example
This example uses compact notation for both DK and KEY for clarity.
To create a chain of trust resolver goes from trusted KEY to DK to
KEY.
Assume the key for domain example. is trusted. In zone example we
have
example. KEY <stuff>
secure.example. DK tag=12345 size=1024 alg=dsa <foofoo>
secure.example. NS ns1.secure.example.
NS ns1.secure.example.
secure.example. NXT NS SIG NXT DK tail.example.
Gudmundsson Expires November 2001 [Page 7]
INTERNET-DRAFT Delegation Signer Record May 2001
secure.example. SIG(NXT)
secure.example. SIG(DK)
In zone secure.example. we have
secure.example. SOA <soa stuff>
secure.example. NS ns1.secure.example.
NS ns1.secure.example.
secure.example. KEY <tag=12345 size=1024 alg=dsa>
KEY <tag=54321 size=512 alg=rsa/sha1>
KEY <tag=32145 size=1024 alg=dsa>
secure.example. SIG(KEY) <by key-tag=12345 size=1024 alg=dsa>
secure.example. SIG(SOA) <by key-tag=54321 size=512 alg=rsa/sha1>
secure.example. SIG(NS) <by key-tag=54321 size=512 alg=rsa/sha1>
In this example the trusted key for example signs the DK record for
secure.example, making that a trusted record. The DK record states
what key is supposed to sign the KEY record at secure.example. In
this example secure.example. has three KEY records and the correct one
signs the KEY set, thus the key set is validated and trusted. One of
the other keys in the keyset actually signs the zone data, and
resolvers will trust the signatures as the key appears in the KEY set
that was correctly signed.
This example has only one DK record for the child but there no reason
to outlaw multiple DK records. More than one DK record is needed
during signing key rollover.
4 Acknowledgments
Number of people have over the last few years contributed number of
ideas that are captured in this document.
4 - Security Considerations:
This document proposes a change to the validation chain of KEY records
in DNS. The change in is not believed to reduce security in the
overall system, in RFC2535 DNSSEC child must communicate keys to
parent and prudent parents will require some authentication on that
handshake. The modified protocol will require same authentication but
allows the child to exert more local control over its own KEY set.
In the compact representation of DK record, there is a possibility
that an attacker can generate an valid KEY that matches all the checks
thus starting to forge data from the child. This is considered
impractical as on average more than 2**80 keys must be generated
before one is found that will match.
Gudmundsson Expires November 2001 [Page 8]
INTERNET-DRAFT Delegation Signer Record May 2001
DK record is a change to DNSSEC protocol and there is some installed
base of implementations, as well as text books on how to set up
secured delegations. Implementations that do not understand DK record
will not be able to follow the KEY to DK to KEY chain and consider all
zone secured that way insecure.
5 - IANA Considerations:
IANA needs to allocate RR type code for DK from the standard RR type
space.
References:
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification'', STD 13, RFC 1035, November 1987.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC
2535, March 1999.
[RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing
Authority'', RFC 3008, November 2000.
[RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone
Status'', RFC 3090, March 2001.
[IDbit] D. Conrad, ``Indicating Resolver Support of DNSSEC'', work in
progress <draft-ietf-dnsext-dnssec-okbit-02.txt>, April 2001.
[Parent] R. Gieben, T. Lindgreen, ``Parent stores the child's zone
KEYs'', work in progress <draft-ietf-dnsext-parent-stores-
zones-keys-01.txt>, May 2001.
Author Address
Olafur Gudmundsson
3826 Legation Street, NW
Washington, DC, 20015
USA
<ogud@ogud.com>
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
Gudmundsson Expires November 2001 [Page 9]
INTERNET-DRAFT Delegation Signer Record May 2001
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."
Gudmundsson Expires November 2001 [Page 10]

618
doc/draft/draft-ietf-dnsext-delegation-signer-01.txt Normal file
View File

@@ -0,0 +1,618 @@
DNSEXT Working Group Olafur Gudmundsson
INTERNET-DRAFT July 2001
<draft-ietf-dnsext-delegation-signer-01.txt>
Updates: RFC 1035, RFC 2535, RFC 3008.
Delegation Signer record in parent.
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
Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org
This draft expires on January 15, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All rights reserved.
Abstract
One of the biggest problems in DNS occur when records of the same type
can appear on both sides of an delegation. If the contents of these
sets differs clients can get confused. RFC2535 KEY records follows
the same model as for NS records, parent is responsible for the
records but the child is responsible for the contents. This document
Gudmundsson Expires January 2002 [Page 1]
INTERNET-DRAFT Delegation Signer Record July 2001
proposes to store a different record in the parent that specifies
which one of the child's keys are authorized to sign the child's KEY
set. This change is not backwards compatible with RFC2535 but
simplifies DNSSEC operation.
1 - Introduction
Familiarity with the DNS system [RFC1035], DNS security extensions
[RFC2535] and DNSSEC terminology [RFC3090] is important.
When the same data can reside in two administratively different DNS
zones sources it is common that the data gets out of sync. NS record
in a zone indicates that there is a delegation at this name and the NS
record lists the authorative servers for the real zone. Based on
actual measurements 10-30% of all delegations in the Internet have
differing NS sets at parent and child. There are number of reasons for
this, including lack of communication between parent and child and
bogus name-servers being listed to meet registrar requirements.
DNSSEC [RFC2535,RFC3008,RFC3090] specifies that child must have its
KEY set signed by the parent to create a verifiable chain of KEYs.
There is some debate, where the signed KEY set should reside,
parent[Parent] or child[RFC2535]. If the KEY set resides at the child,
frequent communication is needed between the two parties, to transmit
key sets up to parent and then the signed set or signatures down to
child. If the KEY set resides at the parent[Parent] the communication
is reduced having only child send updated key sets to parent.
DNSSEC[RFC2535] requires that the parent store NULL key set for
unsecure children, this complicates resolution process as in many
cases as servers for both parent and child need to be queried for KEY
set the [Parent] proposal simplifies this.
Further complication of the DNSSEC KEY model is that KEY record is
used to store DNS zone keys and public keys for other protocols. This
can lead to large key sets at delegation points. There are number of
potential problems with this including:
1. KEY set may become quite large if many applications/protocols store
their keys at the zone apex. Example of protocols are IPSEC, HTTP,
SMTP, SSH etc.
2. Key set may require frequent updates.
3. Probability of compromised/lost keys increases and triggers
emergency key rollover.
4. Parent may refuse sign key sets with NON DNS zone keys.
5. Parent may not have QoS on key changes that meets child's
expectations.
Gudmundsson Expires January 2002 [Page 2]
INTERNET-DRAFT Delegation Signer Record July 2001
Given these and other reasons there is good reason to explore
alternatives to using only KEY records to create chain of trust.
Some of these problems can be reduced or eliminated by operational
rules or protocol changes. To reduce the number of keys at apex, rule
to require applications to store their KEY records at the SRV name for
that application is one possibility. Another is to restrict KEY record
to DNS keys only and create a new type for all non DNS keys. Third
possible solution is to ban the storage of non DNS related keys at
zone apex. There are other possible solutions but they are outside the
scope of this document.
1.1 - Delegation Signer Record model
This document proposes an alternative to the KEY record chain of
trust, that uses a special record that can only reside at the parent.
This record will identify the key(s) that child will use to self sign
its own KEY set.
The chain of trust is now established by verifying the parent KEY set,
the DS set from the parent and then the KEY set at the child. This is
cryptographically equivalent to just using KEY records.
Communication between the parent and child is reduced as the parent
only needs to know of changes in DNS zone KEY(s) used to sign the apex
KEY set. If other KEY records are stored at the zone apex, the parent
does not need to be aware of them.
This approach has the advantage that it minimizes the communication
between the parent and child and the child is the authority for the
KEY set with full control over the contents. This enables each to
operate and maintain each zone independent of each other. Thus if
child wants to have frequent key rollover for its DNS keys parent does
not need to be aware of it as the child can use one key to only sign
its apex KEY set and other keys to sign the other record sets in the
zone. The child can just as well use the same key to sign all records
in its zone.
Another advantage is that this model fits well with slow rollout of
DNSSEC and islands of security model. In the islands of security model
someone that trusts "good.example." preconfigures a key from
"good.example." as a trusted keys and from then on trusts any data
that is signed by that key or has a chain of trust to that key. If
"example." starts advertising DS records "good.example." does not have
to change operations, by suspending self-signing. If DS records can
also be used to identify trusted keys instead of KEY records.
Gudmundsson Expires January 2002 [Page 3]
INTERNET-DRAFT Delegation Signer Record July 2001
The main disadvantage of this approach is double the number of
signatures that need to be verified for the each delegation KEY set.
There is no impact on verifying other record sets.
1.2 - Reserved words
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document
are to be interpreted as described in RFC2119.
2 - DS (Delegation KEY signer) record:
2.1 Protocol change
DS record MUST only appear at secure delegations in the parent zone.
The record lists the child's keys that SHOULD sign the child's key
set. Insecure delegation MUST NOT have a DS record, the presence of
DS record SHOULD be considered a hint that the child might be secure.
Resolver MUST only trust KEY records that match a DS record.
NOTE: It has been suggested that NULL DS record for insecure children
is better than no record. The advantage is to have authenticated
denial of child's security status, the drawback is for large
delegating zones there will be many NULL DS records. If parent uses
NXT records adding NXT record to the authority section in the cases
when no DS record exists at delegation will give the same result as
NULL DS record.
WG please comment on which approach is better.
Updates RFC2535 sections 2.3.4 and 3.4, as well as RFC3008 section
2.7: Delegating zones MUST NOT store KEY records for delegations. The
only records that can appear at delegation in parent are NS, SIG, NXT
and DS.
Zone MUST self sign its apex KEY set, it SHOULD sign it with a key
that corresponds to a DS record in the parent. The KEY used to sign
the apex KEY RRset CAN sign other RRsets in the zone.
If child apex KEY RRset is not signed with one of the keys specified
in the DS record the child is locally secure[RFC3090] and SHOULD only
be considered secure the resolver has been instructed to trust the key
used, via preconfiguration.
Authorative server answering a query, that has the OK bit set[OKbit],
MUST include the DS set in the additional section if the answer is a
referral and there is space. Caching servers SHOULD return the DS
record in the additional section under the same condition.
Gudmundsson Expires January 2002 [Page 4]
INTERNET-DRAFT Delegation Signer Record July 2001
2.1.1 - Comments on protocol change
Over the years there has been various discussions on that the
delegation model in DNS is broken as there is no real good way to
assert if delegation exists. In RFC2535 version of DNSSEC the
authentication of a delegation is the NS bit in the NXT bitmap at the
delegation point. Something more explicit is needed and the DS record
addresses this for secure delegations.
DS record is the first DNS record to be only stored at the upper side
of a delegation. NS records appear at both sides as do SIG and NXT.
All other records can only appear at the lower side. This will cause
some problems as servers authorative for parent may reject DS record
even if the server understands unknown types, or not hand them out
unless explicitly asked. Similarly a nameserver acting as a
authorative for child and as a caching recursive server may never
return the DS record. A caching server does not care from which side
DS record comes from and thus should not have to be changed if it
supports unknown types. Different TTL values on the childs NS set and
parents DS set may cause the DS set to expire before the NS set. In
this case an non-DS aware server would ask the child server for the DS
set and get NXDOMAIN answer. DS aware server will know to ask the
parent for the DS record.
Secure resolvers need to know about the DS record and how to interpret
it. In the worst case, introducing the DS record, doubles the
signatures that need to be checked to validate a KEY set.
Note: The working group must determine if the tradeoff between more
work in resolvers is justified by the operational simplification of
this model. The author think this is a small price to pay to have a
cleaner delegations structure. One argument put forward is that DNS
should be optimized for read when ever possible, and on the face of it
adding the DS record makes reading data from DNS more expensive. The
operational complexities and legal hurdles that KEY records in parents
or children make prevent DNSSEC to ever get deployed.
Gudmundsson Expires January 2002 [Page 5]
INTERNET-DRAFT Delegation Signer Record July 2001
2.2 Wire format of DS record
The DS record consists of algorithm, size, key tag and SHA-1 digest of
the public key KEY record allowed to sign the child's delegation.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key tag | size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | SHA-1 digest |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+
The key tag is calculated as specified in RFC2535, the size is the
size of the public key in bits as specified in the document specifying
the algorithm. Algorithm MUST be an algorithm number assigned in the
range 1..251. The SHA-1 digest is calculated over the canonical name
of the delegation followed by the RDATA of the KEY record.
The size of the DS RDATA is 25 bytes, regardless of the key size.
NOTE: if 160 bits is to large the SHA-1 digest can be shortened but
that weakens the overall security of the system.
2.2.1 Justifications for fields
The algorithm and size fields are here to allow resolvers to quickly
identify the candidate KEY records to examine. Key Tag is to allow
quick check if this is a good candidate. The key tag is redundant but
provides some greater assurance than SHA-1 digest on its own. SHA-1 is
a strong cryptographic checksum, it is hard for attacker to generate a
KEY record that has the same SHA-1 digest. Making sure that the KEY
record is a valid public key is much harder. Combining the name of the
key and the key data as input to the digest provides stronger
assurance of the binding. Combining the SHA-1 with the other fields
makes the task of the attacker is as hard breaking the public key.
Even if someone creates a database of all SHA-1 key hashes seen so
far, the addition of the name renders that database useless for
attacks against random zones.
Gudmundsson Expires January 2002 [Page 6]
INTERNET-DRAFT Delegation Signer Record July 2001
2.3 Presentation format of DS record
The presentation format of DS record consists of 2 numbers, followed
by either the name of the signature algorithm or the algorithm number.
The digest is to be presented in hex.
2.4 Justifications for compact format
This format allows concise representation of the keys that child will
use, thus keeping down the size of the answer for the delegation,
reducing the probability of packet overflow. The SHA-1 hash is strong
enough to uniquely identify the key. This is similar to the PGP
footprint.
Each DS record has RDATA size of 25, regardless of the size of the
keys, keeping the answers from the parent smaller than if public key
was used. The smallest currently defined KEY record RDATA is 70 bytes.
Compact DS format is also better suited to list trusted keys for
islands of security in configuration files.
2.5 Transition issues for installed base
RFC2535 compliant resolver will assume that all DS secured delegations
are locally secure. This is a bad thing, thus it might be necessary
for a transition period to support both DS and SIG@Child. The cost is
one more signatures in the answer and that early adopters have to
cumbersome communications that DS is supposed to solve.
Resolvers will not get confused as they will select signatures with
the KEY they trust and ignore the other one.
3 Resolver Example
To create a chain of trust resolver goes from trusted KEY to DS to
KEY.
Assume the key for domain example. is trusted. In zone "example." we
have
example. KEY <stuff>
secure.example. DS tag=12345 size=1024 alg=dsa <foofoo>
secure.example. NS ns1.secure.example.
NS ns1.secure.example. s
secure.example. NXT NS SIG NXT DS tail.example.
secure.example. SIG(NXT)
secure.example. SIG(DS)
Gudmundsson Expires January 2002 [Page 7]
INTERNET-DRAFT Delegation Signer Record July 2001
In zone "secure.example." we have
secure.example. SOA <soa stuff>
secure.example. NS ns1.secure.example.
NS ns1.secure.example.
secure.example. KEY <tag=12345 size=1024 alg=dsa>
KEY <tag=54321 size=512 alg=rsa/sha1>
KEY <tag=32145 size=1024 alg=dsa>
secure.example. SIG(KEY) <key-tag=12345 size=1024 alg=dsa>
secure.example. SIG(SOA) <key-tag=54321 size=512 alg=rsa/sha1>
secure.example. SIG(NS) <key-tag=54321 size=512 alg=rsa/sha1>
In this example the trusted key for example signs the DS record for
"secure.example.", making that a trusted record. The DS record states
what key is supposed to sign the KEY record at secure.example. In
this example "secure.example." has three different KEY records and the
one corresponding to the KEY identified in the DS record signs the KEY
set, thus the key set is validated and trusted. Note that one of the
other keys in the keyset actually signs the zone data, and resolvers
will trust the signatures as the key appears in the KEY set.
This example has only one DS record for the child but there no reason
to outlaw multiple DS records. More than one DS record is needed
during signing key rollover. It is strongly recommended that the DS
set be kept small.
3.1 Resolver cost estimates for DS records
From a RFC2535 resolver point of view for each delegation followed to
chase down an answer one KEY record has to be verified and possibly
some other records based on policy, for example the contents of the NS
set. Once the resolver gets to the appropriate delegation validating
the answer may require verifying one or more signatures. For a simple
A record lookup requires at least N delegations to be verified and 1
RRset. For a DS enabled resolver the cost is 2N+1. For MX record the
cost where the target of the MX record is in the same zone as the MX
record the costs are N+2 and 2N+2. In the case of negative answer the
same holds ratios hold true.
Resolver may require an extra query to get the DS record but and this
may add to the overall cost of the query, but this is never worse than
chasing down NULL KEY records from the parent in RFC2535 DNSSEC.
DS adds processing overhead on resolvers, increases the size of
delegation answers. DS requires much less storage in large delegation
zones than SIG@Parent.
Gudmundsson Expires January 2002 [Page 8]
INTERNET-DRAFT Delegation Signer Record July 2001
4 Acknowledgments
Number of people have over the last few years contributed number of
ideas that are captured in this document. The core idea of using one
key to that has only the role of signing a key set, comes from
discussions with Bill Manning and Perry Metzger on how to put in a
single root key in all resolver that lives for a long time. Brian
Wellington, Dan Massey, Edward Lewis, Havard Eidnes, Jakob Schlyter,
Mark Kosters, Miek Gieben, Roy Arens, Scott Rosen have provided
usefull comments.
4 - Security Considerations:
This document proposes a change to the validation chain of KEY records
in DNS. The change in is not believed to reduce security in the
overall system, in RFC2535 DNSSEC child must communicate keys to
parent and prudent parents will require some authentication on that
handshake. The modified protocol will require same authentication but
allows the child to exert more local control over its own KEY set.
In the representation of DS record, there is a possibility that an
attacker can generate an valid KEY that matches all the checks thus
starting to forge data from the child. This is considered impractical
as on average more than 2**80 keys must be generated before one is
found that will match.
DS record is a change to DNSSEC protocol and there is some installed
base of implementations, as well as text books on how to set up
secured delegations. Implementations that do not understand DS record
will not be able to follow the KEY to DS to KEY chain and consider all
zone secured that way insecure.
5 - IANA Considerations:
IANA needs to allocate RR type code for DS from the standard RR type
space.
Gudmundsson Expires January 2002 [Page 9]
INTERNET-DRAFT Delegation Signer Record July 2001
References:
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification'', STD 13, RFC 1035, November 1987.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC
2535, March 1999.
[RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing
Authority'', RFC 3008, November 2000.
[RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone
Status'', RFC 3090, March 2001.
[OKbit] D. Conrad, ``Indicating Resolver Support of DNSSEC'', work in
progress <draft-ietf-dnsext-dnssec-okbit-02.txt>, April 2001.
[Parent] R. Gieben, T. Lindgreen, ``Parent stores the child's zone
KEYs'', work in progress <draft-ietf-dnsext-parent-stores-
zones-keys-01.txt>, May 2001.
Author Address
Olafur Gudmundsson
3826 Legation Street, NW
Washington, DC, 20015
USA
<ogud@ogud.com>
Appendix A: Changes from Prior versions
Changes from version 00
Changed name from DK to DS based on working group comments.
Dropped verbose format based on WG comments.
Added text about TTL issue/problem in caching servers.
Added text about islands of security and clarified the cost impact.
Major editing of arguments and some reordering of text for clarity.
Added section on transition issues.
Gudmundsson Expires January 2002 [Page 10]
INTERNET-DRAFT Delegation Signer Record July 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Gudmundsson Expires January 2002 [Page 11]

448
doc/draft/draft-ietf-dnsext-dhcid-rr-02.txt
View File

@@ -1,448 +0,0 @@
DNSEXT Working Group M. Stapp
Internet-Draft Cisco Systems, Inc.
Expires: August 31, 2001 T. Lemon
A. Gustafsson
Nominum, Inc.
March 2, 2001
A DNS RR for Encoding DHCP Information
<draft-ietf-dnsext-dhcid-rr-02.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 August 31, 2001.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
A situation can arise where multiple DHCP clients request the same
DNS name from their (possibly distinct) DHCP servers. To resolve
such conflicts, 'Resolution of DNS Name Conflicts'[6] proposes
storing client identifiers in the DNS to unambiguously associate
domain names with the DHCP clients "owning" them. This memo defines
a distinct RR type for use by DHCP servers, the "DHCID" RR.
Stapp, et. al. Expires August 31, 2001 [Page 1]
Internet-Draft A DNS RR for Encoding DHCP Information March 2001
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. DHCID RDATA format . . . . . . . . . . . . . . . . . . . . . . 3
4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Appendix A: Base 64 Encoding . . . . . . . . . . . . . . . . . 5
References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
Stapp, et. al. Expires August 31, 2001 [Page 2]
Internet-Draft A DNS RR for Encoding DHCP Information March 2001
1. 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 RFC 2119[1].
2. Introduction
A set of procedures to allow DHCP[2] clients and servers to
automatically update the DNS (RFC1034[4], RFC1035[5]) is proposed in
"Resolution of DNS Name Conflicts"[6].
A situation can arise where multiple DHCP clients wish to use the
same DNS name. To resolve such conflicts, Resolution of DNS Name
Conflicts[6] proposes storing client identifiers in the DNS to
unambiguously associate domain names with the DHCP clients using
them. In the interest of clarity, it would be preferable for this
DHCP information to use a distinct RR type.
This memo defines a distinct RR type for this purpose for use by
DHCP clients or servers, the "DHCID" RR.
3. The DHCID RR
The DHCID RR is defined with mnemonic DHCID and type code [TBD].
4. DHCID RDATA format
The RDATA section of a DHCID RR in transmission contains RDLENGTH
bytes of binary data. The format of this data and its
interpretation by DHCP servers and clients are described below.
DNS software should consider the RDATA section to be opaque. In DNS
master files, the RDATA is represented in base 64 encoding (see
Appendix A (Section 7)) 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 signature. These
substrings can span lines using the standard parenthesis. This
format is identical to that used for representing binary data in
DNSSEC (RFC2535[7]).
DHCP clients or servers use the DHCID RR to associate a DHCP
client's identity with a DNS name, so that multiple DHCP clients and
servers may safely perform dynamic DNS updates to the same zone.
From the updater's perspective, the DHCID resource record consists
of a 16-bit identifier type, followed by one or more bytes
representing the actual identifier.
The type code can have one of three classes of values. The first
Stapp, et. al. Expires August 31, 2001 [Page 3]
Internet-Draft A DNS RR for Encoding DHCP Information March 2001
class contains just the value zero. This type indicates that the
remaining contents of the DHCID record encode an identifier that is
based on the client's link-layer network address.
The second class of types contains just the value 0xFFFF. This type
code is reserved for future extensibility.
The third class of types contains all the values not included in the
first two - that is, every value other than zero or 0xFFFF. Types in
this class indicate that the remaining contents of the DHCID record
encode an identifier that is based on the DHCP option whose code is
the same as the specified type. The most common value in this class
at the time of the writing of this draft is 61, which is the DHCP
option code[3] for the Client Identifier option.
The data following the type code (for type codes other than 0xFFFF)
is derived by running a one-way hash across the identifying
information. The details of this are specified in "Resolution of
DNS Name Conflicts"[6].
This RR MUST NOT be used for any purpose other than that detailed in
"Resolution of DNS Name Conflicts"[6]. Althought this RR contains
data that is opaque to DNS servers, the data must be consistent
across all entities that update and interpret this record.
Therefore, new data formats may only be defined through actions of
the DHC Working Group, as a result of revising [6].
4.1 Example
A DHCP server allocating the IPv4 address 10.0.0.1 to a client
"client.org.nil" might use the client's link-layer address to
identify the client:
client.org.nil. A 10.0.0.1
client.org.nil. DHCID AAAYKREXIgqtwYgQo93/yNlJ
A DHCP server allocating the IPv4 address 10.0.12.99 to a client
"chi.org.nil" might use the DHCP client identifier option to
identify the client:
chi.org.nil. A 10.0.12.99
chi.org.nil. DHCID AGGScSLaAYjdOhGMHKD/lJ2B
5. Security Considerations
The DHCID record as such does not introduce any new security
problems into the DNS. In order to avoid exposing private
information about DHCP clients to public scrutiny, a one-way-hash is
used to obscure all client information.
Stapp, et. al. Expires August 31, 2001 [Page 4]
Internet-Draft A DNS RR for Encoding DHCP Information March 2001
6. IANA Considerations
IANA is requested to allocate an RR type number for the DHCID record
type.
7. Appendix A: Base 64 Encoding
The following encoding technique is taken from RFC 2045[8] by N.
Borenstein and N. Freed. It is reproduced here in an edited form
for convenience.
A 65-character subset of US-ASCII is used, enabling 6 bits to be
represented per printable character. (The extra 65th character, "=",
is used to signify a special processing function.)
The encoding process represents 24-bit groups of input bits as
output strings of 4 encoded characters. Proceeding from left to
right, a 24-bit input group is formed by concatenating 3 8-bit input
groups. These 24 bits are then treated as 4 concatenated 6-bit
groups, each of which is translated into a single digit in the base
64 alphabet.
Each 6-bit group is used as an index into an array of 64 printable
characters. The character referenced by the index is placed in the
output string.
The Base 64 Alphabet
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
Special processing is performed if fewer than 24 bits are available
Stapp, et. al. Expires August 31, 2001 [Page 5]
Internet-Draft A DNS RR for Encoding DHCP Information March 2001
at the end of the data being encoded. A full encoding quantum is
always completed at the end of a quantity. When fewer than 24 input
bits are available in an input group, zero bits are added (on the
right) to form an integral number of 6-bit groups. Padding at the
end of the data is performed using the '=' character. Since all
base 64 input is an integral number of octets, only the following
cases can arise: (1) the final quantum of encoding input is an
integral multiple of 24 bits; here, the final unit of encoded output
will be an integral multiple of 4 characters with no "=" padding,
(2) the final quantum of encoding input is exactly 8 bits; here, the
final unit of encoded output will be two characters followed by two
"=" padding characters, or (3) the final quantum of encoding input
is exactly 16 bits; here, the final unit of encoded output will be
three characters followed by one "=" padding character.
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Mar
1997.
[3] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, Mar 1997.
[4] Mockapetris, P., "Domain names - Concepts and Facilities", RFC
1034, Nov 1987.
[5] Mockapetris, P., "Domain names - Implementation and
Specification", RFC 1035, Nov 1987.
[6] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients
(draft-ietf-dhc-dns-resolution-*)", July 2000.
[7] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
Stapp, et. al. Expires August 31, 2001 [Page 6]
Internet-Draft A DNS RR for Encoding DHCP Information March 2001
Authors' Addresses
Mark Stapp
Cisco Systems, Inc.
250 Apollo Dr.
Chelmsford, MA 01824
USA
Phone: 978.244.8498
EMail: mjs@cisco.com
Ted Lemon
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
USA
EMail: mellon@nominum.com
Andreas Gustafsson
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
USA
EMail: gson@nominum.com
Stapp, et. al. Expires August 31, 2001 [Page 7]
Internet-Draft A DNS RR for Encoding DHCP Information March 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Stapp, et. al. Expires August 31, 2001 [Page 8]

504
doc/draft/draft-ietf-dnsext-dhcid-rr-03.txt Normal file
View File

@@ -0,0 +1,504 @@
DNSEXT Working Group M. Stapp
Internet-Draft Cisco Systems, Inc.
Expires: January 18, 2002 T. Lemon
A. Gustafsson
Nominum, Inc.
July 20, 2001
A DNS RR for Encoding DHCP Information (DHCID RR)
<draft-ietf-dnsext-dhcid-rr-03.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 January 18, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
It is possible for multiple DHCP clients to attempt to update the
same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or
the clients themselves perform the DNS updates, conflicts can arise.
To resolve such conflicts, "Resolution of DNS Name Conflicts"[1]
proposes storing client identifiers in the DNS to unambiguously
associate domain names with the DHCP clients to which they refer.
This memo defines a distinct RR type for this purpose for use by
DHCP clients and servers, the "DHCID" RR.
Stapp, et. al. Expires January 18, 2002 [Page 1]
Internet-Draft The DHCID RR July 2001
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . . 3
3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . . 4
3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . . 4
3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . . 4
3.5 Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . 5
3.6 Updater Behavior . . . . . . . . . . . . . . . . . . . . . . 5
3.7 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.7.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.7.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
References . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
Full Copyright Statement . . . . . . . . . . . . . . . . . . 9
Stapp, et. al. Expires January 18, 2002 [Page 2]
Internet-Draft The DHCID RR July 2001
1. 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 RFC 2119[2].
2. Introduction
A set of procedures to allow DHCP[3] clients and servers to
automatically update the DNS (RFC1034[4], RFC1035[5]) is proposed in
"Resolution of DNS Name Conflicts"[1].
Conflicts can arise if multiple DHCP clients wish to use the same
DNS name. To resolve such conflicts, "Resolution of DNS Name
Conflicts"[1] proposes storing client identifiers in the DNS to
unambiguously associate domain names with the DHCP clients using
them. In the interest of clarity, it is preferable for this DHCP
information to use a distinct RR type. This memo defines a distinct
RR for this purpose for use by DHCP clients or servers, the "DHCID"
RR.
In order to avoid exposing potentially sensitive identifying
information, the data stored is the result of a one-way MD5[6] hash
computation. The hash includes information from the DHCP client's
REQUEST message as well as the domain name itself, so that the data
stored in the DHCID RR will be dependent on both the client
identification used in the DHCP protocol interaction and the domain
name. This means that the DHCID RDATA will vary if a single client
is associated over time with more than one name. This makes it
difficult to 'track' a client as it is associated with various
domain names.
The MD5 hash algorithm has been shown to be weaker than the SHA-1
algorithm; it could therefore be argued that SHA-1 is a better
choice. However, SHA-1 is significantly slower than MD5. A
successful attack of MD5's weakness does not reveal the original
data that was used to generate the signature, but rather provides a
new set of input data that will produce the same signature. Because
we are using the MD5 hash to conceal the original data, the fact
that an attacker could produce a different plaintext resulting in
the same MD5 output is not significant concern.
3. The DHCID RR
The DHCID RR is defined with mnemonic DHCID and type code [TBD].
3.1 DHCID RDATA format
The RDATA section of a DHCID RR in transmission contains RDLENGTH
Stapp, et. al. Expires January 18, 2002 [Page 3]
Internet-Draft The DHCID RR July 2001
bytes of binary data. The format of this data and its
interpretation by DHCP servers and clients are described below.
DNS software should consider the RDATA section to be opaque. DHCP
clients or servers use the DHCID RR to associate a DHCP client's
identity with a DNS name, so that multiple DHCP clients and servers
may deterministically perform dynamic DNS updates to the same zone.
From the updater's perspective, the DHCID resource record RDATA
consists of a 16-bit identifier type, in network byte order,
followed by one or more bytes representing the actual identifier:
< 16 bits > DHCP identifier used
< n bytes > MD5 digest
3.2 DHCID Presentation Format
In DNS master files, the RDATA is represented as a single block in
base 64 encoding and may be divided up into any number of white
space separated substrings, down to single base 64 digits, which are
concatenated to form the complete RDATA. These substrings can span
lines using the standard parentheses. This format is identical to
that used for representing binary data in RFC2535[7].
3.3 The DHCID RR Type Codes
The type code can have one of three classes of values. The first
class contains just the value zero. This type indicates that the
remaining contents of the DHCID record encode an identifier that is
based on the client's link-layer network address.
The second class of types contains just the value 0xFFFF. This type
code is reserved for future extensibility.
The third class of types contains all the values not included in the
first two - that is, every value other than zero or 0xFFFF. Types in
this class indicate that the remaining contents of the DHCID record
encode an identifier that is based on the DHCP option whose code is
the same as the specified type. The most common value in this class
at the time of the writing of this specification is 0x3d (61
decimal), which is the DHCP option code for the Client Identifier
option [8].
3.4 Computation of the RDATA
The data following the type code (for type codes other than 0xFFFF)
is derived by running the MD5 hash algorithm across a buffer
containing the identifying information. The identifying information
includes some data from the DHCP client's DHCPREQUEST message, and
the FQDN which is the target of the update.
Stapp, et. al. Expires January 18, 2002 [Page 4]
Internet-Draft The DHCID RR July 2001
The domain name is represented in the buffer in dns wire-format as
described in RFC1035[5], section 3.1. The domain name MUST NOT be
compressed as described in RFC1035[5], section 4.1.4. Any uppercase
alphabetic ASCII character in a label MUST be converted to lowercase
before being used to compute the hash.
When the updater is using the client's link-layer address as the
identifier, the first two bytes of the DHCID RDATA MUST be zero. To
generate the rest of the resource record, the updater computes a
one-way hash using the MD5 algorithm across a buffer containing the
client's network hardware type, link-layer address, and the FQDN
data. Specifically, the first byte of the buffer contains the
network hardware type as it appeared in the DHCP 'htype' field of
the client's DHCPREQUEST message. All of the significant bytes of
the chaddr field in the client's DHCPREQUEST message follow, in the
same order in which the bytes appear in the DHCPREQUEST message. The
number of significant bytes in the 'chaddr' field is specified in
the 'hlen' field of the DHCPREQUEST message. The FQDN data, as
specified above, follows.
When the updater is using a DHCP option sent by the client in its
DHCPREQUEST message, the first two bytes of the DHCID RR MUST be the
option code of that option, in network byte order. For example, if
the DHCP client identifier option is being used, the first byte of
the DHCID RR should be zero, and the second byte should be 61
decimal. The rest of the DHCID RR MUST contain the results of
computing an MD5 hash across the payload of the option being used,
followed by the FQDN. The payload of a DHCP option consists of the
bytes of the option following the option code and length.
The "Resolution of DNS Name Conflicts"[1] specification describes
the selection process that updaters follow to choose an identifier
from the information presented in a client's DHCPREQUEST message.
3.5 Use of the DHCID RR
This RR MUST NOT be used for any purpose other than that detailed in
"Resolution of DNS Name Conflicts"[1]. Although this RR contains
data that is opaque to DNS servers, the data must be consistent
across all entities that update and interpret this record.
Therefore, new data formats may only be defined through actions of
the DHC Working Group, as a result of revising [1].
3.6 Updater Behavior
The data in the DHCID RR allows updaters to determine whether more
than one DHCP client desires to use a particular FQDN. This allows
site administrators to establish policy about DNS updates. The DHCID
RR does not establish any policy itself.
Stapp, et. al. Expires January 18, 2002 [Page 5]
Internet-Draft The DHCID RR July 2001
Updaters use data from a DHCP client's request and the domain name
that the client desires to use to compute a client identity hash,
and then compare that hash to the data in any DHCID RRs on the name
that they wish to associate with the client's IP address. If an
updater discovers DHCID RRs whose RDATA does not match the client
identity that they have computed, the updater SHOULD conclude that a
different client is currently associated with the name in question.
The updater SHOULD then proceed according to the site's
administrative policy. That policy might dictate that a different
name be selected, or it might permit the updater to continue.
3.7 Examples
3.7.1 Example 1
A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
Ethernet MAC address 01:02:03:04:05:06 using domain name
"client.org.nil" uses the client's link-layer address to identify
the client. The DHCID RDATA is composed by setting the two type
bytes to zero, and performing an MD5 hash computation across a
buffer containing the Ethernet MAC type byte, 0x01, the six bytes of
MAC address, and the domain name (represented as specified in
Section 3.4).
client.org.nil. A 10.0.0.1
client.org.nil. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU
3.7.2 Example 2
A DHCP server allocates the IPv4 address 10.0.12.99 to a client
which included the DHCP client-identifier option data
01:07:08:09:0a:0b:0c in its DHCP request. The server updates the
name "chi.org.nil" on the client's behalf, and uses the DHCP client
identifier option data as input in forming a DHCID RR. The DHCID
RDATA is formed by setting the two type bytes to the option code,
0x003d, and performing an MD5 hash computation across a buffer
containing the seven bytes from the client-id option and the FQDN
(represented as specified in Section 3.4).
chi.org.nil. A 10.0.12.99
chi.org.nil. DHCID AD3dquu0xNqYn/4zw2FXy8X3
4. Security Considerations
The DHCID record as such does not introduce any new security
problems into the DNS. In order to avoid exposing private
information about DHCP clients to public scrutiny, a one-way hash is
used to obscure all client information. In order to make it
difficult to 'track' a client by examining the names associated with
Stapp, et. al. Expires January 18, 2002 [Page 6]
Internet-Draft The DHCID RR July 2001
a particular hash value, the FQDN is included in the hash
computation. Thus, the RDATA is dependent on both the DHCP client
identification data and on each FQDN associated with the client.
Administrators should be wary of permitting unsecured DNS updates to
zones which are exposed to the global Internet. Both DHCP clients
and servers SHOULD use some form of update authentication (e.g.,
TSIG[9]) when performing DNS updates.
5. IANA Considerations
IANA is requested to allocate an RR type number for the DHCID record
type.
References
[1] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients
(draft-ietf-dhc-dns-resolution-*)", March 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Mar
1997.
[4] Mockapetris, P., "Domain names - Concepts and Facilities", RFC
1034, Nov 1987.
[5] Mockapetris, P., "Domain names - Implementation and
Specification", RFC 1035, Nov 1987.
[6] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April
1992.
[7] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[8] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, Mar 1997.
[9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
Stapp, et. al. Expires January 18, 2002 [Page 7]
Internet-Draft The DHCID RR July 2001
Authors' Addresses
Mark Stapp
Cisco Systems, Inc.
250 Apollo Dr.
Chelmsford, MA 01824
USA
Phone: 978.244.8498
EMail: mjs@cisco.com
Ted Lemon
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
USA
EMail: mellon@nominum.com
Andreas Gustafsson
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
USA
EMail: gson@nominum.com
Stapp, et. al. Expires January 18, 2002 [Page 8]
Internet-Draft The DHCID RR July 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Stapp, et. al. Expires January 18, 2002 [Page 9]

112
doc/draft/draft-ietf-dnsext-unknown-rrs-00.txt → doc/draft/draft-ietf-dnsext-unknown-rrs-01.txt
View File

@@ -1,6 +1,6 @@
INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsext-unknown-rrs-00.txt Nominum Inc.
November 2000
draft-ietf-dnsext-unknown-rrs-01.txt Nominum Inc.
July 2001
Handling of Unknown DNS RR Types
@@ -49,9 +49,9 @@ Abstract
Expires May 2001 [Page 1]
Expires January 2002 [Page 1]
draft-ietf-dnsext-unknown-rrs-00.txt November 2000
draft-ietf-dnsext-unknown-rrs-01.txt July 2001
fully realized. This memo proposes changes to name servers and to
@@ -67,12 +67,16 @@ draft-ietf-dnsext-unknown-rrs-00.txt November 2000
In this document, a "well known" RR type means one defined in
RFC1035.
An "RR of unknown type" is an RR type whose RDATA format is not known
to the DNS implementation at hand, and which therefore cannot be
converted to a type-specific text format, compressed, or otherwise
handled in any type-specific way. This includes the case where the
RR's type is recognized but its RDATA format is class specific and
the RR is of a class for which the format is not known.
An "RR of unknown type" is an RR whose RDATA format is not known to
the DNS implementation at hand, such that it cannot be converted to a
type-specific text format, compressed, or otherwise handled in a
type-specific way, and whose type is not an assigned QTYPE or Meta-
TYPE in RFC2929 section 3.1 nor within the range reserved in that
section for assignment only to QTYPEs and Meta-TYPEs.
In the case of a type whose RDATA format is class specific, an RR is
considered to be of unknown type when the RDATA format for that
combination of type and class is not known.
3. Transparency
@@ -98,18 +102,18 @@ draft-ietf-dnsext-unknown-rrs-00.txt November 2000
type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
NXT, NAPTR, and SRV (although the SRV RR is clearly defined to not
allow compression of the target field, some existing name servers
Expires January 2002 [Page 2]
draft-ietf-dnsext-unknown-rrs-01.txt July 2001
compress it anyway).
Future specifications for new RR types that contain domain names
within their RDATA MUST NOT allow the use of name compression for
Expires May 2001 [Page 2]
draft-ietf-dnsext-unknown-rrs-00.txt November 2000
those names, and SHOULD explicitly state that the embedded domain
names MUST NOT be compressed.
@@ -154,18 +158,18 @@ draft-ietf-dnsext-unknown-rrs-00.txt November 2000
effectively treated as an unknown type for the purpose of parsing the
RDATA text representation, all further processing by the server MUST
treat it as a known type and take into account any applicable type-
Expires January 2002 [Page 3]
draft-ietf-dnsext-unknown-rrs-01.txt July 2001
specific rules regarding compression, canonicalization, etc.
The following are examples of RRs represented in this manner,
illustrating various combinations of generic and type-specific
Expires May 2001 [Page 3]
draft-ietf-dnsext-unknown-rrs-00.txt November 2000
encodings for the different fields of the master file format:
a.example. CLASS32 TYPE731 \# 6 abcd (
@@ -198,7 +202,7 @@ draft-ietf-dnsext-unknown-rrs-00.txt November 2000
the canonical form, domain names embedded in the RDATA are converted
to lower case.
To ensure backwards compatilbility, this canonical form remains
To ensure backwards compatibility, this canonical form remains
unchanged for any RR types defined in RFC2931 or earlier. That is,
the domain names embedded in RRs of type NS, MD, MF, CNAME, SOA, MB,
MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT,
@@ -211,29 +215,28 @@ draft-ietf-dnsext-unknown-rrs-00.txt November 2000
the octet sequence is the canonical form as revised by this
specification.
Expires January 2002 [Page 4]
draft-ietf-dnsext-unknown-rrs-01.txt July 2001
8. Additional Section Processing
Unknown RR types cause no additional section processing. Future RR
Expires May 2001 [Page 4]
draft-ietf-dnsext-unknown-rrs-00.txt November 2000
type specifications MAY specify type-specific additional section
processing rules, but any such processing MUST be optional as it can
only be performed by servers for which the RR type in case is known.
9. IANA Considerations
9. IANA Considerations
The IANA is hereby requested to verify that specifications for new RR
types requesting an RR type number comply with this specification.
In particular, the IANA MUST NOT assign numbers to RR types whose
In particular, the IANA MUST NOT assign numbers to new RR types whose
specification allows embedded domain names to be compressed.
10. Security Considerations
10. Security Considerations
This specification is not believed to cause any new security
problems, nor to solve any existing ones.
@@ -250,11 +253,14 @@ References
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE). P.
Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997.
Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997.
[RFC2535] Domain Name System Security Extensions. D. Eastlake. March
[RFC2535] Domain Name System Security Extensions. D. Eastlake, March
1999.
[RFC2929] Domain Name System (DNS) IANA Considerations. D. Eastlake,
E. Brunner-Williams, B. Manning, September 2000.
Author's Address
Andreas Gustafsson
@@ -263,22 +269,21 @@ Author's Address
Redwood City, CA 94063
USA
Phone: +1 650 779 6004
Phone: +1 650 381 6004
Expires January 2002 [Page 5]
draft-ietf-dnsext-unknown-rrs-01.txt July 2001
Email: Andreas.Gustafsson@nominum.com
Full Copyright Statement
Expires May 2001 [Page 5]
draft-ietf-dnsext-unknown-rrs-00.txt November 2000
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
@@ -324,10 +329,5 @@ draft-ietf-dnsext-unknown-rrs-00.txt November 2000
Expires May 2001 [Page 6]
Expires January 2002 [Page 6]

110
doc/draft/draft-ietf-dnsop-inaddr-required-01.txt → doc/draft/draft-ietf-dnsop-inaddr-required-02.txt
View File

@@ -1,9 +1,17 @@
INTERNET-DRAFT D. Senie
Category: BCP Amaranth Networks Inc.
Expires in six months February 2001
Expires in six months July 2001
Requiring DNS IN-ADDR Mapping
draft-ietf-dnsop-inaddr-required-01.txt
draft-ietf-dnsop-inaddr-required-02.txt.
Status of this Memo
@@ -26,8 +34,12 @@ 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."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
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.
Copyright Notice
@@ -56,7 +68,7 @@ Senie [Page 1]
Internet-Draft Requiring DNS IN-ADDR Mapping February 2001
Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
From the early days of the Domain Name Service [RFC 883] a special
@@ -116,7 +128,7 @@ Senie [Page 2]
Internet-Draft Requiring DNS IN-ADDR Mapping February 2001
Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
export of that software is prohibited to some locales. Credit card
@@ -137,7 +149,7 @@ Internet-Draft Requiring DNS IN-ADDR Mapping February 2001
Many web servers look up the IN-ADDR of visitors to be used in log
analysis. This adds to the server load, but in the case of IN-ADDR
unavailability, it can lead to delayed web page accesses for users.
unavailability, it can lead to delayed responses for users.
Traceroutes with descriptive IN-ADDR naming proves useful when
debugging problems spanning large areas. When this information is
@@ -146,27 +158,27 @@ Internet-Draft Requiring DNS IN-ADDR Mapping February 2001
4. Requirements
Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
of IN-ADDR, sometimes in conjunction with a lookup of the name
resulting from the PTR record adds no real security, can lead to
erroneous results and generally just increases load on DNS servers.
Further, in cases where address block holders fail to properly
configure IN-ADDR, users of those blocks are penalized.
All IP address space which is assigned and in use SHOULD be resolved
by IN-ADDR records. 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.
by IN-ADDR records. All PTR records MUST use canonical names.
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
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
address, and must therefore have an IN-ADDR mapping.
Regional Registries and any Local Registries to whom they delegate
SHOULD establish and convey a policy to those to whom they delegate
blocks that IN-ADDR mappings are required. Internet providers and end
@@ -176,15 +188,23 @@ Senie [Page 3]
Internet-Draft Requiring DNS IN-ADDR Mapping February 2001
Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
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
address, and must therefore have an IN-ADDR mapping.
Regional Registries and any Local Registries to whom they delegate
SHOULD establish and convey a policy to those to whom they delegate
blocks that IN-ADDR mappings are required. Internet providers and end
users with address blocks must verify their own internal networks are
properly represented in IN-ADDR records, either by providing that
service themselves, or delegating it to others.
Those to whom blocks have been delegated SHOULD convey a policy to
degegatees requiring that they too provide IN-ADDR records and
delegatees requiring that they too provide IN-ADDR records and
require and delegations below to do the same. ISPs may wish to
provide IN-ADDR records for their clients if the customers are unable
to provide this for themselves.
@@ -196,6 +216,11 @@ Internet-Draft Requiring DNS IN-ADDR Mapping February 2001
anonimity, 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
mechanism this document points out that this practice, despite its
use by many applications, is an ineffective form of security.
Applications should use better mechanisms of authentication.
6. References
[RFC883] P.V. Mockapetris, "Domain names: Implementation
@@ -214,6 +239,18 @@ Internet-Draft Requiring DNS IN-ADDR Mapping February 2001
[RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
Guidelines", RFC2050, BCP 12, Novebmer 1996.
Senie [Page 4]
Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
[ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
unknown, http://www.arin.net/regserv/initial-isp.html
@@ -227,18 +264,6 @@ Internet-Draft Requiring DNS IN-ADDR Mapping February 2001
7. Acknowledgements
Senie [Page 4]
Internet-Draft Requiring DNS IN-ADDR Mapping February 2001
Thanks to Peter Koch and Gary Miller for their input, and to many
people who encouraged me to write this document.
@@ -269,19 +294,6 @@ Internet-Draft Requiring DNS IN-ADDR Mapping February 2001
@@ -291,3 +303,5 @@ Internet-Draft Requiring DNS IN-ADDR Mapping February 2001
Senie [Page 5]

90
doc/draft/draft-ietf-idn-idna-02.txt → doc/draft/draft-ietf-idn-idna-03.txt
View File

@@ -1,6 +1,6 @@
Internet Draft Patrik Faltstrom
draft-ietf-idn-idna-02.txt Cisco
June 16, 2001 Paul Hoffman
draft-ietf-idn-idna-03.txt Cisco
July 20, 2001 Paul Hoffman
Expires in six months IMC & VPNC
Internationalizing Host Names In Applications (IDNA)
@@ -148,14 +148,14 @@ An IDNA-aware application can accept and display internationalized host
names in two formats: the internationalized character set(s) supported
by the application, and in an ACE. Applications MAY allow ACE input and
output, but are not encouraged to do so except as an interface for
advanced users, possibly for debugging. ACE encoding is opaque and ugly,
and should thus only be exposed to users who absolutely need it. The
optional use, especially during a transition period, of ACE encodings in
the user interface is described in section 3. Since ACE can be rendered
either as the encoded ASCII glyphs or the proper decoded character
glyphs, the rendering engine for an application SHOULD have an option
for the user to select the preferred display; if it does, rendering the
ACE SHOULD NOT be the default.
special purposes, possibly for debugging. ACE encoding is opaque and
ugly, and should thus only be exposed to users who absolutely need it.
The optional use, especially during a transition period, of ACE
encodings in the user interface is described in section 3. Because name
parts encoded with ACE can be rendered either as the encoded ASCII
characters or the proper decoded characters, the application MAY have an
option for the user to select the preferred method of display; if it
does, rendering the ACE SHOULD NOT be the default.
Host names are often stored and transported in many places. For example,
they are part of documents such as mail messages and web pages. They are
@@ -165,9 +165,13 @@ and the body content in HTTP.
In protocols and document formats that define how to handle
specification or negotiation of charsets, IDN host name parts can be
given in any charset allowed by the protocol or document format. If a
encoded in any charset allowed by the protocol or document format. If a
protocol or document format only allows one charset, IDN host name parts
must be given in that charset.
must be given in that charset. In any place where a protocol or document
format allows transmition of the characters in IDN host name parts, IDN
host name parts SHOULD be transmitted using whatever character encoding
and escape mechanism that the protocol or document format uses at that
place.
All protocols that have host names as protocol elements already have the
capacity for handling host names in the ASCII charset. Thus, IDN host
@@ -190,7 +194,7 @@ name parts encoded in ACE from the resolver.
IDNA-aware applications MUST be able to work with both
non-internationalized host name parts (those that conform to [STD13] and
[STD3]) and internationalized host name parts. An IDNA-aware application
that is resolving a non-internationalized host name parts MUST NOT do
that is resolving a non-internationalized host name part MUST NOT do
any preparation or conversion to ACE on any non-internationalized name
part.
@@ -227,11 +231,19 @@ characters in the decoded name, such as if the name contains characters
that the output system cannot display, the application SHOULD show the
name in ACE format instead of displaying the name with the replacement
character (U+FFFD). This is to make it easier for the user to transfer
the name correctly to other programs using copy-and-paste techniques.
Programs that by default show the ACE form when they cannot show all the
characters in a name part SHOULD also have a mechanism to show the name
with as many characters as possible and replacement characters in the
positions where characters cannot be displayed.
the name correctly to other programs. Programs that by default show the
ACE form when they cannot show all the characters in a name part SHOULD
also have a mechanism to show the name with as many characters as
possible and replacement characters in the positions where characters
cannot be displayed. In many cases, the application doesn't know exactly
what the underlying rendering engine can or cannot display.
In addition to the condition above, if an application decodes an ACE
name but finds that the decoded name was not properly prepared according
to [NAMEPREP] (for example, if it has illegal characters in it), the
application SHOULD show the name in ACE format and SHOULD NOT display
the name in its decoded form. This is to avoid security issues described
in [NAMEPREP].
2.1.5 Automatic detection of ACE
@@ -240,7 +252,7 @@ the host name is in ACE. This is possible by verifying the prefix in
each of the labels, and seeing whether or not the label is in ACE. This
MUST be done regardless of whether or not the communication channel used
(such as keyboard input, cut and paste, application protocol,
application payload, and so on) has negotiated ACE.
application payload, and so on) is encoding with ACE.
The reason for this requirement is that many applications are not
ACE-aware. Applications that are not ACE-aware will send host names in
@@ -249,14 +261,11 @@ has the characters that are valid in [STD13] as a subset.
2.1.6 Bidirectional text
In IDNA, bidirectional text is entered and displayed exactly as it is
specified in ISO/IEC 10646. Both ISO/IEC 10646 and the Unicode standard
have extensive discussion of how to deal with bidirectional text. Any
input mechanism and display mechanism that handles characters from
bidirectional scripts should already conform to those specifications.
Note that the formatting characters that manually change the direction
of display are prohibited by nameprep, thus making the task for input
and display mechanisms easier.
In IDNA, text storage and display follows the rules in the Unicode standard
[Unicode3.1]. In particular, all Unicode text is stored in logical order;
the Unicode standard has an extensive discussion of how to deal with reorder
glyphs for display when dealing with bidirectional text such as Arabic or
Hebrew. See [UAX9] for more information.
3. Name Server Considerations
@@ -329,24 +338,30 @@ and Support" (RFC 1123), STD 3, October 1989.
1034) and "Domain names - implementation and specification" (RFC 1035,
STD 13, November 1987.
[UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm.
http://www.unicode.org/unicode/reports/tr9/
B. Changes from the -01 draft
[Unicode3.1] The Unicode Standard, Version 3.1.0: The Unicode
Consortium. The Unicode Standard, Version 3.0. Reading, MA,
Addison-Wesley Developers Press, 2000. ISBN 0-201-61633-5, as amended
by: Unicode Standard Annex #27: Unicode 3.1
<http://www.unicode.org/unicode/reports/tr27/tr27-4.html>.
1.1: Revised whole section to deal with more proposals.
2.1: Clarified the ASCII art
2.1.1: Changed the section title. Added the last three paragraphs.
B. Changes from the -02 draft
2.1.4: Added the second paragraph.
Editorial changes throughout
2.1.6: Added this section.
2.1.1: Major changes to the second paragraph. Added major text to fourth
paragraph.
2.1.5: Added this section.
2.1.4: Added to the end of the second paragraph. Added the third
paragraph.
3: Added note in the last sentence of second paragraph.
2.1.6: Complete change.
5: Added second and third paragraphs.
6: Added [Unicode3.1] and [UAX9].
C. Authors' Addresses
@@ -354,8 +369,7 @@ C. Authors' Addresses
Patrik Faltstrom
Cisco Systems
Arstaangsvagen 31 J
S-117 43 Stockholm
Sweden
S-117 43 Stockholm Sweden
paf@cisco.com
Paul Hoffman

494
doc/draft/draft-ietf-ipngwg-default-addr-select-04.txt → doc/draft/draft-ietf-ipngwg-default-addr-select-05.txt
View File

File diff suppressed because it is too large Load Diff