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

added drafts

Browse Source
This commit is contained in:
Andreas Gustafsson
2001-06-14 16:43:02 +00:00
parent 1d9ab72131
commit bb7babe2ae
3 changed files with 2219 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

709
doc/draft/draft-ietf-dnsext-aaaa-a6-00.txt Normal file
View File

@@ -0,0 +1,709 @@
Internet Engineering Task Force Jun-ichiro itojun Hagino
INTERNET-DRAFT IIJ Research Laboratory
Expires: November 27, 2001 May 27, 2001
Comparison of AAAA and A6 (do we really need A6?)
draft-ietf-dnsext-aaaa-a6-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
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.
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
deprecated.
The draft tries to understand pros and cons between these two record
types, and makes suggestions on deployment of IPv6 record type.
The draft does not cover the use of bit string label and DNAME resource
record (reverse mapping), as it seems that nibble form is well accepted
in the community, newer formats have too much deployment costs, thus we
see few need/voice that calls for migration. Refer to IETF50 dnsext
working group minutes for more details.
HAGINO Expires: November 27, 2001 [Page 1]
DRAFT Comparison of AAAA and A6 May 2001
1. A brief summary of the IPv6 resource record types
1.1. AAAA record
AAAA resource record is formatted as follows. DNS record type value for
AAAA is 28 (assigned by IANA). Note that AAAA record is formatted as a
fixed-length data.
+------------+
|IPv6 Address|
| (16 octets)|
+------------+
With AAAA, we can define DNS records for IPv6 address resolution as
follows, just like A records for IPv4.
$ORIGIN X.EXAMPLE.
N AAAA 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
N AAAA 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
N AAAA 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
1.2. A6 record
A6 resource record is formatted as follows. DNS record type value for
A6 is 38 (assigned by IANA). Note that A6 record is formatted as a
variable-length data.
+-----------+------------------+-------------------+
|Prefix len.| Address suffix | Prefix name |
| (1 octet) | (0..16 octets) | (0..255 octets) |
+-----------+------------------+-------------------+
With A6, it is possible to define an IPv6 address by using multiple DNS
records. Here is an example taken from RFC2874:
HAGINO Expires: November 27, 2001 [Page 2]
DRAFT Comparison of AAAA and A6 May 2001
$ORIGIN X.EXAMPLE.
N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
SUBNET-1.IP6 A6 48 0:0:0:1:: IP6
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.
SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG.
C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
If we translate the above into AAAA records, it will be as follows:
$ORIGIN X.EXAMPLE.
N AAAA 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
N AAAA 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
N AAAA 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
It is also possible to use A6 records in ``non-fragmented'' manner, like
below.
$ORIGIN X.EXAMPLE.
N A6 0 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
N A6 0 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
N A6 0 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
There is a large design difference between A6 and AAAA. A6 imposes
address resolutions tasks more to the resolver side, to reduce the
amount of zone file maintenance cost. The complexity is in the resolver
side. AAAA asks zone file maintainers to supply the full 128bit IPv6
address in one record, and the resolver side can be implemented very
simple.
2. Deployment status
2.1. Name servers/resolvers
As of writing, AAAA is deployed pretty widely. BIND4 (since 4.9.4),
BIND8, BIND9 and other implementations support AAAA, as both DNS servers
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]
DRAFT Comparison of AAAA and A6 May 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).
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.
2.3. DNS database
There are no IPv6-reachable root DNS servers, partly because we have
both AAAA and A6, and we are not decided about which is the one we would
like to really deploy (so we cannot put IPv6 root NS records). The lack
of IPv6-reachable root DNS servers is now preventing IPv6-only or
IPv4/v6 dual stack network operations.
At this moment, very small number of ccTLD registries accept
registeration requests for IPv6 glue records. Many of the ccTLDs and
gTLDs do not take IPv6 glue records, partly because of the lack of
consensus between AAAA and A6. Again, the lack of IPv6 glue records is
causing pain in IPv6-ready network operations. For example, JP ccTLD
accepts IPv6 glue records and registers them as AAAA records. IPv6 NS
records (with AAAA) works flawlessly from our experiences. For example,
try the following commands to see how JP ccTLD registers IPv6 glue
records (``/e'' is for English-language output):
% whois -h whois.nic.ad.jp wide.ad.jp/e
% whois -h whois.nic.ad.jp ns1.v6.wide.ad.jp/e
3. Deploying DNS records
At this moment, the following four strategies are proposed for the
deployment of IPv6 DNS resource record; AAAA, fragmented A6 records,
non-fragmented A6 records, and AAAA synthesis.
3.1. AAAA records
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-
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]
DRAFT Comparison of AAAA and A6 May 2001
section.
3.2. Fragmented A6 records
If we are to use fragmented A6s (128bit splitted into multiple A6s), we
have a lot of issues/worries.
If we are to resolve IPv6 addresses using fragmented A6 records, we need
to query DNS multiple times to resolve a single DNS name into an IPv6
address. Since there has been no DNS record types that require multiple
queries for resolution of the address itself, we have very little
experience on such resource records.
There will be more delays in name resolution compared to queries to
A/AAAA records. If we define a record with more number of fragments,
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]
; 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::
Some says that caches will avoid querying fragmented A6s again and
again. However, most of the library resolver implementations do not
cache anything. The traffic between library resolver and the first-hop
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]
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.
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
IPv6 address itself (total time needed for reassembly) and (3) TTL
timeout for A6 fragment records.
o In the case of library resolver implementation, it is harder to deal
with exceptions (signals in UNIX case) for the large code fragment for
resolvers.
o When A6 prefix length field is not multiple of 8, address suffix
portion needs to be shifted bitwise while A6 fragments are
reassembled. Also, resolver implementations must be careful about
overwraps of the bits. From our implementatation experiences, the
logic gets very complex and we (unfortunately) expect to see a lot of
security-critical bugs in the future.
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]
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
specific set of records, like for load distribution purposes. Consider
the following example. Even if we would like to advertise only
2345:00D2:DA11:1:1234:5678:9ABC:DEF0 for N.X.EXAMPLE, it is not possible
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.
; with the following record we would advertise both records
$ORIGIN X.EXAMPLE.
N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
M A6 64 ::2345:2345:2345:2345 SUBNET-1.IP6
SUBNET-1.IP6 A6 0 2345:00C1:CA11:1::
A6 0 2345:00D2:DA11:1::
; we need to do the following, jeopardizing renumbering
; friendliness for N.X.EXAMPLE
$ORIGIN X.EXAMPLE.
N A6 0 2345:00C1:CA11:1:1234:5678:9ABC:DEF0
M A6 64 ::2345:2345:2345:2345 SUBNET-1.IP6
SUBNET-1.IP6 A6 0 2345:00C1:CA11:1::
A6 0 2345:00D2:DA11:1::
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.
3.3. Non-fragmented A6 records
There are proposals to use non-fragmented A6 records in most of the
places, like ``A6 0 <128bit>'', so that we would be able to switch to
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.
If the nameserver/resolver programs hardcode A6 processing to handle no
fragments, there will be no future possibility for us to introduce
fragmented A6 records. When there is no need for A6 reassembly, there
will be no code deployment, and even if the reassembly code gets
deployed they will not be tested enough. The author believes that the
``prepare for the future, use non-fragmented A6'' argument is not
worthwhile.
In the event of renumbering, non-fragmented A6 record has the same
property as AAAA (the whole zone file has to be updated).
3.4. AAAA synthesis (A6 and AAAA hybrid approach)
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'':
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.
The approach needs to be diagnosed/specified in far more detail. For
example, the following questions need to be answered:
o What is the DNS error code against AAAA querier, if the A6 reassembly
fails?
o What TTL should the synthesized AAAA record have? [BIND 9.2.0snap
uses TTL=0]
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?
o What if the resolver wants no synthesis? Do we want to have a flag
bit in DNS packet, to enable/disable AAAA synthesis?
o Relationships between A6 TTL, AAAA TTL, A6 query timeouts, AAAA query
timeouts, and other timeout parameters?
The approach seems to be vulnerable against DoS attacks, because the
nameserver reassembles A6 fragments on behalf of the AAAA querier. See
security consideration section for more details.
3.5. Issues in keeping both AAAA and A6
If we are to keep both AAAA and A6 records onto the worldwide DNS
database, it would impose more query delays to the client resolvers.
Suppose we have a dual-stack host implementation. If they need to
resolve a name into addresses, the node would need to query in the
following order (in the order which RFC2874 suggests):
o Query A6 records, and get full IPv6 addresses by chasing and
reassembling A6 fragment chain.
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] .
o Contact the destination addresses in sequence.
The ordering imposes additional delays to the resolvers. The above
ordering would be necessary for all approaches that use A6, as there are
existing AAAA records in the world.
4. Network renumbering
Some says that there will be more frequent renumbers in IPv6 network
operation, and A6 is necessary to reduce the zone modification cost as
well as zone signing costs on renumber operation.
It is not clear if we really want to renumber that frequently. With
IPv6, it should be easier for ISPs to assign addresses statically to the
downstream customers, rather than dynamically like we do in IPv4 dialup
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.
It is questionable if it is possible to renumber IPv6 networks more
frequently than with IPv4. Router renumbering protocol [Crawford, 2000]
, IPv6 host autoconfiguration and IPv6 address lifetime [Thomson, 1998]
can help us renumber the IPv6 network, however, network renumbering
itself is not an easy task. If you would like to maintain reachability
from the outside world, a site administrator needs to carefully
coordinate site renumber. The minimal interval between renumber is
restricted by DNS record timeouts, as DNS records will be cached around
the world. If the TTL of DNS records are X, the interval between
renumber must be longer than 2 * X. If we consider clients/servers that
tries to validate addresses using reverse lookups, we also need to care
about the relationship between IPv6 address lifetime [Thomson, 1998] and
the interval between renumber. At IETF50 ipngwg session, there was a
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
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.
A6 was designed to help administators update zone files during network
renumbering events. Even with AAAA, zone file modification itself is
easy; you can just query-replace the addresses in the zone files. The
difficulty of network renumber comes from elsewhere.
With AAAA, we need to sign the whole zone again with DNSSEC keys, after
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.
5. Security consideration
There are a couple of security worries mentioned in the above. To give
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
defining an IPv6 address. Malicious parties may try to put a very
complex A6 chains and confuse nameservers worldwide.
o A6 resolver/nameserver is much harder to implement correctly than AAAA
resolver/nameserver. A6 fragment reassembly code needs to take care
of bitwise data reassembly, bitwise overwrap checks, and others. From
our implementatation experiences, we expect to see a lot of security-
issue bugs in the future.
o Interaction between DNS record TTL and the DNS query delays leads to
non-trivial timeout problem.
We would like to go into more details for some of these.
5.1. DoS attacks against AAAA synthesis
When a DNS server is configured for AAAA synthesis, malicious parties
can impose DoS attacks using the interaction between DNS TTL and query
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
nameservers that serve A6 fragments.
o Bad guy queries the record using AAAA request, to the victim
nameserver.
o The victim nameserver will try to reassemble A6 fragments. During the
reassembly process, the victim nameserver puts A6 fragments into the
local cache. The cached records will expire during the reassembly
process. The nameserver will need to query a lot of A6 fragments
(more traffic). The server can go into an infinite loop, if it tries
to query the expired A6 fragments again.
To remedy this problem, we have a couple of solutions:
(1) Deprecate A6 and deploy AAAA worldwide. If we do not have A6, the
problem goes away.
(2) Even if we use A6, do not configure nameservers for AAAA synthesis.
Deployment issues with existing IPv6 hosts get much harder.
(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.
6. Conclusion
NOTE: the section expresses the impressions of the author.
A6/AAAA discussion has been an obstacle for IPv6 deployment, as the
deployment of IPv6 NS recodrs have been deferred because of the
discussion. The author do not see benefit in keeping both AAAA and A6
records, as it imposes more query delays to the clients. So the author
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
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.
References
Thomson, 1995.
S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.txt.
Crawford, 2000.
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.
Hagino, 2000.
Jun-ichiro Hagino and Kazu Yamamoto, "Requirements for IPv6 dialup PPP
operation" in draft-itojun-ipv6-dialup-requirement-00.txt (July 2000).
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.
S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration" in
RFC2462 (December 1998). ftp://ftp.isi.edu/in-notes/rfc2462.txt.
Change history
none.
Acknowledgements
The draft was written based on discussions in IETF IPv6 and dnsext
working groups, and help from WIDE research group.
Author's address
Jun-ichiro itojun HAGINO
Research Laboratory, Internet Initiative Japan Inc.
Takebashi Yasuda Bldg.,
3-13 Kanda Nishiki-cho,
Chiyoda-ku,Tokyo 101-0054, JAPAN
Tel: +81-3-5259-6350
Fax: +81-3-5259-6351
Email: itojun@iijlab.net
HAGINO Expires: November 27, 2001 [Page 12]

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

@@ -0,0 +1,557 @@
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]

953
doc/draft/draft-ietf-dnsext-not-existing-rr-01.txt Normal file
View File

@@ -0,0 +1,953 @@
Network Working Group S. Josefsson
Internet-Draft RSA Security
Expires: May 25, 2001 November 24, 2000
Authenticating denial of existence in DNS with minimum disclosure
(or; An alternative to DNSSEC NXT records)
draft-ietf-dnsext-not-existing-rr-01
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 25, 2001.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This draft present an alternative to NXT records, used to achieve
authenticated denial of existence of a domain name, class and type.
Problems with NXT records, as specified in RFC 2535, are identified.
One solution, the NO record, is presented.
The NO record differ from the NXT record by using a cryptographic
hash value instead of the domain name. This prevent an adversery
from collecting information by "chaining" through a zone. It also
remove delegation point concerns that was a side effect of NXT
records. The document also describe hash truncation and record
merging that reduces storage/network load.
Josefsson Expires May 25, 2001 [Page 1]
Internet-Draft The NO Record November 2000
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Context . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The NO Resource Record . . . . . . . . . . . . . . . . . . 4
3.1 Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 NO RDATA Format . . . . . . . . . . . . . . . . . . . . . 4
3.3 NO RDATA on-the-wire format example . . . . . . . . . . . 6
3.4 Owner Names . . . . . . . . . . . . . . . . . . . . . . . 6
3.5 Additional Complexity Due To Wildcards . . . . . . . . . . 7
3.6 No Considerations at Delegation Points . . . . . . . . . . 7
3.7 Hash Truncation and Dynamic Updates . . . . . . . . . . . 8
3.8 Reducing Number of Records . . . . . . . . . . . . . . . . 9
3.9 Hash Collisions . . . . . . . . . . . . . . . . . . . . . 9
3.10 Authenticating Denial of NO Records . . . . . . . . . . . 9
3.11 Case Considerations . . . . . . . . . . . . . . . . . . . 10
3.12 Presentation Format . . . . . . . . . . . . . . . . . . . 10
3.13 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.13.1 Adding NO Records to a Zone . . . . . . . . . . . . . . . 10
3.13.2 Simple NO creating entity . . . . . . . . . . . . . . . . 11
3.13.3 Advanced NO creating entity . . . . . . . . . . . . . . . 11
3.13.4 Resolver Query for Non-existing Domain . . . . . . . . . . 11
3.13.5 Resolver Query for Non-existing Type At Existing Domain . 12
4. Comparing NO and NXT . . . . . . . . . . . . . . . . . . . 13
4.1 Denial Of Existence Of Non-Existing Names . . . . . . . . 13
4.2 Denial Of Types Of Existing Names . . . . . . . . . . . . 13
4.3 Information disclosure (chain problem) . . . . . . . . . . 13
4.4 Delegation problem . . . . . . . . . . . . . . . . . . . . 13
4.5 Zone size (Bytes) . . . . . . . . . . . . . . . . . . . . 13
4.6 Zone size (Number Of Records) . . . . . . . . . . . . . . 13
4.7 Zone size (Number Of Owner names) . . . . . . . . . . . . 14
4.8 SIG Labels field and Wildcard records . . . . . . . . . . 14
4.9 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . 15
References . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . 17
Josefsson Expires May 25, 2001 [Page 2]
Internet-Draft The NO Record November 2000
1. Introduction
"Domain Name Security Extensions", RFC 2535 [1], specifies several
extensions to DNS that provides data integrity and authentication.
Among them is the NXT record, used to achieve authenticated denial
of existence of domains, and authenticated denial of existence on
certain class/types on existing domains.
As a consequence of NXT records it is possible to "chain" through a
zone secured by DNS security extensions, collecting all names and/or
records in the zone. NXT records also introduce a complication at
delegation points. These are the main problems that motivated this
draft.
2. Context
There have been arguments that the "chain" problem of NXT records is
a non-issue. Often used is the argument that information in DNS is
public, and if you wish to keep information private, you shouldn't
publish it in DNS. This might be true, but nonetheless major
service providers and companies are restricting access to zone
transfers. Also, people have debated whether NXT records should be
part of DNSSEC at all because of this problem [5].
Another aspect exist. When DNS is used to store certificates, as
described in RFC 2538 [2], certificates can identify individuals
and/or carry authentication information for special purposes. This
context has been the motivation for developing this draft.
The "chain" problem is not the only concern with NXT records. The
delegation considerations for NXT records (different RRsets in the
parent and child for the same domain) has also been regarded as a
flaw of the NXT records.
Josefsson Expires May 25, 2001 [Page 3]
Internet-Draft The NO Record November 2000
3. The NO Resource Record
This section describe the NO Resource Record.
3.1 Idea
A straight-forward extension to the NXT record that minimize
disclosure of information is to store a one-way function value
instead of the actual domain name. This is similar to NXT records;
where NXT records secure a interval where no existing domain names
are to be found, NO records secure a interval where no one-way value
of existing domain names are to be found.
The benefit, of course, is that an adversary does not yield any
useful information from the record. Specifically, "chaining"
through a zone to collect all records is no longer possible.
This idea has been extended in this document into allowing (but not
requiring) one record to deny existence of several records, and
truncating the hash value to the shortest unique prefix to preserve
space.
3.2 NO RDATA Format
The RDATA for a NO RR consists of one or more fields with the
following structure. The structure have the following elements: a
zero-terminated list of RR types, a hash length specifier, and a
hash value, as shown below. Both the "RR type" list and the "next
hash value" fields are of variable width.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ owner RR type list /
/ |
+---------------+-----------------------------------------------+
| # hash octets | SHA-1 hash value /
+---------------+ /
/ /
+---------------------------------------------------------------+
Replacing the NXT RR "type bit map" field is a variable length list
of RR types. Each RR type is 16 bits. As the list is of variable
length, a end-of-list indicator is require. End of the list is
signalled by a all-zero RR type. Each element is a 2 byte RR type.
The list MUST be sorted in RR type order. The change from NXT's
bitmap field removes the limit of authenticating only the first 127
RR types.
Josefsson Expires May 25, 2001 [Page 4]
Internet-Draft The NO Record November 2000
The RR type list indicates what types exist at the previous hash
value -- i.e. the first RR type list in the RRdata of a NO record
indicate what RR types exist at the domain name that hashes to the
owner name of that NO record. The second RR type list, if any, in
the RRdata of a NO record indicate what RR types exist at the domain
name that hashes the first SHA-1 value in the RRdata. And so on.
See below for a complete example of the on-the-wire-format of a NO
record with hash truncation and record merging and its
interpretation.
Length of the hash value field is denoted by the # hash octets
fields, it is a unsigned integer ranging from 0 to 255. The meaning
of a zero length integer is reserved.
The SHA-1 hash value field is a variable length field containing the
actual hash value.
The NO RRs for a zone SHOULD be automatically calculated and added
to the zone when SIGs are added. The NO RR's TTL SHOULD NOT exceed
the zone minimum TTL.
The type number for the NO RR is TBD.
NO RR's MUST only be signed by zone level keys [7].
Josefsson Expires May 25, 2001 [Page 5]
Internet-Draft The NO Record November 2000
3.3 NO RDATA on-the-wire format example
The following is a example of the on-the-wire-format of a complete
NO resource record were hash truncation and record merging is used.
It is the on-the-wire format of the NO record in section 3.13.1.2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR type 1 (A) | RR type 0 (end-of-list) |
+---------------+-----------------------------------------------+
| 1 hash octet | Hash 0x22 | RR type 2 (NS) |
+---------------+---------------+-------------------------------+
| RR type 6 (SOA) | RR type 15 (MX) |
+-------------------------------+---------------+---------------+
| RR type 0 (end-of-list) | 1 hash octet | Hash 0x83 |
+-------------------------------+---------------+---------------+
| RR type 1 (A) | RR type 0 (end-of-list) |
+---------------+-----------------------------------------------+
| 1 hash octet | Hash 0x90 | RR type 1 (A) |
+---------------+---------------+-------------------------------+
| RR type 16 (TXT) | RR type 0 (end-of-list) |
+---------------+---------------+-------------------------------+
| 1 hash octet | Hash 0x1b |
+-------------------------------+
The intepretation here is that the domain that corresponds with the
NO owner name ("1b._no.example.org.", not shown above) have a A
record, that the domain that hash to 0x22 (truncated to one octet)
have a NS, SOA and MX record, that the domain that hash to 0x83
(truncated to 1 octet) have a A record etc. Note that the last hash
value of NO RRdata does not have a RR type list in the same record.
3.4 Owner Names
As the previous NO RR format describe, the "next domain name" of NXT
records is replaced by its hash value. This removes the possibility
of chaining both backwards and forwards through a zone.
But without also modifying the owner names of NO records it is still
not difficult to chain through a zone. Consider querying a server
for (say) "m._no.example.org", the reply could contain a NO record
for "g._no.example.org", now an adversary can lookup records for
"g._no.example.org", and then issue a query for a domain that would
sort (in "the canonical order" described in RFC 2535) just before
"g._no.example.org". Applying the technique over and over again, all
records in the zone can still be collected.
To prevent this, the owner names of NO records is replaced by its
Josefsson Expires May 25, 2001 [Page 6]
Internet-Draft The NO Record November 2000
hash value. As DNS places limits on what characters can be used in
owner names, the owner name uses a base 16 "hex" encoding [6].
In order to remove the (very small) chance of generated NO record
names colliding with existing, "real", domains, all NO records MUST
be stored directly in the "_no" domain of the zone. I.e., a zone
"example.org." store its NO records as, say,
"35a4d1._no.example.org.".
This change in owner names also make sure that the delegation point
concerns of NXT records does not occur in NO records.
3.5 Additional Complexity Due To Wildcards
Proving that a non-existent name response is correct, or that a
wildcard expansion response is correct, makes things a little more
complex.
In particular, when a non-existent name response is returned, an NO
must be returned showing that the exact name did not exist and, in
general, one or more additional NO need to be returned to also prove
that there wasn't a wildcard whose expansion should have been
returned. (There is no need to return multiple copies of the same
NO.) These NOs, if any, are returned in the authority section of the
response.
Furthermore, if a wildcard expansion is returned in a response, in
general one or more NOs needs to also be returned in the authority
section to prove that no more specific name (including possibly more
specific wildcards in the zone) existed on which the response should
have been based.
3.6 No Considerations at Delegation Points
When NXT records are used to deny existance, there exists a special
case at delegation points. Namely, that two distinct RRsets exist
for the same owner name, one in the parent zone and one in the child
zone.
$ORIGIN parent.example.org.
@ SOA
NS
NXT child SOA NS SIG NXT
child NS foo
NXT next NS SIG NXT
next A 127.0.0.2
Josefsson Expires May 25, 2001 [Page 7]
Internet-Draft The NO Record November 2000
$ORIGIN child.parent.example.org.
@ SOA
NS
NXT name SOA NS SIG NXT
name A 127.0.2.1
NXT child.parent.example.org.
With NO records, the parent would deny existance of domains in
"_no.parent.example" and the child in
"_no.child.parent.example.org". Thus no NO RRset collision occur.
3.7 Hash Truncation and Dynamic Updates
Entities that create NO records MAY truncate the hash field. It
MUST NOT truncate hash fields so they are no longer unique
throughout a zone. Hash truncations MUST only be done to octet
offsets. Truncation MUST be such that less significant bits are
truncated, i.e. higher-order bits are preserved (see the examples).
Zones that are dynamically updated will have to calculate and add NO
records on-the-fly. If hash truncation is used, adding a new name
to the zone will require updating (and signing) NO records for the
conflicting name(s).
Since truncation (and also "compression" described in the next
section) make it impossible to predict the corresponding NO record
given a domain name, resolvers should not ask for a hashed NO record
(aaaa._no.example.org. IN NO) for a known domain name if they want
to find out what types exist at the domain. Instead, a resolver
might ask for NO records on the original name (www.example.org. IN
NO). Such records will never exist, and the correct NO record will
be returned by the server.
To summarize, the behaviour of hash truncation should be
configurable in the entity that creates NO records, to accomodate
different usage-patterns. If the zone is intended to be dynamicly
updated, hash truncation may be considered not worth the extra
on-the-fly processing required.
Josefsson Expires May 25, 2001 [Page 8]
Internet-Draft The NO Record November 2000
3.8 Reducing Number of Records
Entitities that create NO records MAY deny existence for several
records per NO record. Entities that create NO records should take
care so that each resulting NO record is not "too large". [Comments
on this? Should there be a specific limit? It might be left as a
DNS Operational consideration]
Merging several NO records into one record also place more work on
the resolver. Instead of parsing two hash values for each NO record
to determine if it's applicaple, a resolver will have to parse
several hash values and compare each.
The NO RR record consist of one or more RR type list / hash values,
described above, and a resolver need to parse the entire record to
collect each individual field. I.e., a NO parse algorithm could
looke like: read RRs, stop when you read a zero RR type, read hash
length indicator, read hash size, if the entire record is read stop,
otherwise read RRs, stop when you read a zero RR type, etc..
3.9 Hash Collisions
Hash value collisions are expected not to occur. For SHA-1, the
probability that this should happen is 1 out of 2^80 on average.
However, collisions are actually only a problem if the domain names
producing the same hash value have different sets of existing types.
Consider the following records
; SHA-1(one.example.org) = SHA-1(two.example.org)
one.example.org. IN A 1.2.3.4
two.example.org. IN A 5.6.7.8
Given that no other RR types exist for neither domain, both
"one.example.org" and "two.example.org" would be authenticated not
to exist by the same NO record.
3.10 Authenticating Denial of NO Records
NO records (together with SIG records) authenticate denial for other
types in a zone. Unlike NXT records that re-use the namespace in
the zone, NO records are not intended to authenticate denial of
other NO records.
Josefsson Expires May 25, 2001 [Page 9]
Internet-Draft The NO Record November 2000
3.11 Case Considerations
Before calculating SHA-1 hash values, domain names MUST be converted
into canonical format as described in RFC 2535. This is to make hash
comparisons possible.
3.12 Presentation Format
NO RRs do not appear in original unsigned zone master files since
they should be derived from the zone as it is being signed.
If a signed file with NO records is printed or NO records are
printed by debugging code, they appear as a list of unsigned
integers or RR mnemonics, and the hash value in base 16 hex
representation [6] with "0x" prepended (to distinguish it from
integer RR codes). The zero RR that terminate the list of RR types,
and the hash value length indicator, does not appear.
See the next section for examples of printed NO RRs.
3.13 Examples
This section contain examples of NO records, using the reserved
domain exmaple.org [3].
3.13.1 Adding NO Records to a Zone
Consider the following zone file.
$ORIGIN example.org.
@ IN SOA ...
@ IN NS ns
@ IN MX 0 server
ns IN A ...
www IN A ...
sERVEr IN A ...
sERVEr IN TXT "text"
; SHA1(example.org.) = 0x222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1
; SHA1(ns.example.org.) = 0x1b7838c69a66eb50cc215f66ee4554d0c4c940a5
; SHA1(www.example.org.) = 0x839ebd4386c0b26d81f147421b5b7036e61438cf
; SHA1(server.example.org.) = 0x906a0ad5e604b1905828499dc8672ecb8de73e2f
Note that hash values are calculcated on the canonical form.
The following two sections describe two valid ways of adding NO
records to a zone.
Josefsson Expires May 25, 2001 [Page 10]
Internet-Draft The NO Record November 2000
3.13.2 Simple NO creating entity
A simple NO creator entity might not implement truncation or provide
the possibility to deny more than one records per NO record. In
this case, the following would be added to the zone file.
$ORIGIN _no.example.org.
1b7838c69a66eb50cc215f66ee4554d0c4c940a5
IN NO A 0x222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1
222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1
IN NO NS SOA MX 0x839ebd4386c0b26d81f147421b5b7036e61438cf
839ebd4386c0b26d81f147421b5b7036e61438cf
IN NO A 0x906a0ad5e604b1905828499dc8672ecb8de73e2f
906a0ad5e604b1905828499dc8672ecb8de73e2f
IN NO A TXT 0x1b7838c69a66eb50cc215f66ee4554d0c4c940a5
3.13.3 Advanced NO creating entity
A more advanced NO creator entity might append the following
instead, using both truncation and "compression".
$ORIGIN _no.example.org
1b IN NO A 0x22 NS SOA MX 0x83 A 0x90 A TXT 0x1b A
Note that this contain 5 hash values while the zone only contain 4
records, the last value in the line above is in fact the first hash
value in the zone, closing the circular NO chain.
3.13.4 Resolver Query for Non-existing Domain
Consider a client looking up the non-existant domain name
"baz.example.org.", using the zone file from the previous section.
First, we note the following calculations.
SHA-1(baz.example.org.) = 0xd5d0f98783eec6e9943750f35904304bd1a4090e
SHA-1(*.example.org.) = 0x7ab3776e3b529eb42467cc5d279c88ec951cf021
A server would reply with an RCODE of NXDOMAIN and the authority
section data including the following:
Josefsson Expires May 25, 2001 [Page 11]
Internet-Draft The NO Record November 2000
; backwards compatibility
example.org. IN SOA
; prove no baz.example.org
906a0ad5e604b1905828499dc8672ecb8de73e2f._no.example.org.
IN NO A TXT 0x1b7838c69a66eb50cc215f66ee4554d0c4c940a5
906a0ad5e604b1905828499dc8672ecb8de73e2f._no.example.org. IN SIG NO
; prove no *.example.org:
222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1._no.example.org.
IN NO NS SOA MX 0x839ebd4386c0b26d81f147421b5b7036e61438cf
222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1._no.example.org. IN SIG NO
In order for a client to verify the authenticity of this reply, in
addition of verifying the SIG record, it will also need to calculate
the one-way hash of "baz.example.org." and verify it is contained
inside the interval of any NO record in the authority section.
Also, to prove there are no wildcard records for baz.example.org.,
NO records for possible wildcard expansions are returned. A client
should similarily calculate hash values of possible wildcards and
compare them to the authority section.
Of course, if the zone was generated with the more advanced NO
creating entity, only the NO record from the previous section would
have to be returned.
3.13.5 Resolver Query for Non-existing Type At Existing Domain
Consider a client looking up TXT records for the existing domain
"www.example.org.", again, using the same zone file as previous. A
server would reply with an authority section like the following:
839ebd4386c0b26d81f147421b5b7036e61438cf._no.example.org.
IN NO A 0x906a0ad5e604b1905828499dc8672ecb8de73e2f
839ebd4386c0b26d81f147421b5b7036e61438cf._no.example.org. IN SIG NO
The resolver verifies the signature and make sure
SHA-1("bar.example.org.") hashes correctly.
Josefsson Expires May 25, 2001 [Page 12]
Internet-Draft The NO Record November 2000
4. Comparing NO and NXT
To ease comparison between NXT and NO records, this section
summarize (mis-)features of the NXT and the NO record formats. The
intent here is to address all operational differences between NO and
NXT records.
4.1 Denial Of Existence Of Non-Existing Names
Both NXT and NO provide strong data non-existance for non-existing
names.
NXT records authenticate data non-existance up to the probability of
finding a collision in the signature algorithm (1 in 2^64 for
RSA/MD5). NO records authenticate data non-existance up to the
probability of finding a collision in the signature algorithm (1 in
2^64 for RSA/MD5) and the NO record hash value (varies due to
truncation). If the RSA/MD5 scheme is used, hash values in NO
records may be truncated to 64 bits.
4.2 Denial Of Types Of Existing Names
Both NXT and NO provide strong data non-existance of types for
existing names. The previous discussion also apply here.
4.3 Information disclosure (chain problem)
NXT records make it possible to collect all names (and records) in a
zone. NO records prohibit this.
4.4 Delegation problem
NXT records require a special case where two different RRsets exist
at the same owner name, class and type. NO records does not have
this problem.
4.5 Zone size (Bytes)
The size difference is due to changing complete domain names with
hash values (SHA1 20 bytes). Without truncation, NO records are
probably larger than most NXT records. With truncation, NO records
uses a few byte per hash value instead of the (possibly compressed)
complete owner name.
4.6 Zone size (Number Of Records)
When NO compression is not used, NXT and NO uses the same number of
records.
Josefsson Expires May 25, 2001 [Page 13]
Internet-Draft The NO Record November 2000
However, NO compression can greatly reduce the number of records.
As an example, considering a zone with records of 100.000 different
names. NXT uses 200.000 records (NXT+SIG). Using NO compression
with 10 hash values on each reduce this number to 20.000 records
(NO+SIG).
4.7 Zone size (Number Of Owner names)
NO uses twice the amount of owner names as NXT.
However, NO compression can be used to reduce this to a fraction of
the normal amount. From the previous example with 10 hash values
per NO record, it will uses 10.000 additional owner names in a zone
with 100.000 names
4.8 SIG Labels field and Wildcard records
It is marginally faster to verify signatures for NXT records when
wildcard records are involved -- the SIG "Label fields" hints can be
used to determine the canonical name. With NO records this hint
cannot be used, because it relies on knowing the full name whereas
only the hash is available. One need to try a few SHA1 hashes to
find the correct canonical name. The number of hashes required to
try depend on the number of labels in the name, and scale linearly.
N.B. This penalty only apply to wildcard records.
4.9 Dynamic Updates
Resigning dynamically updated records is required both with NXT and
NO records.
However, when NO truncation and compression is used, the additional
penalty of re-hashing might also be required.
Josefsson Expires May 25, 2001 [Page 14]
Internet-Draft The NO Record November 2000
5. Security Considerations
Chaining through all NO records is still technically possible,
altough it cannot be used to collect names and/or records in the
zone (other than NO records themself).
The security of NO record hash values is dependent on the security
of the SHA-1 hash functions used. Truncation may affect this, but
the birthday-paradox argument does not apply. One must find a hash
collision given an existing hash value -- not simply find any hash
collision. It is thus reasonably to truncate NO records to half the
hash length used in the signature scheme (this would mean 64 bits in
the RSA/MD5 case).
It should be pointed out that given this scheme, it is easy to
estimate the number of records within a zone, considering hash
values are supposed to be equally distributed. This can be foiled
by adding any number of bogus records in the zone.
The authentication of NO records is provided by DNS SIG records, as
specified in RFC 2535. The security considerations of RFC 2535 is
not affected by this document, and should also be considered.
6. IANA Considerations
The NO RR type number should be selected by the IANA from the normal
RR type space.
The meaning of a zero hash length value can only be assigned by a
standards action.
Acknowledgement
The idea of encrypting names, that later evolved into just hashing
them, was originally proposed by Jonas Holmerin in private
discussions about DNS Security. Magnus Nystr÷m proposed truncating
the hash values.
Thanks to John Linn and Magnus Nystr÷m for comments on a early
version of this draft.
Olafur Gudmundsson pointed out delegation point issues, suggested
the use of a "_no" subdomain, and suggested replacing the type bit
map field with a sorted list. From the namedroppers mailing list,
I'd like to thank Alan Barrett, Andrew Draper, Andreas Gustafsson,
Peter Koch and Brian Wellington for comments and suggestions. Ed
Lewis noted that truncation to shortest unique prefix would not work.
Josefsson Expires May 25, 2001 [Page 15]
Internet-Draft The NO Record November 2000
References
[1] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[2] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
Domain Name System (DNS)", RFC 2538, March 1999.
[3] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", RFC
2606, June 1999.
[4] NIST, , "Secure Hash Standard", FIPS PUB 180-1, April 1995.
[5] Massey, D., Lehman, T. and E. Lewis, "DNSSEC Implementation in
the CAIRN Testbed.", I.D. draft-ietf-dnsop-dnsseccairn-00.txt,
October 1999.
[6] Josefsson, S.A. (editor), "Base 64, 32 and 16 Encodings", I.D.
draft-josefsson-base-encoding-00.txt, August 2000.
[7] Wellington, B, "Domain Name System Security (DNSSEC) Signing
Authority", I.D. draft-ietf-dnsext-signing-auth-01.txt, May
2000.
Author's Address
Simon Josefsson
RSA Security
Arenav„gen 29
Stockholm 121 29
Sweden
Phone: +46 8 7250914
EMail: sjosefsson@rsasecurity.com
Josefsson Expires May 25, 2001 [Page 16]
Internet-Draft The NO Record November 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Josefsson Expires May 25, 2001 [Page 17]