upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-04-15 22:09:31 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

This commit was manufactured by cvs2git to create branch 'v9_2'.

Browse source
This commit is contained in:
cvs2git 2003-05-14 23:21:21 +00:00
commit d73173f93f
54 changed files with 35593 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

100
contrib/queryperf/utils/gen-data-queryperf.py Normal file
View file

@ -0,0 +1,100 @@
#!/usr/bin/python
#
# $Id: gen-data-queryperf.py,v 1.1 2003/04/10 02:33:40 marka Exp $
#
# Contributed by Stephane Bortzmeyer <bortzmeyer@nic.fr>
#
# "A small tool which may be useful with contrib/queryperf. This script
# can generate files of queries, both with random names (to test the
# behaviour with NXdomain) and with domains from a real zone file."
#
import sys
import getopt
import random
import re
ldh = []
# Letters
for i in range(97, 122):
ldh.append(chr(i))
# Digits
for i in range(48, 57):
ldh.append(chr(i))
# Hyphen
ldh.append('-')
maxsize=10
tld='org'
num=4
percent_random = 0.3
gen = None
zone_file = None
domains = {}
domain_ns = "^([a-z0-9-]+)(\.([a-z0-9-\.]+|)|)( +IN|) +NS"
domain_ns_re = re.compile(domain_ns, re.IGNORECASE)
def gen_random_label():
label = ""
for i in range(gen.randint(1, maxsize)):
label = label + gen.choice(ldh)
return label
def make_domain(label):
return "www." + label + "." + tld + " A"
def usage():
sys.stdout.write("Usage: " + sys.argv[0] + " [-n number] " + \
"[-p percent-random] [-t TLD]\n")
sys.stdout.write(" [-m MAXSIZE] [-f zone-file]\n")
try:
optlist, args = getopt.getopt(sys.argv[1:], "hp:f:n:t:m:",
["help", "percentrandom=", "zonefile=",
"num=", "tld=",
"maxsize="])
for option, value in optlist:
if option == "--help" or option == "-h":
usage()
sys.exit(0)
elif option == "--number" or option == "-n":
num = int(value)
elif option == "--maxsize" or option == "-m":
maxsize = int(value)
elif option == "--percentrandom" or option == "-p":
percent_random = float(value)
elif option == "--tld" or option == "-t":
tld = str(value)
elif option == "--zonefile" or option == "-f":
zone_file = str(value)
else:
error("Unknown option " + option)
except getopt.error, reason:
sys.stderr.write(sys.argv[0] + ": " + str(reason) + "\n")
usage()
sys.exit(1)
if len(args) <> 0:
usage()
sys.exit(1)
gen = random.Random()
if zone_file:
file = open(zone_file)
line = file.readline()
while line:
domain_line = domain_ns_re.match(line)
if domain_line:
domain = domain_line.group(1)
domains[domain] = 1
line = file.readline()
file.close()
for i in range(num):
if zone_file:
if gen.random() < percent_random:
print make_domain(gen_random_label())
else:
print make_domain(gen.choice(domains.keys()))
else:
print make_domain(gen_random_label())

336
doc/draft/draft-baba-dnsext-acl-reqts-00.txt Normal file
View file

@ -0,0 +1,336 @@
Internet-Draft T. Baba
Expires: August 4, 2003 NTT Data
February 4, 2003
Requirements for Access Control in Domain Name Systems
draft-baba-dnsext-acl-reqts-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to 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.
This Internet-Draft will expire on August 4, 2003.
Abstract
This document describes the requirements for access control
mechanisms in the Domain Name System (DNS), which authenticate
clients and then allow or deny access to resource records in the
zone according to the access control list (ACL).
1. Introduction
The Domain Name System (DNS) is a hierarchical, distributed, highly
available database used for bi-directional mapping between domain
names and IP addresses, for email routing, and for other information
[RFC1034, 1035]. DNS security extensions (DNSSEC) have been defined
to authenticate the data in DNS and provide key distribution services
using SIG, KEY, and NXT resource records (RRs) [RFC2535].
Baba Expires August 4, 2003 [Page 1]
Internet-Draft DNS Access Control Requirements February 2003
At the 28th IETF Meeting in Houston in 1993, DNS security design team
started a discussion about DNSSEC and agreed to accept the assumption
that "DNS data is public". Accordingly, confidentiality for queries
or responses is not provided by DNSSEC, nor are any sort of access
control lists or other means to differentiate inquirers. However,
about ten years has passed, access control in DNS has been more
important than before. With DNS access control mechanism, access
from unauthorized clients can be blocked when they perform DNS name
resolution. Thus, for example, Denial of Service (DoS) attacks
against a server used by a closed user group can be prevented using
this mechanism if IP address of the server is not revealed by other
sources.
This document describes the requirements for access control
mechanisms in DNS.
2. Terminology
AC-aware client
This is the client that understands the DNS access control
extensions. This client may be an end host which has a stub
resolver, or a cashing/recursive name server which has a
full-service resolver.
AC-aware server
This is the authoritative name server that understands the DNS
access control extensions.
ACE
An Access Control Entry. This is the smallest unit of access
control policy. It grants or denies a given set of access
rights to a set of principals. An ACE is a component of an ACL,
which is associated with a resource.
ACL
An Access Control List. This contains all of the access control
policies which are directly associated with a particular
resource. These policies are expressed as ACEs.
Client
A program or host which issues DNS requests and accepts its
responses. A client may be an end host or a cashing/recursive name
server.
RRset
All resource records (RRs) having the same NAME, CLASS and TYPE
are called a Resource Record Set (RRset).
Baba Expires August 4, 2003 [Page 2]
Internet-Draft DNS Access Control Requirements February 2003
3. Requirements
This section describes the requirements for access control in DNS.
3.1 Authentication
3.1.1 Client Identifier / Authentication Mechanism
The AC-aware server must identify AC-aware clients based on IP
address and/or domain name (user ID or host name), and must
authenticate them using strong authentication mechanism such as
digital signature or message authentication code (MAC).
SIG(0) RR [RFC2931] contains a domain name associated with sender's
public key in its signer's name field, and TSIG RR [RFC2845] also
contains a domain name associated with shared secret key in its key
name field. Each of these domain names can be a host name or a user
name, and can be used as a sender's identifier for access control.
Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for
message authentication. These mechanisms can be used to authenticate
AC-aware clients.
Server authentication may be also provided.
3.1.2 End-to-End Authentication
In current DNS model, caching/recursive name servers are deployed
between end hosts and authoritative name servers. Although
authoritative servers can authenticate caching/recursive name servers
using SIG(0) or TSIG, they cannot authenticate end hosts behind them.
For end-to-end authentication, the mechanism for an end host to
discover the target authoritative name server and directly access to
it bypassing caching/recursive name servers is needed. For example,
an end host can get the IP addresses of the authoritative name
servers by retrieving NS RRs for the zone via local caching/recursive
name server.
3.1.3 Authentication Key Retrieval
Keys which are used to authenticate clients should be able to be
automatically retrieved. The KEY RR is used to store a public key
for a zone or a host that is associated with a domain name. SIG(0)
RR uses a public key in KEY RR for verifying the signature. If
DNSSEC is available, the KEY RR would be protected by the SIG RR.
KEY RR or newly defined RR can be used to automatic key retrieval.
Baba Expires August 4, 2003 [Page 3]
Internet-Draft DNS Access Control Requirements February 2003
3.2 Confidentiality
3.2.1 Data Encryption
To avoid disclosure to eavesdroppers, the response containing the
RRsets which are restricted to access from particular users should be
encrypted. Although IPsec can be used to encrypt DNS packets, it
authenticates a peer based on IP address. Currently, no encryption
mechanism is specified in DNS. Therefore, new RRs must be defined
for DNS message encryption. In case encryption is applied, entire
DNS message including DNS header must be encrypted to hide
information including error code.
Query encryption may be also provided.
3.2.2 Key Exchange
If DNS message encryption is provided, automatic key exchange
mechanism must be also provided. [RFC2930] specifies a TKEY RR that
can be used to establish and delete shared secret keys used by TSIG
between a client and a server. With minor extensions, TKEY can be
used to establish shared secret keys used for message encryption.
3.2.3 Caching
The RRset that is restricted to access from particular users must not
be cached. To avoid caching, the TTL of the RR that is restricted to
access should be set to zero during transit.
3.3 Access Control
3.3.1 Granularity of Access Control
Control of access on a per-user/per-host granularity must be
supported. Control of access to individual RRset (not just the
entire zone) must be also supported. However, SOA, NS, SIG, NXT,
KEY, and DS RRs must be publicly accessible to avoid unexpected
results.
Baba Expires August 4, 2003 [Page 4]
Internet-Draft DNS Access Control Requirements February 2003
3.3.2 ACL Representation
Access Control List (ACL) format must be standardized so that both
the primary and secondary AC-aware servers can recognize the same
ACL. Although ACL may appear in or out of zone data, it must be
transferred to the secondary AC-aware server with associated zone
data. It is a good idea to contain ACL in zone data, because ACL can
be transferred with zone data using existing zone transfer mechanisms
automatically. However, ACL must not be published except for
authorized secondary master servers.
In zone data master files, ACL should be specified using TXT RRs or
newly defined RRs. In each access control entry (ACE), authorized
entities (host or user) must be described using domain name (host
name, user name, or IP address in in-addr.arpa/ip6.arpa format).
There may be other access control attributes such as access time.
It must be possible to create publicly readable entries, which may be
read even by unauthenticated clients.
3.3.3 Zone/ACL Transfer
As mentioned above, ACL should be transferred from a primary AC-aware
server to a secondary AC-aware server with associated zone data.
When an AC-aware server receives a zone/ACL transfer request, the
server must authenticate the client, and should encrypt the zone
data and associated ACL during transfer.
3.4 Backward/co-existence Compatibility
Any new protocols to be defined for access control in DNS must be
backward compatible with existing DNS protocol. AC-aware servers
must be able to process normal DNS query without authentication, and
must respond if retrieving RRset is publicly accessible.
Modifications to root/gTLD/ccTLD name servers are not allowed.
4. Security Considerations
This document discusses the requirements for access control
mechanisms in DNS.
5. Acknowledgements
This work is funded by the Telecommunications Advancement
Organization of Japan (TAO).
The author would like to thank the members of the NTT DATA network
security team for their important contribution to this work.
Baba Expires August 4, 2003 [Page 5]
Internet-Draft DNS Access Control Requirements February 2003
6. References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
RFC 2930, September 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s)", RFC 2931, September 2000.
Author's Address
Tatsuya Baba
NTT Data Corporation
Research and Development Headquarters
Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku,
Tokyo 104-0033, Japan
Tel: +81 3 3523 8081
Fax: +81 3 3523 8090
Email: babatt@nttdata.co.jp
Baba Expires August 4, 2003 [Page 6]

246
doc/draft/draft-dnsext-opcode-discover-01.txt Normal file
View file

@ -0,0 +1,246 @@
IETF DNSEXT WG Bill Manning
draft-dnsext-opcode-discover-01.txt ISI
Paul Vixie
ISC
Erik Guttman
SUN
21 Dec 2002
The DISCOVER opcode
This document is an Internet-Draft and is subject to all provisions of
Section 10 of RFC2026.
Comments may be submitted to the group mailing list at "mdns@zocalo.net"
or the authors.
Distribution of this memo is unlimited.
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.
The capitalized keywords "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
0. Abstract:
The QUERY opcode in the DNS is designed for unicast. With the
development of multicast capabilities in the DNS, it is desireable
to have a more robust opcode for server interactions since a single
request may result in replies from multiple responders. So DISCOVER
is defined to deal with replies from multiple responders.
As such, this document extend the core DNS specifications to allow
clients to have a method for coping with replies from multiple
responders. Use of this new opcode may facilitate DNS operations in
modern networking topologies. A prototype of the DISCOVER opcode
was developed as part of the TBDS project, funded under DARPA grant
F30602-99-1-0523.
1. Introduction:
This document describes an experimental extension to the DNS to receive
multiple responses which is the likely result when using DNS that has
enabled multicast queries. This approach was developed as part of the
TBDS research project, funded under DARPA grant F30602-99-1-0523. The
full processing rules used by TBDS are documented here for possible
incorporation in a future revision of the DNS specification."
2. Method:
DISCOVER works like QUERY except:
1. it can be sent to a broadcast or multicast destination QUERY
isn't defined for non-unicast, and arguably shouldn't be.
2. the Question section, if present, has <QNAME=zonename,QTYPE=SOA>
tuples. Our testing tried to augment this structure as follows:
<QNAME=service,QTYPE=SRV>. While this worked for our purposes in
TBDS, it is cleaner to place the SRV question in a separate pass.
3. if QDCOUNT==0 then only servers willing to do recursion should
answer. Other servers must silently discard the DISCOVER request.
4. if QDCOUNT!=0 then only servers who are authoritative for the
zones named by some QNAME should answer.
5. responses may echo the request's Question section or leave it blank,
just like QUERY.
6. responses have "normal" Answer, Authority, and Additional sections.
e.g. the response is the same as that to a QUERY. It is desireable
that zero content answers not be sent to avoid badly formed or
unfulfilled requests. Responses should be sent to the unicast
address of the requester and the source address should reflect
the unicast address of the responder.
Example usage for gethostby{name,addr}-style requestors:
Compute the zone name of the enclosing in-addr.arpa, ip6.int, or
ip6.arpa domain.
DISCOVER whether anyone in-scope is authoritative for this zone.
If so, query these authoritative servers for local
in-addr/ip6 names.
If not, DISCOVER whether there are recursive servers available.
If so, query these recursive servers for local
in-addr/ip6 names.
So, a node will issue a multicast request with the DISCOVER opcode at
some particular multicast scope. Then determine, from the replies,
whether there are any DNS servers which are authoritative (or support
recursion) for the zone. Replies to DISCOVER requests MUST set the
Recursion Available (RA) flag in the DNS message header.
It is important to recognize that a requester must be prepared to
receive multiple replies from multiple responders.
Once one learns a host's FQDN by the above means, repeat the process
for discovering the closest enclosing authoritative server of such
local name.
Cache all NS and A data learned in this process, respecting TTL's.
TBDS usage for SRV requestors:
Do the gethostbyaddr() and gethostbyname() on one's own link-local
address, using the above process.
Assume that the closest enclosing zone for which an authority server
answers an in-scope DISCOVER packet is "this host's parent domain".
Compute the SRV name as _service._transport.*.parentdomain.
This is a change to the definition as defined in RFC 1034.
A wildcard label ("*") in the QNAME used in a DNS message with
opcode DISCOVER SHOULD be evaluated with special rules. The
wildcard matches any label for which the DNS server data is
authoritative. For example 'x.*.example.com.' would match
'x.y.example.com.' and 'x.yy.example.com.' provided that the
server was authoritative for 'example.com.' In this particular
case, we suggest the follwing considerations be made:
getservbyname() can be satisfied by issuing a request with
this computed SRV name. The servent structure can be
populated by values returned from a request as follows:
s_name The name of the service, "_service" without the
preceding underscore.
s_aliases The names returned in the SRV RRs in replies
to the query.
s_port The port number in the SRV RRs replies to the
query. If these port numbers disagree - one
of the port numbers is chosen, and only those
names which correspond are returned.
s_proto The transport protocol from named by the
"_transport" label, without the preceding
underscore.
Send SRV query for this name to discovered local authority servers.
Usage for disconnected networks with no authority servers:
Hosts should run a "stub server" which acts as though its FQDN is a
zone name. Computed SOA gives the host's FQDN as MNAME, "." as the
ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE
and the other timers. Computed NS gives the host's FQDN. Computed
glue gives the host's link-local address. Or Hosts may run a
"DNS stub server" which acts as though its FQDN is a zone name. The
rules governing the behavior of this stub server are given elsewhere
[1] [2].
Such stub servers should answer DISCOVER packets for its zone, and
will be found by the iterative "discover closest enclosing authority
server" by DISCOVER clients, either in the gethostbyname() or SRV
cases described above. Note that stub servers only answer with
zone names which match QNAME's, not with zone names which are owned
by QNAME's.
The only deviation from the DNS[3][4] model is that a host (like, say, a
printer offering LPD services) has a DNS server which answers authoritatively
for something which hasn't been delegated to it. However, the only way that
such DNS servers can be discovered is with a new opcode, DISCOVER, which
is explicitly defined to discover undelegated zones for tightly scoped
purposes. Therefore this isn't officially a violation of DNS's coherency
principles. In some cases, a responder to DISCOVER, may not be traditional
DNS software, it could be special purpose software.
3. IANA Considerations
As a new opcode, the IANA will need to assign a numeric value
for the memnonic. The last OPCODE assigned was "5", for UPDATE.
Test implementations have used OPCODE "6".
4. Security Considerations
No new security considerations are known to be introduced with a new
opcode, however using multicast for service discovery has the potential
for denial of service, primarly from flooding attacks. It may also be
possible to enable deliberate misconfiguration of clients simply by
running a malicious DNS resolver that claims to be authoritative for
things that it is not. One possible way to mitigate this effect is by
use of credentials, such as CERT resource records within an RR set.
The TBDS project took this approach.
5. Attribution:
This material was generated in discussions on the mdns mailing list
hosted by Zocalo in March 2000. Paul Vixie, Stuart Cheshire, Bill Woodcock,
Erik Guttman and Bill Manning were active contributors.
6. Author's Address
Bill Manning
PO 12317
Marina del Rey, CA. 90295
+1.310.322.8102
bmanning@karoshi.com
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063
+1 650 779 7001
<vixie@isc.org>
Erik Guttman
Sun Microsystems
Eichh\367lzelstr. 7
74915 Waibstadt Germany
+49 6227 356 202
erik.guttman@sun.com
7. References
Informational References:
[1] Esibov, L., Aboba, B., Thaler, D., "Multicast DNS",
draft-ietf-dnsext-mdns-00.txt, November 2000. Expired
[2] Woodcock, B., Manning, B., "Multicast Domain Name Service",
draft-manning-dnsext-mdns-00.txt, August 2000. Expired.
Normative References:
[3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, November 1987.
[4] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
RFC 1035, November 1987

240
doc/draft/draft-durand-dnsop-dynreverse-00.txt Normal file
View file

@ -0,0 +1,240 @@
Internet Engineering Task Force Alain Durand
INTERNET-DRAFT SUN Microsystems
Feb 21, 2003
Expires Aug 2, 2003
Dynamic reverse DNS for IPv6
<draft-durand-dnsop-dynreverse-00.txt>
Status of this memo
This memo provides information to the Internet community. It does
not specify an Internet standard of any kind. This memo is in full
conformance with all provisions of Section 10 of RFC2026 [RFC2026].
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes a method to dynamically generate PTR records
and corresponding A or AAAA records when the reverse path DNS tree is
not populated.
A special domain dynrev.arpa. is reserved for that purpose.
1. Introduction
In IPv4, the reverse path tree of the DNS under in-addr.arpa.
although not perfectly maintained, is still mostly usable and its
existence is important for a number of applications that relies on
its existence and decent status. Some applications performs some
(very) weak security checks based on it. Mail relays relies on it for
some anti-spams checks an some FTP server will not let you in unless
your IP address resolve properly with a PTR record.
IPv6 addresses being much longer (and cumbersome) than IPv4
addresses, it is to fear that the reverse path tree under ip6.arpa.
would not be as well maintained. Also, tools like 6to4, Isatap and
others have made creative use of the 128 bits of an IPv6 address to
automatically embed an IPv4 address to enable seamless connection to
the IPv6 Internet. However, no provision has been made to make sure
the reverse path tree gets automatically updated as well for those
new IPv6 addresses. One step furter, RFC3041 describes a mechanism
to basically use random bits in the bottom part of an IPv6 address to
preserver anonymity. If those addresses are to resolve in the reverse
path tree, it obviously has to be with anonymous data as well.
Another point to note is that home customer ISPs in IPv4 have a
current practice to pre-populate the reverse path tree with names
automatically derived from the IP addresses. This practice is no
longer possible in IPv6, where IP address allocation is not dense as
it is the case in IPv4. The mere size of typical customer allocation
(2^48 according to the recommendation of RFC3177) makes it
impossible.
Applications that check the existence of PTR records usually follow
this by checking if the name pointed by the PTR resolve in a A (or
AAAA for IPv6) that match the original IP address. Thus the forward
path tree must also include the corresponding data.
One simple approach of this problem is to simply declare the usage of
the reverse path DNS as described above obsolete. The author believe
this is too strong an approach for now.
Similarly, a completely different approach would be to deprecate the
usage of DNS for the reverse tree altogether and replace it by
something inspired from ICMP name-info messages. The author believes
that this approached is an important departure from the current
practise and thus not very realistic. Also, there are some concerns
about the the security implications of this method as any node could
easily impersonate any name. This approach would fundamentally change
the underlying assumption of "I trust what has been put in the DNS by
the local administrators" to "I trust what has been configured on
each machine I query directly".
2. Dynamic record generation
If static pre-population of the tree is not possible anymore and data
still need to be returned to applications using getnameinfo(), the
alternative is dynamic record generation. This can be done is two
places: in the DNS servers responsible for the allocated space (/64
or /48) in the ip6.arpa. domain. or in the DNS resolvers (either the
sub resolver library or the recursive DNS server).
2.1. On the resolver side.
The resolver, either in the recursive DNS server or in the stub
library could theoretically generate this data.
In case DNSsec is in place, the recursive DNS server would have to
pretend these records are authentic.
If the synthesis is done in the stub-resolver library, no record
needs to be actually generated, only the right information needs to
be passed to getnameinfo() and getaddrinfo(). If the synthesis is
done in the recursive DNS server, no modification is required to
existing stub resolvers.
2.2. On the server side.
PTR records could be generated automatically by the server
responsible for the reverse path tree of an IPv6 prefix (a /64 or /48
prefixes or basically anything in between) when static data is not
available.
There could be impact on DNSsec as the zone or some parts of the zone
may need to be resigned each time a DNS query is made for an
unpopulated address. This can be seen as a DOS attack on a DNSsec
zone, so server side synthesis is not recommended if DNSsec is
deployed.
3. Synthesis
The algorithm is simple: Do the normal queries. If the query returns
No such domain, replace this answer by the synthetized one if
possible.
3.1. PTR synthesis
The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa.
where [X] is any valid DNS name.
The fact that the synthetized PTR points to the dynrev.arpa. domain
is an indication to the applications that this record has been
dynamically generated.
3.2. A synthesis
If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A
record for the string [X].dynrev.arpa. which value is d.c.b.a. with
a,b,c & d being integer [0..255]
3.3. AAAA synthesis
If [X] is in the form
a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.s.t.u.v.w.x.y.z.A.B.C.D.E.F.in-
addr.arpa, one can synthetized a AAAA record for the string
[X].dynrev.arpa. which value is
FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with
a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits.
3.4. Server side synthesis
If synthesis is done on the server side, PTR could be set not to use
the dynrev.arpa domain but the local domain name instead. It culd be
for instance dynrev.mydomain.com.
Note also that server side synthesis is not incompatible with
resolver side synthesis.
4. IANA considerations
The dynrev.arpa. domain is reserved for the purpose of this document.
5. Security considerations
Section 2. discusses the the interactions with DNSsec.
6. Authors addresses
Alain Durand
SUN Microsystems, Inc
17, Network Circle
UMPK17-202
Menlo Park, CA 94025
USA
Mail: Alain.Durand@sun.com

393
doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt Normal file
View file

@ -0,0 +1,393 @@
INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsext-axfr-clarify-05.txt Nominum Inc.
November 2002
DNS Zone Transfer Protocol Clarifications
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.
Abstract
In the Domain Name System, zone data is replicated among
authoritative DNS servers by means of the "zone transfer" protocol,
also known as the "AXFR" protocol. This memo clarifies, updates, and
adds missing detail to the original AXFR protocol specification in
RFC1034.
1. Introduction
The original definition of the DNS zone transfer protocol consists of
a single paragraph in [RFC1034] section 4.3.5 and some additional
notes in [RFC1035] section 6.3. It is not sufficiently detailed to
serve as the sole basis for constructing interoperable
implementations. This document is an attempt to provide a more
complete definition of the protocol. Where the text in RFC1034
conflicts with existing practice, the existing practice has been
codified in the interest of interoperability.
Expires May 2003 [Page 1]
draft-ietf-dnsext-axfr-clarify-05.txt November 2002
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. The zone transfer request
To initiate a zone transfer, the slave server sends a zone transfer
request to the master server over a reliable transport such as TCP.
The form of this request is specified in sufficient detail in RFC1034
and needs no further clarification.
Implementers are advised that one server implementation in widespread
use sends AXFR requests where the TCP message envelope size exceeds
the DNS request message size by two octets.
3. The zone transfer response
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. 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
zone. Therefore, slaves MAY interpret an immediate graceful close of
the TCP connection as equivalent to a "Refused" response (RCODE 5).
If a zone transfer can be provided, the master server sends one or
more DNS messages containing the zone data as described below.
3.1. Multiple answers per message
The zone data in a zone transfer response is a sequence of answer
RRs. These RRs are transmitted in the answer section(s) of one or
more DNS response messages.
The AXFR protocol definition in RFC1034 does not make a clear
distinction between response messages and answer RRs. Historically,
DNS servers always transmitted a single answer RR per message. This
encoding is wasteful due to the overhead of repeatedly sending DNS
message headers and the loss of domain name compression
opportunities. To improve efficiency, some newer servers support a
mode where multiple RRs are transmitted in a single DNS response
message.
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 May 2003 [Page 2]
draft-ietf-dnsext-axfr-clarify-05.txt November 2002
DNS message size. In the case of a small zone, this can cause the
entire transfer to be transmitted in a single response message.
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
historical mode of one answer per message, and the configuration
SHOULD be settable on a per-slave basis.
3.2. DNS message header contents
RFC1034 does not specify the contents of the DNS message header of
the zone transfer response messages. The header of each message MUST
be as follows:
ID Copy from request
QR 1
OPCODE QUERY
AA 1, but MAY be 0 when RCODE is not NOERROR
TC 0
RD Copy from request, or 0
RA Set according to availability of recursion, or 0
Z 0
AD 0
CD 0
RCODE NOERROR on success, error code otherwise
The slave MUST check the RCODE in each message and abort the transfer
if it is not NOERROR. It SHOULD check the ID of the first message
received and abort the transfer if it does not match the ID of the
request. The ID SHOULD be ignored in subsequent messages, and fields
other than RCODE and ID SHOULD be ignored in all messages, to ensure
interoperability with certain older implementations which transmit
incorrect or arbitrary values in these fields.
3.3. Additional section and SIG processing
Zone transfer responses are not subject to any kind of additional
section processing or automatic inclusion of SIG records. SIG RRs in
the zone data are treated exactly the same as any other RR type.
3.4. The question section
RFC1034 does not specify whether zone transfer response messages have
a question section or not. The initial message of a zone transfer
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 May 2003 [Page 3]
draft-ietf-dnsext-axfr-clarify-05.txt November 2002
any combination of messages with and without a question section.
3.5. The authority section
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.
3.6. The additional section
The additional section MAY contain additional RRs such as transaction
signatures. The slave MUST ignore any unexpected RRs in the
additional section. It MUST NOT treat additional section RRs as zone
data.
4. Zone data
The purpose of the zone transfer mechanism is to exactly replicate at
each slave the set of RRs associated with a particular zone at its
primary master. An RR is associated with a zone by being loaded from
the master file of that zone at the primary master server, or by some
other, equivalent method for configuring zone data.
This replication shall be complete and unaltered, regardless of how
many and which intermediate masters/slaves are involved, and
regardless of what other zones those intermediate masters/slaves do
or do not serve, and regardless of what data may be cached in
resolvers associated with the intermediate masters/slaves.
Therefore, in a zone transfer the master MUST send exactly those
records that are associated with the zone, whether or not their owner
names would be considered to be "in" the zone for purposes of
resolution, and whether or not they would be eligible for use as glue
in responses. The transfer MUST NOT include any RRs that are not
associated with the zone, such as RRs associated with zones other
than the one being transferred or present in the cache of the local
resolver, even if their owner names are in the zone being transferred
or are pointed to by NS records in the zone being transferred.
The slave MUST associate the RRs received in a zone transfer with the
specific zone being transferred, and maintain that association for
purposes of acting as a master in outgoing transfers.
5. Transmission order
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
Expires May 2003 [Page 4]
draft-ietf-dnsext-axfr-clarify-05.txt November 2002
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. 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 SHOULD be transmitted only once, and slaves MUST ignore
any duplicate RRs received.
6. Security Considerations
The zone transfer protocol as defined in [RFC1034] and clarified by
this memo does not have any built-in mechanisms for the slave to
securely verify the identity of the master server and the integrity
of the transferred zone data. The use of a cryptographic mechanism
for ensuring authenticity and integrity, such as TSIG [RFC2845],
IPSEC, or TLS, is RECOMMENDED.
The zone transfer protocol allows read-only public access to the
complete zone data. Since data in the DNS is public by definition,
this is generally acceptable. Sites that wish to avoid disclosing
their full zone data MAY restrict zone transfer access to authorized
slaves.
These clarifications are not believed to themselves introduce any new
security problems, nor to solve any existing ones.
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, 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 May 2003 [Page 5]
draft-ietf-dnsext-axfr-clarify-05.txt November 2002
[RFC1035] - Domain Names - Implementation and Specifications, P.
Mockapetris, November 1987.
[RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
S. Bradner, BCP 14, March 1997.
[RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P.
Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.
Author's Address
Andreas Gustafsson
Nominum Inc.
2385 Bay Rd
Redwood City, CA 94063
USA
Phone: +1 650 381 6004
Email: gson@nominum.com
Full Copyright Statement
Copyright (C) The Internet Society (2000 - 2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation 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
Expires May 2003 [Page 6]
draft-ietf-dnsext-axfr-clarify-05.txt November 2002
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Expires May 2003 [Page 7]

914
doc/draft/draft-ietf-dnsext-delegation-signer-14.txt Normal file
View file

@ -0,0 +1,914 @@
DNSEXT Working Group Olafur Gudmundsson
INTERNET-DRAFT May 2003
<draft-ietf-dnsext-delegation-signer-14.txt>
Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090.
Delegation Signer Resource Record
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 December 6, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All rights reserved.
Abstract
The delegation signer (DS) resource record is inserted at a zone cut
(i.e., a delegation point) to indicate that the delegated zone is
digitally signed and that the delegated zone recognizes the indicated
key as a valid zone key for the delegated zone. The DS RR is a
modification to the DNS Security Extensions definition, motivated by
Gudmundsson Expires December 2003 [Page 1]
INTERNET-DRAFT Delegation Signer Record February 2003
operational considerations. The intent is to use this resource record
as an explicit statement about the delegation, rather than relying on
inference.
This document defines the DS RR, gives examples of how it is used and
the implications of this record on resolvers. This change is not
backwards compatible with RFC 2535.
This document updates RFC1035, RFC2535, RFC3008 and RFC3090.
1 Introduction
Familiarity with the DNS system [RFC1035], DNS security extensions
[RFC2535] and DNSSEC terminology [RFC3090] is important.
Experience shows that when the same data can reside in two
administratively different DNS zones, the data frequently gets out of
sync. The presence of an NS RRset in a zone anywhere other than at
the apex indicates a zone cut or delegation. The RDATA of the NS
RRset specifies the authoritative servers for the delegated or
"child" zone. Based on actual measurements, 10-30% of all delegations
on the Internet have differing NS RRsets at parent and child. There
are a number of reasons for this, including a lack of communication
between parent and child and bogus name servers being listed to meet
registry requirements.
DNSSEC [RFC2535,RFC3008,RFC3090] specifies that a child zone needs to
have its KEY RRset signed by its parent to create a verifiable chain
of KEYs. There has been some debate on where the signed KEY RRset
should reside, whether at the child [RFC2535] or at the parent. If
the KEY RRset resides at the child, maintaining the signed KEY RRset
in the child requires frequent two-way communication between the two
parties. First the child transmits the KEY RRset to the parent and
then the parent sends the signature(s) to the child. Storing the KEY
RRset at the parent was thought to simplify the communication.
DNSSEC [RFC2535] requires that the parent store a NULL KEY record for
an unsecure child zone to indicate that the child is unsecure. A NULL
KEY record is a waste: an entire signed RRset is used to communicate
effectively one bit of information--that the child is unsecure.
Chasing down NULL KEY RRsets complicates the resolution process in
many cases, because servers for both parent and child need to be
queried for the KEY RRset if the child server does not return it.
Storing the KEY RRset only in the parent zone simplifies this and
would allow the elimination of the NULL KEY RRsets entirely. For
large delegation zones the cost of NULL keys is a significant barrier
to deployment.
Gudmundsson Expires December 2003 [Page 2]
INTERNET-DRAFT Delegation Signer Record February 2003
Another complication of the DNSSEC key model is that the KEY record
can be used to store public keys for other protocols in addition to
DNSSEC keys. There are number of potential problems with this,
including:
1. The KEY RRset can become quite large if many applications and
protocols store their keys at the zone apex. Possible protocols
are IPSEC, HTTP, SMTP, SSH and others that use public key
cryptography.
2. The KEY RRset may require frequent updates.
3. The probability of compromised or lost keys, which trigger
emergency key rollover procedures, increases.
4. The parent may refuse sign KEY RRsets with non-DNSSEC zone keys.
5. The parent may not meet the child's expectations in turnaround
time for resigning the KEY RRset.
Given these reasons, SIG@parent isn't any better than SIG/KEY@Child.
1.2 Reserved Words
The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
"RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
interpreted as described in RFC2119.
2 Specification of the Delegation key Signer
This section defines the Delegation Signer (DS) RR type (type code
TBD) and the changes to DNS to accommodate it.
2.1 Delegation Signer Record Model
This document presents a replacement for the DNSSEC KEY record chain
of trust [RFC2535] that uses a new RR that resides only at the
parent. This record identifies the key(s) that the child uses to
self-sign its own KEY RRset.
The chain of trust is now established by verifying the parent KEY
RRset, the DS RRset from the parent and the KEY RRset at the child.
This is cryptographically equivalent to using just KEY records.
Communication between the parent and child is greatly reduced, since
the child only needs to notify the parent about changes in keys that
sign its apex KEY RRset. The parent is ignorant of all other keys in
the child's apex KEY RRset. Furthermore, the child maintains full
control over the apex KEY RRset and its content. The child can
maintain any policies regarding its KEY usage for DNSSEC with minimal
impact on the parent. Thus if the child wants to have frequent key
rollover for its DNS zone keys, the parent does not need to be aware
of it. The child can use one key to sign only its apex KEY RRset and
Gudmundsson Expires December 2003 [Page 3]
INTERNET-DRAFT Delegation Signer Record February 2003
a different key to sign the other RRsets in the zone.
This model fits well with a slow roll out of DNSSEC and the islands
of security model. In this model, someone who trusts "good.example."
can preconfigure a key from "good.example." as a trusted key, and
from then on trusts any data signed by that key or that 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. DS records can also be used to identify trusted keys
instead of KEY records. Another significant advantage is that the
amount of information stored in large delegation zones is reduced:
rather than the NULL KEY record at every unsecure delegation required
by RFC 2535, only secure delegations require additional information
in the form of a signed DS RRset.
The main disadvantage of this approach is that verifying a zone's KEY
RRset requires two signature verification operations instead of the
one required by RFC 2535. There is no impact on the number of
signatures verified for other types of RRsets.
Even though DS identifies two roles for KEY's, Key Signing Key (KSK)
and Zone Signing Key (ZSK), there is no requirement that zone use two
different keys for these roles. It is expected that many small zones
will only use one key, while larger organizations will be more likely
to use multiple keys.
2.2 Protocol Change
All DNS servers and resolvers that support DS MUST support the OK bit
[RFC3225] and a larger message size [RFC3226]. In order for a
delegation to be considered secure the delegation MUST contain a DS
RRset. If a query contains the OK bit, a server returning a referral
for the delegation MUST include the following RRsets in the authority
section in this order:
If DS RRset is present:
parents copy of childs NS RRset
DS and SIG(DS)
If no DS RRset is present:
parents copy of childs NS RRset
parents zone NXT and SIG(NXT)
This increases the size of referral messages and possilbly causing
some or all glue to be omitted. If the DS or NXT RRsets with
signatures do not fit in the DNS message, the TC bit MUST be set.
Additional section processing is not changed.
A DS RRset accompanying a NS RRset indicates that the child zone is
secure. If a NS RRset exists without a DS RRset, the child zone is
unsecure (from the parents point of view). DS RRsets MUST NOT appear
Gudmundsson Expires December 2003 [Page 4]
INTERNET-DRAFT Delegation Signer Record February 2003
at non-delegation points or at a zone's apex.
Section 2.2.1 defines special considerations related to authoritative
servers responding to DS queries and replaces RFC2535 sections 2.3.4
and 3.4. Section 2.2.2 replaces RFC3008 section 2.7, and section
2.2.3 updates RFC3090.
2.2.1 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points
DNS security views each zone as a unit of data completely under the
control of the zone owner with each entry (RRset) signed by a special
private key held by the zone manager. But the DNS protocol views the
leaf nodes in a zone that are also the apex nodes of a child zone
(i.e., delegation points) as "really" belonging to the child zone.
The corresponding domain names appear in two master files and might
have RRsets signed by both the parent and child zones' keys. A
retrieval could get a mixture of these RRsets and SIGs, especially
since one server could be serving both the zone above and below a
delegation point [RFC 2181].
Each DS RRset stored in the parent zone MUST be signed by at least
one of the parent zone's private key. The parent zone MUST NOT
contain a KEY RRset at any delegation point. Delegations in the
parent MAY contain only the following RR types: NS, DS, NXT and SIG.
The NS RRset MUST NOT be signed. The NXT RRset is the exceptional
case: it will always appear differently and authoritatively in both
the parent and child zones if both are secure.
A secure zone MUST contain a self-signed KEY RRset at its apex. Upon
verifying the DS RRset from the parent, a resolver MAY trust any KEY
identified in the DS RRset as a valid signer of the child's apex KEY
RRset. Resolvers configured to trust one of the keys signing the KEY
RRset MAY now treat any data signed by the zone keys in the KEY RRset
as secure. In all other cases resolvers MUST consider the zone
unsecure. A DS RRset MUST NOT appear at a zone's apex.
An authoritative server queried for type DS MUST return the DS RRset
in the answer section.
2.2.1.1 Special processing for DS queries
When a server is authoritative for the parent zone at a delegation
point and receives a query for the DS record at that name, it will
return the DS from the parent zone. This is true whether or not it
is also authoritative for the child zone.
Gudmundsson Expires December 2003 [Page 5]
INTERNET-DRAFT Delegation Signer Record February 2003
When the server is authoritative for the child zone at a delegation
point but not the parent zone, there is no natural response, since
the child zone is not authoritative for the DS record at the zone's
apex. As these queries are only expected to originate from recursive
servers which are not DS-aware, the authoritative server MUST answer
with:
RCODE: NOERROR
AA bit: set
Answer Section: Empty
Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
That is, it answers as if it is authoritative and the DS record does
not exist. DS-aware recursive servers will query the parent zone at
delegation points, so will not be affected by this.
A server authoritative for only the child zone at a delegation point
that is also a caching server MAY (if the RD bit is set in the query)
perform recursion to find the DS record at the delegation point, and
may return the DS record from its cache. In this case, the AA bit
MUST not be set in the response.
2.2.1.2 Special processing when child and an ancestor share server"
Special rules are needed to permit DS RR aware servers to gracefully
interact with older caches which otherwise might falsely label a
server as lame because of the new placement of the DS RR set.
Such a situation might arise when a server is authoritative for both
a zone and it's grandparent, but not the parent. This sounds like an
obscure example, but it is very real. The root zone is currently
served on 13 machines, and "root-servers.net." is served on 4 of the
same 13, but "net." is served elsewhere.
When a server receives a query for (<QNAME>, DS, IN), the response
MUST be determined from reading these rules in order:
1) If the server is authoritative for the zone that holds the DS RR
set (i.e., the zone that delegates <QNAME> away, aka the "parent"
zone), the response contains the DS RR set as an authoritative
answer.
2) If the server is offering recursive service and the RD bit is set
in the query, the server performs the query itself (according to the
rules for resolvers described below) and returns it's findings.
3) If the server is authoritative for the zone that holds the
<QNAME>'s SOA RR set, the response is an authoritative negative
Gudmundsson Expires December 2003 [Page 6]
INTERNET-DRAFT Delegation Signer Record February 2003
answer as described in 2.2.1.1.
4) If the server is authoritative for a zone or zones above the
QNAME, a referral to the most enclosing zone's servers is made.
5) If the server is not authoritative for any part of the QNAME, a
response indicating a lame server for QNAME is given.
Using these rules will require some special processing on the part of
a DS RR aware resolver. To illustrate this, an example is used.
Assuming a server is authoritative for roots.example.net. and for the
root zone but not the intervening two zones (or the intervening two
label deep zone). Assume that QNAME=roots.example.net., QTYPE=DS,
and QCLASS=IN.
The resolver will issue this request (assuming no cached data)
expecting a referral to a net. server. Instead, rule number 3 above
applies and a negative answer is returned by the server. The
reaction by the resolver is not to accept this answer as final as it
can determine from the SOA RR in the negative answer the context
within which the server has answered.
A solution to this is to instruct the resolver to hunt for the
authoritative zone of the data in a brute force manner.
This can be accomplished by taking the owner name of the returned SOA
RR and strip off enough left-hand labels until a successful NS
response is obtained. A successful response here means that the
answer has NS records in it. (Entertaining the possibility that a
cut point may be two labels down in a zone.)
Returning to the example, the response will include a negative answer
with either the SOA RR for "roots.example.net." or "example.net."
depending on whether roots.example.net is a delegated domain. In
either case, removing the least significant label of the SOA owner
name will lead to the location of the desired data.
2.2.1.3 Modification on KEY RR in the construction of Responses
This section updates RFC2535 section 3.5 by replacing it with the
following:
An query for KEY RR MUST NOT trigger any additional section
processing. Security aware resolver will include corresponding SIG
records in the answer section.
Gudmundsson Expires December 2003 [Page 7]
INTERNET-DRAFT Delegation Signer Record February 2003
KEY records SHOULD NOT be added to additional records section in
response to any query.
RFC2535 included rules to in add KEY records to additional section
when SOA or NS records where included in an answer. The is was done
to reduce round trips (in the case of SOA) and to force out NULL
KEY's (in the NS case), as this document obsoletes NULL keys there is
no need for the second case, the first case causes redundant
transfers of KEY RRset as SOA is included in the authority section of
negative answers.
RFC2535 section 3.5 also included rule for adding KEY RRset to query
for A and AAAA, as Restrict KEY[RFC3445] eliminated use of KEY RR by
all applications therfore the rule is not needed anymore.
2.2.2 Signer's Name (replaces RFC3008 section 2.7)
The signer's name field of a SIG RR MUST contain the name of the zone
to which the data and signature belong. The combination of signer's
name, key tag, and algorithm MUST identify a zone key if the SIG is
to be considered material. This document defines a standard policy
for DNSSEC validation; local policy may override the standard policy.
There are no restrictions on the signer field of a SIG(0) record.
The combination of signer's name, key tag, and algorithm MUST
identify a key if this SIG(0) is to be processed.
2.2.3 Changes to RFC3090
A number of sections of RFC3090 need to be updated to reflect the DS
record.
2.2.3.1 RFC3090: Updates to section 1: Introduction
Most of the text is still relevant but the words ``NULL key'' are to
be replaced with ``missing DS RRset''. In section 1.3 the last three
paragraphs discuss the confusion in sections of RFC 2535 that are
replaced in section 2.2.1 above. Therefore, these paragraphs are now
obsolete.
2.2.3.2 RFC3090 section 2.1: Globally Secured
Rule 2.1.b is replaced by the following rule:
Gudmundsson Expires December 2003 [Page 8]
INTERNET-DRAFT Delegation Signer Record February 2003
2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a
private key whose public counterpart MUST appear in a zone signing
KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to-
implement algorithm. This KEY RR MUST be identified by a DS RR in a
signed DS RRset in the parent zone.
If a zone cannot get its parent to advertise a DS record for it, the
child zone cannot be considered globally secured. The only exception
to this is the root zone, for which there is no parent zone.
2.2.3.3 RFC3090 section 3: Experimental Status.
The only difference between experimental status and globally secured
is the missing DS RRset in the parent zone. All locally secured zones
are experimental.
2.2.4 NULL KEY elimination
RFC3445 section 3 elminates the top two bits in the flags field of
KEY RR. These two bits where used to indicate NULL KEY or NO KEY.
RFC3090 defines that zone that defines that zone is either secure or
not, eliminates the possible need to put NULL keys in the zone apex
to indicate that the zone is not secured for a algorithm. Along with
this document these other two elminate all uses for the NULL KEY,
Thus this document obsoletes NULL KEY.
2.3 Comments on Protocol Changes
Over the years there have been various discussions surrounding the
DNS delegation model, declaring it to be broken because there is no
good way to assert if a delegation exists. In the RFC2535 version of
DNSSEC, the presence of the NS bit in the NXT bit map proves there is
a delegation at this name. Something more explicit is needed and the
DS record addresses this need for secure delegations.
The DS record is a major change to DNS: it is the first resource
record that can appear only on the upper side of a delegation. Adding
it will cause interoperabilty problems and requires a flag day for
DNSSEC. Many old servers and resolvers MUST be upgraded to take
advantage of DS. Some old servers will be able to be authoritative
for zones with DS records but will not add the NXT or DS records to
the authority section. The same is true for caching servers; in
fact, some may even refuse to pass on the DS or NXT records.
Gudmundsson Expires December 2003 [Page 9]
INTERNET-DRAFT Delegation Signer Record February 2003
2.4 Wire Format of the DS record
The DS (type=TDB) record contains these fields: key tag, algorithm,
digest type, and the digest of a public key KEY record that is
allowed and/or used to sign the child's apex KEY RRset. Other keys
MAY sign the child's apex KEY RRset.
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 | algorithm | Digest type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| digest (length depends on type) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (SHA-1 digest is 20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The key tag is calculated as specified in RFC2535. Algorithm MUST be
an algorithm number assigned in the range 1..251 and the algorithm
MUST be allowed to sign DNS data. The digest type is an identifier
for the digest algorithm used. The digest is calculated over the
canonical name of the delegated domain name followed by the whole
RDATA of the KEY record (all four fields).
digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata)
KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key
Digest type value 0 is reserved, value 1 is SHA-1, and reserving
other types requires IETF standards action. For interoperabilty
reasons, as few digest algorithms as possible should be reserved. The
only reason to reserve additional digest types is to increase
security.
DS records MUST point to zone KEY records that are allowed to
authenticate DNS data. The indicated KEY record's protocol field
MUST be set to 3; flag field bit 7 MUST be set to 1. The value of
other flag bits is not significant for the purposes of this document.
The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless
of key size, new digest types probably will have larger digests.
Gudmundsson Expires December 2003 [Page 10]
INTERNET-DRAFT Delegation Signer Record February 2003
2.4.1 Justifications for Fields
The algorithm and key tag fields are present to allow resolvers to
quickly identify the candidate KEY records to examine. SHA-1 is a
strong cryptographic checksum: it is computationally infeasible for
an attacker to generate a KEY record that has the same SHA-1 digest.
Combining the name of the key and the key rdata as input to the
digest provides stronger assurance of the binding. Having the key
tag in the DS record adds greater assurance than the SHA-1 digest
alone, as there are now two different mapping functions that a KEY RR
must match.
This format allows concise representation of the keys that the child
will use, thus keeping down the size of the answer for the
delegation, reducing the probability of DNS message overflow. The
SHA-1 hash is strong enough to uniquely identify the key and is
similar to the PGP key footprint. The digest type field is present
for possible future expansion.
The DS record is well suited to listing trusted keys for islands of
security in configuration files.
2.5 Presentation Format of the DS Record
The presentation format of the DS record consists of three numbers
(key tag, algorithm and digest type) followed by the digest itself
presented in hex:
example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890
2.6 Transition Issues for Installed Base
No backwards compatibility with RFC2535 is provided.
RFC2535-compliant resolvers will assume that all DS-secured
delegations are locally secure. This is bad, but the DNSEXT Working
Group has determined that rather than dealing with both
RFC2535-secured zones and DS-secured zones, a rapid adoption of DS is
preferable. Thus the only option for early adopters is to upgrade to
DS as soon as possible.
2.6.1 Backwards compatibility with RFC2535 and RFC1035
This section documents how a resolver determines the type of
delegation.
RFC1035 delegation (in parent) has:
RFC1035 NS
RFC2535 adds the following two cases:
Gudmundsson Expires December 2003 [Page 11]
INTERNET-DRAFT Delegation Signer Record February 2003
Secure RFC2535: NS + NXT + SIG(NXT)
NXT bit map contains: NS SIG NXT
Unsecure RFC2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT)
NXT bit map contains: NS SIG KEY NXT
KEY must be a NULL key.
DNSSEC with DS has the following two states:
Secure DS: NS + DS + SIG(DS)
NXT bit map contains: NS SIG NXT DS
Unsecure DS: NS + NXT + SIG(NXT)
NXT bit map contains: NS SIG NXT
It is difficult for a resolver to determine if a delegation is secure
RFC 2535 or unsecure DS. This could be overcome by adding a flag to
the NXT bit map, but only upgraded resolvers would understand this
flag, anyway. Having both parent and child signatures for a KEY RRset
might allow old resolvers to accept a zone as secure, but the cost of
doing this for a long time is much higher than just prohibiting RFC
2535-style signatures at child zone apexes and forcing rapid
deployment of DS-enabled servers and resolvers.
RFC 2535 and DS can in theory be deployed in parallel, but this would
require resolvers to deal with RFC 2535 configurations forever. This
document obsoletes the NULL KEY in parent zones, which is a difficult
enough change that a flag day is required.
2.7 KEY and corresponding DS record example
This is an example of a KEY record and the corresponding DS record.
dskey.example. KEY 256 3 1 (
AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj
4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt
) ; key id = 28668
DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
Gudmundsson Expires December 2003 [Page 12]
INTERNET-DRAFT Delegation Signer Record February 2003
3 Resolver
3.1 DS Example
To create a chain of trust, a resolver goes from trusted KEY to DS to
KEY.
Assume the key for domain "example." is trusted. Zone "example."
contains at least the following records:
example. SOA <soa stuff>
example. NS ns.example.
example. KEY <stuff>
example. NXT NS SOA KEY SIG NXT secure.example.
example. SIG(SOA)
example. SIG(NS)
example. SIG(NXT)
example. SIG(KEY)
secure.example. NS ns1.secure.example.
secure.example. DS tag=12345 alg=3 digest_type=1 <foofoo>
secure.example. NXT NS SIG NXT DS unsecure.example.
secure.example. SIG(NXT)
secure.example. SIG(DS)
unsecure.example NS ns1.unsecure.example.
unsecure.example. NXT NS SIG NXT example.
unsecure.example. SIG(NXT)
In zone "secure.example." following records exist:
secure.example. SOA <soa stuff>
secure.example. NS ns1.secure.example.
secure.example. KEY <tag=12345 alg=3>
secure.example. KEY <tag=54321 alg=5>
secure.example. NXT <nxt stuff>
secure.example. SIG(KEY) <key-tag=12345 alg=3>
secure.example. SIG(SOA) <key-tag=54321 alg=5>
secure.example. SIG(NS) <key-tag=54321 alg=5>
secure.example. SIG(NXT) <key-tag=54321 alg=5>
In this example the private key for "example." signs the DS record
for "secure.example.", making that a secure delegation. The DS record
states which key is expected to sign the KEY RRset at
"secure.example.". Here "secure.example." signs its KEY RRset with
the KEY identified in the DS RRset, thus the KEY RRset is validated
and trusted.
This example has only one DS record for the child, but parents MUST
allow multiple DS records to facilitate key rollover and multiple KEY
algorithms.
Gudmundsson Expires December 2003 [Page 13]
INTERNET-DRAFT Delegation Signer Record February 2003
The resolver determines the security status of "unsecure.example." by
examining the parent zone's NXT record for this name. The absence of
the DS bit indicates an unsecure delegation. Note the NXT record
SHOULD only be examined after verifying the corresponding signature.
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 RRset has to be verified.
Additional RRsets might also need to be verified based on local
policy (e.g., the contents of the NS RRset). Once the resolver gets
to the appropriate delegation, validating the answer might require
verifying one or more signatures. A simple A record lookup requires
at least N delegations to be verified and one RRset. For a DS-enabled
resolver, the cost is 2N+1. For an MX record, where the target of
the MX record is in the same zone as the MX record, the costs are N+2
and 2N+2, for RFC 2535 and DS, respectively. In the case of negatives
answer the same ratios hold true.
The resolver may require an extra query to get the DS record 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 and increases the size of
delegation answers, but much less than storing signatures in the
parent zone.
4 Security Considerations:
This document proposes a change to the validation chain of KEY
records in DNSSEC. The change is not believed to reduce security in
the overall system. In RFC2535 DNSSEC, the child zone has to
communicate keys to its parent and prudent parents will require some
authentication with that transaction. The modified protocol will
require the same authentication, but allows the child to exert more
local control over its own KEY RRset.
There is a remote possibility that an attacker could generate a valid
KEY that matches all the DS fields, of a specific DS set, and thus
forge data from the child. This possibility is considered
impractical, as on average more than
2 ^ (160 - <Number of keys in DS set>)
keys would have to be generated before a match would be found.
An attacker that wants to match any DS record will have to generate
on average at least 2^80 keys.
The DS record represents a change to the DNSSEC protocol and there is
an installed base of implementations, as well as textbooks on how to
Gudmundsson Expires December 2003 [Page 14]
INTERNET-DRAFT Delegation Signer Record February 2003
set up secure delegations. Implementations that do not understand the
DS record will not be able to follow the KEY to DS to KEY chain and
will consider all zones secured that way as unsecure.
5 IANA Considerations:
IANA needs to allocate an RR type code for DS from the standard RR
type space (type 43 requested).
IANA needs to open a new registry for the DS RR type for digest
algorithms. Defined types are:
0 is Reserved,
1 is SHA-1.
Adding new reservations requires IETF standards action.
6 Acknowledgments
Over the last few years a number of people have contributed ideas
that are captured in this document. The core idea of using one key to
sign only the KEY RRset comes from discussions with Bill Manning and
Perry Metzger on how to put in a single root key in all resolvers.
Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie, Jakob
Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt Larson,
Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker, Miek
Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David
Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark
Andrews, Harald Alvestrand, and others have provided useful comments.
Normative 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.
[RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC
3225, December 2001.
[RFC3445] D. Massey, S. Rose ``Limiting the scope of the KEY Resource
Record (RR)``, RFC 3445, December 2002.
Gudmundsson Expires December 2003 [Page 15]
INTERNET-DRAFT Delegation Signer Record February 2003
Informational References
[RFC2181] R. Elz, R. Bush, ``Clarifications to the DNS Specification'',
RFC 2181, July 1997.
[RFC3226] O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver
message size requirements'', RFC 3226, December 2001.
Author Address
Olafur Gudmundsson
3821 Village Park Drive
Chevy Chase, MD, 20815
USA
<ogud@ogud.com>
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 December 2003 [Page 16]

560
doc/draft/draft-ietf-dnsext-dhcid-rr-06.txt Normal file
View file

@ -0,0 +1,560 @@
DNSEXT Working Group M. Stapp
Internet-Draft Cisco Systems, Inc.
Expires: May 2, 2003 T. Lemon
A. Gustafsson
Nominum, Inc.
November 1, 2002
A DNS RR for Encoding DHCP Information (DHCID RR)
<draft-ietf-dnsext-dhcid-rr-06.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 2, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). 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 May 2, 2003 [Page 1]
Internet-Draft The DHCID RR November 2002
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . . 4
3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . . 4
3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . . 4
3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . . 5
3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . 6
5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
References . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
Full Copyright Statement . . . . . . . . . . . . . . . . . . 10
Stapp, et. al. Expires May 2, 2003 [Page 2]
Internet-Draft The DHCID RR November 2002
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]. The
DHCID RR is only defined in the IN class. DHCID RRs cause no
additional section processing. The DHCID RR is not a singleton type.
Stapp, et. al. Expires May 2, 2003 [Page 3]
Internet-Draft The DHCID RR November 2002
3.1 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. 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 identical to that used for representing binary data
in RFC2535[7]. The data 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.
3.3 The DHCID RR Type Codes
The DHCID RR Type Code specifies what data from the DHCP client's
request was used as input into the hash function. The type codes are
defined in a registry maintained by IANA, as specified in Section 7.
The initial list of assigned values for the type code is:
0x0000 = htype, chaddr from a DHCPv4 client's
DHCPREQUEST (RFC 2131)
0x0001 = The data portion from a DHCPv4 client's Client
Identifier option (RFC 2132)
0x0002 = The data portion (i.e., the DUID) from a DHCPv6
client's Client Identifier option
(draft-ietf-dhc-dhcpv6-*.txt)
0x0003 - 0xfffe = Available to be assigned by IANA
0xffff = RESERVED
Stapp, et. al. Expires May 2, 2003 [Page 4]
Internet-Draft The DHCID RR November 2002
3.4 Computation of the RDATA
The DHCID RDATA is formed by concatenating the two type bytes with
some variable-length identifying data.
< type > < data >
The RDATA for all type codes other than 0xffff, which is reserved
for future expansion, is formed by concatenating the two type bytes
and a 16-byte MD5 hash value. The input to the hash function is
defined to be:
data = MD5(< identifier > < FQDN >)
The FQDN is represented in the buffer in unambiguous canonical form
as described in RFC2535[7], section 8.1. The type code and the
identifier are related as specified in Section 3.3: the type code
describes the source of the identifier.
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 the DHCPv4 Client Identifier option sent
by the client in its DHCPREQUEST message, the first two bytes of the
DHCID RR MUST be 0x0001, in network byte order. The rest of the
DHCID RR MUST contain the results of computing an MD5 hash across
the payload of the option, followed by the FQDN. The payload of the
option consists of the bytes of the option following the option code
and length.
When the updater is using the DHCPv6 DUID sent by the client in its
REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002,
in network byte order. The rest of the DHCID RR MUST contain the
results of computing an MD5 hash across the payload of the option,
followed by the FQDN. The payload of the option consists of the
bytes of the option following the option code and length.
Stapp, et. al. Expires May 2, 2003 [Page 5]
Internet-Draft The DHCID RR November 2002
3.5 Examples
3.5.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.example.com" 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.example.com. A 10.0.0.1
client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU
3.5.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.example.com" 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 value
0x0001, 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.example.com. A 10.0.12.99
chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012
4. 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].
5. 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.
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,
Stapp, et. al. Expires May 2, 2003 [Page 6]
Internet-Draft The DHCID RR November 2002
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.
6. 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
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[10]) when performing DNS updates.
7. IANA Considerations
IANA is requested to allocate an RR type number for the DHCID record
type.
This specification defines a new number-space for the 16-bit type
codes associated with the DHCID RR. IANA is requested to establish a
registry of the values for this number-space.
Three initial values are assigned in Section 3.3, and the value
0xFFFF is reserved for future use. New DHCID RR type codes are
tentatively assigned after the specification for the associated type
code, published as an Internet Draft, has received expert review by
a designated expert. The final assignment of DHCID RR type codes is
through Standards Action, as defined in RFC2434[11].
8. Acknowledgements
Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz,
and Ralph Droms for their review and suggestions.
References
[1] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP
Stapp, et. al. Expires May 2, 2003 [Page 7]
Internet-Draft The DHCID RR November 2002
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] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
(draft-ietf-dhc-dhcpv6-*.txt)", November 2002.
[10] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
Authors' Addresses
Mark Stapp
Cisco Systems, Inc.
250 Apollo Dr.
Chelmsford, MA 01824
USA
Phone: 978.244.8498
EMail: mjs@cisco.com
Stapp, et. al. Expires May 2, 2003 [Page 8]
Internet-Draft The DHCID RR November 2002
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 May 2, 2003 [Page 9]
Internet-Draft The DHCID RR November 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
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 May 2, 2003 [Page 10]

1288
doc/draft/draft-ietf-dnsext-dnssec-intro-05.txt Normal file
View file

File diff suppressed because it is too large Load diff

1456
doc/draft/draft-ietf-dnsext-dnssec-opt-in-05.txt Normal file
View file

File diff suppressed because it is too large Load diff

2296
doc/draft/draft-ietf-dnsext-dnssec-protocol-01.txt Normal file
View file

File diff suppressed because it is too large Load diff

1848
doc/draft/draft-ietf-dnsext-dnssec-records-03.txt Normal file
View file

File diff suppressed because it is too large Load diff

896
doc/draft/draft-ietf-dnsext-dnssec-roadmap-07.txt Normal file
View file

@ -0,0 +1,896 @@
DNS Extensions S. Rose
Internet-Draft NIST
Expires: August 5, 2003 February 4, 2003
DNS Security Document Roadmap
draft-ietf-dnsext-dnssec-roadmap-07
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 5, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
DNS Security (DNSSEC) technology is composed of extensions to the
Domain Name System (DNS) protocol that provide data integrity and
authentication to security aware resolvers and applications through
the use of cryptographic digital signatures. Several documents exist
to describe these extensions and the implementation-specific details
regarding specific digital signing schemes. The interrelationship
between these different documents is discussed here. A brief
overview of what to find in which document and author guidelines for
what to include in new DNS Security documents, or revisions to
existing documents, is described.
Rose Expires August 5, 2003 [Page 1]
Internet-Draft DNSSEC Document Roadmap February 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Interrelationship of DNS Security Documents . . . . . . . . . 4
3. Relationship of DNS Security Documents to other DNS
Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Recommended Content for new DNS Security Documents . . . . . . 9
4.1 Security Related Resource Records . . . . . . . . . . . . . . 9
4.2 Digital Signature Algorithm Implementations . . . . . . . . . 9
4.3 Refinement of Security Procedures . . . . . . . . . . . . . . 10
4.4 The Use of DNS Security Extensions with Other Protocols . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
Normative References . . . . . . . . . . . . . . . . . . . . . 13
Informative References . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16
Rose Expires August 5, 2003 [Page 2]
Internet-Draft DNSSEC Document Roadmap February 2003
1. Introduction
This document is intended to provide guidelines for the development
of supplemental documents describing security extensions to the
Domain Name System (DNS).
The main goal of the DNS Security (DNSSEC) extensions is to add data
authentication and integrity services to the DNS protocol. These
protocol extensions should be differentiated from DNS operational
security issues, which are beyond the scope of this effort. DNS
Security documents fall into one or possibly more of the following
sub-categories: new DNS security resource records, implementation
details of specific digital signing algorithms for use in DNS
Security and DNS transaction authentication. Since the goal of DNS
Security extensions is to become part of the DNS protocol standard,
additional documents that seek to refine a portion of the security
extensions will be introduced as the specifications progress along
the IETF standards track.
There is a set of basic guidelines for each sub-category of documents
that explains what should be included, what should be considered a
protocol extension, and what should be considered an operational
issue. Currently, there are at least two documents that fall under
operational security considerations that deal specifically with the
DNS security extensions: the first is RFC 2541 [6] which deals with
the operational side of implementing the security extensions; the
other is the CAIRN DNSSEC testbed Internet draft [CAIRN]. These
documents should be considered part of the operational side of DNS,
but will be addressed as a supplemental part of the DNS Security
roadmap. That is not to say that these two documents are not
important to securing a DNS zone, but they do not directly address
the proposed DNS security extensions. Authors of documents that seek
to address the operational concerns of DNS security should be aware
of the structure of DNS Security documentation.
It is assumed the reader has some knowledge of the Domain Name System
[2] and the Domain Name System Security Extensions.
Rose Expires August 5, 2003 [Page 3]
Internet-Draft DNSSEC Document Roadmap February 2003
2. Interrelationship of DNS Security Documents
The DNSSEC set of documents can be partitioned into five main groups
as depicted in Figure 1. All of these documents in turn are under
the larger umbrella group of DNS base protocol documents. It is
possible that some documents fall into more than one of these
categories, such as RFC 2535, and should follow the guidelines for
the all of the document groups it falls into. However, it is wise to
limit the number of "uberdocuments" that try to be everything to
everyone. The documents listed in each category are current as to
the time of writing.
Rose Expires August 5, 2003 [Page 4]
Internet-Draft DNSSEC Document Roadmap February 2003
---------------------------------------------------------------------
+--------------------------------+
| |
| Base DNS Protocol Docs. |
| [RFC1035, RFC2181, etc.] |
| |
+--------------------------------+
|
|
|
+------------+ +-----------+ +-------------+
| New | | DNSSEC | | New |
| Security |----------| protocol |----------| Security |
| RRs | | | | Uses |
+------------+ | | +-------------+
+-----------+
|
|
+----------------------+***********************
| * *
| * *
+------------+ +---------------+ +-*-*-*-*-*-*-*-*-+
| DS | | | | Implementation |
| Algorithm | | Transactions | * Notes *
| Impl. | | | | |
+------------+ +---------------+ +-*-*-*-*-*-*-*-*-+
DNSSEC Document Roadmap
---------------------------------------------------------------------
The "DNSSEC protocol" document set refers to the document that makes
up the groundwork for adding security to the DNS protocol [1]and
updates to this document. RFC 2535 laid out the goals and
expectations of DNS Security and the new security-related Resource
Records KEY, SIG, DS, and NXT [23]. Expanding from this document,
related document groups include the implementation documents of
various digital signature algorithms with DNSSEC, and documents
further refining the transaction of messages. It is expected that
RFC 2535 will be obsoleted by one or more documents that refine the
set of security extensions [22], [23], [24]. Documents that seek to
modify or clarify the base protocol documents should state so clearly
Rose Expires August 5, 2003 [Page 5]
Internet-Draft DNSSEC Document Roadmap February 2003
in the introduction of the document (as well as proscribe to the IETF
guidelines of RFC/Internet Draft author guidelines). Also, the
portions of the specification to be modified should be synopsized in
the new document for the benefit of the reader. The "DNSSEC
protocol" set includes the documents [1], [11], [12], [9], [14],
[15], [21], [16], [OPTIN], [17] and their derivative documents.
The "New Security RRs" set refers to the group of documents that seek
to add additional Resource Records to the set of base DNS Record
types. These new records can be related to securing the DNS protocol
[1], [8], or using DNS security for other purposes such as storing
certificates [5]. Another related document is [26]. While not
detailing a new RR type, it defines a flag bit in the existing KEY
RR. This flag bit does not affect the protocol interpretation of the
RR, only a possible operational difference. Therefore, this draft is
place here and not with the protocol document set.
The "DS Algorithm Impl" document set refers to the group of documents
that describe how a specific digital signature algorithm is
implemented to fit the DNSSEC Resource Record format. Each one of
these documents deals with one specific digital signature algorithm.
Examples of this set include [4], [5], [25], [19][18] and [13].
The "Transactions" document set refers to the group of documents that
deal with the message transaction sequence of security-related DNS
operations. The contents and sequence for operations such as dynamic
update [3], [11] and transaction signatures [10] are described in
this document category. Additional message transaction schemes to
support DNSSEC operation would also fall under this group, including
secret key establishment [7], [RENEW], and verification.
The final document set, "New Security Uses", refers to documents that
seek to use proposed DNS Security extensions for other security
related purposes. Documents that fall in this category include the
use of DNS in the storage and distribution of certificates and
individual user public keys (PGP, e-mail, etc.) Some documents in
this group may fall beyond the DNSEXT WG scope, but they are included
because of their use of the security extensions. The documents in
this group should not propose any changes to the DNS protocol to
support other protocols; only how existing DNS security records and
transactions can be used to support other protocols. Such documents
include [SSH-DNS] and [IPSEC-DNS] which deals with storing SSH and
IPSec keying information the DNS using new records and utilizing
DNSSEC to provide authentication and integrity checking.
Lastly, there is a set of documents that should be classified as
"Implementation Notes". Because the DNS security extensions are
still in the developmental stage, there is an audience for documents
Rose Expires August 5, 2003 [Page 6]
Internet-Draft DNSSEC Document Roadmap February 2003
that detail the transition and implementation of the security
extensions. These have more to do with the practical side of DNS
operations, but can also point to places in the protocol
specifications that need improvement. An example of this type is the
report on the CAIRN DNSSEC testbed [CAIRN] This document was
submitted through the DNSOP Working Group at the time of this
writing, however the main concern of this document is the
implementation and limitations of the DNS security extensions, hence
their interest to the DNS security community. The CAIRN draft deals
with the implementation of a secure DNS. Authors of documents that
deal with the implementation and operational side of the DNSSEC
specifications would be advised/encouraged to submit their documents
to any other relevant DNS related WG meeting in the problem space.
Rose Expires August 5, 2003 [Page 7]
Internet-Draft DNSSEC Document Roadmap February 2003
3. Relationship of DNS Security Documents to other DNS Documents
The DNS security-related extensions should be considered a subset of
the DNS protocol. Therefore, all DNS security-related documents
should be seen as a subset of the main DNS architecture documents.
It is a good idea for authors of future DNS security documents to be
familiar with the contents of these base protocol documents.
Rose Expires August 5, 2003 [Page 8]
Internet-Draft DNSSEC Document Roadmap February 2003
4. Recommended Content for new DNS Security Documents
Documents that seek to make additions or revisions to the DNS
protocol to add security should follow common guidelines as to
minimum required content and structure. It is the purpose of this
document roadmap to establish criteria for content that any new DNS
security protocol specifications document should contain. These
criteria should be interpreted as a minimum set of information
required/needed in a document, any additional information regarding
the specific extension should also be included in the document.
These criteria are not officially part of the IETF guidelines
regarding RFC/Internet Drafts, but should be considered as guidance
to promote uniformity to Working Group documents.
Since the addition of security to the DNS protocol is now considered
a general extension to the DNS protocol, any guideline for the
contents of a DNS Security document could be taken as a framework
suggestion for the contents of any DNS extension document. The
development process of the DNS security extensions could be used as a
model framework for any, more general DNS extensions.
4.1 Security Related Resource Records
Documents describing a new type of DNS Security Resource Record (RR)
should contain information describing the structure and use of the
new RR type. It is a good idea to only discuss one new type in a
document, unless the set of new resource records are closely related
or a protocol extension requires the use of more than one new record
type. Specifically, each document detailing a new security-related
RR type should include the following information:
o The format of the new RR type, both "on the wire" (bit format) and
ASCII representation (for text zone files), if appropriate;
o when and in what section of a DNS query/response this new RR type
is to be included;
o at which level of the DNS hierarchy this new RR type is to be
considered authoritative (i.e. in a zone, in a zone's superzone)
and who is authoritative to sign the new RR;
4.2 Digital Signature Algorithm Implementations
Documents describing the implementation details of a specific digital
signature algorithm such as [4] ,[13] (and others as new digital
signatures schemes are introduced) for use with DNS Security should
include the following information:
Rose Expires August 5, 2003 [Page 9]
Internet-Draft DNSSEC Document Roadmap February 2003
o The format/encoding of the algorithm's public key for use in a KEY
Resource Record;
o the acceptable key size for use with the algorithm;
o the current known status of the algorithm (as one of REQUIRED,
RECOMMENDED, or OPTIONAL).
In addition, authors are encouraged to include any necessary
description of the algorithm itself, as well as any know/suspected
weaknesses as an appendix to the document. This is for reference
only, as the goals of the DNSEXT working group is to propose
extensions to the DNS protocol, not cryptographic research.
4.3 Refinement of Security Procedures
This set of documents includes DNS protocol operations that
specifically relate to DNS Security, such as DNS secret key
establishment [7] and security extensions to pre-existing or
proposed DNS operations such as dynamic update [3]. Documents that
describe a new set of DNS message transactions, or seek to refine a
current series of transactions that make up a DNS operation should
include the following information:
o The order in which the DNS messages are sent by the operation
initiator and target;
o the format of these DNS messages;
o any required authentication mechanisms for each stage of the
operation and the required authority for that mechanism (i.e.
zone, host, or some other trusted authority such as a DNS
administrator or certificate authority);
4.4 The Use of DNS Security Extensions with Other Protocols
Because of the flexibility and ubiquity of the DNS, there may exist
other Internet protocols and applications that could make use of, or
extend, the DNS security protocols. Examples of this type of
document include the use of DNS to support IPSEC [IPSEC-DNS], SSH
[SSH-DNS] the Public Key Infrastructure (PKI). It is beyond the
scope of this roadmap to describe the contents of this class of
documents. However, if uses or extensions require the addition or
modification of a DNS Resource Record type or DNS query/response
transactions, then the guidelines laid out in the previous sections
of this document should be adhered to.
Rose Expires August 5, 2003 [Page 10]
Internet-Draft DNSSEC Document Roadmap February 2003
5. Security Considerations
This document provides a roadmap and guidelines for writing DNS
Security related documents. This document does not discuss the
aspects of the DNS security extensions. The reader should refer to
the documents outlined here for the details of the services and
shortcomings of DNS security.
Rose Expires August 5, 2003 [Page 11]
Internet-Draft DNSSEC Document Roadmap February 2003
6. Acknowledgements
In addition to the RFCs mentioned in this document, there are also
numerous Internet drafts that fall in one or more of the categories
of DNS Security documents mentioned above. Depending on where (and
if) these documents are on the IETF standards track, the reader may
not be able to access these documents through the RFC repositories.
All of these documents are "Work in Progress" and are subject to
change; therefore a version number is not supplied for the current
revision. Some Internet Drafts are in the RFC editor's queue or
nearing WG Last Call at the time of writing. These Drafts have been
placed in the References section. The drafts below are still subject
to agreement in the IETF.
o CAIRN: D. Massey, T. Lehman, and E. Lewis. "DNSSEC
Implementation in the CAIRN Testbed". draft-ietf-dnsop-
dnsseccairn-NN.txt
o OPTIN: M. Kosters. "DNSSEC Opt-in for Large Zones" draft-
kosters-dnsext-dnssec-opt-in-NN.txt
o SSH-DNS: W. Griffin, J. Schlyter. "Using DNS to securely
publish SSH key fingerprints" draft-ietf-secsh-dns-NN.txt
o IPSEC-DNS: M. Richardson. "A method for storing IPsec keying
material in DNS". draft-richardson-ipsec-rr-NN.txt
o RENEW: Y. Kamite, M. Nakayama. "TKEY Secret Key Renewal Mode".
draft-ietf-dnsext-tkey-renewal-mode-NN.txt
Rose Expires August 5, 2003 [Page 12]
Internet-Draft DNSSEC Document Roadmap February 2003
Normative References
[1] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
2137, April 1997.
[4] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[5] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
Domain Name System (DNS)", RFC 2538, March 1999.
[6] Eastlake, D., "DNS Security Operational Considerations", RFC
2541, March 1999.
[7] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
2930, September 2000.
[8] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.
[9] Lewis, E., "DNS Security Extension Clarification on Zone
Status", RFC 3090, March 2001.
[10] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[11] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[12] Wellington, B., "Domain Name System Security (DNSSEC) Signing
Authority", RFC 3008, April 2000.
[13] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
System (DNS)", RFC 3110, May 2001.
[14] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
December 2001.
[15] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
message size requirements", RFC 3226, December 2001.
Rose Expires August 5, 2003 [Page 13]
Internet-Draft DNSSEC Document Roadmap February 2003
[16] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
Record (RR)", RFC 3445, December 2002.
Rose Expires August 5, 2003 [Page 14]
Internet-Draft DNSSEC Document Roadmap February 2003
Informative References
[17] Austein, R. and D. Atkins, "Threat Analysis of the Domain Name
System (Work in Progress)", RFC XXXX.
[18] Eastlake, R., "Storage of Diffie-Hellman Keys in the Domain
Name System (DNS) (Work in Progress)", RFC XXXX.
[19] Eastlake, D. and R. Schroeppel, "Elliptic Curve KEYs in the DNS
(Work in Progress)", RFC XXXX.
[20] Gundmundsson, O., "Delegation Signer Record in Parent (Work in
Progress)", RFC XXXX.
[21] Wellington, B., "Redefinition of the DNS AD bit (Work in
Progress)", RFC XXXX.
[22] Arends, R., Larson, M., Massey, D. and S. Rose, "DNS Security
Introduction and Requirements (Work in Progress)", RFC XXXX.
[23] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource
Records for DNS Security Extensions (Work in Progress)", RFC
XXXX.
[24] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol
Modifications for the DNS Security Extensions (Work in
Progress)", RFC XXXX.
[25] Kwan, S., Garg, P., Gilroy, J. and L. Esibov, "GSS Algorithm
for TSIG (Work in Progress)", RFC XXXX.
[26] Kolkman, O. and J. Schlyter, "KEY RR Key-Signing-Key (KSK) Flag
(Work in Progress)", RFC XXXX.
Author's Address
Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899-3460
USA
EMail: scott.rose@nist.gov
Rose Expires August 5, 2003 [Page 15]
Internet-Draft DNSSEC Document Roadmap February 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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.
Rose Expires August 5, 2003 [Page 16]

812
doc/draft/draft-ietf-dnsext-ecc-key-03.txt Normal file
View file

@ -0,0 +1,812 @@
INTERNET-DRAFT ECC Keys in the DNS
Expires: June 2003 December 2002
Elliptic Curve KEYs in the DNS
-------- ----- ---- -- --- ---
<draft-ietf-dnsext-ecc-key-03.txt>
Richard C. Schroeppel
Donald Eastlake 3rd
Status of This Document
This draft is intended to be become a Proposed Standard RFC.
Distribution of this document is unlimited. Comments should be sent
to the DNS mailing list <namedroppers@internic.com> or to the
authors.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. 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.
Abstract
A standard method for storing elliptic curve cryptographic keys in
the Domain Name System is described which utilizes DNS KEY resource
record.
R. Schroeppel, et al [Page 1]
INTERNET-DRAFT ECC Keys in the DNS
Acknowledgement
The assistance of Hilarie K. Orman in the production of this document
is greatfully acknowledged.
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Acknowledgement............................................2
Table of Contents..........................................2
1. Introduction............................................3
2. Elliptic Curve KEY Resource Records.....................3
3. The Elliptic Curve Equation.............................9
4. How do I Compute Q, G, and Y?..........................10
5. Performance Considerations.............................11
6. Security Considerations................................11
7. IANA Considerations....................................11
References................................................13
Authors' Addresses........................................14
Expiration and File Name..................................14
R. Schroeppel, et al [Page 2]
INTERNET-DRAFT ECC Keys in the DNS
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information. The DNS has been extended to include digital
signatures and cryptographic keys as described in [RFC 2535].
This document describes how to store elliptic curve cryptographic
(ECC) keys in the DNS so they can be used for a variety of security
purposes. A DNS elliptic curve SIG resource record is not defined.
Familiarity with ECC cryptography is assumed [Menezes].
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. Elliptic Curve KEY Resource Records
Elliptic curve public keys are stored in the DNS as KEY RRs using
algorithm number 4 (see [RFC 2535]). The structure of the RDATA
portion of this RR is as shown below. The first 4 octets, including
the flags, protocol, and algorithm fields are common to all KEY RRs.
The remainder is the "public key" part of the KEY RR.
The period of key validity is not in the KEY RR but is indicated by
the SIG RR(s) which signs and authenticates the KEY RR(s) at that
domain name and class.
The research world continues to work on the issue of which is the
best elliptic curve system, which finite field to use, and how to
best represent elements in the field. So, we have defined
representations for every type of finite field, and every type of
elliptic curve. The reader should be aware that there is a unique
finite field with a particular number of elements, but many possible
representations of that field and its elements. If two different
representations of a field are given, they are interconvertible with
a tedious but practical precomputation, followed by a fast
computation for each field element to be converted. It is perfectly
reasonable for an algorithm to work internally with one field
representation, and convert to and from a different external
representation.
R. Schroeppel, et al [Page 3]
INTERNET-DRAFT ECC Keys in the DNS
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 flags | protocol | algorithm=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S M -FMT- A B Z|
+-+-+-+-+-+-+-+-+
| LP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P (length determined from LP) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F (length determined from LF) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEGH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEGI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DEGJ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRDV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H (length determined from LH) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| LK |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| K (length determined from LK) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Q (length determined from LQ) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A (length determined from LA) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ALTA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B (length determined from LB) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C (length determined from LC) .../
R. Schroeppel, et al [Page 4]
INTERNET-DRAFT ECC Keys in the DNS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| G (length determined from LG) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LY |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Y (length determined from LY) .../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SMFMTABZ is a flags octet as follows:
S = 1 indicates that the remaining 7 bits of the octet selects
one of 128 predefined choices of finite field, element
representation, elliptic curve, and signature parameters.
MFMTABZ are omitted, as are all parameters from LP through G.
LY and Y are retained.
If S = 0, the remaining parameters are as in the picture and
described below.
M determines the type of field underlying the elliptic curve.
M = 0 if the field is a GF[2^N] field;
M = 1 if the field is a (mod P) or GF[P^D] field with P>2.
FMT is a three bit field describing the format of the field
representation.
FMT = 0 for a (mod P) field.
> 0 for an extension field, either GF[2^D] or GF[P^D].
The degree D of the extension, and the field polynomial
must be specified. The field polynomial is always monic
(leading coefficient 1.)
FMT = 1 The field polynomial is given explicitly; D is implied.
If FMT >=2, the degree D is given explicitly.
= 2 The field polynomial is implicit.
= 3 The field polynomial is a binomial. P>2.
= 4 The field polynomial is a trinomial.
= 5 The field polynomial is the quotient of a trinomial by a
short polynomial. P=2.
= 6 The field polynomial is a pentanomial. P=2.
Flags A and B apply to the elliptic curve parameters.
R. Schroeppel, et al [Page 5]
INTERNET-DRAFT ECC Keys in the DNS
A = 1 When P>=5, the curve parameter A is negated. If P=2, then
A=1 indicates that the A parameter is special. See the
ALTA parameter below, following A. The combination A=1,
P=3 is forbidden.
B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3,
then B=1 indicates an alternate elliptic curve equation is
used. When P=2 and B=1, an additional curve parameter C
is present.
The Z bit SHOULD be set to zero on creation of KEY RR and MUST
be ignored when processing a KEY RR (when S=0).
Most of the remaining parameters are present in some formats and
absent in others. The presence or absence of a parameter is
determined entirely by the flags. When a parameter occurs, it is in
the order defined by the picture.
Of the remaining parameters, PFHKQABCGY are variable length. When
present, each is preceded by a one-octet length field as shown in the
diagram above. The length field does not include itself. The length
field may have values from 0 through 110. The parameter length in
octets is determined by a conditional formula: If LL<=64, the
parameter length is LL. If LL>64, the parameter length is 16 times
(LL-60). In some cases, a parameter value of 0 is sensible, and MAY
be represented by an LL value of 0, with the data field omitted. A
length value of 0 represents a parameter value of 0, not an absent
parameter. (The data portion occupies 0 space.) There is no
requirement that a parameter be represented in the minimum number of
octets; high-order 0 octets are allowed at the front end. Parameters
are always right adjusted, in a field of length defined by LL. The
octet-order is always most-significant first, least-significant last.
The parameters H and K may have an optional sign bit stored in the
unused high-order bit of their length fields.
LP defines the length of the prime P. P must be an odd prime. The
parameters LP,P are present if and only if the flag M=1. If M=0, the
prime is 2.
LF,F define an explicit field polynomial. This parameter pair is
present only when FMT = 1. The length of a polynomial coefficient is
ceiling(log2 P) bits. Coefficients are in the numerical range
[0,P-1]. The coefficients are packed into fixed-width fields, from
higher order to lower order. All coefficients must be present,
including any 0s and also the leading coefficient (which is required
to be 1). The coefficients are right justified into the octet string
of length specified by LF, with the low-order "constant" coefficient
at the right end. As a concession to storage efficiency, the higher
order bits of the leading coefficient may be elided, discarding high-
order 0 octets and reducing LF. The degree is calculated by
R. Schroeppel, et al [Page 6]
INTERNET-DRAFT ECC Keys in the DNS
determining the bit position of the left most 1-bit in the F data
(counting the right most bit as position 0), and dividing by
ceiling(log2 P). The division must be exact, with no remainder. In
this format, all of the other degree and field parameters are
omitted. The next parameters will be LQ,Q.
If FMT>=2, the degree of the field extension is specified explicitly,
usually along with other parameters to define the field polynomial.
DEG is a two octet field that defines the degree of the field
extension. The finite field will have P^DEG elements. DEG is
present when FMT>=2.
When FMT=2, the field polynomial is specified implicitly. No other
parameters are required to define the field; the next parameters
present will be the LQ,Q pair. The implicit field poynomial is the
lexicographically smallest irreducible (mod P) polynomial of the
correct degree. The ordering of polynomials is by highest-degree
coefficients first -- the leading coefficient 1 is most important,
and the constant term is least important. Coefficients are ordered
by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial
of degree D is X^D (which is not irreducible). The next is X^D+1,
which is sometimes irreducible, followed by X^D-1, which isn't.
Assuming odd P, this series continues to X^D - (P-1)/2, and then goes
to X^D + X, X^D + X + 1, X^D + X - 1, etc.
When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be
odd. The polynomial is determined by the degree and the low order
term K. Of all the field parameters, only the LK,K parameters are
present. The high-order bit of the LK octet stores on optional sign
for K; if the sign bit is present, the field polynomial is X^DEG - K.
When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
K. When P=2, the H and K parameters are implicitly 1, and are
omitted from the representation. Only DEG and DEGH are present; the
next parameters are LQ,Q. When P>2, then LH,H and LK,K are
specified. Either or both of LH, LK may contain a sign bit for its
parameter.
When FMT=5, then P=2 (only). The field polynomial is the exact
quotient of a trinomial divided by a small polynomial, the trinomial
divisor. The small polynomial is right-adjusted in the two octet
field TRDV. DEG specifies the degree of the field. The degree of
TRDV is calculated from the position of the high-order 1 bit. The
trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If
DEGH is 0, the middle term is omitted from the trinomial. The
quotient must be exact, with no remainder.
When FMT=6, then P=2 (only). The field polynomial is a pentanomial,
with the degrees of the middle terms given by the three 2-octet
R. Schroeppel, et al [Page 7]
INTERNET-DRAFT ECC Keys in the DNS
values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI +
X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI
> DEGJ > 0.
DEGH, DEGI, DEGJ are two-octet fields that define the degree of
a term in a field polynomial. DEGH is present when FMT = 4,
5, or 6. DEGI and DEGJ are present only when FMT = 6.
TRDV is a two-octet right-adjusted binary polynomial of degree <
16. It is present only for FMT=5.
LH and H define the H parameter, present only when FMT=4 and P
is odd. The high bit of LH is an optional sign bit for H.
LK and K define the K parameter, present when FMT = 3 or 4, and
P is odd. The high bit of LK is an optional sign bit for K.
The remaining parameters are concerned with the elliptic curve and
the signature algorithm.
LQ defines the length of the prime Q. Q is a prime > 2^159.
In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data
member of the pair is an element from the finite field defined
earlier. The length field defines a long octet string. Field
elements are represented as (mod P) polynomials of degree < DEG, with
DEG or fewer coefficients. The coefficients are stored from left to
right, higher degree to lower, with the constant term last. The
coefficients are represented as integers in the range [0,P-1]. Each
coefficient is allocated an area of ceiling(log2 P) bits. The field
representation is right-justified; the "constant term" of the field
element ends at the right most bit. The coefficients are fitted
adjacently without regard for octet boundaries. (Example: if P=5,
three bits are used for each coefficient. If the field is GF[5^75],
then 225 bits are required for the coefficients, and as many as 29
octets may be needed in the data area. Fewer octets may be used if
some high-order coefficients are 0.) If a flag requires a field
element to be negated, each non-zero coefficient K is replaced with
P-K. To save space, 0 bits may be removed from the left end of the
element representation, and the length field reduced appropriately.
This would normally only happen with A,B,C, because the designer
chose curve parameters with some high-order 0 coefficients or bits.
If the finite field is simply (mod P), then the field elements are
simply numbers (mod P), in the usual right-justified notation. If
the finite field is GF[2^D], the field elements are the usual right-
justified polynomial basis representation.
R. Schroeppel, et al [Page 8]
INTERNET-DRAFT ECC Keys in the DNS
LA,A is the first parameter of the elliptic curve equation.
When P>=5, the flag A = 1 indicates A should be negated (mod
P). When P=2 (indicated by the flag M=0), the flag A = 1
indicates that the parameter pair LA,A is replaced by the two
octet parameter ALTA. In this case, the parameter A in the
curve equation is x^ALTA, where x is the field generator.
Parameter A often has the value 0, which may be indicated by
LA=0 (with no A data field), and sometimes A is 1, which may
be represented with LA=1 and a data field of 1, or by setting
the A flag and using an ALTA value of 0.
LB,B is the second parameter of the elliptic curve equation.
When P>=5, the flag B = 1 indicates B should be negated (mod
P). When P=2 or 3, the flag B selects an alternate curve
equation.
LC,C is the third parameter of the elliptic curve equation,
present only when P=2 (indicated by flag M=0) and flag B=1.
LG,G defines a point on the curve, of order Q. The W-coordinate
of the curve point is given explicitly; the Z-coordinate is
implicit.
LY,Y is the user's public signing key, another curve point of
order Q. The W-coordinate is given explicitly; the Z-
coordinate is implicit. The LY,Y parameter pair is always
present.
3. The Elliptic Curve Equation
(The coordinates of an elliptic curve point are named W,Z instead of
the more usual X,Y to avoid confusion with the Y parameter of the
signing key.)
The elliptic curve equation is determined by the flag octet, together
with information about the prime P. The primes 2 and 3 are special;
all other primes are treated identically.
If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3
+ A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D].
If A and/or B is negative (i.e., in the range from P/2 to P), and
P>=5, space may be saved by putting the sign bit(s) in the A and B
bits of the flags octet, and the magnitude(s) in the parameter
fields.
If M=1 and P=3, the B flag has a different meaning: it specifies an
alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of
the right-hand-side is different. When P=3, this equation is more
R. Schroeppel, et al [Page 9]
INTERNET-DRAFT ECC Keys in the DNS
commonly used.
If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 +
A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A
parameter can often be 0 or 1, or be chosen as a single-1-bit value.
The flag B is used to select an alternate curve equation, Z^2 + C*Z =
W^3 + A*W + B. This is the only time that the C parameter is used.
4. How do I Compute Q, G, and Y?
The number of points on the curve is the number of solutions to the
curve equation, + 1 (for the "point at infinity"). The prime Q must
divide the number of points. Usually the curve is chosen first, then
the number of points is determined with Schoof's algorithm. This
number is factored, and if it has a large prime divisor, that number
is taken as Q.
G must be a point of order Q on the curve, satisfying the equation
Q * G = the point at infinity (on the elliptic curve)
G may be chosen by selecting a random [RFC 1750] curve point, and
multiplying it by (number-of-points-on-curve/Q). G must not itself
be the "point at infinity"; in this astronomically unlikely event, a
new random curve point is recalculated.
G is specified by giving its W-coordinate. The Z-coordinate is
calculated from the curve equation. In general, there will be two
possible Z values. The rule is to choose the "positive" value.
In the (mod P) case, the two possible Z values sum to P. The smaller
value is less than P/2; it is used in subsequent calculations. In
GF[P^D] fields, the highest-degree non-zero coefficient of the field
element Z is used; it is chosen to be less than P/2.
In the GF[2^N] case, the two possible Z values xor to W (or to the
parameter C with the alternate curve equation). The numerically
smaller Z value (the one which does not contain the highest-order 1
bit of W (or C)) is used in subsequent calculations.
Y is specified by giving the W-coordinate of the user's public
signature key. The Z-coordinate value is determined from the curve
equation. As with G, there are two possible Z values; the same rule
is followed for choosing which Z to use.
R. Schroeppel, et al [Page 10]
INTERNET-DRAFT ECC Keys in the DNS
During the key generation process, a random [RFC 1750] number X must
be generated such that 1 <= X <= Q-1. X is the private key and is
used in the final step of public key generation where Y is computed
as
Y = X * G (as points on the elliptic curve)
If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2
in the (mod P) case, or the high-order non-zero coefficient of Z >
P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the
GF[2^N] case), then X must be replaced with Q-X. This will
correspond to the correct Z-coordinate.
5. Performance Considerations
Elliptic curve signatures use smaller moduli or field sizes than RSA
and DSA. Creation of a curve is slow, but not done very often. Key
generation is faster than RSA or DSA.
DNS implementations have been optimized for small transfers,
typically less than 512 octets including DNS overhead. Larger
transfers will perform correctly and and extensions have been
standardized to make larger transfers more efficient [RFC 2671].
However, it is still advisable at this time to make reasonable
efforts to minimize the size of KEY RR sets stored within the DNS
consistent with adequate security. Keep in mind that in a secure
zone, an authenticating SIG RRset will also be returned.
6. Security Considerations
Many of the general security consideration in [RFC 2535] apply. Some
specific key generation considerations are given above. Of course,
the elliptic curve key stored in the DNS for an entity should not be
trusted unless it has been obtain via a trusted DNS resolver that
vouches for its security or unless the application using the key has
done a similar authentication.
7. IANA Considerations
Assignment of meaning to the remaining ECC KEY flag bits or to values
of ECC fields outside the ranges for which meaning in defined in this
document requires an IETF consensus as defined in [RFC 2434].
This specification uses algorithm number 4 for DNS elliptic curve KEY
R. Schroeppel, et al [Page 11]
INTERNET-DRAFT ECC Keys in the DNS
RRs that was reserved for this purpose in [RFC 2535]. An elliptic
curve (algorithm = 4) SIG RR is not defined. Assignment of a meaning
to it requires an IETF Standards action.
R. Schroeppel, et al [Page 12]
INTERNET-DRAFT ECC Keys in the DNS
References
[RFC 1034] - P. Mockapetris, "Domain names - concepts and
facilities", 11/01/1987.
[RFC 1035] - P. Mockapetris, "Domain names - implementation and
specification", 11/01/1987.
[RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness
Recommendations for Security", 12/29/1994.
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", October 1998.
[RFC 2535] - D. Eastlake,"Domain Name System Security Extensions",
March 1999.
[RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August
1999.
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and Sons
[Menezes] - Alfred Menezes, "Elliptic Curve Public Key
Cryptosystems", 1993 Kluwer.
[Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves",
1986, Springer Graduate Texts in mathematics #106.
R. Schroeppel, et al [Page 13]
INTERNET-DRAFT ECC Keys in the DNS
Authors' Addresses
Rich Schroeppel
500 S. Maple Drive
Woodland Hills, UT 84653 USA
Telephone: 1-801-423-7998(h)
1-505-844-9079(w)
Email: rcs@cs.arizona.edu
rschroe@sandia.gov
Donald E. Eastlake 3rd
Motorola
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1 508-634-2066 (h)
+1 508-851-8280 (w)
FAX: +1 508-851-8507 (w)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in June 2003.
Its file name is draft-ietf-dnsext-ecc-key-03.txt.
R. Schroeppel, et al [Page 14]

1231
doc/draft/draft-ietf-dnsext-gss-tsig-06.txt Normal file
View file

File diff suppressed because it is too large Load diff

580
doc/draft/draft-ietf-dnsext-insensitive-03.txt Normal file
View file

@ -0,0 +1,580 @@
INTERNET-DRAFT Donald E. Eastlake 3rd
Clarifies STD0013 Motorola Laboratories
Expires September 2003 April 2003
Domain Name System (DNS) Case Insensitivity Clarification
------ ---- ------ ----- ---- ------------- -------------
<draft-ietf-dnsext-insensitive-03.txt>
Donald E. Eastlake 3rd
Status of This Document
Distribution of this document is unlimited. Comments should be sent
to the DNSEXT working group at namedroppers@ops.ietf.org.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. 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.
Abstract
Domain Name System (DNS) names are "case insensitive". This document
explains exactly what that means and provides a clear specification
of the rules. This clarification should not have any interoperability
consequences.
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT DNS Case Insensitivity
Acknowledgements
The contributions to this document of Rob Austein, Olafur
Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
Andreas Gustafsson, Andrew Main, and Scott Seligman are gratefully
acknowledged.
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Acknowledgements...........................................2
Table of Contents..........................................2
1. Introduction............................................3
2. Case Insensitivity of DNS Labels........................3
2.1 Escaping Unusual DNS Label Octets......................3
2.2 Example Labels with Escapes............................4
2.3 Name Lookup Case Insensitivity.........................4
2.4 Original DNS Label Types...............................5
3. Additional DNS Case Insensitivity Considerations........5
3.1 CLASS Case Insensitivity Considerations................5
3.2 Extended Label Type Case Insensitivity Considerations..5
4. Case on Input and Output................................6
4.1 DNS Output Case Preservation...........................6
4.2 DNS Input Case Preservation............................6
4.3 Wildcard Matching......................................7
5. Internationalized Domain Names..........................7
6. Security Considerations.................................7
Normative References.......................................9
Informative References.....................................9
-02 to -03 Changes........................................10
Author's Address..........................................10
Expiration and File Name..................................10
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT DNS Case Insensitivity
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information. Each node in the DNS tree has a name consisting of
zero or more labels [STD 13][RFC 1591, 2606] that are treated in a
case insensitive fashion. This document clarifies the meaning of
"case insensitive" for the DNS.
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. Case Insensitivity of DNS Labels
DNS was specified in the era of [ASCII]. DNS names were expected to
look like most host names or Internet email address right halves (the
part after the at-sign, "@") or be numeric as in the in-addr.arpa
part of the DNS name space. For example,
foo.example.net.
aol.com.
www.gnu.ai.mit.edu.
or 69.2.0.192.in-addr.arpa.
Case varied alternatives to the above would be DNS names like
Foo.ExamplE.net.
AOL.COM.
WWW.gnu.AI.mit.EDU.
or 69.2.0.192.in-ADDR.ARPA.
The individual octets of which DNS names consist are not limited to
valid ASCII character codes. They are as 8-bit bytes and all values
are allowed. Many applications, however, interprete them as ASCII
characters.
2.1 Escaping Unusual DNS Label Octets
In Master Files [STD 13] and other human readable and writable ASCII
contexts, an escape is needed for the byte value for period (0x2E,
".") and all octet values outside of the inclusive range of 0x21 ("!")
to 0x7E ("~"). That is to say, 0x2E and all octet values in the two
inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.
One typographic convention for octets that do not correspond to an
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT DNS Case Insensitivity
ASCII printing graphic is to use a back-slash followed by the value of
the octet as an unsigned integer represented by exactly three decimal
digits.
The same convention can be used for printing ASCII characters so that
they will be treated as a normal label character. This includes the
back-slash character used in this convention itself and the special
label separator period (".") which can be expressed as \092 and \046
respectively. It is advisable to avoid using a backslash to quote an
immediately following non-printing ASCII character code to avoid
implementation difficulties.
A back-slash followed by only one or two decimal digits is
undefined. A back-slash followed by four decimal digits produces two
octets, the first octet having the value of the first three digits
considered as a decimal number and the second octet being the
character code for the fourth decimal digit.
2.2 Example Labels with Escapes
The first example below shows embedded spaces and a period (".")
within a label. The second one show a 5 octet label where the second
octet has all bits zero, the third is a backslahs,
and the fourth octet has all bits one.
Donald\032E\.\032Eastlake\0323rd.example.
and a\000\\\255z.example.
2.3 Name Lookup Case Insensitivity
The design decision was made that comparisons on name lookup for DNS
queries should be case insensitive [STD 13]. That is to say, a lookup
string octet with a value in the inclusive range of 0x41 to 0x5A, the
upper case ASCII letters, MUST match the identical value and also
match the corresponding value in the inclusive range 0x61 to 0x7A,
the lower case ASCII letters. And a lookup string octet with a lower
case ASCII letter value MUST similarly match the identical value and
also match the corresponding value in the upper case ASCII letter
range.
(Historical Note: the terms "upper case" and "lower case" were
invented after movable type. The terms originally referred to the
two font trays for storing, in partitioned areas, the different
physical type elements. Before movable type, the nearest equivalent
terms were "majuscule" and "minuscule".)
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT DNS Case Insensitivity
One way to implement this rule would be, when comparing octets, to
subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A
before the comparison. Such an operation is commonly known as "case
folding" but implementation via case folding is not required. Note
that the DNS case insensitivity does NOT correspond to the case
folding specified in iso-8859-1 or iso-8859-2. For example, the
octets 0xDD (\221) and 0xFD (\253) do NOT match although in other
contexts, where they are interpreted as the upper and lower case
version of "Y" with an acute accent, they might.
2.4 Original DNS Label Types
DNS labels in wire encoded names have a type associated with them.
The original DNS standard [RFC 1035] had only two types. ASCII
labels, with a length of from zero to 63 octets and indirect labels
which consist of an offset pointer to a name location elsewhere in
the wire encoding on a DNS message. (The ASCII label of length zero
is reserved for use as the name of the root node of the name tree.)
ASCII labels follow the ASCII case conventions described above.
Indirect labels are, in effect, replaced by the name to which they
point which is then treated with the case insensitivity rules in this
document.
3. Additional DNS Case Insensitivity Considerations
This section clarifies the effect of DNS CLASS and extended Label
Type on case insensitivity.
3.1 CLASS Case Insensitivity Considerations
As described in [STD 13] and [RFC 2929], DNS has an additional axis
for data location called CLASS. The only CLASS in global use at this
time is the "IN" or Internet CLASS.
The handling of DNS label case is not CLASS dependent.
3.2 Extended Label Type Case Insensitivity Considerations
DNS was extended by [RFC 2671] to have additional label type numbers
available. (The only such type defined so far is the BINARY type [RFC
2673].)
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT DNS Case Insensitivity
The ASCII case insensitivity conventions, or case folding, only apply
to ASCII labels, that is to say, label type 0x0, whether appearing
directly or invoked by indirect labels.
4. Case on Input and Output
While ASCII label comparisons are case insensitive, case MUST be
preserved on output, except when output is optimized by the use of
indirect labels, and preserved when convenient on input.
4.1 DNS Output Case Preservation
[STD 13] views the DNS namespace as a node tree. ASCII output is as
if a name was marshalled by taking the label on the node whose name
is to be output, converting it to a typographically encoded ASCII
string, walking up the tree outputting each label encountered, and
preceding all labels but the first with a period ("."). Wire output
follows the same sequence but each label is wire encoded and no
periods inserted. No "case conversion" or "case folding" is done
during such output operations. However, to optimize output, indirect
labels may be used to point to names elsewhere in the DNS answer. In
determining whether the name to be pointed to is the "same" as the
remainder of the name being optimized, the case insensitive
comparison specified above is done. Thus such optimization MAY
destroy the output preservation of case. This type of optimization is
commonly called "name compression".
4.2 DNS Input Case Preservation
Originally, DNS input came from an ASCII Master File as defined in
[STD 13]. DNS Dynamic update has been added as a source of DNS data
[RFC 2136, 3007]. When a node in the DNS name tree is created by such
input, no case conversion is done and the case of ASCII labels is
preserved if they are for nodes being created. However, when a name
label is input for a node that already exist in DNS data being
augmented or updated, the situation is more complex. Implemenations
may retain the case first input for such a label or allow new input
to override the old case or maintain separate copies preserving the
input case.
For example, if data with owner name "foo.bar.example" is input and
then later data with owner name "xyz.BAR.example" is input, the name
of the label on the "bar.example" node, i.e. "bar", might or might
not be changed to "BAR" or the actual input case could be preserved.
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT DNS Case Insensitivity
Thus later retrieval of data stored under "xyz.bar.example" in this
case can easily result is obtaining data with "xyz.BAR.example". The
same considerations apply when inputting multiple data records with
owner names differing only in case. From the example above, if an "A"
record is stored under owner name "xyz.BAR.example" and then a second
"A" record under "XYZ.BAR.example", the second MAY be stored with the
first (lower case initial label) name.
Note that the order of insertion into a server database of the DNS
name tree nodes that appear in a Master File is not defined so that
the results of inconsistent capitalization in a Master File are
unpredicatable output capitalization.
4.3 Wildcard Matching
There is one additional instance of note, which reflects the general
rules that output case reflects input case unless there is
conflicting capitalization in the DNS database or the output case is
hidden by name compression. This is when a query matches a wildcard
in the DNS database at a server. In that case, the answer SHOULD
reflect the input case of the label or labels that matched the
wildcard unless they are replaced by an indirect label which MAY
point to a name with different capitalization.
5. Internationalized Domain Names
A scheme has been adopted for "internationalized domain names" and
"internationalized labels" as described in [RFC 3490, 3454, 3491, and
3492]. It makes most of [UNICODE] available through a separate
application level transformation from internationalized domain name
to DNS domain name and from DNS domain name to internationalized
domain name. Any case insensitivity that internationalized domain
names and labels have varies depending on the script and is handled
entirely as part of the transformation described in [RFC 3454] and
[RFC 3491] which should be seen for further details. This is not a
part of the DNS as standardized in STD 13.
6. Security Considerations
The equivalence of certain DNS label types with case differences, as
clarified in this document, can lead to security problems. For
example, a user could be confused by believing two domain names
differing only in case were actually different names.
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT DNS Case Insensitivity
Furthermore, a domain name may be used in contexts other than the
DNS. It could be used as a case sensitive index into some data base
system. Or it could be interpreted as binary data by some integrity
or authentication code system. These problems can usually be handled
by using a standardized or "canonical" form of the DNS ASCII type
labels, that is, always map the ASCII letter value octets in ASCII
labels to some specific pre-chosen case, either upper case or lower
case. An example of a canonical form for domain names (and also a
canonical ordering for them) appears in Section 8 of [RFC 2535]. See
also [UNKRR].
Finally, a non-DNS name may be stored into DNS with the false
expectation that case will always be preserved. For example, although
this would be quite rare, on a system with case sensitive email
address local parts, an attempt to store two "RP" records that
differed only in case would probably produce unexpected results that
might have security implications. That is because the entire email
address, including the possibly case sensitive local or left hand
part, is encoded into a DNS name in a readable fashion where the case
of some letters might be changed on output as described above.
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT DNS Case Insensitivity
Normative References
[ASCII] - ANSI, "USA Standard Code for Information Interchange",
X3.4, American National Standards Institute: New York, 1968.
[RFC 1034, 1035] - See [STD 13].
[RFC 2119] - "Key words for use in RFCs to Indicate Requirement
Levels", S. Bradner, March 1997.
[RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.
[RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
[RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic
Update", November 2000.
[STD 13]
- P. Mockapetris, "Domain names - concepts and facilities", RFC
1034, November 1987.
- P. Mockapetris, "Domain names - implementation and
specification", RFC 1035, November 1987.
[UNKRR] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",
draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.
Informative References
[RFC 1591] - J. Postel, "Domain Name System Structure and
Delegation", March 1994.
[RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
June 1999.
[RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain
Name System (DNS) IANA Considerations", September 2000.
[RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
1999.
[RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
August 1999.
[RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of
Internationalized String ("stringprep")", December 2002.
D. Eastlake 3rd [Page 9]
INTERNET-DRAFT DNS Case Insensitivity
[RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", March 2003.
[RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
for Internationalized Domain Names (IDN)", March 2003.
[RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications (IDNA)", March
2003.
[UNICODE] - The Unicode Consortium, "The Unicode Standard",
<http://www.unicode.org/unicode/standard/standard.html>.
-02 to -03 Changes
The following changes were made between draft version -02 and -03:
1. Add internationalized domain name section and references.
2. Change to indicate that later input of a label for an existing DNS
name tree node may or may not be normalized to the earlier input or
override it or both may be preserved.
3. Numerous minor wording changes.
Author's Address
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1 508-851-8280 (w)
+1 508-634-2066 (h)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires September 2003.
Its file name is draft-ietf-dnsext-insensitive-03.txt.
D. Eastlake 3rd [Page 10]

1178
doc/draft/draft-ietf-dnsext-ipv6-name-auto-reg-00.txt Normal file
View file

File diff suppressed because it is too large Load diff

560
doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-06.txt Normal file
View file

@ -0,0 +1,560 @@
DNS Extensions O. Kolkman
Internet-Draft RIPE NCC
Expires: August 18, 2003 J. Schlyter
Carlstedt Research &
Technology
E. Lewis
ARIN
February 17, 2003
KEY RR Key-Signing Key (KSK) Flag
draft-ietf-dnsext-keyrr-key-signing-flag-06
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 18, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
With the DS resource record the concept of key-signing and
zone-signing keys has been introduced. During key-exchanges with the
parent there is a need to differentiate between these zone- and
key-signing keys. We propose a flag to indicate which key is used as
key-signing key.
Kolkman, et al. Expires August 18, 2003 [Page 1]
Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Key-Signing Key (KSK) Flag . . . . . . . . . . . . . . . . 4
3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . 4
4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Internationalization Considerations . . . . . . . . . . . . . 5
8. Document Changes . . . . . . . . . . . . . . . . . . . . . . . 6
8.1 draft version 00 -> 01 . . . . . . . . . . . . . . . . . . . . 6
8.2 draft version 01 -> 02 . . . . . . . . . . . . . . . . . . . . 6
8.3 draft version 02 -> 03 . . . . . . . . . . . . . . . . . . . . 6
8.4 draft version 03 -> 04 . . . . . . . . . . . . . . . . . . . . 6
8.5 draft version 04 -> 05 . . . . . . . . . . . . . . . . . . . . 6
8.6 draft version 05 -> 06 . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
Normative References . . . . . . . . . . . . . . . . . . . . . 7
Informative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 9
Kolkman, et al. Expires August 18, 2003 [Page 2]
Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003
1. Introduction
"All keys are equal but some keys are more equal than others" [6]
With the definition of the DS Resource Record [5] the concept of a
key being either a key-signing key (KSK) or zone-signing key(ZSK) has
been introduced into DNSSEC[3]. A KSK is one that signs the zone's
KEY RR set, and is a key that is either used to generate a DS RR or
is distributed to resolvers that use the key as the root of a trusted
subtree[4].
In early deployment tests, the use of two keys has been prevalent,
one key for exchange with delegating zone and the other key to sign
the zone. These dual roles were defined to allow a zone to more
rapidly change the ZSK without a high volume of traffic needed to
make new DS RRs. Because of this, participants have had to manage
two keys at all times, one acting as a KSK and the other ZSK (per
cryptographic algorithm). In practice, participants used a longer
key for the KSK or resorted to writing the footprints on paper.
There is a need to differentiate between a KSK and a ZSK by the zone
administrator. This need is driven by knowing which keys are to be
sent for DS RRs, which keys are to be distributed to resolvers, and
which keys are fed to the signer application at the appropriate time.
While addressing this need it is important that the distinction is
made in a way compatible with single key zone, those whose KSK and
ZSK is one in the same. The best way to address this is to define a
bit setting in the KEY RR flags field that is ignored in the
resolver. This allows for both dual key and single key management to
be workable.
The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
"RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
interpreted as described in RFC2119.
Kolkman, et al. Expires August 18, 2003 [Page 3]
Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003
2. The Key-Signing Key (KSK) Flag
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |K| protocol | algorithm |
| |S| | |
| |K| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KEY RR Format
The KSK bit (TBD) in the flags field is assigned to be the
key-signing key flag. If the the bit is set to 1 the key is intended
to be used as key-signing key. One SHOULD NOT assign special meaning
to the key if the bit is set to 0. The document proposes using the
current 15th bit [1] as the KSK bit. This way operators can recognize
the key-signing by the even or odd-ness of the decimal representation
of the flag field.
3. DNSSEC Protocol Changes
The bit MUST NOT be used during the resolving and verification
process. The KSK flag is only used to provide a hint about the
different administrative properties of the key and therefore the use
of the KSK flag does not change the DNS resolution and resolution
protocol.
4. Operational Guidelines
The KSK bit is set by the key-generator and used by the zone signer:
The KSK bit is used to indicate that the key represented in the KEY
RR is intended to sign the KEY RR set of the zone. As the KSK bit is
within the data that is used to compute a KEY RR's footprint,
changing the KSK bit will change the identity of the key within DNS.
When a key pair is created, the operator needs to indicate whether
the KSK bit is to be set in the KEY RR. The KSK bit is recommended
whenever the public key of the key pair will be distributed to the
parent zone to build the authentication chain or if the public key is
to be distributed for static configuration in verifiers.
When signing a zone, it is intended that the key(s) with the KSK bit
Kolkman, et al. Expires August 18, 2003 [Page 4]
Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003
set (if such keys exist) are used to sign the KEY RR set of the zone.
The same key can be used to sign the rest of the zone data too. It
is conceivable that not all keys with a KSK bit set will sign the KEY
RR set, such keys might be pending retirement or not yet in use.
When verifying a RR set, the KSK bit is not intended to play a role.
How the key is used by the verifier is not intended to be a
consideration at key creation time.
Although the KSK flag provides a hint on which key to be used as
trusted root, administrators can choose to ignore the flag when
configuring a trusted root for their resolvers.
Using the flag a key roll over can be automated. The parent can use
an existing trust relation to verify key sets in which a new key with
the KSK flag appears.
5. Security Considerations
As stated in Section 3 the flag is not to used in the resolution
protocol or to determine the security status of a key. The flag is to
be used for administrative purposes only.
No trust in a key should be inferred from this flag - trust MUST be
inferred from an existing chain of trust or an out-of-band exchange.
Since this flag might be used for automating key exchanges, we think
the following consideration is in place.
Automated mechanisms for roll over of the DS RR might be vulnerable
to a class of replay attacks. This might happen after a key exchange
where a key set, containing two keys with the KSK flag set, is sent
to the parent. The parent verifies the key set with the existing
trust relation and creates the new DS RR from the key that the
current DS is not pointing to. This key exchange might be replayed.
Parents are encouraged to implement a replay defence. A simple
defence can be based on a registry of keys that have been used to
generate DS RRs during the most recent roll over.
6. IANA Considerations
draft-ietf-dnsext-restrict-key-for-dnssec [1] eliminates all flags
field except for the zone key flag in the KEY RR. We propose to use
the 15'th bit as the KSK bit; the decimal representation of the
flagfield will then be odd for key-signing keys.
7. Internationalization Considerations
Kolkman, et al. Expires August 18, 2003 [Page 5]
Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003
There are no internationalization considerations.
8. Document Changes
8.1 draft version 00 -> 01
Clean up of references and correction of typos;
modified Abstract text a little;
Added explicit warning for replay attacks to the security section;
Removed the text that hinted on a distinction between a
key-signing key configured in resolvers and in parent zones.
8.2 draft version 01 -> 02
Added IANA and Internationalization section.
Split references into informational and normative.
Spelling and style corrections.
8.3 draft version 02 -> 03
Changed the name from KS to KSK, this to prevent confusion with
NS, DS and other acronyms in DNS.
In the security section: Rewrote the section so that it does not
suggest to use a particular type of registry and that it is clear
that a key registry is only one of the defences possible.
Spelling and style corrections.
8.4 draft version 03 -> 04
Text has been made consistent with the statement: 'No special
meaning should be assigned to the bit not being set.'
Made explicit that the keytag changes in SIG RR.
8.5 draft version 04 -> 05
One occurrence of must and one occurrence of should uppercased
Kolkman, et al. Expires August 18, 2003 [Page 6]
Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003
(RFC2119).
Reordering of sentences in section 3, so that the point of the bit
NOT being used in resolving is made directly.
To make explicit that the KSK is used at key generation and at
signing time I added the first sentence to section 4.
Some minor style and spelling corrections.
8.6 draft version 05 -> 06
References and acronyms where stripped from the Abstract. the
Introduction and the the Operational Guideline section were
rewritten in such a way that the draft does not suggest any use of
the bit in the verification process and that the draft does not
enforce, but suggests, the use of a key- and zone-signing key.
Added 'and verification' in the sentence "MUST NOT be used during
the resolving and verification process" (protocol changes
section).
9. Acknowledgements
The ideas documented in this document are inspired by communications
we had with numerous people and ideas published by other folk. Among
others Mark Andrews, Olafur Gudmundsson, Daniel Karrenberg, Dan
Massey, Marcos Sanz and Sam Weiler have contributed ideas and
provided feedback.
This document saw the light during a workshop on DNSSEC operations
hosted by USC/ISI.
Normative References
[1] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
Record out", draft-ietf-dnsext-restrict-key-for-dnssec-04 (work
in progress), September 2002.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[4] Lewis, E., "DNS Security Extension Clarification on Zone
Kolkman, et al. Expires August 18, 2003 [Page 7]
Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003
Status", RFC 3090, March 2001.
Informative References
[5] Gudmundsson, O., "Delegation Signer Resource Record",
draft-ietf-dnsext-delegation-signer-12 (work in progress),
December 2002.
[6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
Story"", ISBN 0151002177 (50th anniversery edition), April 1996.
Authors' Addresses
Olaf M. Kolkman
RIPE NCC
Singel 256
Amsterdam 1016 AB
NL
Phone: +31 20 535 4444
EMail: olaf@ripe.net
URI: http://www.ripe.net/
Jakob Schlyter
Carlstedt Research & Technology
Stora Badhusgatan 18-20
Goteborg SE-411 21
Sweden
EMail: jakob@crt.se
URI: http://www.crt.se/~jakob/
Edward P. Lewis
ARIN
3635 Concorde Parkway Suite 200
Chantilly, VA 20151
US
Phone: +1 703 227 9854
EMail: edlewis@arin.net
URI: http://www.arin.net/
Kolkman, et al. Expires August 18, 2003 [Page 8]
Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 assignees.
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
Kolkman, et al. Expires August 18, 2003 [Page 9]
Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003
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.
Kolkman, et al. Expires August 18, 2003 [Page 10]

1260
doc/draft/draft-ietf-dnsext-mdns-19.txt Normal file
View file

File diff suppressed because it is too large Load diff

223
doc/draft/draft-ietf-dnsext-obsolete-iquery-04.txt Normal file
View file

@ -0,0 +1,223 @@
DNSEXT Working Group David C Lawrence
INTERNET-DRAFT Nominum
<draft-ietf-dnsext-obsolete-iquery-04.txt> July 2002
Updates: RFC 1035
Obsoleting IQUERY
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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 14 January 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All rights reserved.
Abstract
The IQUERY method of performing inverse DNS lookups, specified in
RFC 1035, has not been generally implemented and has usually been
operationally disabled where it has been implemented. Both reflect
a general view in the community that the concept was unwise and
that the widely-used alternate approach of using PTR queries and
reverse-mapping records is preferable. Consequently, this document
deprecates the IQUERY operation and updates RFC 1035 to declare it
entirely obsolete.
Expires Jan 2003 [Page 1]
INTERNET-DRAFT Obsoleting IQUERY July 2002
1 - Introduction
As specified in RFC 1035 (section 6.4), the IQUERY operation for
DNS queries is used to look up the name(s) which are associated
with the given value. The value being sought is provided in the
query's answer section and the response fills in the question
section with one or more 3-tuples of type, name and class.
As noted in [RFC1035], section 6.4.3, inverse query processing can
put quite an onerous burden on a server. A server would need to
perform either an exhaustive search of its database or maintain a
separate database that is keyed by the values of the primary
database. Both of these approaches could strain system resource
use, particularly for servers that are authoritative for millions
of names.
Response packet from these megaservers could be exceptionally
large, and easily run into megabyte sizes. For example, using
IQUERY to find every domain that is delegated to one of the
nameservers of a large ISP could return tens of thousands of
3-tuples in the question section. This could easily be used to
launch denial of service attacks.
Operators of servers that do support IQUERY in some form (such as
very old BIND 4 servers) generally opt to disable it. This is
largely due to bugs in insufficiently-exercised code, or concerns
about exposure of large blocks of names in their zones by probes
such as inverse MX queries.
IQUERY is also somewhat inherently crippled by being unable to tell
a requestor where it needs to go to get the information that was
requested. The answer is very specific to the single server that
was queried. This is sometimes a handy diagnostic tool, but
apparently not enough so that server operators like to enable it,
or request implementation where it's lacking.
No known clients use IQUERY to provide any meaningful service. The
only common reverse mapping support on the Internet, mapping
address records to names, is provided through the use of PTR
records in the in-addr.arpa tree and has served the community well
for many years.
Based on all of these factors, this draft proposes that the IQUERY
operation for DNS servers be officially obsoleted.
2 - Requirements
The key word "SHOULD" in this document is to be interpreted as
described in RFC 2119, namely that there may exit valid reasons
to ignore a particular item, but the full implications must be
understood and carefully weighed before choosing a different course.
Expires Jan 2003 [Page 2]
INTERNET-DRAFT Obsoleting IQUERY July 2002
3 - Effect on RFC 1035
The effect of this document is to change the definition of opcode 1
from that originally defined in section 4.1.1 of RFC 1035, and to
entirely supersede section 6.4 (including subsections) of RFC 1035.
The definition of opcode 1 is hereby changed to:
"1 an inverse query (IQUERY) (obsolete)"
The text in section 6.4 of RFC 1035 is now considered obsolete.
The following is an applicability statement regarding the IQUERY
opcode:
Inverse queries using the IQUERY opcode were originally described
as the ability to look up the names that are associated with a
particular RR. Their implementation was optional and never
achieved widespread use. Therefore IQUERY is now obsolete, and
name servers SHOULD return a "Not Implemented" error when an IQUERY
request is received.
4 - Security Considerations
Since this document obsoletes an operation that was once available,
it is conceivable that someone was using it as the basis of a
security policy. However, since the most logical course for such a
policy to take in the face of a lack of positive response from a
server is to deny authentication/authorization, it is highly
unlikely that removing support for IQUERY will open any new
security holes.
Note that if IQUERY is not obsoleted, securing the responses with
DNSSEC is extremely difficult without out-on-the-fly digital signing.
5 - IANA Considerations
The IQUERY opcode of 1 should be permanently retired, not to be
assigned to any future opcode.
6 - Acknowledgments
Olafur Gudmundsson was the instigator for this action.
Matt Crawford, John Klensin, Erik Nordmark and Keith Moore
contributed some improved wording as the matter of how to handle
obsoleting functionality described by an Internet Standard.
Expires Jan 2003 [Page 3]
INTERNET-DRAFT Obsoleting IQUERY July 2002
7 - References
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification'', STD 13, RFC 1035, November 1987.
[RFC2026] S. Bradner, ``The Internet Standards Process -- Revision 3'',
BCP 9, RFC 2026, October 1996.
[RFC2119] S. Bradner, ``Key Words for Use in RFCs to Indicate
Requirement Levels'', BCP 14, RFC 2119, March 1997.
8 - Author's Address
David C Lawrence
Nominum, Inc.
2385 Bay Rd
Redwood City CA 94063
USA
Phone: +1.650.779.6042
EMail: tale@nominum.com
9 - Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
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."
Expires Jan 2003 [Page 4]

390
doc/draft/draft-ietf-dnsext-rfc1886bis-02.txt Normal file
View file

@ -0,0 +1,390 @@
Internet Engineering Task Force S. Thomson, Cisco
INTERNET-DRAFT C. Huitema, Microsoft
February 28, 2003 V. Ksinant, 6WIND
Expires August 28, 2003 M. Souissi, AFNIC
DNS Extensions to support IP version 6
<draft-ietf-dnsext-rfc1886bis-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."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
This Internet Draft expires August 28, 2003.
Abstract
This document defines the changes that need to be made to the Domain
Name System to support hosts running IP version 6 (IPv6). The
changes include a resource record type to store an IPv6 address,
a domain to support lookups based on an IPv6 address, and updated
definitions of existing query types that return Internet addresses as
part of additional section processing. The extensions are designed
to be compatible with existing applications and, in particular, DNS
implementations themselves.
This Document combines RFC1886 and changes to RFC 1886 made by
RFC 3152, obsoleting both. Changes mainly consist in replacing
the IP6.INT domain by IP6.ARPA as defined in RFC 3152.
draft-ietf-dnsext-rfc1886bis-02.txt [Page 1]
INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
Table of Contents
1. Introduction............................................. 2
2. New resource record definition and domain................ 2
2.1. AAAA record type.................................... 3
2.2. AAAA data format.................................... 3
2.3. AAAA query.......................................... 3
2.4. Textual format of AAAA records...................... 3
2.5. IP6.ARPA domain..................................... 3
3. Modifications to existing query types.................... 4
4. Security Considerations.................................. 4
5. IANA Considerations...................................... 4
APPENDIX A: Changes from RFC-1886............................ 4
Acknowledgments.............................................. 5
References................................................... 5
Authors' Addresses........................................... 6
Full Copyright Statement..................................... 7
1. INTRODUCTION
Current support for the storage of Internet addresses in the Domain
Name System (DNS)[1,2] cannot easily be extended to support IPv6
addresses[3] since applications assume that address queries return
32-bit IPv4 addresses only.
To support the storage of IPv6 addresses in DNS, this document
defines the following extensions:
o A resource record type is defined to map a domain name to an
IPv6 address.
o A domain is defined to support lookups based on address.
o Existing queries that perform additional section processing to
locate IPv4 addresses are redefined to perform additional
section processing on both IPv4 and IPv6 addresses.
The changes are designed to be compatible with existing software. The
existing support for IPv4 addresses is retained. Transition issues
related to the co-existence of both IPv4 and IPv6 addresses in DNS
are discussed in [4].
2. RESOURCE RECORD DEFINITION AND DOMAIN
A record type is defined to store a host's IPv6 address. A host
that has more than one IPv6 address must have more than one such
record.
draft-ietf-dnsext-rfc1886bis-02.txt [Page 2]
INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
2.1 AAAA record type
The AAAA resource record type is a record specific to the Internet
class that stores a single IPv6 address.
The IANA assigned value of the type is 28 (decimal).
2.2 AAAA data format
A 128 bit IPv6 address is encoded in the data portion of an AAAA
resource record in network byte order (high-order byte first).
2.3 AAAA query
An AAAA query for a specified domain name in the Internet class
returns all associated AAAA resource records in the answer section of
a response.
A type AAAA query does not perform additional section processing.
2.4 Textual format of AAAA records
The textual representation of the data portion of the AAAA resource
record used in a master database file is the textual representation
of a IPv6 address as defined in [3].
2.5 IP6.ARPA Domain
A special domain is defined to look up a record given an address. The
intent of this domain is to provide a way of mapping an IPv6 address
to a host name, although it may be used for other purposes as well.
The domain is rooted at IP6.ARPA.
An IPv6 address is represented as a name in the IP6.ARPA domain by a
sequence of nibbles separated by dots with the suffix ".IP6.ARPA".
The sequence of nibbles is encoded in reverse order, i.e. the
low-order nibble is encoded first, followed by the next low-order
nibble and so on. Each nibble is represented by a hexadecimal digit.
For example, the inverse lookup domain name corresponding to the
address
4321:0:1:2:3:4:567:89ab
would be
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.
ARPA.
draft-ietf-dnsext-rfc1886bis-02.txt [Page 3]
INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
3. MODIFICATIONS TO EXISTING QUERY TYPES
All existing query types that perform type A additional section
processing, i.e. name server (NS), location of services (SRV) and
mail exchange (MX) query types, must be redefined to perform both
type A and type AAAA additional section processing. These definitions
mean that a name server must add any relevant IPv4 addresses and any
relevant IPv6 addresses available locally to the additional section
of a response when processing any one of the above queries.
4. SECURITY CONSIDERATIONS
Any information obtained from the DNS must be regarded as unsafe
unless techniques specified in [7] or [8] are used. The definitions
of the AAAA record type and of the IP6.ARPA domain do not change the
model for use of these techniques.
So, this specification is not believed to cause any new security
problems, nor to solve any existing ones.
5. IANA CONSIDERATIONS
There are no IANA assignments to be performed.
APPENDIX A: Changes from RFC 1886
The following changes were made from RFC 1886 "DNS Extensions to
support IP version 6":
- Replaced the "IP6.INT" domain by "IP6.ARPA".
- Mentioned SRV query types in section 3 "MODIFICATIONS TO
EXISTING QUERY TYPES"
- Added security considerations.
- Updated references :
* From RFC 1884 to RFC 2373 (IP Version 6 Addressing
Architecture).
* From "work in progress" to RFC 2893 (Transition Mechanisms for
IPv6 Hosts and Routers).
* Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845.
- Updated document abstract
- Added table of contents
- Added full copyright statement
- Added IANA considerations section
draft-ietf-dnsext-rfc1886bis-02.txt [Page 4]
INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
Acknowledgements
Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien
Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael
Guerin (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND),
Frederic Roudaut (IRISA) and G6 group for their help during the RFC
1886 Interop tests sessions.
Many thanks to Alain Durand and Olafur Gudmundsson for their support.
Normative References
[1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[2] Mockapetris, P., "Domain Names - Implementation and Specifica-
tion", STD 13, RFC 1035, USC/Information Sciences Institute,
November 1987.
[3] Hinden, R., and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, Nokia, Cisco, July 1998.
This RFC is being updated. The current draft is
"draft-ietf-ipngwg-addr-arch-v3-11.txt", Hinden, R., and
S. Deering, October 25, 2002
Informative References
[4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC 2893, FreeGate Corp., Sun Microsystems
Inc., August 2000.
This RFC is being updated. The current draft is
"draft-ietf-v6ops-mech-v2-00.txt", Gilligan, R., and
E. Nordmark, February 24, 2003
[5] Thomson, S., and C. Huitema, "DNS Extensions to support IP
version 6", RFC 1886, Bellcore, INRIA, December 1995.
[6] Bush, R., "Delegation of IP6.ARPA", RFC 3152, RGnet, August
2001.
[7] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, IBM, March 1999
[8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, ISC, NAI Labs, Motorola, Nominum, May 2000.
draft-ietf-dnsext-rfc1886bis-02.txt [Page 5]
INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
Authors' Addresses
Susan Thomson
Cisco Systems
499 Thornall Street, 8th floor
Edison, NJ 08837
Telephone: 732-635-3086
Email: sethomso@cisco.com
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Email: huitema@microsoft.com
Vladimir Ksinant
6WIND S.A.
Immeuble Central Gare - Bat.C
1, place Charles de Gaulle
78180, Montigny-Le-Bretonneux - France
Phone: +33 1 39 30 92 36
Email: vladimir.ksinant@6wind.com
Mohsen Souissi
AFNIC
Immeuble International
2, rue Stephenson,
78181, Saint-Quentin en Yvelines Cedex - France
Phone: +33 1 39 30 83 40
Email: Mohsen.Souissi@nic.fr
draft-ietf-dnsext-rfc1886bis-02.txt [Page 6]
INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
Full Copyright Statement
Copyright (C) The Internet Society (date). 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 implmentation 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."
The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; neither does
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to
rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made
available for publication and any assurances of licenses to
be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may be
required to practice this standard. Please address the
information to the IETF Executive Director.
draft-ietf-dnsext-rfc1886bis-02.txt [Page 7]

1235
doc/draft/draft-ietf-dnsext-tkey-renewal-mode-03.txt Normal file
View file

File diff suppressed because it is too large Load diff

447
doc/draft/draft-ietf-dnsext-unknown-rrs-05.txt Normal file
View file

@ -0,0 +1,447 @@
INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsext-unknown-rrs-05.txt Nominum Inc.
March 2003
Updates: RFC 1034, RFC 2163, RFC 2535
Handling of Unknown DNS Resource Record Types
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.
Abstract
Extending the Domain Name System with new Resource Record (RR) types
currently requires changes to name server software. This document
specifies the changes necessary to allow future DNS implementations
to handle new RR types transparently.
1. Introduction
The DNS is designed to be extensible to support new services through
the introduction of new resource record (RR) types. In practice,
deploying a new RR type currently requires changes to the name server
software not only at the authoritative DNS server that is providing
the new information and the client making use of it, but also at all
slave servers for the zone containing it, and in some cases also at
caching name servers and forwarders used by the client.
Expires September 2003 [Page 1]
draft-ietf-dnsext-unknown-rrs-05.txt March 2003
Because the deployment of new server software is slow and expensive,
the potential of the DNS in supporting new services has never been
fully realized. This memo proposes changes to name servers and to
procedures for defining new RR types aimed at simplifying the future
deployment of new RR types.
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. Definition
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
To enable new RR types to be deployed without server changes, name
servers and resolvers MUST handle RRs of unknown type transparently.
That is, they must treat the RDATA section of such RRs as
unstructured binary data, storing and transmitting it without change
[RFC1123].
To ensure the correct operation of equality comparison (section 6)
and of the DNSSEC canonical form (section 7) when an RR type is known
to some but not all of the servers involved, servers MUST also
exactly preserve the RDATA of RRs of known type, except for changes
due to compression or decompression where allowed by section 4 of
this memo. In particular, the character case of domain names that
are not subject to compression MUST be preserved.
4. Domain Name Compression
RRs containing compression pointers in the RDATA part cannot be
treated transparently, as the compression pointers are only
meaningful within the context of a DNS message. Transparently
copying the RDATA into a new DNS message would cause the compression
pointers to point at the corresponding location in the new message,
which now contains unrelated data. This would cause the compressed
name to be corrupted.
Expires September 2003 [Page 2]
draft-ietf-dnsext-unknown-rrs-05.txt March 2003
To avoid such corruption, servers MUST NOT compress domain names
embedded in the RDATA of types that are class-specific or not well-
known. This requirement was stated in RFC1123 without defining the
term "well-known"; it is hereby specified that only the RR types
defined in RFC1035 are to be considered "well-known".
The specifications of a few existing RR types have explicitly allowed
compression contrary to this specification: RFC2163 specified that
compression applies to the PX RR, and RFC2535 allowed compression in
SIG RRs and NXT RRs records. Since this specification disallows
compression in these cases, it is an update to RFC2163 (section 4)
and RFC2535 (sections 4.1.7 and 5.2).
Receiving servers MUST decompress domain names in RRs of well-known
type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
NXT, NAPTR, and SRV (although the current specification of the SRV RR
in RFC2782 prohibits compression, RFC2052 mandated it, and some
servers following that earlier specification are still in use).
Future specifications for new RR types that contain domain names
within their RDATA MUST NOT allow the use of name compression for
those names, and SHOULD explicitly state that the embedded domain
names MUST NOT be compressed.
As noted in RFC1123, the owner name of an RR is always eligible for
compression.
5. Text Representation
In the "type" field of a master file line, an unknown RR type is
represented by the word "TYPE" immediately followed by the decimal RR
type number, with no intervening whitespace. In the "class" field,
an unknown class is similarly represented as the word "CLASS"
immediately followed by the decimal class number.
This convention allows types and classes to be distinguished from
each other and from TTL values, allowing the "[<TTL>] [<class>]
<type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
RFC1035 to both be unambiguously parsed.
The RDATA section of an RR of unknown type is represented as a
sequence of white space separated words as follows:
The special token \# (a backslash immediately
followed by a hash sign), which identifies the
RDATA as having the generic encoding defined
herein rather than a traditional type-specific
encoding.
Expires September 2003 [Page 3]
draft-ietf-dnsext-unknown-rrs-05.txt March 2003
An unsigned decimal integer specifying the
RDATA length in octets.
Zero or more words of hexadecimal data encoding
the actual RDATA field, each containing an even
number of hexadecimal digits.
If the RDATA is of zero length, the text representation contains only
the \# token and the single zero representing the length.
An implementation MAY also choose to represent some RRs of known type
using the above generic representations for the type, class and/or
RDATA, which carries the benefit of making the resulting master file
portable to servers where these types are unknown. Using the generic
representation for the RDATA of an RR of known type can also be
useful in the case of an RR type where the text format varies
depending on a version, protocol, or similar field (or several)
embedded in the RDATA when such a field has a value for which no text
format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
0.
Even though an RR of known type represented in the \# format is
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-
specific rules regarding compression, canonicalization, etc.
The following are examples of RRs represented in this manner,
illustrating various combinations of generic and type-specific
encodings for the different fields of the master file format:
a.example. CLASS32 TYPE731 \# 6 abcd (
ef 01 23 45 )
b.example. HS TYPE62347 \# 0
e.example. IN A \# 4 0A000001
e.example. CLASS1 TYPE1 10.0.0.2
6. Equality Comparison
Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
to be compared for equality. Two RRs of the same unknown type are
considered equal when their RDATA is bitwise equal. To ensure that
the outcome of the comparison is identical whether the RR is known to
the server or not, specifications for new RR types MUST NOT specify
type-specific comparison rules.
This implies that embedded domain names, being included in the
overall bitwise comparison, are compared in a case-sensitive manner.
Expires September 2003 [Page 4]
draft-ietf-dnsext-unknown-rrs-05.txt March 2003
As a result, when a new RR type contains one or more embedded domain
names, it is possible to have multiple RRs owned by the same name
that differ only in the character case of the embedded domain
name(s). This is similar to the existing possibility of multiple TXT
records differing only in character case, and not expected to cause
any problems in practice.
7. DNSSEC Canonical Form and Ordering
DNSSEC defines a canonical form and ordering for RRs [RFC2535,
section 8.1]. In that canonical form, domain names embedded in the
RDATA are converted to lower case.
The downcasing is necessary to ensure the correctness of DNSSEC
signatures when case distinctions in domain names are lost due to
compression, but since it requires knowledge of the presence and
position of embedded domain names, it cannot be applied to unknown
types.
To ensure continued consistency of the canonical form of RR types
where compression is allowed, and for continued interoperability with
existing implementations that already implement the RFC2535 canonical
form and apply it to their known RR types, the canonical form remains
unchanged for all RR types whose whose initial publication as an RFC
was prior to the initial publication of this specification as an RFC
(RFC TBD).
As a courtesy to implementors, it is hereby noted that the complete
set of such previously published RR types that contain embedded
domain names, and whose DNSSEC canonical form therefore involves
downcasing according to the DNS rules for character comparisons,
consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
DNAME, and A6.
This document specifies that for all other RR types (whether treated
as unknown types or treated as known types according to an RR type
definition RFC more recent than than RFC TBD), the canonical form is
such that no downcasing of embedded domain names takes place, and
otherwise identical to the canonical form specified in RFC2535
section 8.1.
Note that the owner name is always set to lower case according to the
DNS rules for character comparisons, regardless of the RR type.
The DNSSEC canonical RR ordering is as specified in RFC2535 section
8.3, where the octet sequence is the canonical form as revised by
this specification.
Expires September 2003 [Page 5]
draft-ietf-dnsext-unknown-rrs-05.txt March 2003
8. Additional Section Processing
Unknown RR types cause no additional section processing. Future RR
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
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 new RR types whose
specification allows embedded domain names to be compressed.
10. Security Considerations
This specification is not believed to cause any new security
problems, nor to solve any existing ones.
Normative References
[RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
November 1987.
[RFC1035] - Domain Names - Implementation and Specifications, P.
Mockapetris, November 1987.
[RFC1123] - Requirements for Internet Hosts -- Application and
Support, R. Braden, Editor, October 1989.
[RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
S. Bradner, BCP 14, March 1997.
[RFC2535] - Domain Name System Security Extensions. D. Eastlake,
March 1999.
[RFC2613] - Using the Internet DNS to Distribute MIXER Conformant
Global Address Mapping (MCGAM), C. Allocchio, January 1998.
[RFC2929] - Domain Name System (DNS) IANA Considerations, D.
Eastlake, E. Brunner-Williams, B. Manning, September 2000.
Non-normative References
[RFC1876] - A Means for Expressing Location Information in the Domain
Name System, C. Davis, P. Vixie, T. Goodwin, I. Dickinson, January
1996.
Expires September 2003 [Page 6]
draft-ietf-dnsext-unknown-rrs-05.txt March 2003
[RFC2052] - A DNS RR for specifying the location of services (DNS
SRV), A. Gulbrandsen, P. Vixie, October 1996. Obsoleted by RFC2782.
[RFC2136] - Dynamic Updates in the Domain Name System (DNS UPDATE),
P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997.
[RFC2782] - A DNS RR for specifying the location of services (DNS
SRV), A. Gulbrandsen, P. Vixie, L. Esibov, February 2000.
Author's Address
Andreas Gustafsson
Nominum Inc.
2385 Bay Rd
Redwood City, CA 94063
USA
Phone: +1 650 381 6004
Email: gson@nominum.com
Full Copyright Statement
Copyright (C) The Internet Society (2001 - 2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation 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
Expires September 2003 [Page 7]
draft-ietf-dnsext-unknown-rrs-05.txt March 2003
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such proprietary
rights by implementors or users of this specification can be obtained
from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Expires September 2003 [Page 8]

769
doc/draft/draft-ietf-dnsop-interim-signed-root-01.txt Normal file
View file

@ -0,0 +1,769 @@
Internet Draft Johan Ihr‰n
draft-ietf-dnsop-interim-signed-root-01.txt Autonomica
February 2003
Expires in six months
An Interim Scheme for Signing the Public DNS Root
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.
Abstract
This memo documents a proposed mechanism for a first stage of a
transition from an unsigned DNS root to a signed root, such that
the data in the root zone is accompanied by DNSSEC signatures to
allow validation.
The underlying reason for signing the root zone is to be able to
provide a more secure DNS hierarchy, where it is possible to
distinguish false answers from correct answers.
For the special case of the DNS root zone, an interim scheme is
proposed. This scheme is mostly aimed at securing the root zone
itself for technical and operational reasons, and to give
operational experience of DNSSEC.
1. Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
and "MAY" in this document are to be interpreted as described in
RFC 2119.
The term "zone" refers to the unit of administrative control in the
Domain Name System. "Name server" denotes a DNS name server that is
authoritative (i.e. knows all there is to know) for a DNS zone,
typically the root zone. A "resolver", finally, is a DNS "client",
i.e. an entity that sends DNS queries to authoritative nameservers
and interpret the results.
2. Motivation for signing the DNS root
In the special case of the root zone there are very strong reasons
to take a slow and conservative approach to any changes with
operational impact. Signing the root is such a change.
DNSSEC[RFC2535, RFC3090] has been in development for a number of
years now and still has not reached the point where the last flag
day is behind us.
However, during the years of DNSSEC development and refinement
[RFC2930, RFC3007, RFC3008, RFC3110, RFC3225, RFC3226, AD-secure,
Opt-in, Wild-card-optimize], the Internet has matured and more and
more businesses and other organizations have become dependent on
the stability and constant availability of the Internet.
It is therefore prudent to do everything in our power to ensure
that the DNS infrastructure works as well as possible and, when
appropriate and possible, adding enhancements and functionality.
The time is now right for yet another step of improvement by
signing the root zone. By doing that any Internet user that so
wishes will obtain the ability of verifying responses received from
the root nameservers.
Since this is new operational ground the objective is not maximum
security but rather an "Internet-wide" controlled experiment with a
signed root zone, where the trade off is that we utilize the fact
that there are operators in place that can help even though they
are not sufficiently staffed to do off-line signing in a 24x7
mode. For this reason it is fully possible to even do automatic
signing, since the purpose is to ensure that DNSSEC works
operationally with a signed root zone and gain experience from the
exercise.
It should be pointed out, however, that the experimental part is
only the added DNSSEC records. The traditional records in the root
zone remain unchanged and the new records will only be visible to
DNSSEC-aware resolvers that explicitly ask to see these new
records.
2.1. Motivation for signing the root zone now
The reason DNSSEC is not yet widely deployable is that the problem
of key management remains unsolved, especially where communication
between the zone administrators for a parent zone and child zone is
required.
However, during the past year a solution to this problem has been
found (in the form of a new record type, DS aka Delegation Signer)
[DS], discussed, implemented and tested. Therefore, it is finally
reasonable to consider DNSSEC deployment to be a real possibility
within the next 12 months.
In the case of the root zone the particular importance of managing
the transition with zero operational mistakes is a strong reason to
separate the signing of the zone itself, with the associated key
management issues, from the future management of signed delegations
(of top level domains).
Although support for Delegation Signer has been implemented and
tested it is not yet generally available except experimentally. For
this reason signed delegations for productions zones will have to
wait a bit longer. Furthermore, it will take some time to ensure
that the entire RSS aka Root Server System is capable of supporting
the protocol changes that accompany the new support for Delegation
Signer.
By signing now it will be possible to work through the operational
issues with signing the zone itself without at the same time having
to manage the additional complexity of signed delegations. Also, by
explicitly not supporting any signed delegations, it is also
possible to recover in a graceful way should new operational
problems turn up.
Because of these operational and technical issues there is a
"window of opportunity" to sign the root zone before the status of
implementation of "full DNSSEC", including Delegation Signer
support, change to "generally available", thereby increasing the
pressure for signed delegations from the root zone.
3. Trust in DNSSEC Keys
In the end the trust that a validating resolver will be able to put
in a key that it cannot validate within DNSSEC will have to be a
function of
* trust in the key issuer
* trust in the distribution method
* trust in extra, out-of-band verification
For any security apex, i.e. a node in the DNS hierarchy that issues
out-of-band "trusted keys", it is of critical importance that this
function produces a positive result (i.e. the resolver gains
sufficient confidence in the keys to decide to trust them). The
particular case of the root zone is no different, although possibly
it is more crucial than many other security apexes.
To ensure that the resulting trust is maximized it is necessary to
work with all the parameters that are available. In the case of the
key issuer there is the possibility of chosing a key issuer that
has a large "trust base" (i.e. is already trusted by a large
fraction of the resolver population). However, it is also possible
to expand the aggregated trust base by using multiple simultaneous
key issuers, as described in [Threshold-Validation].
Furthermore, with multiple trusted keys it will be possible for a
validating resolver to optimize for the "right compromise" between
* maximum security (as expressed by all available signatures by all
available keys verifying correctly
* maximum redundancy (as in the DNS lookup being validated if there
is any signature by any trusted key available)
Without multiple, independent trusted keys the rollover operation
will always be a dangerous operation where it is likely that some
fraction of the resolver population lose their ability to verify
lookups (and hence start to fail hard). I.e. the validating
resolver will be forced to adopt the "maximum security" policy,
since there is no alternative.
With multiple, independent trusted keys, however, it is possible to
design for improved redundancy by trusting lookups that are only
validated against a subset of the available keys. This will make
rollovers much less risky to the extent that it will be possible to
"survive" even emergency rollovers without any immediate
configuration chagnes in the validating resolver.
4. Interim signing of the root zone
At present all the authoritative servers for the root zone pull the
zone from a primary master. I.e. any changes at the primary master
will propagate via NOTIFY[RFC1996] and subsequent
AXFR/IXFR[RFC1995, AXFR-clarify] to the slave servers.
Between the primary master and the slaves transactions are signed
with TSIG[RFC2845] signatures. This mechanism is already in place,
and there is operational experience with periodic key rollover of
the TSIG keys.
4.1. Design philosophy
By introducing a signing step into the distribution of the zone
file complexity is increased. To avoid introducing new single
points of failure it is therefore important to ensure that any
added or changed steps are as redundant as possible.
The assumption is that the operators of the root servers are
trusted and that consistency of the zone among the root servers is
a crucial property that MUST be preserved in emergencies.
To ensure that consistency is maintained new single points of
failure SHOULD NOT be introduced by the signing step. Therefore a
structure where several parties have the ability to sign the zone
is proposed. Furthermore, such a design helps avoid any individual
party becoming a de facto single zone signing authority.
4.2. Proposed new management structure for the root zone
Taking into account the already existing infrastructure for
management of TSIG keys and rollover of these keys the following
structure is proposed:
* Day-to-day signing of the root zone is performed by a subgroup of
the root server operators referred to as "signing operators". For
this task individual, per-operator, Zone Signing Keys, ZSKs, are
used.
* The set of Zone Signing Keys are signed by several Key Signing
Keys, KSKs, at any particular time. The public part of KSKs in
use have to be statically configured as "trusted keys" in all
resolvers that want to be able to perform validation of
responses.
* Key rollover, the operation when an old KSK is exchanged for a
new KSK, is managed with minimal overlap and on a frequent basis
of no less than three times per year per KSK. The rollover
schedule is chosen to be frequent enough to not make long-term
trust possible while being low enough to not become operationally
infeasible.
4.2.1. Management and distribution of the zone file
The present, unsigned zone is published by the official slaves, the
"root nameservers", transferring the zone securely from a primary
master and subsequently using the data to respond to queries. This
mechanism is changed into:
* The unsigned root zone is transferred securely from the primary
master to a set of "signing primaries" managed by the operators
participating in signing the zone. This is done via the
traditional mechanisms NOTIFY + AXFR/IXFR + TSIG.
* The root nameservers change their configuration so that they
replace the present, single, primary master as the source of the
zone with a set of multiple possible "signing primaries" as
masters that provide the signed zone.
* When a new, unsigned zone, is published by the primary master it
will automatically be transferred to the pre-signing servers. The
responsible operator will then sign the new zone and publish it
from his signing primary. Since the serial number is higher than
what the official root nameservers presently have the official
root nameservers will all transfer the zone from this source
(because of the redundant configuration with multiple possible
masters for the signed zone).
* The operators that participate in signing rotate the signing
responsibility among themselves. Should the responsible operator
be unable to do this for any reason then any of the others are
able to do the signing instead. Traceability is maintained since
the zone signing keys are individual.
* To avoid having several "backup signing operators" possibly sign
at exactly the same time backups are allocated "time windows"
within which they are allowed to publish a signed zone.
With N signers, each signer is assigned a unique number R in
[1..N].
T = 2*k*((S-R) mod N)
T is time to wait in seconds, S current serial number. The length
of the window is k, thereby separating each signing window with
an interval where signing is not allowed.
The constant k is used to create sufficient separation of the
signers with respect to time used to sign and time needed to
distribute the zone. A reasonable value for k would be in the
order of 1800 seconds.
* Because the digital signatures in the signed root zone MUST NOT
expire it is necessary to ensure that the unsigned zone does
change sufficiently often to cause new signing to occur within
the validity period of the old signatures. This is most easily
accomplished by a dummy update that only increments the serial
number in the SOA record.
This new requirement will not cause any operational problems,
since in fact the root zone is maintained this way since several
years back.
4.2.2. Management of the Key Signing Keys
Key Signing Keys, KSKs, are periodically issued by a several "Key
Signing Key Holders", KSK holders, individually. These KSKs consist
of a private part that should always be kept secret and a public
part that should be published as widely as possible since it will
be used as a "trusted key" in resolver configurations.
The public part of each KSK should be included in the keyset for
"." as described in [Threshold-Validation]. I.e. the keyset will be
the union of the public parts of all KSKs and all ZSKs, Zone
Signing Keys.
* Each KSK holder should generate a sequence of KSKs where the
public parts will be used to include in the keyset for "." and
the private parts will be used for signing the keyset.
* Each KSK holder should, on request from the signing operators,
send in the public part of the KSK. The union of the public parts
of KSKs and the corresponding public parts of ZSKs, as collected
by the signing operators, constitute a "keyset".
* Each KSK holder should, on request from the signing operators,
sign the complete keyset with the private part of the associated
KSK and send in the resulting signature to the signing operators
for inclusion in the signed zone.
4.2.3. Management of the Zone Signing Keys and the keyset signatures
A subgroup of the root operators that choose to participate in
signing the zone each hold an individual "Zone Signing Key",
ZSK. The subgroup of operators may include all operators, but that
is not necessary as long as a sufficient number to achieve
redundancy in "signing ability" participates.
* The complete keyset (i.e. all the public parts of KSKs and ZSKs)
should be signed by each KSK holder individually, generating a
new signature for the keyset which is sent back to the signing
operators via an out-of-band mechanism.
* The signing operators should verify each received signature
against the corresponding key in the keyset and, unless invalid,
accept the signature into the set of signatures associated with
this keyset as described in [Threshold-Validation].
* The signing operators should include one of the keysets together
with all the KSK signatures in the zone file according to an
agreed upon rotation schedule.
4.2.4. Management of key rollover
The Key Signing Keys should, for this interim scheme, be relatively
short-lived and rolled over frequently. The direct intent is that
it should not be possible to put long term trust in the keys.
Therefore, by design, every resolver that chooses to configure
these as "trusted keys" (to be able to validate lookups) will have
to change the configuration periodically.
This is, after all, only an interim method of root zone signing.
* Key rollover is executed by changing from one signed keyset to
another. I.e. from a keyset signed by one set of KSKs to a keyset
signed by a partially different set of KSKs. By not rolling all
the KSKs at the same time redundancy is improved.
* Technically the signing operators are able to initiate key
rollover, although except for the case of a suspected key
compromise (with subsequent immediate key rollover) this ability
should only be used according to an established schedule.
* New Key Signing Keys will be published as widely as possible,
however exactly how and where to publish the keys is by itself an
area where it is necessary to acquire more experience. Especially
for the case of individual hosts and other devices this will be a
significant issue to deal with.
* Since the keys expire within a few months the aim is to make it
as difficult as possible to configure an interim key and then
forget about it long enough to still trust an interim key when a
long term design for signing the root zone emerges.
4.2.5. The role of the KSK holder
With multiple KSKs it is possible to have multiple individual KSK
holders. Each will perform the role of authenticating the identity
of the signing operators, through the act of signing the keyset
that includes the operator Zone Signing Keys.
The chain of authority that defines editorial control over the zone
contents is entirely separate from this and is in no way affected.
I.e. the KSK holder is only asserting identity of the holders of
ZSKs and does not in any way take part in issues regarding zone
contents. In this respect the role of a KSK holder is much like
that of a public notary or a Certificate Authority.
The primary function that the KSK holder is performing is adding
trust to the authenticity of the Zone Signing Keys and this trust
has to be propagated down to validating resolvers. Therefore an
obvious key characteristic of a KSK holder is that it should
already be trusted by as large a fraction of the "resolver
population" as possible. In this document that fraction is referred
to as the "trust base" of a KSK holder.
The key characteristics of a KSK holder will be entities that
* already are trusted by some part of the "resolver population",
i.e. have a "trust base"
* are multiple entities that complement each other (so that the
aggregated "trust base" grows)
* are willing to help work on methods for distributing their
trusted keys to the resolvers (hard problem)
The requirement on the individual KSK holders is that they must be
able to
* establish a secure out-of-band communication path in
collaboration with the signing operators which will be used for
authenticated exchange of the unsigned keyset and generated
signatures
* periodically generate strong keys using a good random number
generator
* manage their keys (i.e. use them for signing the operator keyset
and keeping the private key appropriately secret)
4.2.5.6. Suggestions for KSK holders
Regional Internet Registries, RIRs, are suggested to be one
suitable choice of KSK holders. However, since every KSK holder
will act on its own there is no requirement that all RIRs
participate, although more than one would be good. Other suitable
KSK holders may exist and as long as the requirements are met more
would be better within the packe size limitations that are
discussed in [Threshold-Validation].
The basis of the suggestion of RIRs is
* their neutrality
* their proven record of service to the Internet community
* that they don't have the domain name system as their primary
field of activity
* their geographical diversity
* the fact that they are, by definition, not a single entity, but
rather a collective of organizations.
5. Risk Analysis
A change in the management of the root zone is always a risk. But
that is all the more reason to do it carefully and after due
consideration, rather than as a result of an immediate and urgent
need. The gains of a signed root zone have to be judged against the
added complexity of the signing step.
However, added complexity, in one form or another, is basically
unavoidable. It is possible to argue for or against implementation
details, but in the end the benefits of a signed root will have to
be compared against some amount of added complexity. If the cost or
risk of this complexity is deemed to be too high, then it is not
possible to sign the DNS root zone. If that is the conclusion; then
it is obviously important to reach it as soon as possible.
The same is true for the need for operational experience with a
signed root zone. There is no method of acquiring this experience
except by signing the root zone, so that is what is being proposed.
Some identified scenarios:
5.1. What will the consequences of a signed root zone be for old
resolver software?
Nameservers that are authoritative for signed zones only give out
these signatures when explicitly asked for them. Therefore, the
presence of signatures in the root zone will not have any impact at
all on the majority of resolvers on the Internet that does not
validate lookups.
5.2. What happens if a signing operator fails to sign the zone on
time?
Literally nothing. I.e. the root zone that is published will be the
version prior to the last change. This is not believed to be a
major problem, since all changes to the data in the root zone are
characterized by long overlaps in time. Furthermore every change is
preceded by an administrative process that takes several days or
even weeks. Because of this, a failure to install a new version of
the root zone for even so long as a day will not noticeably change
the turn-around time for changes in the root zone.
5.3. What happens if several signing operators by mistake sign the
same version?
Literally nothing. One signing operator will be first, according to
the mechanism designed to separate the different backup signing
operators described in 3.3.1. The signed zone published by this
operator will be the version of the signed root zone that all the
root nameservers pick up.
When the second signing operator signs the zone the serial number
in the zone will be unchanged, and therefore the root nameservers
will not pick this zone up but instead stay with the first version.
5.4. What happens if the unsigned zone is compromised between the
primary master and the signing primaries?
This is basically the same threat as the zone being compromised
between the primary master and the root servers in the traditional
unsigned case. To guard against this possibility every zone
transfer is already protected by a TSIG signature.
Because of this the root zone file cannot get transferred to the
signing primaries unless the transaction signature matches, thereby
proving that the zone contents are uncompromised. The consequence
is that if the zone transfers are somehow compromised in transit,
they will not get signed and therefore the published root zone will
remain the signed version of the last uncompromised transfer.
5.5. What are the security implications for the new "signing
primaries"? Will they not have to be as secure as the primary
master is now?
Yes. However, the entire root server system is based upon trust,
i.e. the entire Internet is trusting the present root server system
because there is no alternative to doing that. This proposal is not
about changing the need for trust in the root server system. It is
about providing a method of determining authenticity of data,
something that is presently missing.
The root operators are already trusted to provide a root server
system based upon secure servers lacking validation mechanisms. It
is therefore a bit difficult to argue for not trusting them to
provide an improved system that adds exactly the lacking validation
mechanisms on a basis of not trusting them to secure the servers
involved. In both cases trust is involved, the difference is that
in the latter case validation is possible.
Furthermore, the proposed signing primaries will not need to have
publicly known addresses (just as the present primary master is not
publicly known), nor will they need to be able to communicate with
anyone outside the well defined set of servers that are part of the
root server system. Because of this it will be significantly easier
to secure the signing primaries than the already present task of
securing the DNS root nameservers.
5.6. What happens if a Zone Signing Key is compromised?
If this happens it is necessary to do an emergency rollover of the
keyset that includes the compromised key. I.e. the old keyset (and
its signatures) is replaced by a new keyset containing new ZSKs but
the same, uncompromised, KSKs and its signatures. Then the root
zone is re-signed using one of the new Zone Signing Keys.
This problem is not unique to a signed root zone, it is inherent in
any activity involving cryptographic keys.
Also note that there will be no need to change any configuration in
the resolver end. The rollover is an entirely atomic operation
inside the management structure of the root zone.
5.7. What happens if a Key Signing Key is compromised?
Depending on the trust model used by individual validating
resolvers one of two things will happen.
Resolvers that through local policy have chosen to trust this KSK
alone will need to change their configuration to instead trust
other KSKs, either available from other KSK holders or a new
trusted key made available by the same KSK holder that held the
compromised key.
Resolvers that have chosen to require multiple signatures by KSKs
for the root zone will not have to do any emergency key rollover at
all, since validation of lookups will still work, based upon the
integrity of the other trusted keys that have not been compromised.
In the management end it is necessary to do an emergency rollover
of the keyset including the compromised key and the suggested
method is by switching to a keyset that only changes the
compromised KSK and the ZSKs and keeps all other KSKs. Such keysets
should be prepared and signed in advance.
The new signed keyset is added to the root zone and then the zone
is re-signed using one of the new Zone Signing Keys. In this case,
since a Key Signing Key is changed, every resolver that choose to
trust that KSK holder will over time have to configure the new key
to be able to validate lookups.
This problem is not unique to a signed root zone, it is inherent in
any activity involving cryptographic keys.
5.8. Does the out-of-band communication between the signing operators
and the RIRs holding the key-signing keys add a new failure mode?
Yes. The traditional DNSSEC design assumes that (for an arbitrary
zone, not particularly for the root zone) the key-signing key is
managed by the same entity that manages the operator keys and hence
no communication issue exists.
In this case it is important that the signing operators do not hold
the responsibility for the key-signing keys. The root server
operators should only act as a "publishing service" for the root
zone contents, not as the entity that verifies correctness of the
published data.
However, apart from established secure methods of out-of-band
communication being available, there is also the very real
possibility of managing these exchanges with actual eye-to-eye
contact. Representatives for the RIRs and the root server operators
already meet on a regular basis during IETF meetings and the
different RIR meetings.
6. Security Considerations
Signing the DNS root zone is all about security. A signed root zone
may aid applications and organizations all over the Internet in
improving their security by enabling validation of DNS lookups.
Signing the root zone does add a new management step and therefore
it is important to ensure that possible failures in this management
step does not leave the published root zone in a state that is
actually worse than the original unsigned state.
The various failure modes that have been identified all show this
property of not being any worse than the unsigned case.
There is however one scenario that changes drastically with the
proposed distributed signing scheme and that is the consequences of
one signing operator intentionally changing the contents of the
root zone prior to the actual signing. In the unsigned case this
will cause the root zone to become inconsistent (i.e. the responses
vary depending upon which server it comes from), while in the
signed case the root zone will remain consistent but with erroneous
data in it.
It is my belief (this is impossible to prove) that the risk of
human error among the operators, however small, is still far
greater than the risk of willful misconduct. Therefore, the
proposed design that enforces consistency among the roots, is
actually also an improvement in stability and security.
Se further section 4 for a more complete risk analysis.
7. IANA Considerations
NONE.
8. References
8.1. Normative.
[RFC2535] Domain Name System Security Extensions. D. Eastlake.
March 1999.
[RFC3090] DNS Security Extension Clarification on Zone Status.
E. Lewis. March 2001.
[RFC1995] Incremental Zone Transfer in DNS. M. Ohta. August 1996.
[RFC1996] A Mechanism for Prompt Notification of Zone Changes
(DNS NOTIFY). P. Vixie. August 1996.
[RFC2845] Secret Key Transaction Authentication for DNS (TSIG).
P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington.
May 2000.
8.2. Informative.
[RFC2930] Secret Key Establishment for DNS (TKEY RR). D. Eastlake.
September 2000.
[RFC3007] Secure Domain Name System (DNS) Dynamic Update.
B. Wellington. November 2000.
[RFC3008] Domain Name System Security (DNSSEC) Signing Authority.
B. Wellington. November 2000.
[RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
(DNS). D. Eastlake 3rd. May 2001.
[RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad.
December 2001.
[RFC3226] DNSSEC and IPv6 A6 aware server/resolver message size
requirements. O. Gudmundsson. December 2001.
[Delegation-Signer] Delegation Signer Resource Record.
O. Gudmundsson. October 2002. Work In Progress.
[AXFR-clarify] draft-ietf-dnsext-axfr-clarify-NN.txt DNS Zone
Transfer Protocol Clarifications. A. Gustafsson. March
2002. Work In Progress.
[AD-secure] draft-ietf-dnsext-ad-is-secure-NN.txt Redefinition of
DNS AD bit. B. Wellington, O Gudmundsson. June 2002.
Work In Progress.
[Opt-In] draft-ietf-dnsext-dnssec-opt-in-NN.txt DNSSEC Opt-In
R. Arends, M Kosters, D. Blacka. June 2002. Work In
Progress.
[Wild-card-optimize] draft-olaf-dnsext-dnssec-wildcard-
optimization-NN.txt DNSSEC Wildcard optimization.
O. Kolkman, J. Ihren, R. Arends. September 2002.
Work In Progress.
[Threshold-Validation]
draft-ihren-dnsop-threshold-validation-00.txt Threshold
validation: A Mechanism for Improved Trust and Redundancy
for DNSSEC Keys. J. Ihren. February 2003. Work In
Progress.
9. Acknowledgments.
To help me produce this document I have received lots and lots of
comments from many people around the Internet with suggestions for
lots and lots sorely needed improvements. Among the folks who
helped out are, in no particular order: Paul Vixie, Bill Manning,
Ôlafur Gumundsson, Rob Austein, Patrik F„ltstr÷m, Olaf Kolkman,
Harald Alvestrand, Suzanne Woolf, John M. Brown, Lars-Johan Liman
and M…ns Nilsson.
10. Authors' Address
Johan Ihr‰n
Autonomica AB
Bellmansgatan 30
SE-118 47 Stockholm, Sweden
johani@autonomica.se

480
doc/draft/draft-ietf-dnsop-ipv6-dns-issues-02.txt Normal file
View file

@ -0,0 +1,480 @@
Internet Engineering Task Force Alain Durand
INTERNET-DRAFT SUN Microsystems,inc.
Feb, 27, 2003 Johan Ihren
Expires August, 28, 2003 Autonomica
IPv6 DNS transition issues
<draft-ietf-dnsop-ipv6-dns-issues-02.txt>
Status of this memo
This memo provides information to the Internet community. It does not
specify an Internet standard of any kind. This memo is in full
conformance with all provisions of Section 10 of RFC2026
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
Abstract
This memo summarizes DNS related issues when transitioning a network
to IPv6. Consensus and open issues are presented.
1. Representing IPv6 addresses in DNS records
In the direct zones, according to [RFC3363], IPv6 addresses are
represented using AAAA records [RFC1886]. In the reverse zone, IPv6
addresses are represented using PTR records in nibble format under
the ip6.arpa. tree [RFC3152].
2. IPv4/IPv6 name space
2.1 Terminology
The phrase "IPv4 name server" indicates a name server available over
IPv4 transport. It does not imply anything about what DNS data is
served. Likewise, "IPv6 name server" indicates a name server
available over IPv6 transport.
2.2. Introduction to the problem of name space fragmentation:
following the referral chain
The caching resolver that tries to lookup a name starts out at the
root, and follows referrals until it is referred to a nameserver that
is authoritative for the name. If somewhere down the chain of
referrals it is referred to a nameserver that is only accessible over
a type of transport that is unavailable, a traditional nameserver is
unable to finish the task.
When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
only a matter of time until this starts to happen and the complete
DNS hierarchy starts to fragment into a graph where authoritative
nameservers for certain nodes are only accessible over a certain
transport. What is feared is that a node using only a particular
version of IP, querying information about another node using the same
version of IP can not do it because, somewhere in the chain of
servers accessed during the resolution process, one or more of them
will only be accessible with the other version of IP.
With all DNS data only available over IPv4 transport everything is
simple. IPv4 resolvers can use the intended mechanism of following
referrals from the root and down while IPv6 resolvers have to work
through a "translator", i.e. they have to use a second name server on
a so-called "dual stack" host as a "forwarder" since they cannot
access the DNS data directly.
With all DNS data only available over IPv6 transport everything would
be equally simple, with the exception of old legacy IPv4 name servers
having to switch to a forwarding configuration.
However, the second situation will not arise in a foreseeable time.
Instead, it is expected that the transition will be from IPv4 only to
a mixture of IPv4 and IPv6, with DNS data of theoretically three
categories depending on whether it is available only over IPv4
transport, only over IPv6 or both.
The latter is the best situation, and a major question is how to
ensure that it as quickly as possible becomes the norm. However,
while it is obvious that some DNS data will only be available over v4
transport for a long time it is also obvious that it is important to
avoid fragmenting the name space available to IPv4 only hosts. I.e.
during transition it is not acceptable to break the name space that
we presently have available for IPv4-only hosts.
2.3 Policy based avoidance of name space fragmentation.
Today there are only a few DNS "zones" on the public Internet that
are available over IPv6 transport, and they can mostly be regarded
as "experimental". However, as soon as there is a root name server
available over IPv6 transport it is reasonable to expect that it will
become more common to have zones served by IPv6 servers over time.
Having those zones served only by IPv6-only name server would not be
a good development, since this will fragment the previously
unfragmented IPv4 name space and there are strong reasons to find a
mechanism to avoid it.
The RECOMMENDED approach to maintain name space continuity is to use
administrative policies:
- every recursive DNS server SHOULD be either IPv4-only or dual
stack,
- every single DNS zone SHOULD be served by at least one IPv4
reachable DNS server.
This rules out IPv6-only recursive DNS servers and DNS zones served
only by IPv6-only DNS servers. This approach could be revisited
if/when translation techniques between IPv4 and IPv6 were to be
widely deployed.
In order to enforce the second point, the zone validation process
SHOULD ensure that there is at least one IPv4 address record
available for the name servers of any child delegations within the
zone.
3. Local Scope addresses.
[IPv6ADDRARCH] define three scopes of addresses, link local, site
local and global.
3.1 Link local addresses
Local addresses SHOULD NOT be published in the DNS, neither in the
forward tree nor in the reverse tree.
3.2 Site local addresses
Note: There is an ongoing discussion in the IPv6 wg on the
usefulness of site local addresses that may end up deprecating or
limiting the use of Site Local addresses.
Site local addresses are an evolution of private addresses [RFC1918]
in IPv4. The main difference is that, within a site, nodes are
expected to have several addresses with different scopes. [ADDRSELEC]
recommends to use the lowest possible scope possible for
communications. That is, if both site local & global addresses are
published in the DNS for node B, and node A is configured also with
both site local & global addresses, the communication between node A
and B has to use site local addresses.
For reasons illustrated in [DontPublish], site local addresses SHOULD
NOT be published in the public DNS. They MAY be published in a site
view of the DNS if two-face DNS is deployed.
For a related discussion on how to handle those "local" zones, see
[LOCAL].
3.3 Reverse path DNS for site local addresses.
The main issue is that the view of a site may be different on a stub
resolver and on a fully recursive resolver it points to. A simple
scenario to illustrate the issue is a home network deploying site
local addresses. Reverse DNS resolution for site local addresses has
to be done within the home network and the stub resolver cannot
simply point to the ISP DNS resolver.
Site local addresses SHOULD NOT be populated in the public reverse
tree. If two-face DNS is deployed, site local addresses MAY be
populated in the local view of reverse tree.
4. Automatic population of the Reverse path DNS
Getting the reverse tree DNS populated correctly in IPv4 is not an
easy exercise and very often the records are not really up to date or
simply are just not there. As IPv6 addresses are much longer than
IPv4 addresses, the situation of the reverse tree DNS will probably
be even worse.
A fairly common practice from IPv4 ISP is to generate PTR records for
home customers automatically from the IPv4 address itself. Something
like:
1.2.3.4.in-addr.arpa. IN PTR 4.3.2.1.local-ISP.net
It is not clear today if something similar need to be done in IPv6,
and, if yes, what is the best approach to this problem.
As the number of possible PTR records would be huge (2^80) for a /48
prefix, a possible solution would be to use wildcards entries like:
*.0.1.2.3.4.5.6.7.8.9.a.b.c.ip6.arpa. IN PTR customer-42.local-
ISP.net
However, the use of wildcard is generally discouraged and this may
not be an acceptable solution.
An alternative approach is to dynamically synthetize PTR records,
either on the server side or on the resolver side. This approach is
discussed at length in [DYNREVERSE].
Other solutions like the use of ICMP name lookups [ICMPNL] have been
proposed but failed to reach consensus. It would work if and only the
remote host is reachable at the time of the request and one can
somehow trust the value that would be returned by the remote host.
the
A more radical approach would be not to pre-populate the reverse tree
at all. This approach claims that applications that misuse reverse
DNS for any kind of access control are fundamentally broken and
should be fixed without introducing any kludge in the DNS. There is a
certain capital of sympathy for this, however, ISP who who pre-
generate statically PTR records for their IPv4 customers do it for a
reason, and it is unlikely that this reason will disappear with the
introduction of IPv6.
5. Privacy extension addresses
[RFC3041] defines privacy extensions for IPv6 stateless
autoconfiguration where the interface ID is a random number. As those
addresses are designed to provide privacy by making it more difficult
to log and trace back to the user, it makes no sense to in the
reverse tree DNS to have them pointing to a real name.
[RFC3041] type addresses SHOULD NOT be published in the reverse tree
DNS pointing to meaningful names. A generic, catch-all name MAY be
acceptable. An interesting alternative would be to use dynamic
synthesis as in [DYNREVERSE].
6. 6to4
6to4 addresses can be published in the forward DNS, however special
care is needed in the reverse tree. See [6to4ReverseDNS] for details.
The delegation of 2.0.0.2.ip6.arpa. is suggested in [6to4ARPA],
however, delegations in the reverse zone under 2.0.0.2.ip6.arpa are
the core of the problem. Delegating the next 32 bits of the IPv4
address used in the 6to4 domain won't scale and delegating on less
may require cooperation from the upstream IPSs. The problem here is
that, especially in the case of home usage of 6to4, the entity being
delegated the x.y.z.t.2.0.0.2.ip6.arpa. zone (the ISP) may not be the
same as the one using 6to4 (the end customer). the
Another problem with reverse DNS for 6to4 addresses is that the 6to4
prefix may be transient. One of the usage scenario of 6to4 is to have
PCs connected via dial-up use 6to4 to connect to the IPv6 Internet.
In such a scenario, the lifetime of the 6to4 prefix is the same as
the DHCP lease of the IPv4 address it is derived from. It means that
the reverse DNS delegation is only valid for the same duration.
A possible approach is not to populate the reverse tree DNS for 6to4
addresses. Another one is to use dynamic synthesis as described in
[DYNREVERSE].
7. Recursive DNS server discovery
[DNSdiscovery] has been proposed to reserve a well known site local
unicast address to configure the DNS resolver as a last resort
mechanism, when no other information is available. Another approach
is to use a DHCPv6 extensions [DHCPv6DNS].
8. DNSsec
There is nothing specific to IPv6 or IPv4 in DNSsec. However,
translation tools such as NAT-PT [RFC2766] introduce a DNS-ALG that
will break DNSsec by imposing a change in the trust model. See [DNS-
ALG] for details.
9. Security considerations
Using wildcard DNS records in the reverse path tree may have some
implication when used in conjunction with DNSsec. Security
considerations for referenced documents are described in those memos
and are not replicated here.
10. Author addresses
Alain Durand
SUN Microsystems, Inc
17 Network circle UMPK17-202
Menlo Park, CA, 94025
USA
Mail: Alain.Durand@sun.com
Johan Ihren
Autonomica
Bellmansgatan 30
SE-118 47 Stockholm, Sweden
Mail: johani@autonomica.se
11. References
[RFC1918] Address Allocation for Private Internets. Y. Rekhter, B.
Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February
1996.
[RFC2766] Network Address Translation - Protocol Translation (NAT-
PT).
G. Tsirtsis, P. Srisuresh. February 2000.
[RFC3041] Privacy Extensions for Stateless Address Autoconfiguration
in IPv6,
T. Narten, R. Draves, January 2001.
[RFC3152] Delegation of ip6.arpa, R. Bush, August 2001.
[RFC3363] Representing Internet Protocol version 6 (IPv6) Addresses
in the Domain Name System (DNS), R. Bush, A. Durand, B.
Fink, O. Gudmundsson, T. Hain. August 2002.
[DYNREVERSE] Dynamic reverse DNS for IPv6, A. Durand,
draft-durand-dnsops-dynreverse-00.txt, work in progress.
[DNS-ALG] Issues with NAT-PT DNS ALG in RFC2766, A. Durand,
draft-durand-v6ops-natpt-dns-alg-issues-00.txt, work in
progress.
[LOCAL] Operational Guidelines for "local" zones in the DNS,
Kato, A., Vixie, P., draft-kato-dnsop-local-zones-00.txt,
work in progress.
[ICMPNL] Use of ICMPv6 node information query for reverse DNS lookup,
Jun-ichiro itojun Hagino, draft-itojun-ipv6-nodeinfo-
revlookup-00.txt, work in progress.
[IPv6ADDRARCH] IP Version 6 Addressing Architecture, R. Hinden,
draft-ipngwg-addr-arch-v3-11.txt, work in progress.
[6to4ARPA] Delegation of 2.0.0.2.ip6.arpa, Bush, R., Damas, J.,
draft-ymbk-6to4-arpa-delegation-00.txt, work in progress.
[6to4ReverseDNS] 6to4 and DNS, K. Moore, draft-moore-6to4-dns-03.txt,
work in progress.
[DNSdiscovery] Well known site local unicast addresses for DNS
resolver,
A. Durand, J. hagano, D. Thaler, draft-ietf-ipv6-dns-
discovery-07.txt, work in progress.
[DHCPv6DNS] DNS Configuration options for DHCPv6, Droms, R.
draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt, work in
progress.
12. 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.

283
doc/draft/draft-ietf-dnsop-serverid-01.txt Normal file
View file

@ -0,0 +1,283 @@
INTERNET-DRAFT David Conrad
draft-ietf-dnsop-serverid-01.txt Nominum, Inc.
November, 2002
Identifying an Authoritative Name Server
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.
Abstract
A standardized mechanism to determine the identity of a name server
responding to a particular query would be useful, particularly as a
diagnostic aid. This document describes an identification convention
used in one widely deployed implementation of the DNS protocol and
proposes a slight modification to that convention aimed at addressing
some implementation concerns.
1. Introduction
Determining the identity of the name server responding to a query has
become more complex due primarily to the proliferation of various
load balancing techniques. This document describes a convention used
by one particular DNS server implementation to provide identifying
information and proposes a slight modification to that convention to
address concerns regarding implementation neutrality.
Note that this document makes no value judgements as to whether or
not the convention in current use is good or bad; it merely documents
Expires May, 2003 [Page 1]
draft-ietf-dnsop-serverid-01.txt May, 2002
the covention's existence and proposes a slight redefinition of the
convention to address non-technical implementation concerns.
2. Rationale
Identifying which name server is responding to queries is often
useful, particularly in attempting to diagnose name server
difficulties. However, relying on the IP address of the name server
has become more problematic due the deployment of various load
balancing solutions, including the use of shared unicast addresses as
documented in [RFC3258].
An unfortunate side effect of these load balancing solutions is that
traditional methods of determining which server is responding can be
unreliable. Specifically, non-DNS methods such as ICMP ping, TCP
connections, or non-DNS UDP packets (e.g., as generated by tools such
as "traceroute"), etc., can end up going to a different server than
that which receives the DNS queries.
This proposal makes the assumption that an identification mechanism
that relies on the DNS protocol is more likely to be successful
(although not guaranteed) in going to the same machine as a "normal"
DNS query.
3. Historical Conventions
Recent versions of the commonly deployed Berkeley Internet Name
Domain implementation of the DNS protocol suite from the Internet
Software Consortium [BIND] support a way of identifying a particular
server via the use of a standard, if somewhat unusual, DNS query.
Specifically, a query to a late model BIND server for a TXT resource
record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will
return a string that can be configured by the name server
administrator to provide a unique identifier for the responding
server (defaulting to the value of a gethostname() call). This
mechanism, which is an extension of the BIND convention of using
CHAOS class TXT RR queries to sub-domains of the "BIND." domain for
version information, has been copied by several name server vendors.
For reference, the other well-known name used by recent versions of
BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A
query for a TXT RR for this name will return an administratively re-
definable string which defaults to the version of the server
responding.
4. An Implementation Neutral Convention
The previously described use of the CHAOS class "BIND." domain has
Expires May, 2003 [Page 2]
draft-ietf-dnsop-serverid-01.txt May, 2002
(rightly) been viewed by many implementors as not being standardized
nor being implementation neutral. As such, a standard mechanism to
identify a particular machine among a shared unicast set of machines
serving the same DNS data does not currently exist.
Since a name server conforming to [RFC1034] and [RFC1035] should
support the CHAOS class and the use of TXT resource record queries in
the CHAOS class to derive information about a name server has been
used in several independent name server implementations, the quickest
way of supporting the identification of a particular name server out
of a set of name servers all sharing the same unicast prefix would
likely be to standardize on the BIND convention, albeit with a slight
modification to address implementation neutrality concerns.
The convention proposed here simply redefines the top level CHAOS
domain to be "SERVER." instead of "BIND.". Since using the actual
hostname may be considered an information leakage security risk, the
use of the actual hostname of the server is discouraged and instead a
unique per-server identifier should be used. As the BIND convention
of "HOSTNAME" implies the use of a hostname, the domain name
"ID.SERVER" is proposed. That is, a TXT RR query for "ID.SERVER." in
the CHAOS class will return an administratively defined string that
can be used to differentiate among multiple servers.
To make this convention useful, DNS operators wishing to identify
their servers uniquely MUST, for EACH server, put a unique string for
the RDATA of the TXT record associated with the "ID.SERVER." domain
in class CHAOS. For example, given two machines "a.example.com" and
"b.example.com" that receive DNS queries at the same IP address, the
name server administrator could include
$ORIGIN SERVER.
ID CH TXT "a"
in the appropriate zone file on machine "a.example.com" and
$ORIGIN SERVER.
ID CH TXT "b"
in the appropriate zone file on machine "b.example.com".
Queries for TXT RRs of "id.server" in class CHAOS to the IP address
serving both "a.example.com" and "b.example.com" should return "a" or
"b" depending on which machine the query was routed.
Implementors MUST provide a way to disable returning this identifying
information. Implementors SHOULD provide a way to limit who can
query for the identifying information.
Expires May, 2003 [Page 3]
draft-ietf-dnsop-serverid-01.txt May, 2002
The use of other names in the CHAOS class "SERVER." domain are beyond
the scope of this document.
IANA Considerations
The "SERVER." domain in the CHAOS class should be reserved by IANA
and a registry should be created that reserves the "ID" name. In the
future, requests may be submitted for other sub-domains of "SERVER.",
e.g., "VERSION.SERVER." and the IANA should take appropriate action.
Security Considerations
Providing identifying information as to which server is responding
can be seen as information leakage and thus a security risk. It may
be appropriate to restrict who can query for the "ID.SERVER." domain.
Filtering on source address would be one way in which restrictions
can be applied.
The identifer returned via an "ID.SERVER." query SHOULD NOT contain
the hostname or other information that could be considered sensitive.
Acknowledgements
The technique for host identification documented here derive from
practices implemented by Paul Vixie of the Internet Software
Consortium in the Berkeley Internet Name Domain package. Useful
comments on earlier drafts were provided by Bob Halley, Brian
Wellington, Andreas Gustafsson, Ted Hardie, Chris Yarnell, and
members of the ICANN Root Server System Advisory Council. Additional
explanatory information provided due to questions received from Randy
Bush.
References
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3258] Hardie, T., "Distributing Authoritative Name Servers via
Shared Unicast Addresses", RFC 3258, April, 2002.
Author's Address
Expires May, 2003 [Page 4]
draft-ietf-dnsop-serverid-01.txt May, 2002
David Conrad
Nominum, Inc.
2385 Bay Road
Redwood City, CA 94063
USA
Phone: +1 650 381 6003
Fax: +1 650 381 6055
Email: david.conrad@nominum.com
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."
Expires May, 2003 [Page 5]

1495
doc/draft/draft-ietf-idn-punycode-03.txt Normal file
View file

File diff suppressed because it is too large Load diff

442
doc/draft/draft-ietf-idn-uri-03.txt Normal file
View file

@ -0,0 +1,442 @@
Network Working Group M. Duerst
Internet-Draft W3C
Expires: May 4, 2003 November 3, 2002
Internationalized Domain Names in URIs
draft-ietf-idn-uri-03
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 4, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document proposes to upgrade the definition of URIs (RFC 2396)
[RFC2396] to work consistently with internationalized domain names.
Duerst Expires May 4, 2003 [Page 1]
Internet-Draft IDNs in URIs November 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. URI syntax changes . . . . . . . . . . . . . . . . . . . . . . 3
3. Security considerations . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
5. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1 Changes from draft-ietf-idn-uri-02 to draft-ietf-idn-uri-03 . 5
5.2 Changes from draft-ietf-idn-uri-01 to draft-ietf-idn-uri-02 . 5
5.3 Changes from draft-ietf-idn-uri-00 to draft-ietf-idn-uri-01 . 5
References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
Duerst Expires May 4, 2003 [Page 2]
Internet-Draft IDNs in URIs November 2002
1. Introduction
Internet domain names serve to identify hosts and services on the
Internet in a convenient way. The IETF IDN working group [IDNWG] has
been working on extending the character repertoire usable in domain
names beyond a subset of US-ASCII.
One of the most important places where domain names appear are
Uniform Resource Identifiers (URIs, [RFC2396], as modified by
[RFC2732]). However, in the current definition of the generic URI
syntax, the restrictions on domain names are 'hard-coded'. In
Section 2, this document relaxes these restrictions by updating the
syntax, and defines how internationalized domain names are encoded in
URIs.
The syntax in this document has been chosen to further increase the
uniformity of URI syntax, which is a very important principle of
URIs.
In practice, escaped domain names should be used as rarely as
possible. Wherever possible, the actual characters in
Internationalized Domain Names should be preserved as long as
possible by using IRIs [IRI] rather than URIs, and only converting to
URIs and then to ACE-encoded [IDNA] domain names (or ideally directly
to ACE-encoding without even using URIs) when resolving the IRI.
Also, this document does not exclude the use of ACE encoding directly
in an URI domain name part. ACE encoding may be used directly in an
URI domain name part if this is considered necessary for
interoperability.
Please note that even with the definition of URIs in [RFC2396], some
URIs can already contain host names with escaped characters. For
example, mailto:example@w%33.org is legal per [RFC2396] because the
mailto: URI scheme does not follow the generic syntax of [RFC2396].
2. URI syntax changes
The syntax of URIs [RFC2396] currently contains the following rules
relevant to domain names:
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum
Duerst Expires May 4, 2003 [Page 3]
Internet-Draft IDNs in URIs November 2002
The later two rules are changed as follows:
domainlabel = anchar | anchar *( anchar | "-" ) anchar
toplabel = achar | achar *( anchar | "-" ) anchar
and the following rules are added:
anchar = alphanum | escaped
achar = alpha | escaped
Characters outside the repertoire (alphanum) are encoded by first
encoding the characters in UTF-8 [RFC 2279], resulting in a sequence
of octets, and then escaping these octets according to the rules
defined in [RFC2396].
Using UTF-8 assures that this encoding interoperates with IRIs [IRI].
It is also aligned with the recommendations in [RFC2277] and
[RFC2718], and is consistent with the URN syntax [RFC2141] as well as
recent URL scheme definitions that define encodings of non-ASCII
characters based on UTF-8 (e.g., IMAP URLs [RFC2192] and POP URLs
[RFC2384]).
The above syntax rules permit for domain names that are neither
permitted as US-ASCII only domain names nor as internationalized
domain names. However, such domain names should never be used, and
will never be resolved because no such domains will be registered.
For US-ASCII only domain names, the syntax rules in [RFC2396] are
relevant. For example, http://www.w%33.org is legal, because the
corresponding 'w3' is a legal 'domainlabel' according to [RFC2396].
However, http://%2a.example.org is illegal because the corresponding
'*' is not a legal 'domainlabel' according to [RFC2396].
For domain names containing non-ASCII characters, the legal domain
names are those for which the ToASCII operation ([IDNA], [Nameprep];
using the unescaped UTF-8 values as input), with the flags
"UseSTD3ASCIIRules" and "AllowUnassigned" set, is successful. The
URI resolver MUST apply any steps required as part of domain name
resolution by [IDNA], in particular the ToASCII operation, with the
above-mentioned flags set. URIs where the ToASCII operation results
in an error should be treated as unresolvable.
For domain names containing non-ASCII characters, the Nameprep
specification ([Nameprep]) defines some mappings, which mainly
include normalization to NFKC and folding to lower case. When
encoding an internationalized domain name in an URI, these mappings
SHOULD NOT be applied. It should be assumed that the domain name is
already normalized as far as appropriate.
Duerst Expires May 4, 2003 [Page 4]
Internet-Draft IDNs in URIs November 2002
For consistency in comparison operations and for interoperability
with older software, the following should be noted: 1) US-ASCII
characters in domain names should not be escaped. 2) Because of the
principle of syntax uniformity for URIs, it is always more prudent to
take into account the possibility that US-ASCII characters are
escaped.
3. Security considerations
The security considerations of [RFC2396] and those applying to
internationalized domain names apply. There may be an increased
potential to smuggle escaped US-ASCII-based domain names across
firewalls, although because of the uniform syntax principle for URIs,
such a potential is already existing.
4. Acknowledgements
Erik Nordmark
5. Change Log
5.1 Changes from draft-ietf-idn-uri-02 to draft-ietf-idn-uri-03
Clarified expectations on name checking.
5.2 Changes from draft-ietf-idn-uri-01 to draft-ietf-idn-uri-02
Moved change log to back
Changed to only change URIs; IRI syntax updated directly in IRI
draft.
Removed syntax restriction on %hh in the US-ASCII part, but made
clear that restrictions to domain names apply.
Made clear that escaped domain names in URIs should only be an
intermediate representation.
Gave example of mailto: as already allowing escaped host names.
Corrected some typos.
5.3 Changes from draft-ietf-idn-uri-00 to draft-ietf-idn-uri-01
Changed requirement for URI/IRI resolvers from MUST to SHOULD
Changed IRI syntax slightly (ichar -> idchar, based on changes in
[IRI])
Duerst Expires May 4, 2003 [Page 5]
Internet-Draft IDNs in URIs November 2002
Various wording changes
References
[IDNA] Faltstrom, P., Hoffman, P. and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
draft-ietf-idn-idna-14.txt (work in progress), October
2002, <http://www.ietf.org/internet-drafts/draft-ietf-
idn-idna-14.txt>.
[IDNWG] "IETF Internationalized Domain Name (idn) Working Group".
[IRI] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRI)", draft-duerst-iri-02.txt (work in
progress), November 2002, <http://www.ietf.org/internet-
drafts/draft-duerst-iri-02.txt>.
[ISO10646] International Organization for Standardization,
"Information Technology - Universal Multiple-Octet Coded
Character Set (UCS) - Part 1: Architecture and Basic
Multilingual Plane", ISO Standard 10646-1, October 2000.
[Nameprep] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names", draft-ietf-
idn-nameprep-11.txt (work in progress), June 2002,
<http://www.ietf.org/internet-drafts/draft-ietf-idn-
nameprep-11.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2192] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[RFC2384] Gellens, R., "POP URL Scheme", RFC 2384, August 1998.
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2640] Curtin, B., "Internationalization of the File Transfer
Duerst Expires May 4, 2003 [Page 6]
Internet-Draft IDNs in URIs November 2002
Protocol", RFC 2640, July 1999.
[RFC2718] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
"Guidelines for new URL Schemes", RFC 2718, November
1999.
[RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for
Literal IPv6 Addresses in URL's", RFC 2732, December
1999.
Author's Address
Martin Duerst
World Wide Web Consortium
200 Technology Square
Cambridge, MA 02139
U.S.A.
Phone: +1 617 253 5509
Fax: +1 617 258 5999
EMail: duerst@w3.org
URI: http://www.w3.org/People/D%C3%BCrst/
Duerst Expires May 4, 2003 [Page 7]
Internet-Draft IDNs in URIs November 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
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.
Duerst Expires May 4, 2003 [Page 8]

2045
doc/draft/draft-ietf-ipngwg-rfc2553bis-10.txt Normal file
View file

File diff suppressed because it is too large Load diff

660
doc/draft/draft-ietf-ipv6-dns-discovery-07.txt Normal file
View file

@ -0,0 +1,660 @@
Network Working Group Alain Durand
INTERNET-DRAFT SUN Microsystems, inc.
October 25, 2002 Jun-ichiro itojun Hagino
Expires April 2002 IIJ Research Laboratory
Dave Thaler
Microsoft
Well known site local unicast addresses
to communicate with recursive DNS servers
<draft-ietf-ipv6-dns-discovery-07.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 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 a "work in progress".
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This documents specifies 3 well known addresses to configure stub
resolvers on IPv6 nodes to enable them to communicate with recursive
DNS server with minimum configuration in the network and without
running a discovery protocol on the end nodes. This method may be
used when no other information about the addresses of recursive DNS
servers is available. Implementation of stub resolvers using this as
default configuration must provide a way to override this.
Copyright notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
1. Introduction
RFC 2462 [ADDRCONF] provides a way to autoconfigure nodes with one or
more IPv6 address and default routes.
However, for a node to be fully operational on a network, many other
parameters are needed, such as the address of a name server that
offer recursive service (a.k.a. recursive DNS server), mail relays,
web proxies, etc. Except for name resolution, all the other services
are usually described using names, not addresses, such as
smtp.myisp.net or webcache.myisp.net. For obvious bootstrapping
reasons, a node needs to be configured with the IP address (and not
the name) of a recursive DNS server. As IPv6 addresses look much
more complex than IPv4 ones, there is some incentive to make this
configuration as automatic and simple as possible.
Although it would be desirable to have all configuration parameters
configured/discovered automatically, it is common practice in IPv4
today to ask the user to do manual configuration for some of them by
entering server names in a configuration form. So, a solution that
will allow for automatic configuration of the recursive DNS server is
seen as an important step forward in the autoconfiguration story.
The intended usage scenario for this proposal is a home or enterprise
network where IPv6 nodes are plugged/unplugged with minimum
management and use local resources available on the network to
autoconfigure. This proposal is also useful in cellular networks
where all mobile devices are included within the same site.
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 [KEYWORDS].
2. Well known addresses vs discovery
Some of the discussions in the past around DNS server discovery have
been trying to characterize the solution space into stateless versus
stateful or server oriented versus severless. It is not absolutely
clear how much state if any needs to be kept to perform DNS server
discovery, and, although the semantic differences between a router
and a server are well understood from a conceptual perspective, the
current implementations tend to blur the picture. In another attempt
to characterize different approaches, one can look at how much
intelligence a client needs to have in order to use the service.
One avenue is to ask the IPv6 node to participate in a discovery
protocol, such as SLP or DHCP, learn the address of the server and
send packets to this server. Another one is to configure the IPv6
node with well known addresses and let the local routing system
forward packets to the right place. This document explores this
later avenue of configuration using well known addresses that does
not require participation of the end node in any discovery mechanism.
3. Reserved prefix and addresses
The mechanism described here is:
- intended for ongoing use and not not just for bootstrapping
- intended to populate a stub resolver's list of available
recursive servers only if that list is otherwise unpopulated
- providing reliability through redundancy using three unicast
addresses.
3.1 Stub resolver configuration
This memo reserved three well known IPv6 site local addresses.
In the absence of any other information about the addresses of
recursive DNS servers, IPv6 stub-resolvers MAY use any of those three
IPv6 addresses in their list of candidate recursive DNS servers.
3.2 Recursive DNS servers configuration
Within sites, one or more recursive DNS server SHOULD be configured
with any of those three addresses. It is RECOMMENDED that large sites
deploy 3 recursive DNS servers, one for each reserved address. Small
site could use only one recursive DNS server and assign the 3
addresses to it.
3.3 Rationale for the choice of three addresses
Three was chosen based on common practice in many places in the
industry. While it's true that if the first one fails, that it's
unlikely the second one will succeed (due to there really being no
DNS server at all), using multiple addresses is important so that
when ones do exist, the host can fail over to a second server more
quickly than routing converges. Three servers is a compromise between
extra reliability and increased complexity (maintaining additional
servers, having multiple entries in the routing system, additional
delays before the stub resolver returns an error,...).
Another reason to have multiple addresses is to avoid the need to use
of anycast addresses to achieve reliability through redundancy. On
top of the classic problems (TCP sessions, ICMP messages,...) using
an anycast address would hide the real locations of the recursive DNS
servers to the stub resolver, prohibiting it to keep track of which
servers are performing correctly. For this particular matter, using
well known addresses is no different than configuring the stub
resolver with regular addresses taken from the local site.
3.4 Implementation considerations
Stub resolver implementation MAY be configured by default using those
addresses. However, implementing only the mechanism described in this
memo may end up causing some interoperability problems when operating
in networks where no recursive DNS server is configured with any of
the well known addresses. Thus, stub resolvers MUST implement
mechanisms for overriding this default, for example: manual
configuration, L2 mechanisms and/or DHCPv6.
4. Routing
A solution to enable the stub resolvers to reach the recursive DNS
servers is to inject host routes in the local routing system.
Examples of methods for injecting host routes and a brief discussion
of their fate sharing properties are presented here:
a) Manual injection of routes by a router on the same subnet.
If the node running the recursive DNS server goes down, the router
may or may not be notified and keep announcing the route.
b) Running a routing protocol on the same node running the DNS
resolver.
If the process running the recursive DNS server dies, the routing
protocol may or may not be notified and keep announcing the route.
c) Running a routing protocol within the same process running the
recursive DNS server.
If the recursive DNS server and the routing protocol run in
separated threads, similar concerns as above are true.
d) Developing an "announcement" protocol that the recursive DNS
server could use to advertize the host route to the nearby router.
Details of such a protocol are out of scope of this document, but
something similar to [MLD] is possible. However, the three first
mechanisms should cover most cases.
An alternate solution is to configure a link with the well known
prefix and position the three recursive DNS servers on that link.
The advantage of this method is that host routes are not necessary ,
the well known prefix is advertised to the routing system by the
routers on the link. However, in the event of a problem on the
physical link, all resolvers will become unreachable.
IANA considerations for this prefix are covered in Section 6.
5. Site local versus global scope considerations
The rationales for having a site local prefix are:
-a) Using a site local prefix will ensure that the traffic to the
recursive DNS servers stays local to the site. This will prevent
the DNS requests from accidentally leaking out of the site.
However, the local resolver can implement a policy to forward DNS
resolution of non-local addresses to an external DNS resolver.
-b) Reverse DNS resolution of site local addresses is only
meaningful within the site. Thus, making sure that such queries
are first sent to a recursive DNS server located within the site
perimeter increase their likelihood of success.
6. Examples of use
This section presents example scenarios showing how the mechanism
described in this memo can co-exist with other techniques, namely
manual configuration and DHCPv6 discovery.
Note: those examples are just there to illustrate some usage
scenarios and in no way do they suggest any recommended practices.
6.1 Simple case, general purpose recursive DNS server
This example shows the case of a network that manages one recursive
DNS server and a large number of nodes running DNS stub resolvers.
The recursive DNS server is performing (and caching) all the
recursive queries on behalf of the stub resolvers. The recursive DNS
server is configured with an IPv6 address taken from the prefix
delegated to the site and with the 3 well known addresses defined in
this memo. The stub resolvers are either configured with the "real"
IPv6 address of the recursive DNS server or with the well known site
local unicast addresses defined in this memo.
--------------------------------------------
| |
| --------------------- |
| |DNS stub resolver | |
| |configured with the| |
| |"real" address of | |
| |the recursive DNS | |
| |server | |
| --------------------- |
| ----------- | |
| |recursive| | |
| |DNS |<---------- |
| |server |<---------------- |
| ----------- | |
| ---------------------- |
| |DNS stub resolver | |
| |configured with 3 | |
| |well known addresses| |
| ---------------------- |
| |
--------------------------------------------
(The recursive DNS server is configured to listen both on
its IPv6 address and on the well known address)
6.2 Three recursive DNS servers
This is a similar example as above, except that three recursive DNS
resolvers are configured instead of just one.
-------------------------------------------
| |
| --------------------- |
| |DNS stub resolver | |
| |configured with the| |
| |"real" address of | |
| |the recursive DNS | |
| |server | |
| --------------------- |
| | |
| ----------- | |
| |recursive| | |
| |DNS |<---------| |
| |server 1 |<---------|------ |
| ----------- | | |
| | | |
| ----------- | | |
| |recursive| | | |
| |DNS |<---------| | |
| |server 2 |<---------|-----| |
| ----------- | | |
| | | |
| ----------- | | |
| |recursive| | | |
| |DNS |<---------- | |
| |server 3 |<---------------| |
| ----------- | |
| ---------------------- |
| |DNS stub resolver | |
| |configured with 3 | |
| |well known addresses| |
| ---------------------- |
| |
-------------------------------------------
(The recursive DNS server is configured to listen both on
its IPv6 address and on the well known address)
6.3 DNS forwarder
A drawback of the choice of site local scope for the reserved
addresses for recursive DNS server is that, in the case of a
home/small office network connected to an ISP, DNS traffic cannot be
sent directly to the ISP recursive DNS server without having the ISP
and all its customers share the same definition of site.
In this scenario, the home/small office network is connected to the
ISP router (PE) via an edge router (CPE).
-------------
/ |
-------- ----- / |
|ISP PE| |CPE| / Customer |
| |===========| |====< site |
| | | | \ |
-------- ----- \ |
\ |
-------------
The customer router CPE could be configured on its internal interface
with one of the reserved site local addresses and listen for DNS
queries. It would be configured to use one (or several) of the well
known site local unicast addresses within the ISP's site to send its
own queries to. It would act as a DNS forwarder, forwarding queries
received on its internal interface to the ISP's recursive DNS server.
-------------
/ |
---------- -------------- / |
|ISP | | CPE| / Customer |
|DNS |===========| DNS|====< site |
|server | <------|---forwarder|-----\---- |
---------- -------------- \ |
\ |
-------------
In this configuration, the CPE is acting as a multi-sited router.
6.4 DNS forwarder with DHCPv6 interactions
In this variant scenario, DHCPv6 is be used between the PE and CPE to
do prefix delegation [DELEG] and recursive DNS server discovery.
-------------
/ |
-------- -------------- / |
|ISP | |customer CPE| / Customer |
|DHCPv6|===========| DHCPv6|====< site |
|server| <------|------client| \ |
-------- -------------- \ |
\ |
-------------
This example will show how DHCPv6 and well known site local unicast
addresses cooperate to enable the internal nodes to access DNS.
The customer router CPE is configured on its internal interface with
one of the reserved site local addresses and listen for DNS queries.
It would act as a DNS forwarder, as in 5.2, forwarding those queries
to the recursive DNS server pointed out by the ISP in the DHCPv6
exchange.
-------------
/ |
---------- -------------- / |
|ISP | |customer CPE| / Customer |
|DNS |===========| DNS|====< site |
|resolver| <------|---forwarder|-----\---- |
---------- -------------- \ |
\ |
-------------
The same CPE router could also implement a local DHCPv6 server and
advertizes itself as DNS forwarder.
-------------
/ |
-------- -------------- / Customer |
|ISP PE| |customer CPE| / site |
| |===========|DHCPv6 |====< |
| | |server------|-----\---> |
-------- -------------- \ |
\ |
-------------
Within the site:
a) DHCPv6 aware clients use DHCPv6 to obtain the address of the
DNS forwarder...
-------------
/ |
---------- -------------- / Customer |
|ISP | |customer CPE| / site |
|DNS |===========| DNS|====< |
|resolver| <------|---forwarder|-----\----DHCPv6 |
---------- -------------- \ client |
\ |
-------------
(The address of the DNS forwarder is acquired via DHCPv6.)
b) other nodes simply send their DNS request to the reserved site
local addresses.
-------------
/ |
---------- -------------- / customer |
|ISP | |customer CPE| / site |
|DNS |===========| DNS|====< |
|resolver| <------|---forwarder|-----\----non DHCPv6|
---------- -------------- \ node |
\ |
-------------
(Internal nodes use the reserved site local unicast address.)
A variant of this scenario is the CPE can decide to pass the global
address of the ISP recursive DNS server in the DHCPv6 exchange with
the internal nodes.
7. IANA considerations
The site local prefix fec0:0000:0000:ffff::/64 is to be reserved out
of the site local fec0::/10 prefix.
The unicast addresses fec0:000:0000:ffff::1, fec0:000:0000:ffff::2
and fec0:000:0000:ffff::3 are to be reserved for recursive DNS server
configuration.
All other addresses within the fec0:0000:0000:ffff::/64 are reserved
for future use and are expected to be assigned only with IESG
approval.
8. Security Considerations
Ensuring that queries reach a legitimate DNS server relies on the
security of the IPv6 routing infrastructure. The issues here are the
same as those for protecting basic IPv6 connectivity.
IPsec/IKE can be used as the well known addresses are used as unicast
addresses.
The payload can be protected using standard DNS security techniques.
If the client can preconfigure a well known private or public key
then TSIG [TSIG] can be used with the same packets presented for the
query. If this is not the case, then TSIG keys will have to be
negotiated using [TKEY]. After the client has the proper key then
the query can be performed.
The use of site local addresses instead of global addresses will
ensure the DNS queries issued by host using this mechanism will not
leak out of the site.
9. References
[KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ADDRCONF]
Thomson, S., and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[MLD]
Deering, S., Fenner, W., Haberman, B.,
"Multicast Listener Discovery (MLD) for IPv6",
RFC2710, October 1999.
[TSIG]
Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)",
RFC2845, May 2000.
[TKEY]
D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)",
RFC2930, September 2000.
[DHCPv6]
Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and
Droms, R. (ed.), "Dynamic host Configuration Protocol for IPv6
(DHCPv6)", draft-ietf-dhc-dhcpv6-27 (work in progress),
Februray 2002.
[DELEG]
Troan, O., Droms, R., "IPv6 Prefix Options for DHCPv6",
draft-troan-dhcpv6-opt-prefix-delegation-01.txt (work in progress),
February 2002.
10. Authors' Addresses
Alain Durand
SUN microsystems, inc.
17 Network Circle, UMPK 17-202
Menlo Park, CA 94025
Email: Alain.Durand@sun.com
Jun-ichiro itojun HAGINO
Research Laboratory, Internet Initiative Japan Inc.
Takebashi Yasuda Bldg.,
3-13 Kanda Nishiki-cho,
Chiyoda-ku, Tokyo 101-0054, JAPAN
Email: itojun@iijlab.net
Dave Thaler
Microsoft
One Microsoft Way
Redmond, CA 98052, USA
Email: dthaler@microsoft.com
11. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
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 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.

616
doc/draft/draft-ietf-secsh-dns-04.txt Normal file
View file

@ -0,0 +1,616 @@
Secure Shell Working Group J. Schlyter
Internet-Draft Carlstedt Research &
Expires: October 1, 2003 Technology
W. Griffin
Network Associates Laboratories
April 2, 2003
Using DNS to securely publish SSH key fingerprints
draft-ietf-secsh-dns-04.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 October 1, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes a method to verify SSH host keys using
DNSSEC. The document defines a new DNS resource record that contains
a standard SSH key fingerprint.
Schlyter & Griffin Expires October 1, 2003 [Page 1]
Internet-Draft DNS and SSH fingerprints April 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3
2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . 3
2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4
2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4
3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4
3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 4
3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . . 5
3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . . 5
3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Presentation Format of the SSHFP RR . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
Normative References . . . . . . . . . . . . . . . . . . . . 8
Informational References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . 10
Schlyter & Griffin Expires October 1, 2003 [Page 2]
Internet-Draft DNS and SSH fingerprints April 2003
1. Introduction
The SSH [5] protocol provides secure remote login and other secure
network services over an insecure network. The security of the
connection relies on the server authenticating itself to the client.
Server authentication is normally done by presenting the fingerprint
of an unknown public key to the user for verification. If the user
decides the fingerprint is correct and accepts the key, the key is
saved locally and used for verification for all following
connections. While some security-conscious users verify the
fingerprint out-of-band before accepting the key, many users blindly
accepts the presented key.
The method described here can provide out-of-band verification by
looking up a fingerprint of the server public key in the DNS [1][2]
and using DNSSEC [4] to verify the lookup.
In order to distribute the fingerprint using DNS, this document
defines a new DNS resource record to carry the fingerprint.
Basic understanding of the DNS system [1][2] and the DNS security
extensions [4] is assumed by this document.
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 [3].
2. SSH Host Key Verification
2.1 Method
Upon connection to a SSH server, the SSH client MAY look up the SSHFP
resource record(s) for the host it is connecting to. If the
algorithm and fingerprint of the key received from the SSH server
matches the algorithm and fingerprint of one of the SSHFP resource
record(s) returned from DNS, the client MAY accept the identity of
the server.
2.2 Implementation Notes
Client implementors SHOULD provide a configurable policy used to
select the order of methods used to verify a host key. This document
defines one method: Fingerprint storage in DNS. Another method
defined in the SSH Architecture [5] uses local files to store keys
for comparison. Other methods that could be defined in the future
might include storing fingerprints in LDAP or other databases. A
configurable policy will allow administrators to determine which
Schlyter & Griffin Expires October 1, 2003 [Page 3]
Internet-Draft DNS and SSH fingerprints April 2003
methods they want to use and in what order the methods should be
prioritized. This will allow administrators to determine how much
trust they want to place in the different methods.
One specific scenario for having a configurable policy is where
clients do not use fully qualified host names to connect to servers.
In this scenario, the implementation SHOULD verify the host key
against a local database before verifying the key via the fingerprint
returned from DNS. This would help prevent an attacker from injecting
a DNS search path into the local resolver and forcing the client to
connect to a different host.
2.3 Fingerprint Matching
The public key and the SSHFP resource record are matched together by
comparing algorithm number and fingerprint.
The public key algorithm and the SSHFP algorithm number MUST
match.
A message digest of the public key, using the message digest
algorithm specified in the SSHFP fingerprint type, MUST match the
SSH FP fingerprint.
2.4 Authentication
A public key verified using this method MUST only be trusted if the
SSHFP resource record (RR) used for verification was authenticated by
a trusted SIG RR.
Clients that do not validate the DNSSEC signatures themselves MUST
use a secure transport, e.g. TSIG [8], SIG(0) [9] or IPsec [7],
between themselves and the entity performing the signature
validation.
3. The SSHFP Resource Record
The SSHFP resource record (RR) is used to store a fingerprint of a
SSH public host key that is associated with a Domain Name System
(DNS) name.
The RR type code for the SSHFP RR is TBA.
3.1 The SSHFP RDATA Format
The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
type and the fingerprint of the public host key.
Schlyter & Griffin Expires October 1, 2003 [Page 4]
Internet-Draft DNS and SSH fingerprints April 2003
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | fp type | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ /
/ fingerprint /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.1 Algorithm Number Specification
This algorithm number octet describes the algorithm of the public
key. The following values are assigned:
Value Algorithm name
----- --------------
0 reserved
1 RSA
2 DSS
Reserving other types requires IETF consensus.
3.1.2 Fingerprint Type Specification
The fingerprint type octet describes the message-digest algorithm
used to calculate the fingerprint of the public key. The following
values are assigned:
Value Fingerprint type
----- ----------------
0 reserved
1 SHA-1
Reserving other types requires IETF consensus. For interoperability
reasons, as few fingerprint types as possible should be reserved.
The only reason to reserve additional types is to increase security.
3.1.3 Fingerprint
The fingerprint is calculated over the public key blob as described
in [6].
The message-digest algorithm is presumed to produce an opaque octet
string output which is placed as-is in the RDATA fingerprint field.
Schlyter & Griffin Expires October 1, 2003 [Page 5]
Internet-Draft DNS and SSH fingerprints April 2003
3.2 Presentation Format of the SSHFP RR
The presentation format of the SSHFP resource record consists of two
numbers (algorithm and fingerprint type) followed by the fingerprint
itself presented in hex, e.g:
host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890
4. Security Considerations
Currently, the amount of trust a user can realistically place in a
server key is proportional to the amount of attention paid to
verifying that the public key presented actually corresponds to the
private key of the server. If a user accepts a key without verifying
the fingerprint with something learned through a secured channel, the
connection is vulnerable to a man-in-the-middle attack.
The approach suggested here shifts the burden of key checking from
each user of a machine to the key checking performed by the
administrator of the DNS recursive server used to resolve the host
information. Hopefully, by reducing the number of times that keys
need to be verified by hand, each verification is performed more
completely. Furthermore, by requiring an administrator do the
checking, the result may be more reliable than placing this task in
the hands of an application user.
The overall security of using SSHFP for SSH host key verification is
dependent on detailed aspects of how verification is done in SSH
implementations. One such aspect is in which order fingerprints are
looked up (e.g. first checking local file and then SSHFP). We note
that in addition to protecting the first-time transfer of host keys,
SSHFP can optionally be used for stronger host key protection.
If SSHFP is checked first, new SSH host keys may be distributed by
replacing the corresponding SSHFP in DNS.
If SSH host key verification can be configured to require SSHFP,
we can implement SSH host key revocation by removing the
corresponding SSHFP from DNS.
As stated in Section 2.2, we recommend that SSH implementors provide
a policy mechanism to control the order of methods used for host key
verification. One specific scenario for having a configurable policy
is where clients use unqualified host names to connect to servers. In
this case, we recommend that SSH implementations check the host key
against a local database before verifying the key via the fingerprint
returned from DNS. This would help prevent an attacker from injecting
Schlyter & Griffin Expires October 1, 2003 [Page 6]
Internet-Draft DNS and SSH fingerprints April 2003
a DNS search path into the local resolver and forcing the client to
connect to a different host.
A different approach to solve the DNS search path issue would be for
clients to use a trusted DNS search path, i.e., one not acquired
through DHCP or other autoconfiguration mechanisms. Since there is no
way with current DNS lookup APIs to tell whether a search path is
from a trusted source, the entire client system would need to be
configured with this trusted DNS search path.
Another dependency is on the implementation of DNSSEC itself. As
stated in Section 2.4, we mandate the use of secure methods for
lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This
is especially important if SSHFP is to be used as a basis for host
key rollover and/or revocation, as described above.
Since DNSSEC only protects the integrity of the host key fingerprint
after it is signed by the DNS zone administrator, the fingerprint
must be transferred securely from the SSH host administrator to the
DNS zone administrator. This could be done manually between the
administrators or automatically using secure DNS dynamic update [10]
between the SSH server and the nameserver. We note that this is no
different from other key enrollment situations, e.g. a client sending
a certificate request to a certificate authority for signing.
5. IANA Considerations
IANA needs to allocate a RR type code for SSHFP from the standard RR
type space (type 44 requested).
IANA needs to open a new registry for the SSHFP RR type for public
key algorithms. Defined types are:
0 is reserved
1 is RSA
2 is DSA
Adding new reservations requires IETF consensus.
IANA needs to open a new registry for the SSHFP RR type for
fingerprint types. Defined types are:
0 is reserved
1 is SHA-1
Adding new reservations requires IETF consensus.
Normative References
Schlyter & Griffin Expires October 1, 2003 [Page 7]
Internet-Draft DNS and SSH fingerprints April 2003
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[5] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH
Protocol Architecture", draft-ietf-secsh-architecture-13 (work
in progress), September 2002.
[6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
Lehtinen, "SSH Transport Layer Protocol",
draft-ietf-secsh-transport-15 (work in progress), September
2002.
Informational References
[7] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
Roadmap", RFC 2411, November 1998.
[8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[9] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.
[10] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
Authors' Addresses
Jakob Schlyter
Carlstedt Research & Technology
Stora Badhusgatan 18-20
Goteborg SE-411 21
Sweden
EMail: jakob@crt.se
URI: http://www.crt.se/~jakob/
Schlyter & Griffin Expires October 1, 2003 [Page 8]
Internet-Draft DNS and SSH fingerprints April 2003
Wesley Griffin
Network Associates Laboratories
15204 Omega Drive Suite 300
Rockville, MD 20850
USA
EMail: wgriffin@tislabs.com
URI: http://www.nailabs.com/
Appendix A. Acknowledgements
The authors gratefully acknowledges, in no particular order, the
contributions of the following persons:
Martin Fredriksson
Olafur Gudmundsson
Edward Lewis
Bill Sommerfeld
Schlyter & Griffin Expires October 1, 2003 [Page 9]
Internet-Draft DNS and SSH fingerprints April 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 assignees.
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
Schlyter & Griffin Expires October 1, 2003 [Page 10]
Internet-Draft DNS and SSH fingerprints April 2003
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.
Schlyter & Griffin Expires October 1, 2003 [Page 11]

519
doc/draft/draft-ihren-dnsext-threshold-validation-00.txt Normal file
View file

@ -0,0 +1,519 @@
Internet Draft Johan Ihren
draft-ihren-dnsext-threshold-validation-00.txt Autonomica
February 2003
Expires in six months
Threshold Validation:
A Mechanism for Improved Trust and Redundancy for DNSSEC Keys
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.
Abstract
This memo documents a proposal for a different method of validation
for DNSSEC aware resolvers. The key change is that by changing from
a model of one Key Signing Key, KSK, at a time to multiple KSKs it
will be possible to increase the aggregated trust in the signed
keys by leveraging from the trust associated with the different
signees.
By having multiple keys to chose from validating resolvers get the
opportunity to use local policy to reflect actual trust in
different keys. For instance, it is possible to trust a single,
particular key ultimately, while requiring multiple valid
signatures by less trusted keys for validation to succeed.
Furthermore, with multiple KSKs there are additional redundancy
benefits available since it is possible to roll over different KSKs
at different times which may make rollover scenarios easier to
manage.
Contents
1. Terminology
2. Introduction and Background
3. Trust in DNSSEC Keys
3.1. Key Management, Split Keys and Trust Models
3.2. Trust Expansion: Authentication versus Authorization
4. Proposed Semantics for Signing the KEY Resource Record
Set
4.1. Packet Size Considerations
5. Proposed Use of Multiple "Trusted Keys" in a Validating
Resolver
5.1. Not All Possible KSKs Need to Be Trusted
5.2. Possible to do Threshold Validation
5.3. Not All Trusted Keys Will Be Available
6. Additional Benefits from Having Multiple KSKs
6.1. More Robust Key Rollovers
6.2. Evaluation of Multiple Key Distribution Mechanisms
7. Security Considerations
8. IANA Considerations.
9. References
9.1. Normative.
9.2. Informative.
10. Acknowledgments.
11. Authors' Address
1. Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
and "MAY" in this document are to be interpreted as described in
RFC 2119.
The term "zone" refers to the unit of administrative control in the
Domain Name System. "Name server" denotes a DNS name server that is
authoritative (i.e. knows all there is to know) for a DNS zone,
typically the root zone. A "resolver", is a DNS "client", i.e. an
entity that sends DNS queries to authoritative nameservers and
interpret the results. A "validating resolver" is a resolver that
attempts to perform DNSSEC validation on data it retrieves by doing
DNS lookups.
2. Introduction and Background
From a protocol perspective there is no real difference between
different keys in DNSSEC. They are all just keys. However, in
actual use there is lots of difference. First and foremost, most
DNSSEC keys have in-band verification. I.e. the keys are signed by
some other key, and this other key is in its turn also signed by
yet another key. This way a "chain of trust" is created. Such
chains have to end in what is referred to as a "trusted key" for
validation of DNS lookups to be possible.
A "trusted key" is a the public part of a key that the resolver
acquired by some other means than by looking it up in DNS. The
trusted key has to be explicitly configured.
A node in the DNS hierarchy that issues such out-of-band "trusted
keys" is called a "security apex" and the trusted key for that apex
is the ultimate source of trust for all DNS lookups within that
entire subtree.
DNSSEC is designed to be able to work with more than on security
apex. These apexes will all share the problem of how to distribute
their "trusted keys" in a way that provides validating resolvers
confidence in the distributed keys.
Maximizing that confidence is crucial to the usefulness of DNSSEC
and this document tries to address this issue.
3. Trust in DNSSEC Keys
In the end the trust that a validating resolver will be able to put
in a key that it cannot validate within DNSSEC will have to be a
function of
* trust in the key issuer, aka the KSK holder
* trust in the distribution method
* trust in extra, out-of-band verification
The KSK holder needs to be trusted not to accidentally lose private
keys in public places. Furthermore it needs to be trusted to
perform correct identification of the ZSK holders in case they are
separate from the KSK holder itself.
The distribution mechanism can be more or less tamper-proof. If the
key holder publishes the public key, or perhaps just a secure
fingerprint of the key in a major newspaper it may be rather
difficult to tamper with. A key acquired that way may be easier to
trust than if it had just been downloaded from a web page.
Out-of-band verification can for instance be the key being signed
by a certificate issued by a known Certificate Authority that the
resolver has reason to trust.
3.1. Simplicity vs Trust
The fewer keys that are in use the simpler the key management
becomes. Therefore increasing the number of keys should only be
considered when the complexity is not the major concern. A perfect
example of this is the distinction between so called Key Signing
Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds
overall complexity but simplifies real life operations and was an
overall gain since operational simplification was considered to be
a more crucial issue than the added complexity.
In the case of a security apex there are additional issues to
consider, among them
* maximizing trust in the KSK received out-of-band
* authenticating the legitimacy of the ZSKs used
In some cases this will be easy, since the same entity will manage
both ZSKs and KSKs (i.e. it will authenticate itself, somewhat
similar to a self-signed certificate). In some environments it will
be possible to get the trusted key installed in the resolver end by
decree (this would seem to be a likely method within corporate and
government environments).
In other cases, however, this will possibly not be sufficient. In
the case of the root zone this is obvious, but there may well be
other cases.
3.2. Expanding the "Trust Base"
For a security apex where the ZSKs and KSK are not held by the same
entity the KSK will effectively authenticate the identity of
whoever does real operational zone signing. The amount of trust
that the data signed by a ZSK will get is directly dependent on
whether the end resolver trusts the KSK or not, since the resolver
has no OOB access to the public part of the ZSKs (for practical
reasons).
Since the KSK holder is distinct from the ZSK holder the obvious
question is whether it would then be possible to further improve
the situation by using multiple KSK holders and thereby expanding
the trust base to the union of that available to each individual
KSK holder. "Trust base" is an invented term intended to signify
the aggregate of Internet resolvers that will eventually choose to
trust a key issued by a particular KSK holder.
A crucial issue when considering trust expansion through addition
of multiple KSK holders is that the KSK holders are only used to
authenticate the ZSKs used for signing the zone. I.e. the function
performed by the KSK is basically:
"This is indeed the official ZSK holder for this zone,
I've verified this fact to the best of my abilitites."
Which can be thought of as similar to the service of a public
notary. I.e. the point with adding more KSK holders is to improve
the public trust in data signed by the ZSK holders by improving the
strength of available authentication.
Therefore adding more KSK holders, each with their own trust base,
is by definition a good thing. More authentication is not
controversial. On the contrary, when it comes to authentication,
the more the merrier.
4. Proposed Semantics for Signing the KEY Resource Record Set
In DNSSEC according to RFC2535 all KEY Resource Records are used to
sign all authoritative data in the zone, including the KEY RRset
itself, since RFC2535 makes no distinction between Key Signing
Keys, KSK, and Zone Signing Keys, ZSK. With Delegation Signer [DS]
it is possible to change this to the KEY RRset being signed with
all KSKs and ZSKs but the rest of the zone only being signed by the
ZSKs.
This proposal changes this one step further, by recommending that
the KEY RRset is only signed by the Key Signing Keys, KSK, and
explicitly not by the Zone Signing Keys, ZSK. The reason for this
is to maximize the amount of space in the DNS response packet that
is available for additional KSKs and signatures thereof. The rest
of the authoritative zone contents are as previously signed by only
the ZSKs.
4.1. Packet Size Considerations
The reason for the change is to keep down the size of the aggregate
of KEY RRset plus SIG(KEY) that resolvers will need to acquire to
perform validation of data below a security apex. For DNSSEC data
to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be
set, and therefore the allowed packet size can be assumed to be at
least the EDNS0 minimum of 4000 bytes.
When querying for KEY + SIG(KEY) for "." (the case that is assumed
to be most crucial) the size of the response packet after the
change to only sign the KEY RR with the KSKs break down into a
rather large space of possibilities. Here are a few examples for
the possible alternatives for different numbers of KSKs and ZSKs
for some different key lengths (all RSA keys, with a public
exponent that is < 254). This is all based upon the size of the
response for the particular example of querying for
". KEY IN"
with a response of entire KEY + SIG(KEY) with the authority and
additional sections empty:
ZSK/768 and KSK/1024 (real small)
Max 12 KSK + 3 ZSK at 3975
10 KSK + 8 ZSK at 3934
8 KSK + 13 ZSK at 3893
ZSK/768 + KSK/1280
MAX 10 KSK + 2 ZSK at 3913
8 KSK + 9 ZSK at 3970
6 KSK + 15 ZSK at 3914
ZSK/768 + KSK/1536
MAX 8 KSK + 4 ZSK at 3917
7 KSK + 8 ZSK at 3938
6 KSK + 12 ZSK at 3959
ZSK/768 + KSK/2048
MAX 6 KSK + 5 ZSK at 3936
5 KSK + 10 ZSK at 3942
ZSK/1024 + KSK/1024
MAX 12 KSK + 2 ZSK at 3943
11 KSK + 4 ZSK at 3930
10 KSK + 6 ZSK at 3917
8 KSK + 10 ZSK at 3891
ZSK/1024 + KSK/1536
MAX 8 KSK + 3 ZSK at 3900
7 KSK + 6 ZSK at 3904
6 KSK + 9 ZSK at 3908
ZSK/1024 + KSK/2048
MAX 6 KSK + 4 ZSK at 3951
5 KSK + 8 ZSK at 3972
4 KSK + 12 ZSK at 3993
Note that these are just examples and this document is not making
any recommendations on suitable choices of either key lengths nor
number of different keys employed at a security apex.
This document does however, based upon the above figures, make the
recommendation that at a security apex that expects to distribute
"trusted keys" the KEY RRset should only be signed with the KSKs
and not with the ZSKs to keep the size of the response packets
down.
5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver
In DNSSEC according to RFC2535[RFC2535] validation is the process
of tracing a chain of signatures (and keys) upwards through the DNS
hierarchy until a "trusted key" is reached. If there is a known
trusted key present at a security apex above the starting point
validation becomes an exercise with a binary outcome: either the
validation succeeds or it fails. No intermediate states are
possible.
With multiple "trusted keys" (i.e. the KEY RRset for the security
apex signed by multiple KSKs) this changes into a more complicated
space of alternatives. From the perspective of complexity that may
be regarded as a change for the worse. However, from a perspective
of maximizing available trust the multiple KSKs add value to the
system.
5.1. Possible to do Threshold Validation
With multiple KSKs a new option that opens for the security
concious resolver is to not trust a key individually. Instead the
resolver may decide to require the validated signatures to exceed a
threshold. For instance, given M trusted keys it is possible for
the resolver to require N-of-M signatures to treat the data as
validated.
I.e. with the following pseudo-configuration in a validating
resolver
security-apex "." IN {
keys { ksk-1 .... ;
ksk-2 .... ;
ksk-3 .... ;
ksk-4 .... ;
ksk-5 .... ;
};
validation {
# Note that ksk-4 is not present below
keys { ksk-1; ksk-2; ksk-3; ksk-5; };
# 3 signatures needed with 4 possible keys, aka 75%
needed-signatures 3;
};
};
we configure five trusted keys for the root zone, but require two
valid signatures for the top-most KEY for validation to
succeed. I.e. threshold validation does not force multiple
signatures on the entire signature chain, only on the top-most
signature, closest to the security apex for which the resolver has
trusted keys.
5.2. Not All Trusted Keys Will Be Available
With multiple KSKs held and managed by separate entities the end
resolvers will not always manage to get access to all possible
trusted keys. In the case of just a single KSK this would be fatal
to validation and necessary to avoid at whatever cost. But with
several fully trusted keys available the resolver can decide to
trust several of them individually. An example based upon more
pseudo-configuration:
security-apex "." IN {
keys { ksk-1 .... ;
ksk-2 .... ;
ksk-3 .... ;
ksk-4 .... ;
ksk-5 .... ;
};
validation {
# Only these two keys are trusted independently
keys { ksk-1; ksk-4; };
# With these keys a single signature is sufficient
needed-signatures 1;
};
};
Here we have the same five keys and instruct the validating
resolver to fully trust data that ends up with just one signature
from by a fully trusted key.
The typical case where this will be useful is for the case where
there is a risk of the resolver not catching a rollover event by
one of the KSKs. By doing rollovers of different KSKs with
different schedules it is possible for a resolver to "survive"
missing a rollover without validation breaking. This improves
overall robustness from a management point of view.
5.3. Not All Possible KSKs Need to Be Trusted
With just one key available it simply has to be trusted, since that
is the only option available. With multiple KSKs the validating
resolver immediately get the option of implementing a local policy
of only trusting some of the possible keys.
This local policy can be implemented either by simply not
configuring keys that are not trusted or, possibly, configure them
but specify to the resolver that certain keys are not to be
ultimately trusted alone.
6. Additional Benefits from Having Multiple KSKs
6.1. More Robust Key Rollovers
With only one KSK the rollover operation will be a delicate
operation since the new trusted key needs to reach every validating
resolver before the old key is retired. For this reason it is
expected that long periods of overlap will be needed.
With multiple KSKs this changes into a system where different
"series" of KSKs can have different rollover schedules, thereby
changing from one "big" rollover to several "smaller" rollovers.
If the resolver trusts several of the available keys individually
then even a failure to track a certain rollover operation within
the overlap period will not be fatal to validation since the other
available trusted keys will be sufficient.
6.2. Evaluation of Multiple Key Distribution Mechanisms
Distribution of the trusted keys for the DNS root zone is
recognized to be a difficult problem that ...
With only one trusted key, from one single "source" to distribute
it will be difficult to evaluate what distribution mechanism works
best. With multiple KSKs, held by separate entitites it will be
possible to measure how large fraction of the resolver population
that is trusting what subsets of KSKs.
7. Security Considerations
From a systems perspective the simplest design is arguably the
best, i.e. one single holder of both KSK and ZSKs. However, if that
is not possible in all cases a more complex scheme is needed where
additional trust is injected by using multiple KSK holders, each
contributing trust, then there are only two alternatives
available. The first is so called "split keys", where a single key
is split up among KSK holders, each contributing trust. The second
is the multiple KSK design outlined in this proposal.
Both these alternatives provide for threshold mechanisms. However
split keys makes the threshold integral to the key generating
mechanism (i.e. it will be a property of the keys how many
signatures are needed). In the case of multiple KSKs the threshold
validation is not a property of the keys but rather local policy in
the validating resolver. A benefit from this is that it is possible
for different resolvers to use different trust policies. Some may
configure threshold validation requiring multiple signatures and
specific keys (optimizing for security) while others may choose to
accept a single signature from a larger set of keys (optimizing for
redundancy). Since the security requirements are different it would
seem to be a good idea to make this choice local policy rather than
global policy.
Furthermore, a clear issue for validating resolvers will be how to
ensure that they track all rollover events for keys they
trust. Even with operlap during the rollover (which is clearly
needed) there is still a need to be exceedingly careful not to miss
any rollovers (or fail to acquire a new key) since without this
single key validation will fail. With multiple KSKs this operation
becomes more robust, since different KSKs may roll at different
times according to different rollover schedules and losing one key,
for whatever reason, will not be crucial unless the resolver
intentionally chooses to be completely dependent on that exact key.
8. IANA Considerations.
NONE.
9. References
9.1. Normative.
[RFC2535] Domain Name System Security Extensions. D. Eastlake.
March 1999.
[RFC3090] DNS Security Extension Clarification on Zone Status.
E. Lewis. March 2001.
9.2. Informative.
[RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
(DNS). D. Eastlake 3rd. May 2001.
[RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad.
December 2001.
[DS] Delegation Signer Resource Record.
O. Gudmundsson. October 2002. Work In Progress.
10. Acknowledgments.
Bill Manning came up with the original idea of moving complexity
from the signing side down to the resolver in the form of threshold
validation. I've also had much appreciated help from (in no
particular order) Jakob Schlyter, Paul Vixie, Olafur Gudmundson and
Olaf Kolkman.
11. Authors' Address
Johan Ihren
Autonomica AB
Bellmansgatan 30
SE-118 47 Stockholm, Sweden
johani@autonomica.se

386
doc/draft/draft-jeong-hmipv6-dns-optimization-00.txt Normal file
View file

@ -0,0 +1,386 @@
Individual Submission
Internet Draft
Jae-Hoon Jeong
Jung-Soo Park
Kyeong-Jin Lee
Hyoung-Jun Kim
<draft-jeong-hmipv6-dns-optimization-00.txt> ETRI
Expires: August 2003 February 2003
The Autoconfiguration of Recursive DNS Server and the Optimization of
DNS Name Resolution in Hierarchical Mobile IPv6
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted [1].
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.
Abstract
This document provides the mechanism for the autoconfiguration of
recursive DNS server in mobile node and the optimization of DNS name
resolution in the hierarchical mobile IPv6 networks. Whenever the
mobile node moves into a new MAP domain, the region managed by
another MAP, in the hierarchical mobile IPv6 networks, it detects the
addresses of recursive DNS servers which are placed in the region and
replaces the old ones with the new ones for DNS name resolution. This
allows the time for DNS name resolution much reduced by using the
nearest DNS recursive server which exists in the region. Therefore,
the mechanism of this document can optimize the DNS name resolution.
Jeong, Park, Lee, Kim Expires - August 2003 [Page 1]
DNS Autoconfiguration and Optimization in HMIPv6 February 2003
Conventions used in this document
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].
Table of Contents
1. Terminology....................................................2
2. Introduction...................................................2
3. Overview.......................................................3
4. HMIPv6 extension - Advertisement of Recursive DNS Server.......4
5. Neighbor Discovery extension - RDNSS option message format.....4
6. RDNSS selection by the Mobile Node.............................5
7. Detection of RDNSS failure.....................................6
8. Security Considerations........................................6
9. References.....................................................6
10. Author's Addresses............................................7
1. Terminology
This memo uses the terminology described in [3]. In addition, a new
term is defined below:
Recursive DNS Server (RDNSS) A Recursive DNS Server is a name server
that offers the recursive service of
DNS name resolution.
2. Introduction
RFC 2462 [4] provides a way to autoconfigure either fixed or mobile
nodes with one or more IPv6 addresses and default routes.
For the support of the various services in the Internet, not only the
configuration of IP address in network interface, but also that of
the recursive DNS server for DNS name resolution are necessary.
Up to now, many mechanisms to autoconfigure recursive DNS server in
nodes have been proposed [5][6].
This document suggests not only the autoconfiguration of recursive
DNS server in mobile node that moves within the hierarchical mobile
IPv6 networks [3], but also the optimization of the DNS name
resolution in such networks. Whenever the mobile node moves into a
new MAP (Mobility Anchor Point) domain, the region managed by another
MAP, in the hierarchical mobile IPv6 networks, it detects the
addresses of recursive DNS servers which are placed in the region and
replaces the old ones with the new ones for DNS name resolution. This
allows the time for DNS name resolution much reduced by using the
Jeong, Park, Lee, Kim Expires - August 2003 [Page 2]
DNS Autoconfiguration and Optimization in HMIPv6 February 2003
nearest DNS recursive server which exists in the region. Like this,
because the mobile nodes use the recursive DNS server in the same
domain instead of the fixed recursive DNS server, the DNS name
resolution of the mobile nodes can be optimized.
3. Overview
+-------+ +--------+
| HA |---| RDNSS1 |
+-------+ +--------+
|
| +----+
| | CN |
| +----+
+-----+ |
| |
| +---+
| |
+-------+
| MAP | RCoA
+-------+
| |
| +--------+
| |
| |
+-----+ +-----+ +--------+
| AR1 | | AR2 |---| RDNSS2 |
+-----+ +-----+ +--------+
+----+
| MN |
+----+ ------------>
Movement
Figure 1: Optimization of DNS Name Resolution in HMIPv6 domain
Whenever a mobile node enters into a new MAP domain of the visited
network, it receives the RA message including MAP option from Access
Router (AR) and performs the local binding update with the new MAP.
If the list of the addresses of the recursive DNS server (RDNSS) is
included in the RA message with the MAP option, the mobile node can
detect the new RDNSSs and select one of them for the DNS name
resolution. Like Figure 1, this scheme can reduce considerably the
time of the name resolution between the mobile node and the RDNSS.
Because the mobile node uses the nearest RDNSS in the same MAP domain,
RDNSS2, instead of the RDNSS in its home network, RDNSS1. When the
mobile node moves into another MAP domain, it replaces the old RDNSS
with the new RDNSS for the succeeding name resolutions.
Jeong, Park, Lee, Kim Expires - August 2003 [Page 3]
DNS Autoconfiguration and Optimization in HMIPv6 February 2003
4. HMIPv6 extension - Advertisement of Recursive DNS Server
Because this document considers only router advertisement for MAP
discovery, all ARs belonging to the MAP domain MUST advertise the
MAP's IP address.
The information of the RDNSS in the MAP domain is stored in the MAP
by the network administrator and advertised as a new option through
the RA message with MAP option. There MAY be more than one RDNSS in a
MAP domain. A MAP advertises the RA message including the list of
RDNSSs in the same domain with MAP option. The RA message with MAP
and RDNSS options is propagated from the MAP to the mobile node
through certain (configured) router interfaces within the hierarchy
of routers. This would require manual configuration of the MAP and
RDNSS options in the MAP and also the routers receiving the MAN and
RDNSS options to allow them to propagate the options on certain
interfaces.
Finally, the mobile node listening to RA messages receives the new RA
message and checks if the MAP is new or not. If the MAP is a new one,
the mobile node perceives it has moved into another MAP domain and
performs both the local binding update with the new MAP and the
update of the list of RDNSSs in the configuration of name resolution
with the new ones. From the next name resolution, the mobile node
uses the new RDNSSs.
5. Neighbor Discovery extension - RDNSS option message format
The mechanism of this document needs a new option in Neighbor
Discovery [7].
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length( = 3) | Pref | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address for RDNSS +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jeong, Park, Lee, Kim Expires - August 2003 [Page 4]
DNS Autoconfiguration and Optimization in HMIPv6 February 2003
Fields:
Type Message type. TBA.
Length 8-bit unsigned integer. The length of the
option (including the type and length fields)
in units of 8 octets. The default value is 3.
The value 0 is invalid. Nodes MUST silently
discard an ND packet that contains an option with
length zero.
Pref The preference of an RDNSS. A 4 bit unsigned
integer. A decimal value of 15 indicates the
highest preference. A decimal value of 0
indicates that the RDNSS can not be used.
IPv6 Address for RDNSS
The RDNSS IPv6 address. The scope of the address
can be any scope.
i.e., link-local, site-local and global.
The prefix of the address is be /64.
When advertising more than one RDNSS, as many RDNSS options as the
number of RDNSSs are included in an RA message.
6. RDNSS selection by the Mobile Node
When a mobile node perceives multiple RDNSSs through RA message, it
stores the RDNSSs in order into the configuration the resolver on the
node uses for DNS name resolution on the basis of the value of "Pref"
field and the prefix of "IPv6 Address for RDNSS" field in the RDNSS
option. The following algorithm is simply based on the rule of
selecting the nearest possible RDNSS, providing that its preference
value did not reach the maximum value of 15. When the distances are
the same, this algorithm uses the preference value to order the
RDNSSs. The mobile node operation is shown below:
1) Receive and parse all RDNSS options
2) Arrange RDNSSs in an ascending order, starting with the nearest
RDNSS and store them in the configuration for DNS name resolution
used by resolver. (i.e., the longest prefix matching between the
"IPv6 Address for RDNSS" field and mobile node's On-link CoA
(LCoA) MAY be used to decide the distance between mobile node and
RDNSS, how far away the mobile node is from the RDNSS.)
3) For each RDNSS entry, check the following;
- If the value of "Pref" field is set to zero, exclude the RDNSS
entry from the list of RDNSSs of the configuration for DNS name
Jeong, Park, Lee, Kim Expires - August 2003 [Page 5]
DNS Autoconfiguration and Optimization in HMIPv6 February 2003
resolution.
Whenever the resolver on the mobile node performs the name resolution,
it refers to the address(es) of RDNSS in the configuration for name
resolution according to the current rule of selecting an RDNSS,
namely from the 1st RDNSS.
7. Detection of RDNSS failure
A MAP placed in a MAP domain checks periodically if the RDNSSs
registered in the MAP are alive. Whenever the MAP detects the failure
of any RDNSS, it advertises the failure down to the hierarchy with a
new RA message including an RDNSS option of which "Pref" field has
zero for the RDNSS. When a mobile node receives the RA message, it
perceives that the RDNSS is out of work or the path to the RDNSS is
broken and excludes the RDNSS from the configuration for name
resolution.
The dynamic detection of RDNSS failure in a MAP can be done by simply
pinging the RDNSS periodically (e.g., every ten seconds). If no
response is received, the MAP MAY try to aggressively ping the RDNSS
for a short period of time (e.g., once every 5 seconds for 15
seconds); if no response is received, an RDNSS option MAY be sent
with a preference value of zero.
8. Security Considerations
In order to guarantee the secure communication between routers, the
router advertisements sent between routers SHOULD be authenticated by
AH or ESP [3]. This security is essentially related to Neighbor
Discovery protocol security [7].
9. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[3] H. Soliman, C. Castelluccia, K. El-Malki and L. Bellier,
"Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-
ietf-mobileip-hmipv6-07.txt, October 2002.
[4] S. Thomson and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC2462.
Jeong, Park, Lee, Kim Expires - August 2003 [Page 6]
DNS Autoconfiguration and Optimization in HMIPv6 February 2003
[5] A. Durand, J. itojun and D. Thaler, "Well known site local
unicast addresses to communicate with recursive DNS servers",
draft-ietf-ipv6-dns-discovery-07.txt, October 25 2002.
[6] Luc Beloeil, "IPv6 Router Advertisement DNS resolver Option",
draft-beloeil-ipv6-dns-resolver-option-01.txt, January 2003.
[7] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for
IP version 6", RFC 2461.
10. Author's Addresses
Jae-Hoon Jeong
ETRI / PEC
161 Gajong-Dong, Yusong-Gu
Daejon 305-350
Korea
Phone: +82 42 860 1664
EMail: paul@etri.re.kr
Jung-Soo Park
ETRI / PEC
161 Gajong-Dong, Yusong-Gu
Daejon 305-350
Korea
Phone: +82 42 860 6514
EMail: pjs@etri.re.kr
Kyeong-Jin Lee
ETRI / PEC
161 Gajong-Dong, Yusong-Gu
Daejon 305-350
Korea
Phone: +82 42 860 6484
EMail: leekj@etri.re.kr
Hyoung-Jun Kim
ETRI / PEC
161 Gajong-Dong, Yusong-Gu
Daejon 305-350
Korea
Phone: +82 42 860 6576
EMail: khj@etri.re.kr
Jeong, Park, Lee, Kim Expires - August 2003 [Page 7]

295
doc/draft/draft-kato-dnsop-local-zones-00.txt Normal file
View file

@ -0,0 +1,295 @@
Internet Engineering Task Force Akira Kato, WIDE
INTERNET-DRAFT Paul Vixie, ISC
Expires: August 24, 2003 February 24, 2003
Operational Guidelines for "local" zones in the DNS
draft-kato-dnsop-local-zones-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.''
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 August 24, 2003.
Abstract
A large number of DNS queries regarding to the "local" zones are sent
over the Internet in every second. This memo describes operational
guidelines to reduce the unnecessary DNS traffic as well as the load of
the Root DNS Servers.
1. Introduction
While it has yet been described in a RFC, .local is used to provide a
local subspace of the DNS tree. Formal delegation process has not been
completed for this TLD. In spite of this informal status, .local has
been used in many installations regardless of the awareness of the
users. Usually, the local DNS servers are not authoritative to the
.local domain, they end up to send queries to the Root DNS Servers.
There are several other DNS zones which describe the "local"
information. .localhost has been used to describe the localhost for
more than a couple of decades and virtually all of the DNS servers are
configured authoritative for .localhost and its reverse zone .127.in-
KATO Expires: August 24, 2003 [Page 1]
DRAFT DNS local zones February 2003
addr.arpa. However, there are other "local" zones currently used in the
Internet or Intranets connected to the Internet through NATs or similar
devices.
At a DNS server of an university in Japan, half of the DNS queries sent
to one of the 13 Root DNS Servers were regarding to the .local. At
another DNS Server running in one of the Major ISPs in Japan, the 1/4
were .local. If those "local" queries are able to direct other DNS
servers than Root, or they can be resolved locally, it contributes the
reduction of the Root DNS Servers.
2. Rationale
Any DNS queries regarding to "local" names should not be sent to the DNS
servers on the Internet.
3. Operational Guidelines
Those queries should be processed at the DNS servers internal to each
site so that the severs respond with NXDOMAIN rather than sending
queries to the DNS servers outside.
The "local" names have common DNS suffixes which are listed below:
3.1. Local host related zones:
Following two zones are described in [Barr, 1996] and .localhost is also
defined in [Eastlake, 1999] .
o .localhost
o .127.in-addr.arpa
Following two zones are for the loopback address in IPv6 [Hinden, 1998]
. While the TLD for IPv6 reverse lookup is .arpa as defined in [Bush,
2001] , the old TLD .int has been used for this purpose for years
[Thomson, 1995] and many implementations still use .int. So it is
suggested that both zones should be provided for each IPv6 reverse
lookup zone for a while.
o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int
o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
3.2. Locally created name space
While the use of .local has been proposed in several Internet-Drafts, it
has not been described in any Internet documents with formal status.
However, the amount of the queries for .local is much larger than
others, it is suggested to resolve the following zone locally:
KATO Expires: August 24, 2003 [Page 2]
DRAFT DNS local zones February 2003
o .local
3.3. Private or site-local addresses
The following IPv4 "private" addresses [Rekhter, 1996] and IPv6 site-
local addresses [Hinden, 1998] should be resolved locally:
o 10.in-addr.arpa
o 16.172.in-addr.arpa
o 17.172.in-addr.arpa
o 18.172.in-addr.arpa
o 19.172.in-addr.arpa
o 20.172.in-addr.arpa
o 21.172.in-addr.arpa
o 22.172.in-addr.arpa
o 23.172.in-addr.arpa
o 24.172.in-addr.arpa
o 25.172.in-addr.arpa
o 26.172.in-addr.arpa
o 27.172.in-addr.arpa
o 28.172.in-addr.arpa
o 29.172.in-addr.arpa
o 30.172.in-addr.arpa
o 31.172.in-addr.arpa
o 168.192.in-addr.arpa
o c.e.f.ip6.int
o d.e.f.ip6.int
o e.e.f.ip6.int
o f.e.f.ip6.int
o c.e.f.ip6.arpa
o d.e.f.ip6.arpa
o e.e.f.ip6.arpa
o f.e.f.ip6.arpa
3.4. Link-local addresses
The link-local address blocks for IPv4 [IANA, 2002] and IPv6 [Hinden,
1998] should be resolved locally:
o 254.169.in-addr.arpa
o 8.e.f.ip6.int
o 9.e.f.ip6.int
o a.e.f.ip6.int
o b.e.f.ip6.int
o 8.e.f.ip6.arpa
o 9.e.f.ip6.arpa
o a.e.f.ip6.arpa
o b.e.f.ip6.arpa
KATO Expires: August 24, 2003 [Page 3]
DRAFT DNS local zones February 2003
4. Suggestions to developers
4.1. Suggestions to DNS software implementors
In order to avoid unnecessary traffic, it is suggested that DNS software
implementors provide configuration templates or default configurations
so that the names described in the previous section are resolved locally
rather than sent to other DNS servers in the Internet.
4.2. Suggestions to developers of NATs or similar devices
There are many NAT or similar devices available in the market.
Regardless of the availability of DNS Servers in those devices, it is
suggested that those devices are able to filter the DNS traffic or
respond to the DNS traffic related to "local" zones by configuration
regardless of its ability of DNS service. It is suggested that this
functionality is activated by default.
5. IANA Consideration
While .local TLD has yet defined officially, there are substantial
queries to the Root DNS Servers as of writing. About 1/4 to 1/2% of the
traffic sent to the Root DNS Servers are related to the .local zone.
Therefore, while it is not formally defined, it is suggested that IANA
delegates .local TLD to an organization.
The AS112 Project [Vixie, ] serves authoritative DNS service for RFC1918
address and the link-local address. It has several DNS server instances
around the world by using BGP Anycast [Hardie, 2002] . So the AS112
Project is one of the candidates to host the .local TLD.
Authors' addresses
Akira Kato
The University of Tokyo, Information Technology Center
2-11-16 Yayoi Bunkyo
Tokyo 113-8658, JAPAN
Tel: +81 3-5841-2750
Email: kato@wide.ad.jp
Paul Vixie
Internet Software Consortium
950 Charter Street
Redwood City, CA 94063, USA
Tel: +1 650-779-7001
Email: vixie@isc.org
KATO Expires: August 24, 2003 [Page 4]
DRAFT DNS local zones February 2003
References
To be filled
References
Barr, 1996.
D. Barr, "Common DNS Operational and Configuration Errors" in RFC1912
(February 1996).
Eastlake, 1999.
D. Eastlake, "Reserved Top Level DNS Names" in RFC2606 (June 1999).
Hinden, 1998.
R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in
RFC2373 (July 1998).
Bush, 2001.
R. Bush, "Delegation of IP6.ARPA" in RFC3152 (August 2001).
Thomson, 1995.
S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
RFC1886 (December 1995).
Rekhter, 1996.
Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear,
"Address Allocation for Private Internets" in RFC1918 (February 1996).
IANA, 2002.
IANA, "Special-Use IPv4 Addresses" in RFC3330 (September 2002).
Vixie, .
P. Vixie, "AS112 Project" in AS112. http://www.as112.net/.
Hardie, 2002.
T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast
Addresses" in RFC3258 (April 2002).
KATO Expires: August 24, 2003 [Page 5]

437
doc/draft/draft-klensin-idn-tld-00.txt Normal file
View file

@ -0,0 +1,437 @@
INTERNET-DRAFT John C Klensin
21 October 2002
Expires April 2003
National and Local Characters in DNS TLD Names
draft-klensin-idn-tld-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 except that the
right to produce derivative works is not granted.
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.
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.
Abstract
In the context of work on internationalizing the Domain Name System
(DNS), there have been extensive discussions about "multilingual" or
"internationalized" top level domain names (TLDs), especially for
countries whose predominant language is not written in a Roman-based
script. This document reviews some of the motivations for such
domains and the constraints that the DNS imposes. It then suggests
an alternative, local translation, that may solve a superset of the
problem while avoiding protocol changes, serious deployment delays,
and other difficulties.
Table of Contents
1 Introduction
1.1 Background on the "Multilingual Name" Problem
1.2 Domain Name System Constraints
1.3 Internationalization and Localization
2. Client-side solutions
2.1 IDNA and the client
2.2 Local translation tables for TLD names
3. Advantages and disadvantages of local translation
3.1 Every TLD in the local language and character set
3.2 Unification of country code domains
3.3 User understanding of local and global reference
3.4 Limits on TLD propagation
4. Security Considerations
5. References
6. Acknowledgements
7. Author's Address
1. Introduction
1.1 Background on the "Multilingual Name" Problem
People who share a language prefer to communicate in it, using whatever
characters are normally used to write that language, rather than in some
"foreign" one. There have been standards for using mutually-agreed
characters and languages in electronic mail message bodies and selected
headers since the introduction of MIME in 1992 [MIME] and the Web has
permitted multilingual text since its inception. However, since domain
names are exposed to users in email addresses and URLs, and
corresponding arrangements in other protocols, demand rapidly arose to
permit domain names in applications that used characters other than
those of the very restrictive, ASCII-subset, "LDH" conventions [LDH].
The effort to do this rapidly became known as "multilingual domain
names", although that is a misnomer, since the DNS deals only with
characters and identifier strings, and not, except by accident, what
people usually think of as "names". And there has been little actual
interest in what would actually be a "multilingual name" -- i.e., a name
that contains components from more than one language -- but only the use
of strings conforming to different languages in the context of the DNS.
1.1.1 Approaches to the requirement
If the requirement is seen, not as "modifying the DNS", but as
"providing users with access to the DNS from a variety of languages and
character sets", three sets of proposals have emerged in the IETF and
elsewhere. They are:
(1) Perform processing in client software that recodes a user-visible
string into an ASCII-compatible form that can safely be passed
through the DNS protocols and stored in the DNS. This is the
approach used, for example, in the IETF's "IDNA" protocol [IDNA].
(2) Modify the DNS to be more hospitable to non-ASCII names and
strings. There have been a variety of proposals to do this in almost
as many ways, some of which have been implemented on a proprietary
basis by various vendors. None of them have gained acceptance in the
IETF community, primarily because they would take a long time to
deploy and would leave many problems unsolved.
(3) Move the problem out of the DNS entirely, relying instead on a
"directory" or "presentation" layer to handle internationalization.
The rationale for this approach is discussed in [DNSROLE].
This document proposes a fourth approach, applicable to the top level
domains (TLDs) only (see section 1.2.1 for a discussion of the special
issues that make TLDs problematic). That approach could be used as an
alternate or supplement to the strategies summarized above.
1.1.2 Writing the name of one's country in its own characters
An early focus of the "multilingual domain name" efforts was expressed
in statements such as "users in my country, in which ASCII is rarely
used, should be able to write an entire domain name in their own
character set. In particular, since all top-level domain names, at
present, follow the LDH rules, the somewhat more restrictive naming
rules discussed in [STD3], and the coding conventions specified in
[RFC1591], all fully-qualified DNS names were effectively required to
contain at least one ASCII label (the TLD name), and that was considered
inappropriate. One should, instead, be able to write the name of the
ccTLD for China in Chinese, the name of the ccTLD for Saudi Arabia in
Arabic, and so on.
1.1.3 Countries with multiple languages and countries with multiple
names
>From a user interface standpoint, writing ccTLD names in local
characters is a problem. As discussed in section 1.2.2, the DNS itself
does not easily permit a domain to be referred to by more than one name
(or spelling or translation of a name). Countries with more than one
official language would require that the country name be represented in
each of those languages. And, just as it is important that a user in
China be able to represent the name of the Chinese ccTLD in Chinese
characters, she should be able to access a Chinese-language site in
France using Chinese characters, requiring that she be able to write the
name of the French ccTLD in those characters rather than in a form based
on a Roman character set.
1.2 Domain Name System Constraints
1.2.1 Administrative hierarchy
The domain name system is designed around the idea of an "administrative
hierarchy", with the entity responsible for a given node of the
hierarchy responsible for policies applicable to its subhierarchies (Cf.
[STD13]). The model works quite well for the domain and subdomains of a
particular enterprise, where the hierarchy can be organized to match the
organizational structure, there are established ways to set policies and
there is, at least presumably, shared assumptions about overall goals
and objectives among all registrants in the domain. It is more
problematic when a domain is shared by unrelated entities which lack
common policy assumptions. It is difficult to reach agreement on rules
that should apply to all of them. That situation always prevails for
the labels registered in a TLD (second-level names) except in those TLDs
for which the second level is structural (e.g., the .CO, .AC, .GOV
conventions in many ccTLD) in which case, it exists for the labels
within that structural level.
TLDs may, but need not, have consistent registration policies for those
second (or third) level names. Countries (or ccTLD administrators) have
often adopted rules about what entities may register in those ccTLDs,
and the forms the names may take. RFC 1591 outlined registration norms
for most of the gTLDs, even though those norms have been largely ignored
in recent years. And some recent "sponsored" domains are based on quite
specific rules about appropriate registrations. Homogeneous
registration rules for the root are, by contrast, impossible: almost by
definition, the subdomains registered in it are diverse and no single
policy applying to all root subdomains (TLDs) is feasible.
1.2.2 Aliases
In an environment different from the DNS, a rational way to permit
assigning local-language names to a country code (or other) domain would
be to set up an alias for the name, or to use some sort of "see instead"
reference. But the DNS does not have quite the right facilities for
either. Instead, it supports a "CNAME" record, whose label can refer
onto to a particular label and not to a subtree. For example, if A.B.C
is a fully-qualified name, then a CNAME reference from X to A would make
X.B.C appear to have the same values as A.B.C. However, a CNAME
reference from Y to C would not make A.B.Y referenceable (or even
defined) at all. A second record type, DNAME [RFC2672], can provide an
alias for a portion of the tree. But it is problematic technically, and
its use is strongly discouraged except for transition uses from one
domain to another.
1.3 Internationalization and Localization
It has often been observed that while many people talk about
"internationalization" (a term we typically use for making something
globally accessible while incorporating a broad-range "universal"
character set and conventions appropriate to all languages), they often really
mean, and want, "localization" (making things work well in a particular
locality, or well, but potentially differently, for a broad range of
localities). Anything that actually involves the DNS must be global and
hence internationalized since the DNS cannot meaningfully support
different responses based, e.g., on the location of the user making a
query. While the DNS cannot support localization internally, many of
the features discussed earlier in this section are much more easily
thought about in local terms --whether localized to a geographical area,
users of a language, or using some other criteria -- than in global ones.
2. Client-side solutions
Traditionally, the IETF has avoided becoming involved in standardization
for actions that take place strictly on individual hosts on the network,
assuming that it should confine itself to behavior that is observable
"on the wire", i.e., in protocols between network hosts. Exceptions to
this general principle have been made when different clients were
required to utilize data or interpret values in compatible ways to
preserve interoperability: the standards for email and web body formats,
and IDNA itself, are examples of these exceptions. Regardless of what
is required to be standardized, it is almost never required, and often
unwise, that a user interface, by default, present on-the-wire formats
to the user. However, in most cases when the presentation format and
the wire format differ, the client program must take precautions that
the wire format can be reconstructed from user input, or to keep the
wire format, while hidden, bound to the presentation mechanism so that
it can be reconstructed. And, while it is rarely a goal in itself, it
is often necessary that the user be at least vaguely aware that the wire
("real") format is different from the presentation one and that the wire
format be available for debugging.
2.1 IDNA and the client
As mentioned above, IDNA itself is entirely a client-side protocol. It
works by providing labels to the DNS in a special format (so-called
"ACE"). When labels in that format are encountered, they are
transformed, by the client, back into internationalized (normally
Unicode) characters. In the context of this document, the important
obvservation about IDNA is that any application program that supports it
is already doing considerable transformation work on the client; it is
not simply presenting the on-the-wire formats to the user.
2.2 Local translation tables for TLD names
We suggest that, in addition to maintaining the code and tables required
to support IDNA, clients may want to maintain a table that contains a
list of TLDs and that maps between them and locally-desirable names.
For ccTLDs, these might be the names (or locally-standard abbreviations)
by which the relevant countries are known locally (whether in ASCII
characters or others). With some care on the part of the application
designer (e.g., to ensure that local forms do not conflict with the
actual TLD names), a particular TLD name input from the user could be
either in local or standard form without special tagging or problems.
When DNS names are received by these client programs, the TLD labels
would be mapped to local form before IDNA is applied to the rest of the
name; when names are received from users, local TLD names would be
mapped to the global ones before being passed into IDNA or for other DNS
processing.
3. Advantages and disadvantages of local translation
3.1 Every TLD in the local language and character set
The notion of a top-level domain whose name matches, e.g., the name that
is used for a country in that country or the name of a language in that
language as, as mentioned above, immediately appealing. But most of the
reasons for it argue equally strongly for other TLDs being accessible
from that language. A user in Korea who can access the national ccTLD
in the Korean language and character set has every reason to expect that
both generic top level domains and and domains associated with other
countries would be similarly accessible, especially if the second-level
domains bear Korean names. A user in Spain or Portugal, or in Latin
America, would presumably have similar expectations, but would expect to
use Spanish names, not Korean ones.
That level of local optimization is not realistic --some would argue not
possible-- with the DNS since it would ultimately require that every top
level domain be replicated for each of the world's languages. That
replication process would involve not just the top level domain itself:
in principle, all of its subtrees would need to be completely replicated
as well (or at least all of the subtrees for which a the language
associated with the a given replicant was relevant). The administrative
hierarchy characteristics of the DNS (see section 1.2.1) turn the
replication process into an administrative nightmare: every
administrator of a second-level domain in the world would be forced to
maintain dozens, probably hundreds, of similar zone files for the the
replicates of the domain. Even if only the zones relevant to a
particular country or language were replicated, the administrative and
tracking problems to bind these to the appropriate top-level domain and
keep all of the replicas synchronized would be extremely difficulty at
best. And many administrators of third- and fourth-level domains, and
beyond, would be faced with similar problems.
By contrast, dealing with the names of TLDs as a localization problem,
using local translation, is fairly simple. Each function represented by
a TLD -- a country, generic registrations, or purpose-specific
registrations -- could be represented in the local language and
character set as needed. And, for countries with many languages, or
users living, working, or visiting countries where their language was
not dominant, "local" could be defined in terms of the needs or wishes
of each particular user.
3.2 Unification of country code domains
It follows from some of the comments above that, while there appears to
be some immediate appeal from having (at least) two domains for each
country, one using the ISO 3166-1 code and another one using a name
based on the national name in the national language, such a situation
would create considerable problems for registrants in the multiple
domains. For registrants maintaining enterprise or organizational
subdomains, ease of administration in a single family of zone files will
usually make a registration in a single top-level domain preferable to
replicated sets of them, at least as long as their functional
requirements (such a local-language access) are met by the unified
structure.
Of course, having replicated domains might be popular with registries
and registrars, since replication would almost inevitably increase the
total number of domains to be registered.
3.3 User understanding of local and global references
While the IDNA tables (actually Nameprep and Stringprep -- see the IDNA
specification) must be identical globally for IDNA to work reliably, the
tables for mapping between local names and TLD names could be locally
determined, and differ from one locale to another, as long as users
understood that international interchange of names required using the
standard forms. That understanding could be assisted by software. It
is likely that, at least for the foreseeable future, DNS names being
passed among users in different countries, or using different languages,
will be forced to be in ACE form to guarantee compatibility in any
event, so the marginal knowledge or effort needed to put TLD names into
standard form and transmit them that way would be very small.
3.4 Limits on TLD propagation
The concept of using local translation does have one side-effect, which
some portions of the Internet community might consider undesirable.
The size and complexity of translation tables, and maintaining those
tables, will be, to a considerable extent, a function of the number of
top-level domains, the frequency with which new domains are added, and
the number of domains that are added at a time. A country or other
locale that wished to maintain a few set of translations (i.e., so that
every TLD had a representation in the local language) would presumably
find setting up a table for the current collection of a few hundred
domains to be a task that would take some days. If the number of TLDs
was relatively stable, with a relatively small number being added at
infrequent intervals, the updates could probably be dealt with on an ad
hoc basis. But, if large numbers of domains were added frequently, or
if the total number of TLDs became very large, maintaining the table
might require dedicated staff. Worse, updating the tables stored on
client machines might require update and synchronization protocols and
all of the related complexities.
4. Security Considerations
IDNA provides a client-based mechanism for presenting Unicode names in
applications while passing only ASCII-based names on the wire. As such,
it constitutes a major step along the path of introducing a client-based
presentation layer into the Internet. Client-based presentation layer
transformations introduce risks from variant tables that can change
meaning without external protection. For example, if a mapping table
normally maps A onto C and that table is altered by an attacker so that
A maps onto D instead, much mischief can be committed. On the other
hand, these are not the usual sort of network attacks: they may be
thought of as falling into the "users can always cause harm to
themselves" category. The local translation model outlined here does
not significantly increase the risks over those associated with IDNA,
but may provide some new avenues for exploiting them.
Both this approach and IDNA rely on having updated programs present
information to the user in a very different form than the one in which
it is transmitted on the wire. Unless the internal (wire) form is
always used in interchange, there are possibilities for ambiguity and
confusion about references.
5. References
[DNSROLE] Klensin, J.C., "Role of the Domain Name System", work in
progress (draft-klensin-dns-role-04.txt).
[IDNA] Faltstorm, F., P. Hoffman, A. M. Costello, "Internationalizing
Domain Names in Applications (IDNA)", work in progress
(draft-ietf-idn-idna-13.txt)
[LDH] STD13 and comments
[MIME] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
Extensions): Mechanisms for Specifying and Describing the Format of
Internet Message Bodies", RFC 1341, June 1992. Updated and replaced
by Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC2045, November 1996. Also, Moore, K., "Representation of
Non-ASCII Text in Internet Message Headers", RFC 1342, June 1992.
Updated and replaced by Moore, K., "MIME (Multipurpose Internet
Mail Extensions) Part Three: Message Header Extensions for
Non-ASCII Text", RFC 2047, November 1996.
[RFC1591] Postel, J., "Domain Name System Structure and Delegation",
RFC1591, March 1994.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672,
August 1999.
[STD3] Braden, R., Ed., "Requirements for Internet Hosts - Application and
Support", RFC1123, October 1989.
[STD13] Mockapetris, P.V., 1034 "Domain names - concepts and
facilities", RFC 1034, and "Domain names - implementation and
specification", RFC 1035, November 1987.
6. Acknowledgements
This document was inspired by a number of conversations in ICANN, IETF,
MINC, and private contexts about the future evolution and
internationalization of top level domains. Discussions within, and
about, the ICANN IDN Committee have been particularly helpful, although
several of the members of that committee may be surprised about where
those discussions led.
7. Author's Address
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140 USA
email: john+ietf@jck.com

599
doc/draft/draft-lewis-dns-wildcard-clarify-00.txt Normal file
View file

@ -0,0 +1,599 @@
Internet Engineering Task Force E. Lewis
Internet-Draft ARIN
February 4, 2003 Expires: August 4, 2003
Clarifying the Role of Wild Card Domains
in the Domain Name System
<draft-lewis-dns-wildcard-clarify-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The definition of wild cards is recast from the original in RFC 1034,
in words that are more specific and in line with RFC 2119. This document
is meant to supplement the definition in RFC 1034 and to alter neither
the spirit nor intent of that definition.
1 Introduction
The first section of this document will give a crisp overview of what
is begin defined, as well as the motivation for what amounts to a
simple rewording of an original document. An example is included to
help orient the reader.
Wild card domain names are defined in Section 4.3.3. of RFC 1034 as
"instructions for synthesizing RRs." [RFC1034] The meaning of this is
that a specific, special domain name is used to construct responses in
instances in which the query name is not otherwise represented in a zone.
A wild card domain name has a specific range of influence on query names
(QNAMEs) within a given class, which is rooted at the domain name
containing the wild card label, and is limited by explicit entries, zone
cuts and empty non-terminal domains (see section 1.3 of this document).
Note that a wild card domain name has no special impact on the search
for a query type (QTYPE). If a domain name is found that matches the
QNAME (exact or a wild card) but the QTYPE is not found at that point,
the proper response is that there is no data available. The search
does not continue on to seek other wild cards that might match the QTYPE.
To illustrate, a wild card owning an MX RR does not 'cover' other names
in the zone that own an A RR.
Why is this document needed? Empirical evidence suggests that the
words in RFC 1034 are not clear enough. There exist a number of
implementations that have strayed from the definition. There also
exists a misconception of operators that the wild card can be used to
add a specific RR type to all names, such as the MX RR example listed
above. This document is also needed as input to efforts to extend
DNS, such as the DNS Security Extensions [RFC 2535]. Lack of a clear
base specification has proven to result in extension documents that
have unpredictable consequences. (This is true in general, not just
for DNS.)
1.1 Existence
The notion that a domain name 'exists' will arise numerous times in this
discussion. RFC 1034 raises the issue of existence in a number of places,
usually in reference to non-existence and often in reference to processing
involving wild card domain names. RFC 1034 does contain algorithms that
describe how domain names impact the preparation of an answer and does
define wild cards as a means of synthesizing answers.
To help clarify the topic of wild cards, a positive definition of existence
is needed. To complicate matters, though, there needs to be a recognition
that existence is relative. To an authoritative server, a domain name
exists if the domain name plays a role following the algorithms of
preparing a response. To a resolver, a domain name exists if there is
any data available corresponding to the name. The difference between the
two is the synthesis of records according to a wild card.
For the purposes of this document, the point of view of an authoritative
server is adopted. A domain name is said to exist if it plays a role in
the execution of the algorithms in RFC 1034.
1.2 An Example
For example, consider this wild card domain name: *.example. Any query
name under example. is a candidate to be matched (answered) by this wild
card. Although any name is a candidate, not all queries will match.
To further illustrate this, consider this example:
$ORIGIN example.
@ IN SOA
NS
NS
* TXT "this is a wild card"
MX 10 mailhost.example.
host1 A 10.0.0.1
_ssh._tcp.host1 SRV
_ssh._tcp.host2 SRV
subdel NS
The following queries would be synthesized from the wild card:
QNAME=host3.example. QTYPE=MX, QCLASS=IN
the answer will be a "host.example. IN MX ..."
QNAME=host3.example. QTYPE=A, QCLASS=IN
the answer will be a "host.example. IN NXT ..."
because there is no A RR set at '*'
The following queries would not be synthesized from the wild card:
QNAME=host1.example., QTYPE=MX, QCLASS=IN
because host1.example. exists
QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
because _tcp.host1.example. exists (without data)
QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN
because host2.example. exists (without data)
QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
because subdel.example. exists and is a zone cut
To the server, the following domains are considered to exist in the zone:
*, host1, _tcp.host1, _ssh._tcp.host1, host2, _tcp.host2, _ssh._tcp.host2,
and subdel. To a resolver, many more domains appear to exist via the
synthesis of the wild card.
1.3 Empty Non-terminals
Empty non-terminals are domain names that have no data but have
subdomains. This is defined in section 3.1 of RFC 1034:
# The domain name space is a tree structure. Each node and leaf on the
# tree corresponds to a resource set (which may be empty). The domain
# system makes no distinctions between the uses of the interior nodes and
# leaves, and this memo uses the term "node" to refer to both.
The parenthesized "which may be empty" specifies that empty non-terminals
are explicitly recognized. According to the definition of existence in
this document, empty non-terminals do exist at the server.
Carefully reading the above paragraph can lead to an interpretation that
all possible domains exist - up to the suggested limit of 255 octets for
a domain name [RFC 1035]. For example, www.example. may have an A RR, and
as far as is practically concerned, is a leaf of the domain tree. But the
definition can be taken to mean that sub.www.example. also exists, albeit
with no data. By extension, all possible domains exist, from the root
down. As RFC 1034 also defines "an authoritative name error indicating
that the name does not exist" in section 4.3.1, this is not the intent
of the original document.
RFC1034's wording is to be clarified by adding the following paragraph:
A node is considered to have an impact on the algorithms of 4.3.2
if it is a leaf node with any resource sets or an interior node,
with or without a resource set, that has a subdomain that is a leaf
node with a resource set. A QNAME and QCLASS matching an existing
node never results in a response return code of authoritative name
error.
As an aside, an "authoritative name error" has been called NXDOMAIN in
some RFCs, such as RFC 2136 [RFC 2136]. NXDOMAIN is the mnemonic assigned
to such an error by at least one implementation of DNS.
1.3 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 the document entitled
"Key words for use in RFCs to Indicate Requirement Levels." [RFC2119]
Requirements are denoted by paragraphs that begin with with the following
convention: 'R'<sect>.<count>.
2 Defining the Wild Card Domain Name
A wild card domain name is defined by having the initial label be:
0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
This defines domain names that may play a role in being a wild card, that
is, being a source for synthesized answers. Domain names conforming to
this definition that appear in queries and RDATA sections do not have
any special role. These cases will be described in more detail in
following sections.
R2.1 A domain name that is to be interpreted as a wild card MUST begin
with a label of '0000 0001 0010 1010' in binary.
The first octet is the normal label type and length for a 1 octet long
label, the second octet is the ASCII representation [RFC 20] for the
'*' character. In RFC 1034, ASCII encoding is assumed to be the character
encoding.
In the master file formats used in RFCs, a "*" is a legal representation
for the wild card label. Even if the "*" is escaped, it is still
interpreted as the wild card when it is the only character in the label.
R2.2. A server MUST treat a wild card domain name as the basis of
synthesized answers regardless of any "escape" sequences in
the input format.
RFC 1034 and RFC 1035 ignore the case in which a domain name might be
"the*.example.com." The interpretation is that this domain name in a
zone would only match queries for "the*.example.com" and not have any
other role.
Note: By virtue of this definition, a wild card domain name may have a
subdomain. The subdomain (or sub-subdomain) itself may also be a wild
card. E.g., *.*.example. is a wild card, so is *.sub.*.example.
More discussion on this is given in Appendix A.
3 Defining Existence
As described in the Introduction, a precise definition of existence is
needed.
R3.1 An authoritative server MUST treat a domain name as existing during
the execution of the algorithms in RFC 1034 when the domain name
conforms to the following definition. A domain name is defined
to exist if the domain name owns data and/or has a subdomain that
exists.
Note that at a zone boundary, the domain name owns data, including the
NS RR set. At the delegating server, the NS RR set is not authoritative,
but that is of no consequence here. The domain name owns data, therefore,
it exists.
R3.2 An authoritative server MUST treat a domain name that has neither
a resource record set nor a subdomain as nonexistent when executing
the algorithm in section 4.3.2. of RFC 1034.
4 Impact of a Wild Card Domain In a Query Message
When a wild card domain name appears in a question, e.g., the query name
is "*.example.", the response in no way differs from any other query.
In other words, the wild card label in a QNAME has no special meaning,
and query processing will proceed using '*' as a literal query name.
R4.1 A wild card domain name acting as a QNAME MUST be treated as any
other QNAME, there MUST be no special processing accorded it.
If a wild card domain name appears in the RDATA of a CNAME RR or any
other RR that has a domain name in it, the same rule applies. In the
instance of a CNAME RR, the wild card domain name is used in the same
manner of as being the original QNAME. For other RR's, rules vary
regarding what is done with the domain name(s) appearing in them,
in no case does the wild card hold special meaning.
R4.2 A wild card domain name appearing in any RR's RDATA MUST be treated
as any other domain name in that situation, there MUST be no special
processing accorded it.
5 Impact of a Wild Card Domain On a Response
The description of how wild cards impact response generation is in RFC
1034, section 4.3.2. That passage contains the algorithm followed by a
server in constructing a response. Within that algorithm step 3, part
'c' defines the behavior of the wild card. The algorithm is directly
quoted in lines that begin with a '#' sign. Commentary is interleaved.
[Note that are no requirements specifically listed in this section. The
text here is explanatory and interpretative. There is no change to
the algorithm specified in RFC 1034.]
The context of part 'c' is that the search is progressing label by label
through the QNAME. (Note that the data being searched is the authoritative
data in the server, the cache is searched in step 4.) Step 3's part 'a'
covers the case that the QNAME has been matched in full, regardless of the
presence of a CNAME RR. Step 'b' covers crossing a cut point, resulting
in a referral. All that is left is to look for the wild card.
Step 3 of the algorithm also assumes that the search is looking in the
zone closest to the answer, i.e., in the same class as QCLASS and as
close to the authority as possible on this server. If the zone is not
the authority, then a referral is given, possibly one indicating lameness.
# c. If at some label, a match is impossible (i.e., the
# corresponding label does not exist), look to see if a
# the "*" label exists.
The above paragraph refers to finding the domain name that exists in the
zone and that most encloses the QNAME. Such a domain name will mark the
boundary of candidate wild card domain names that might be used to
synthesize an answer. (Remember that at this point, if the most enclosing
name is the same as the QNAME, part 'a' would have recorded an exact
match.) The existence of the enclosing name means that no wild card name
higher in the tree is a candidate to answer the query.
Once the closest enclosing node is identified, there's the matter of what
exists below it. It may have subdomains, but none will be closer to the
QNAME. One of the subdomains just might be a wild card. If it exists,
this is the only wild card eligible to be used to synthesize an answer
for the query. Even if the closest enclosing node conforms to the syntax
rule in section 2 for being a wild card domain name, the closest enclosing
node is not eligible to be a source of a synthesized answer.
The only wild card domain name that is a candidate to synthesize an answer
will be the "*" subdomain of the closest enclosing domain name. Three
possibilities can happen. The "*" subdomain does not exist, the "*"
subdomain does but does not have an RR set of the same type as the QTYPE,
or it exists and has the desired RR set.
For the sake of brevity, the closest enclosing node can be referred to as
the "closest encloser."
To illustrate, using the example in section 1.2 of this document, the
following chart shows QNAMEs and the closest enclosers. In Appendix A
there is another chart showing unusual cases.
QNAME Closest Encloser Wild Card Source
host3.example. example. *.example.
_telnet._tcp.host1.example. _tcp.host1.example. no wild card
_telnet._tcp.host2.example. host2.example. no wild card
_telnet._tcp.host3.example. example. *.example.
_chat._udp.host3.example. example. *.example.
Note that host1.subdel.example. is in a subzone, so the search for it ends
in a referral in part 'b', thus does not enter into finding a closest
encloser.
The fact that a closest encloser will be the only superdomain that
can have a candidate wild card will have an impact when it comes to
designing authenticated denial of existence proofs. (This concept
is not introduced until DNS Security Extensions are considered in
upcoming sections.)
# If the "*" label does not exist, check whether the name
# we are looking for is the original QNAME in the query
# or a name we have followed due to a CNAME. If the name
# is original, set an authoritative name error in the
# response and exit. Otherwise just exit.
The above passage says that if there is not even a wild card domain name
to match at this point (failing to find an explicit answer elsewhere),
we are to return an authoritative name error at this point. If we were
following a CNAME, the specification is unclear, but seems to imply that
a no error return code is appropriate, with just the CNAME RR (or sequence
of CNAME RRs) in the answer section.
# If the "*" label does exist, match RRs at that node
# against QTYPE. If any match, copy them into the answer
# section, but set the owner of the RR to be QNAME, and
# not the node with the "*" label. Go to step 6.
This final paragraph covers the role of the QTYPE in the process. Note
that if no resource record set matches the QTYPE the result is that no data
is copied, but the search still ceases ("Go to step 6.").
6 Authenticated Denial and Wild Cards
In unsecured DNS, the only concern when there is no data to return to
a query is whether the domain name from which the answer comes exists or
not, whether or not a name error is indicated in the return code. In
either case the answer section is empty or contained just a sequence of
CNAME RR sets.
In securing DNS, authenticated denial of existence is a service that is
provided. The chosen solution to provide this service is to generate
resource records indicating what is protected in a zone and to digitally
sign these.
The resource records that do this, as defined in RFC 2535, are NXT RRs.
There are three points to consider when clarifying the topic of wild card
domain names. One is the construction of the records. The second is
the inclusion of records in responses. The third is the interpretation
of the records in a response by the resolver.
6.1 Preparing Wild Card Domain Name Owned Non-existence Proofs
During the creation of the authenticated denial records, the wild card
domain name plays no special role, in the same manner as the wild card
domain name playing no special role in a query.
There is one consideration with regards to preparing non-existence
proofs.
R6.1 Any mechanism used to provide authenticated denial MUST reveal the
closest enclosing existing domain for the query. If this is not
provided, the resolver will not be able to ascertain the identity
of an appropriate wild card domain name.
6.2 Role of Wild Cards in Answers
There are three cases to address. The first is synthesizing from wild card
domain name with data, the second is negatively synthesizing from an
existing wild card, and the third is denying that neither an exact match,
referral, nor wild card exist to answer the query.
6.2.1 Synthesizing From a Wild Card
When preparing an answer from a wild card domain name, the answer needs
to include proof that the exact match of the QNAME and QCLASS does not
exist. This is needed because synthesis of the answer replaces the "*"
label with the QNAME without securing the result. The resolver will
realize that the answer was derived from a wild card, but cannot
detect whether an exact match was maliciously omitted.
R6.2 When synthesizing a positive answer from a wild card domain name, the
answer MUST include proof that the exact match for the QNAME and
QCLASS does not exist.
6.2.2. Synthesizing Negatively From a Wild Card
When synthesizing a negative answer that is derived from a wild card,
meaning that a wild card matched the QNAME (no exact match happened for
QNAME) but that there is no match for QTYPE there, two negative answers
are needed, possibly one. As in 6.2.1, a proof that the exact match
failed is needed. A second proof is needed to show that the wild card
domain name does not have the QTYPE. Depending on the method of
authenticated denial, these this could be possible with one statement.
R6.3 When synthesizing a negative answer from a wild card domain name,
the answer MUST include proof that the exact match of the QNAME
and QCLASS does not exist and that the QTYPE matches no RR set at
the wild card. If this answer can be optimized, an implementation
SHOULD reduce the number of records included in the response.
6.2.3. Answering With an Authoritative Name Error
When answering with a result code of a name error, the answer needs to
provide proof that neither the exact match for QNAME and QCLASS exists
nor that a wild card domain name exists as a subdomain of the closest
enclosing domain name.
R6.4 When preparing a reply with an authoritative name error, the answer
MUST include proof that the exact match for the QNAME and QCLASS
does not exist and that no wild card is available to provide a match.
6.2.4. The Remaining Case
When answering negatively because there is a match for QNAME and QCLASS
but no match for the QTYPE, only a proof for that is needed. Just as
the search does not proceed onto a search for the wild card in this
case, neither does the construction of the negative answer proof.
R6.5 When preparing a reply in which there is an exact match of the
QNAME and QCLASS, but there is no RR set matching the QTYPE,
the reply SHOULD NOT contain any proof regarding the wild card
domain name.
6.3 Interpreting Negative Answers Involving Wild Cards
There are two requirements for resolvers when it comes to handling
negative answers generated as described in section 6.2.
R6.6 A resolver MUST be able to identify negative answer data that
indicate when a match for QNAME and QCLASS does not exist.
R6.7 From a negative answer, a resolver MUST be able to determine
the closest enclosing domain name in a negative answer and
MUST be able to process a negative answer involving the one
wild card domain name that is a candidate to provide a
synthesized answer.
6.4 Authenticated Denial, Wild Card Domain Names, and Opt-In
When considering the Opt-In proposal [WIP], it is wise to not combine
a zone that adheres to both opt-in and that has a wild card domain
name. The reason is rooted in that the synthesis of an answer is done
by substituting the QNAME for the wild card domain name in the answer.
Because this is unsecured, and the is ambiguity regarding whether a
negative proof can be provided for the exact match (when it is outside
the opt-in secured area), a definitive proof of authenticated denial
is not possible.
7 Security Considerations
This document is refining the specifications to make it more likely that
security can be added to DNS. No functional additions are being made,
just refining what is considered proper to allow the system, security
of the system, and extending the system more predictable.
8 References
Normative References
[RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969
[RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris,
Nov-01-1987
[RFC 1035] Domain Names - Implementation and Specification, P.V
Mockapetris, Nov-01-1987
[RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S
Bradner, March 1997
Non-normative References
[RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie,
Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997
[RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999
[WIP] DNSSEC Opt-In, Internet Draft, R. Arends, M. Kosters, D. Blacka, 2002
9 Other Contributing to This Document
Others who have directly caused text to appear in the document: Paul Vixie
and Olaf Kolkman. Many others have indirect influences on the content.
10 Editor
Name: Edward Lewis
Title: Research Engineer
Affiliation: ARIN
Email: edlewis@arin.net
Phone: +1-703-227-9854
Appendix A: Subdomains of Wild Card Domain Names
In reading the definition of section 2 carefully, it is possible to
rationalize unusual names as legal. In the example given, *.example.
could have subdomains of *.sub.*.example. and even the more direct
*.*.example. (The implication here is that these domain names own
explicit resource records sets.) Although defining these names is not
easy to justify, it is important that implementations account for the
possibility. This section will give some further guidance on handling
these names.
The first thing to realize is that by all definitions, subdomains of
wild card domain names are legal. In analyzing them, one realizes
that they cause no harm by their existence. Because of this, they are
allowed to exist, i.e., there are no special case rules made to disallow
them. The reason for not preventing these names is that the prevention
would just introduce more code paths to put into implementations.
The concept of "closest enclosing" existing names is important to keep in
mind. It is also important to realize that a wild card domain name can
be a closest encloser of a query name. For example, if *.*.example. is
defined in a zone, and the query name is a.*.example., then the closest
enclosing domain name is *.example. Keep in mind that the closest
encloser is not eligible to be a source of synthesized answers, just the
subdomain of it that has the first label "*".
To illustrate this, the following chart shows some matches. Assume that
the names *.example., *.*.example., and *.sub.*.example. are defined
in the zone.
QNAME Closest Encloser Wild Card Source
a.example. example. *.example.
b.a.example. example. *.example.
a.*.example. *.example. *.*.example.
b.a.*.example. *.example. *.*.example.
b.a.*.*.example. *.*.example. no wild card
a.sub.*.example. sub.*.example. *.sub.*.example.
b.a.sub.*.example. sub.*.example. *.sub.*.example.
a.*.sub.*.example. *.sub.*.example. no wild card
*.a.example. example. *.example.
a.sub.b.example. example. *.example.
Recall that the closest encloser itself cannot be the wild card. Therefore
the match for b.a.*.*.example. has no applicable wild card.
Finally, if a query name is sub.*.example., any answer available will come
from an exact name match for sub.*.example. No wild card synthesis is
performed in this case.
Full Copyright Statement
Copyright (C) The Internet Society 2003. 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.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-703-227-9854
ARIN Research Engineer

1830
doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt Normal file
View file

File diff suppressed because it is too large Load diff

616
doc/draft/draft-richardson-ipsec-rr-02.txt Normal file
View file

@ -0,0 +1,616 @@
Independent submission M. Richardson
Internet-Draft SSW
Expires: August 24, 2003 February 23, 2003
A method for storing IPsec keying material in DNS.
draft-richardson-ipsec-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 24, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes a new resource record for DNS. This record
may be used to store public keys for use in IPsec systems.
This record replaces the functionality of the sub-type #1 of the KEY
Resource Record, which has been proposed to be obsoleted by [1].
Richardson Expires August 24, 2003 [Page 1]
Internet-Draft ipsecrr February 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 4
3. IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 5
3.1 RDATA format - algo type . . . . . . . . . . . . . . . . . . . 5
3.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 5
3.3 RDATA format - RSA public key . . . . . . . . . . . . . . . . 5
3.4 RDATA format - DSA public key . . . . . . . . . . . . . . . . 6
3.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 6
4. Presentation formats . . . . . . . . . . . . . . . . . . . . . 7
4.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
Normative references . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
Richardson Expires August 24, 2003 [Page 2]
Internet-Draft ipsecrr February 2003
1. Introduction
1.1 Overview
Overview.
Richardson Expires August 24, 2003 [Page 3]
Internet-Draft ipsecrr February 2003
2. Storage formats
The IPSECKEY resource record (RR) is used to publish a public key
that is to be associated with a Domain Name System (DNS) name. It
will be a public key as only public keys are stored in the DNS. This
can be the public key of a host, network, or application (in the case
of per-port keying).
An IPSECKEY RR is, like any other RR, authenticated by a SIG RR.
It is expected that there will often be multiple resource records of
the IPSECKEY type. This will be due to the need to rollover keys,
and due to the presence of multiple gateways.
The type number for the IPSECKEY RR is 45 (IANA TBD).
Richardson Expires August 24, 2003 [Page 4]
Internet-Draft ipsecrr February 2003
3. IPSECKEY RDATA format
The RDATA for an IPSECKEY RR consists of a precedence value, a public
key (and algorithm type), and an optional gateway address.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | algo | precedence | public key length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
~ gateway ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1 RDATA format - algo type
The algorithm type ("algo") field indicates the type of key that is
present in the public key field. Valid values are:
0 No key is present.
1 A RSA key is present, in the format defined in
2 A DSA key is present, in the format defined in
3.2 RDATA format - precedence
This is an 8-bit precedence for this record. This is interpreted in
a similar way to the PREFERENCE field described in section 3.3.9 of
[3].
3.3 RDATA format - RSA public key
If the algorithm type has the value 1, then public key portion
contains an RSA public key, encoded as described in secion 2 of [8],
and repeated here:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pub exp length| public key exponent /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
Richardson Expires August 24, 2003 [Page 5]
Internet-Draft ipsecrr February 2003
+- modulus /
| /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
RFC2065 limited the exponent and modulus to 2552 bits in length, and
RFC3110 to 4096 bits. No such limit is specified here for the
purposes of encoding and decoding. The length in octets of the
public exponent length is represented as one octet if it is in the
range of 1 to 255 and by a zero octet followed by a two octet
unsigned length if it is longer than 255 bytes. The public key
modulus field is a multiprecision unsigned integer. The length of
the modulus can be determined from the RDLENGTH and the preceding
RDATA fields including the exponent.
Leading zero bytes are prohibited in the exponent and modulus.
3.4 RDATA format - DSA public key
If the algorithm type has the value 2, then public key portion
contains an DSA public key, encoded as described in [7].
3.5 RDATA format - gateway
The gateway field indicates a gateway to which an IPsec tunnel may be
created in order to reach the entity holding this resource record.
The length of this field is the size of the data portion minus the
public key length, and the 4 bytes of header. The gateway field may
be absent.
The gateway field is a string. It is most commonly a simple fully
qualified domain name (FQDN). IP version 4 and IP version 6
addresses may be represented using names from in-addr.arpa. and
ip6.arpa.
The gateway field may also include a @-character in it. Either in
the form @FQDN, or user@FQDN. In this context, it does not reference
a single destination, but just an identifier that will be used when
doing key negotiations. This may be used in the context where the
gateway does not have a permanent IP address, but has permanent
address space behind it, and will be initiating connections only.
Richardson Expires August 24, 2003 [Page 6]
Internet-Draft ipsecrr February 2003
4. Presentation formats
4.1 Representation of IPSECKEY RRs
IPSECKEY RRs may appear as lines in a zone data master file. The
precedence field is mandatory. While both the gateway and public key
fields are optional, it is illegal for neither to be present.
As the IPv4, IPv6 and FQDN references to the gateway are mutually
exclusive, they can share a position. If no gateway is to be
indicated, then the special tokens of either "-" or "none" may be
used.
IPv4 addresses are to be represented as a dotted decimal quad, with
no leading zeroes. IPv6 addresses are to be presented as specified
in section 2.2 of [4].
38.46.139.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 192.139.46.38
RSA: AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La
9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1
49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC
MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8
cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3
fejrfi1H )
Richardson Expires August 24, 2003 [Page 7]
Internet-Draft ipsecrr February 2003
5. IANA Considerations
IANA is asked to assign resource record 45 to this resource record.
Richardson Expires August 24, 2003 [Page 8]
Internet-Draft ipsecrr February 2003
6. Acknowledgments
People who pushed me to write this.
Richardson Expires August 24, 2003 [Page 9]
Internet-Draft ipsecrr February 2003
Normative references
[1] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
Record (RR)", RFC 3445, December 2002.
[2] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[3] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[4] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 1884, December 1995.
[5] Thomson, S. and C. Huitema, "DNS Extensions to support IP
version 6", RFC 1886, December 1995.
[6] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[7] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[8] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
System (DNS)", RFC 3110, May 2001.
Author's Address
Michael C. Richardson
Sandelman Software Works
470 Dawson Avenue
Ottawa, ON K1Z 5V7
CA
EMail: mcr@sandelman.ottawa.on.ca
URI: http://www.sandelman.ottawa.on.ca/
Richardson Expires August 24, 2003 [Page 10]
Internet-Draft ipsecrr February 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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.
Richardson Expires August 24, 2003 [Page 11]

280
doc/draft/draft-ymbk-6to4-arpa-delegation-00.txt Normal file
View file

@ -0,0 +1,280 @@
Network Working Group R. Bush
Internet-Draft IIJ
Expires: August 14, 2003 J. Damas
February 13, 2003
Delegation of 2.0.0.2.ip6.arpa
draft-ymbk-6to4-arpa-delegation-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 14, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document discusses the need for delegation of the
2.0.0.2.ip6.arpa DNS zone in order to enable reverse lookups for 6to4
addresses.
1. 6to4 and DNS
6to4 [RFC3056] provides a mechanism for IPv6 native hosts to
communicate over IPv4 clouds without explicit tunnel setup.
6to4 and DNS [I-D.moore-6to4-dns] describes methods to find the
delegation path for reverse lookups of 6to4 addresses in the DNS.
Section 3.1 of the I-D describes a simple method, using established
Bush & Damas Expires August 14, 2003 [Page 1]
Internet-Draft Delegation of 2.0.0.2.ip6.arpa February 2003
mechanisms at the RIRs, that would enable such a mechanism to be
deployed using a minimum of additional setup.
Under the described method, the holders of IPv4 address space can
request the delegation of a sub-zone in the 2.0.0.2.ip6.arpa DNS tree
from the party from which they obtained the corresponding IPv4
in-addr.arpa delegation (or the holder of an even shorter IPv4 prefix
if their immediate parent is not configured for ip6.arpa), following
the mapping of IPv4 delegations. This sub-zone can then be populated
by the entity deploying the 6to4 infrastructure.
2. IANA Considerations
This memo requests that the IANA delegate the 2.0.0.2.IP6.ARPA domain
to the RIRs as will be described in instructions to be provided by
the IAB. Names within this zone are to be further delegated within
the regional IP registries and ISPs in accordance with the delegation
of IPv4 address space.
3. Security Considerations
While DNS spoofing of address to name mapping has been exploited in
IPv4, delegation of the 2.0.0.2.ip6.arpa zone creates no new threats
to the security of the internet.
Normative References
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
Informative References
[I-D.moore-6to4-dns]
Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work
in progress), October 2002.
Authors' Addresses
Randy Bush
IIJ
5147 Crystal Springs
Bainbrisge Island, WA 98110
US
Phone: +1 206 780 0431
EMail: randy@psg.com
URI: http://psg.com/~randy/
Bush & Damas Expires August 14, 2003 [Page 2]
Internet-Draft Delegation of 2.0.0.2.ip6.arpa February 2003
Joao Damas
Amsterdam,
The Netherlands
Phone:
EMail: joao@psg.com
Bush & Damas Expires August 14, 2003 [Page 3]
Internet-Draft Delegation of 2.0.0.2.ip6.arpa February 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 assignees.
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
Bush & Damas Expires August 14, 2003 [Page 4]
Internet-Draft Delegation of 2.0.0.2.ip6.arpa February 2003
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.
Bush & Damas Expires August 14, 2003 [Page 5]

268
doc/rfc/rfc1886.txt Normal file
View file

@ -0,0 +1,268 @@
Network Working Group S. Thomson
Request for Comments: 1886 Bellcore
Category: Standards Track C. Huitema
INRIA
December 1995
DNS Extensions to support IP version 6
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document defines the changes that need to be made to the Domain
Name System to support hosts running IP version 6 (IPv6). The
changes include a new resource record type to store an IPv6 address,
a new domain to support lookups based on an IPv6 address, and updated
definitions of existing query types that return Internet addresses as
part of additional section processing. The extensions are designed
to be compatible with existing applications and, in particular, DNS
implementations themselves.
Thompson & Huitema Standards Track [Page 1]
RFC 1886 IPv6 DNS Extensions December 1995
1. INTRODUCTION
Current support for the storage of Internet addresses in the Domain
Name System (DNS)[1,2] cannot easily be extended to support IPv6
addresses[3] since applications assume that address queries return
32-bit IPv4 addresses only.
To support the storage of IPv6 addresses we define the following
extensions:
o A new resource record type is defined to map a domain name to an
IPv6 address.
o A new domain is defined to support lookups based on address.
o Existing queries that perform additional section processing to
locate IPv4 addresses are redefined to perform additional
section processing on both IPv4 and IPv6 addresses.
The changes are designed to be compatible with existing software. The
existing support for IPv4 addresses is retained. Transition issues
related to the co-existence of both IPv4 and IPv6 addresses in DNS
are discussed in [4].
2. NEW RESOURCE RECORD DEFINITION AND DOMAIN
A new record type is defined to store a host's IPv6 address. A host
that has more than one IPv6 address must have more than one such
record.
2.1 AAAA record type
The AAAA resource record type is a new record specific to the
Internet class that stores a single IPv6 address.
The value of the type is 28 (decimal).
2.2 AAAA data format
A 128 bit IPv6 address is encoded in the data portion of an AAAA
resource record in network byte order (high-order byte first).
Thompson & Huitema Standards Track [Page 2]
RFC 1886 IPv6 DNS Extensions December 1995
2.3 AAAA query
An AAAA query for a specified domain name in the Internet class
returns all associated AAAA resource records in the answer section of
a response.
A type AAAA query does not perform additional section processing.
2.4 Textual format of AAAA records
The textual representation of the data portion of the AAAA resource
record used in a master database file is the textual representation
of a IPv6 address as defined in [3].
2.5 IP6.INT Domain
A special domain is defined to look up a record given an address. The
intent of this domain is to provide a way of mapping an IPv6 address
to a host name, although it may be used for other purposes as well.
The domain is rooted at IP6.INT.
An IPv6 address is represented as a name in the IP6.INT domain by a
sequence of nibbles separated by dots with the suffix ".IP6.INT". The
sequence of nibbles is encoded in reverse order, i.e. the low-order
nibble is encoded first, followed by the next low-order nibble and so
on. Each nibble is represented by a hexadecimal digit. For example,
the inverse lookup domain name corresponding to the address
4321:0:1:2:3:4:567:89ab
would be
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT.
3. MODIFICATIONS TO EXISTING QUERY TYPES
All existing query types that perform type A additional section
processing, i.e. name server (NS), mail exchange (MX) and mailbox
(MB) query types, must be redefined to perform both type A and type
AAAA additional section processing. These new definitions mean that a
name server must add any relevant IPv4 addresses and any relevant
Thompson & Huitema Standards Track [Page 3]
RFC 1886 IPv6 DNS Extensions December 1995
IPv6 addresses available locally to the additional section of a
response when processing any one of the above queries.
4. SECURITY CONSIDERATIONS
Security issues are not discussed in this memo.
Thompson & Huitema Standards Track [Page 4]
RFC 1886 IPv6 DNS Extensions December 1995
5. REFERENCES
[1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[2] Mockapetris, P., "Domain Names - Implementation and Specifica-
tion", STD 13, RFC 1035, USC/Information Sciences Institute,
November 1987.
[3] Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing
Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December
1995.
[4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", Work in Progress.
Authors' Addresses
Susan Thomson
Bellcore
MRE 2P343
445 South Street
Morristown, NJ 07960
U.S.A.
Phone: +1 201-829-4514
EMail: set@thumper.bellcore.com
Christian Huitema
INRIA, Sophia-Antipolis
2004 Route des Lucioles
BP 109
F-06561 Valbonne Cedex
France
Phone: +33 93 65 77 15
EMail: Christian.Huitema@MIRSA.INRIA.FR
Thompson & Huitema Standards Track [Page 5]

283
doc/rfc/rfc3197.txt Normal file
View file

@ -0,0 +1,283 @@
Network Working Group R. Austein
Request for Comments: 3197 InterNetShare
Category: Informational November 2001
Applicability Statement for DNS MIB Extensions
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document explains why, after more than six years as proposed
standards, the DNS Server and Resolver MIB extensions were never
deployed, and recommends retiring these MIB extensions by moving them
to Historical status.
1. History
The road to the DNS MIB extensions was paved with good intentions.
In retrospect, it's obvious that the working group never had much
agreement on what belonged in the MIB extensions, just that we should
have some. This happened during the height of the craze for MIB
extensions in virtually every protocol that the IETF was working on
at the time, so the question of why we were doing this in the first
place never got a lot of scrutiny. Very late in the development
cycle we discovered that much of the support for writing the MIB
extensions in the first place had come from people who wanted to use
SNMP SET operations to update DNS zones on the fly. Examination of
the security model involved, however, led us to conclude that this
was not a good way to do dynamic update and that a separate DNS
Dynamic Update protocol would be necessary.
The MIB extensions started out being fairly specific to one
particular DNS implementation (BIND-4.8.3); as work progressed, the
BIND-specific portions were rewritten to be as implementation-neutral
as we knew how to make them, but somehow every revision of the MIB
extensions managed to create new counters that just happened to
closely match statistics kept by some version of BIND. As a result,
the MIB extensions ended up being much too big, which raised a number
Austein Informational [Page 1]
RFC 3197 Applicability Statement - DNS MIB Extensions November 2001
of concerns with the network management directorate, but the WG
resisted every attempt to remove any of these variables. In the end,
large portions of the MIB extensions were moved into optional groups
in an attempt to get the required subset down to a manageable size.
The DNS Server and Resolver MIB extensions were one of the first
attempts to write MIB extensions for a protocol usually considered to
be at the application layer. Fairly early on it became clear that,
while it was certainly possible to write MIB extensions for DNS, the
SMI was not really designed with this sort of thing in mind. A case
in point was the attempt to provide direct indexing into the caches
in the resolver MIB extensions: while arguably the only sane way to
do this for a large cache, this required much more complex indexing
clauses than is usual, and ended up running into known length limits
for object identifiers in some SNMP implementations.
Furthermore, the lack of either real proxy MIB support in SNMP
managers or a standard subagent protocol meant that there was no
reasonable way to implement the MIB extensions in the dominant
implementation (BIND). When the AgentX subagent protocol was
developed a few years later, we initially hoped that this would
finally clear the way for an implementation of the DNS MIB
extensions, but by the time AgentX was a viable protocol it had
become clear that nobody really wanted to implement these MIB
extensions.
Finally, the MIB extensions took much too long to produce. In
retrospect, this should have been a clear warning sign, particularly
when the WG had clearly become so tired of the project that the
authors found it impossible to elicit any comments whatsoever on the
documents.
2. Lessons
Observations based on the preceding list of mistakes, for the benefit
of anyone else who ever attempts to write DNS MIB extensions again:
- Define a clear set of goals before writing any MIB extensions.
Know who the constituency is and make sure that what you write
solves their problem.
- Keep the MIB extensions short, and don't add variables just
because somebody in the WG thinks they'd be a cool thing to
measure.
- If some portion of the task seems to be very hard to do within the
SMI, that's a strong hint that SNMP is not the right tool for
whatever it is that you're trying to do.
Austein Informational [Page 2]
RFC 3197 Applicability Statement - DNS MIB Extensions November 2001
- If the entire project is taking too long, perhaps that's a hint
too.
3. Recommendation
In view of the community's apparent total lack of interest in
deploying these MIB extensions, we recommend that RFCs 1611 and 1612
be reclassified as Historical documents.
4. Security Considerations
Re-classifying an existing MIB document from Proposed Standard to
Historic should not have any negative impact on security for the
Internet.
5. IANA Considerations
Getting rid of the DNS MIB extensions should not impose any new work
on IANA.
6. Acknowledgments
The author would like to thank all the people who were involved in
this project over the years for their optimism and patience,
misguided though it may have been.
7. References
[DNS-SERVER-MIB] Austein, R. and J. Saperia, "DNS Server MIB
Extensions", RFC 1611, May 1994.
[DNS-RESOLVER-MIB] Austein, R. and J. Saperia, "DNS Resolver MIB
Extensions", RFC 1612, May 1994.
[DNS-DYNAMIC-UPDATE] Vixie, P., Thomson, S., Rekhter, Y. and J.
Bound, "Dynamic Updates in the Domain Name
System (DNS UPDATE)", RFC 2136, April 1997.
[AGENTX] Daniele, M., Wijnen, B., Ellison, M., and D.
Francisco, "Agent Extensibility (AgentX)
Protocol Version 1", RFC 2741, January 2000.
Austein Informational [Page 3]
RFC 3197 Applicability Statement - DNS MIB Extensions November 2001
8. Author's Address
Rob Austein
InterNetShare, Incorporated
325M Sharon Park Drive, Suite 308
Menlo Park, CA 94025
USA
EMail: sra@hactrn.net
Austein Informational [Page 4]
RFC 3197 Applicability Statement - DNS MIB Extensions November 2001
9. 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.
Austein Informational [Page 5]

339
doc/rfc/rfc3363.txt Normal file
View file

@ -0,0 +1,339 @@
Network Working Group R. Bush
Request for Comments: 3363 A. Durand
Updates: 2673, 2874 B. Fink
Category: Informational O. Gudmundsson
T. Hain
Editors
August 2002
Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document clarifies and updates the standards status of RFCs that
define direct and reverse map of IPv6 addresses in DNS. This
document moves the A6 and Bit label specifications to experimental
status.
1. Introduction
The IETF had begun the process of standardizing two different address
formats for IPv6 addresses AAAA [RFC1886] and A6 [RFC2874] and both
are at proposed standard. This had led to confusion and conflicts on
which one to deploy. It is important for deployment that any
confusion in this area be cleared up, as there is a feeling in the
community that having more than one choice will lead to delays in the
deployment of IPv6. The goal of this document is to clarify the
situation.
This document also discusses issues relating to the usage of Binary
Labels [RFC 2673] to support the reverse mapping of IPv6 addresses.
This document is based on extensive technical discussion on various
relevant working groups mailing lists and a joint DNSEXT and NGTRANS
meeting at the 51st IETF in August 2001. This document attempts to
capture the sense of the discussions and reflect them in this
document to represent the consensus of the community.
Bush, et. al. Informational [Page 1]
RFC 3363 Representation of IPv6 Addresses in DNS August 2002
The main arguments and the issues are covered in a separate document
[RFC3364] that reflects the current understanding of the issues.
This document summarizes the outcome of these discussions.
The issue of the root of reverse IPv6 address map is outside the
scope of this document and is covered in a different document
[RFC3152].
1.1 Standards Action Taken
This document changes the status of RFCs 2673 and 2874 from Proposed
Standard to Experimental.
2. IPv6 Addresses: AAAA RR vs A6 RR
Working group consensus as perceived by the chairs of the DNSEXT and
NGTRANS working groups is that:
a) AAAA records are preferable at the moment for production
deployment of IPv6, and
b) that A6 records have interesting properties that need to be better
understood before deployment.
c) It is not known if the benefits of A6 outweigh the costs and
risks.
2.1 Rationale
There are several potential issues with A6 RRs that stem directly
from the feature that makes them different from AAAA RRs: the ability
to build up addresses via chaining.
Resolving a chain of A6 RRs involves resolving a series of what are
nearly-independent queries. Each of these sub-queries takes some
non-zero amount of time, unless the answer happens to be in the
resolver's local cache already. Other things being equal, we expect
that the time it takes to resolve an N-link chain of A6 RRs will be
roughly proportional to N. What data we have suggests that users are
already impatient with the length of time it takes to resolve A RRs
in the IPv4 Internet, which suggests that users are not likely to be
patient with significantly longer delays in the IPv6 Internet, but
terminating queries prematurely is both a waste of resources and
another source of user frustration. Thus, we are forced to conclude
that indiscriminate use of long A6 chains is likely to lead to
increased user frustration.
Bush, et. al. Informational [Page 2]
RFC 3363 Representation of IPv6 Addresses in DNS August 2002
The probability of failure during the process of resolving an N-link
A6 chain also appears to be roughly proportional to N, since each of
the queries involved in resolving an A6 chain has roughly the same
probability of failure as a single AAAA query.
Last, several of the most interesting potential applications for A6
RRs involve situations where the prefix name field in the A6 RR
points to a target that is not only outside the DNS zone containing
the A6 RR, but is administered by a different organization entirely.
While pointers out of zone are not a problem per se, experience both
with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that
pointers to other organizations are often not maintained properly,
perhaps because they're less susceptible to automation than pointers
within a single organization would be.
2.2 Recommended Standard Action
Based on the perceived consensus, this document recommends that RFC
1886 stay on standards track and be advanced, while moving RFC 2874
to Experimental status.
3. Bitlabels in the Reverse DNS Tree
RFC 2673 defines a new DNS label type. This was the first new type
defined since RFC 1035 [RFC1035]. Since the development of 2673 it
has been learned that deployment of a new type is difficult since DNS
servers that do not support bitlabels reject queries containing bit
labels as being malformed. The community has also indicated that
this new label type is not needed for mapping reverse addresses.
3.1 Rationale
The hexadecimal text representation of IPv6 addresses appears to be
capable of expressing all of the delegation schemes that we expect to
be used in the DNS reverse tree.
3.2 Recommended Standard Action
RFC 2673 standard status is to be changed from Proposed to
Experimental. Future standardization of these documents is to be
done by the DNSEXT working group or its successor.
Bush, et. al. Informational [Page 3]
RFC 3363 Representation of IPv6 Addresses in DNS August 2002
4. DNAME in IPv6 Reverse Tree
The issues for DNAME in the reverse mapping tree appears to be
closely tied to the need to use fragmented A6 in the main tree: if
one is necessary, so is the other, and if one isn't necessary, the
other isn't either. Therefore, in moving RFC 2874 to experimental,
the intent of this document is that use of DNAME RRs in the reverse
tree be deprecated.
5. Acknowledgments
This document is based on input from many members of the various IETF
working groups involved in this issues. Special thanks go to the
people that prepared reading material for the joint DNSEXT and
NGTRANS working group meeting at the 51st IETF in London, Rob
Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino,
Christian Huitema. Number of other people have made number of
comments on mailing lists about this issue including Andrew W.
Barclay, Robert Elz, Johan Ihren, Edward Lewis, Bill Manning, Pekka
Savola, Paul Vixie.
6. Security Considerations
As this document specifies a course of action, there are no direct
security considerations. There is an indirect security impact of the
choice, in that the relationship between A6 and DNSSEC is not well
understood throughout the community, while the choice of AAAA does
leads to a model for use of DNSSEC in IPv6 networks which parallels
current IPv4 practice.
7. IANA Considerations
None.
Normative References
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC1886] Thompson, S. and C. Huitema, "DNS Extensions to support IP
version 6", RFC 1886, December 1995.
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
IPv6 Address Aggregation and Renumbering", RFC 2874, July
2000.
Bush, et. al. Informational [Page 4]
RFC 3363 Representation of IPv6 Addresses in DNS August 2002
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152
August 2001.
Informative References
[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
Support for Internet Protocol version 6 (IPv6)", RFC 3364,
August 2002.
Editors' Addresses
Randy Bush
EMail: randy@psg.com
Alain Durand
EMail: alain.durand@sun.com
Bob Fink
EMail: fink@es.net
Olafur Gudmundsson
EMail: ogud@ogud.com
Tony Hain
EMail: hain@tndh.net
Bush, et. al. Informational [Page 5]
RFC 3363 Representation of IPv6 Addresses in DNS August 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
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.
Bush, et. al. Informational [Page 6]

619
doc/rfc/rfc3364.txt Normal file
View file

@ -0,0 +1,619 @@
Network Working Group R. Austein
Request for Comments: 3364 Bourgeois Dilettant
Updates: 2673, 2874 August 2002
Category: Informational
Tradeoffs in Domain Name System (DNS) Support
for Internet Protocol version 6 (IPv6)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The IETF has two different proposals on the table for how to do DNS
support for IPv6, and has thus far failed to reach a clear consensus
on which approach is better. This note attempts to examine the pros
and cons of each approach, in the hope of clarifying the debate so
that we can reach closure and move on.
Introduction
RFC 1886 [RFC1886] specified straightforward mechanisms to support
IPv6 addresses in the DNS. These mechanisms closely resemble the
mechanisms used to support IPv4, with a minor improvement to the
reverse mapping mechanism based on experience with CIDR. RFC 1886 is
currently listed as a Proposed Standard.
RFC 2874 [RFC2874] specified enhanced mechanisms to support IPv6
addresses in the DNS. These mechanisms provide new features that
make it possible for an IPv6 address stored in the DNS to be broken
up into multiple DNS resource records in ways that can reflect the
network topology underlying the address, thus making it possible for
the data stored in the DNS to reflect certain kinds of network
topology changes or routing architectures that are either impossible
or more difficult to represent without these mechanisms. RFC 2874 is
also currently listed as a Proposed Standard.
Austein Informational [Page 1]
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
Both of these Proposed Standards were the output of the IPNG Working
Group. Both have been implemented, although implementation of
[RFC1886] is more widespread, both because it was specified earlier
and because it's simpler to implement.
There's little question that the mechanisms proposed in [RFC2874] are
more general than the mechanisms proposed in [RFC1886], and that
these enhanced mechanisms might be valuable if IPv6's evolution goes
in certain directions. The questions are whether we really need the
more general mechanism, what new usage problems might come along with
the enhanced mechanisms, and what effect all this will have on IPv6
deployment.
The one thing on which there does seem to be widespread agreement is
that we should make up our minds about all this Real Soon Now.
Main Advantages of Going with A6
While the A6 RR proposed in [RFC2874] is very general and provides a
superset of the functionality provided by the AAAA RR in [RFC1886],
many of the features of A6 can also be implemented with AAAA RRs via
preprocessing during zone file generation.
There is one specific area where A6 RRs provide something that cannot
be provided using AAAA RRs: A6 RRs can represent addresses in which a
prefix portion of the address can change without any action (or
perhaps even knowledge) by the parties controlling the DNS zone
containing the terminal portion (least significant bits) of the
address. This includes both so-called "rapid renumbering" scenarios
(where an entire network's prefix may change very quickly) and
routing architectures such as the former "GSE" proposal [GSE] (where
the "routing goop" portion of an address may be subject to change
without warning). A6 RRs do not completely remove the need to update
leaf zones during all renumbering events (for example, changing ISPs
would usually require a change to the upward delegation pointer), but
careful use of A6 RRs could keep the number of RRs that need to
change during such an event to a minimum.
Note that constructing AAAA RRs via preprocessing during zone file
generation requires exactly the sort of information that A6 RRs store
in the DNS. This begs the question of where the hypothetical
preprocessor obtains that information if it's not getting it from the
DNS.
Note also that the A6 RR, when restricted to its zero-length-prefix
form ("A6 0"), is semantically equivalent to an AAAA RR (with one
"wasted" octet in the wire representation), so anything that can be
done with an AAAA RR can also be done with an A6 RR.
Austein Informational [Page 2]
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
Main Advantages of Going with AAAA
The AAAA RR proposed in [RFC1886], while providing only a subset of
the functionality provided by the A6 RR proposed in [RFC2874], has
two main points to recommend it:
- AAAA RRs are essentially identical (other than their length) to
IPv4's A RRs, so we have more than 15 years of experience to help
us predict the usage patterns, failure scenarios and so forth
associated with AAAA RRs.
- The AAAA RR is "optimized for read", in the sense that, by storing
a complete address rather than making the resolver fetch the
address in pieces, it minimizes the effort involved in fetching
addresses from the DNS (at the expense of increasing the effort
involved in injecting new data into the DNS).
Less Compelling Arguments in Favor of A6
Since the A6 RR allows a zone administrator to write zone files whose
description of addresses maps to the underlying network topology, A6
RRs can be construed as a "better" way of representing addresses than
AAAA. This may well be a useful capability, but in and of itself
it's more of an argument for better tools for zone administrators to
use when constructing zone files than a justification for changing
the resolution protocol used on the wire.
Less Compelling Arguments in Favor of AAAA
Some of the pressure to go with AAAA instead of A6 appears to be
based on the wider deployment of AAAA. Since it is possible to
construct transition tools (see discussion of AAAA synthesis, later
in this note), this does not appear to be a compelling argument if A6
provides features that we really need.
Another argument in favor of AAAA RRs over A6 RRs appears to be that
the A6 RR's advanced capabilities increase the number of ways in
which a zone administrator could build a non-working configuration.
While operational issues are certainly important, this is more of
argument that we need better tools for zone administrators than it is
a justification for turning away from A6 if A6 provides features that
we really need.
Austein Informational [Page 3]
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
Potential Problems with A6
The enhanced capabilities of the A6 RR, while interesting, are not in
themselves justification for choosing A6 if we don't really need
those capabilities. The A6 RR is "optimized for write", in the sense
that, by making it possible to store fragmented IPv6 addresses in the
DNS, it makes it possible to reduce the effort that it takes to
inject new data into the DNS (at the expense of increasing the effort
involved in fetching data from the DNS). This may be justified if we
expect the effort involved in maintaining AAAA-style DNS entries to
be prohibitive, but in general, we expect the DNS data to be read
more frequently than it is written, so we need to evaluate this
particular tradeoff very carefully.
There are also several potential issues with A6 RRs that stem
directly from the feature that makes them different from AAAA RRs:
the ability to build up address via chaining.
Resolving a chain of A6 RRs involves resolving a series of what are
almost independent queries, but not quite. Each of these sub-queries
takes some non-zero amount of time, unless the answer happens to be
in the resolver's local cache already. Assuming that resolving an
AAAA RR takes time T as a baseline, we can guess that, on the
average, it will take something approaching time N*T to resolve an
N-link chain of A6 RRs, although we would expect to see a fairly good
caching factor for the A6 fragments representing the more significant
bits of an address. This leaves us with two choices, neither of
which is very good: we can decrease the amount of time that the
resolver is willing to wait for each fragment, or we can increase the
amount of time that a resolver is willing to wait before returning
failure to a client. What little data we have on this subject
suggests that users are already impatient with the length of time it
takes to resolve A RRs in the IPv4 Internet, which suggests that they
are not likely to be patient with significantly longer delays in the
IPv6 Internet. At the same time, terminating queries prematurely is
both a waste of resources and another source of user frustration.
Thus, we are forced to conclude that indiscriminate use of long A6
chains is likely to lead to problems.
To make matters worse, the places where A6 RRs are likely to be most
critical for rapid renumbering or GSE-like routing are situations
where the prefix name field in the A6 RR points to a target that is
not only outside the DNS zone containing the A6 RR, but is
administered by a different organization (for example, in the case of
an end user's site, the prefix name will most likely point to a name
belonging to an ISP that provides connectivity for the site). While
pointers out of zone are not a problem per se, pointers to other
organizations are somewhat more difficult to maintain and less
Austein Informational [Page 4]
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
susceptible to automation than pointers within a single organization
would be. Experience both with glue RRs and with PTR RRs in the IN-
ADDR.ARPA tree suggests that many zone administrators do not really
understand how to set up and maintain these pointers properly, and we
have no particular reason to believe that these zone administrators
will do a better job with A6 chains than they do today. To be fair,
however, the alternative case of building AAAA RRs via preprocessing
before loading zones has many of the same problems; at best, one can
claim that using AAAA RRs for this purpose would allow DNS clients to
get the wrong answer somewhat more efficiently than with A6 RRs.
Finally, assuming near total ignorance of how likely a query is to
fail, the probability of failure with an N-link A6 chain would appear
to be roughly proportional to N, since each of the queries involved
in resolving an A6 chain would have the same probability of failure
as a single AAAA query. Note again that this comment applies to
failures in the the process of resolving a query, not to the data
obtained via that process. Arguably, in an ideal world, A6 RRs would
increase the probability of the answer a client (finally) gets being
right, assuming that nothing goes wrong in the query process, but we
have no real idea how to quantify that assumption at this point even
to the hand-wavey extent used elsewhere in this note.
One potential problem that has been raised in the past regarding A6
RRs turns out not to be a serious issue. The A6 design includes the
possibility of there being more than one A6 RR matching the prefix
name portion of a leaf A6 RR. That is, an A6 chain may not be a
simple linked list, it may in fact be a tree, where each branch
represents a possible prefix. Some critics of A6 have been concerned
that this will lead to a wild expansion of queries, but this turns
out not to be a problem if a resolver simply follows the "bounded
work per query" rule described in RFC 1034 (page 35). That rule
applies to all work resulting from attempts to process a query,
regardless of whether it's a simple query, a CNAME chain, an A6 tree,
or an infinite loop. The client may not get back a useful answer in
cases where the zone has been configured badly, but a proper
implementation should not produce a query explosion as a result of
processing even the most perverse A6 tree, chain, or loop.
Interactions with DNSSEC
One of the areas where AAAA and A6 RRs differ is in the precise
details of how they interact with DNSSEC. The following comments
apply only to non-zero-prefix A6 RRs (A6 0 RRs, once again, are
semantically equivalent to AAAA RRs).
Austein Informational [Page 5]
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
Other things being equal, the time it takes to re-sign all of the
addresses in a zone after a renumbering event is longer with AAAA RRs
than with A6 RRs (because each address record has to be re-signed
rather than just signing a common prefix A6 RR and a few A6 0 RRs
associated with the zone's name servers). Note, however, that in
general this does not present a serious scaling problem, because the
re-signing is performed in the leaf zones.
Other things being equal, there's more work involved in verifying the
signatures received back for A6 RRs, because each address fragment
has a separate associated signature. Similarly, a DNS message
containing a set of A6 address fragments and their associated
signatures will be larger than the equivalent packet with a single
AAAA (or A6 0) and a single associated signature.
Since AAAA RRs cannot really represent rapid renumbering or GSE-style
routing scenarios very well, it should not be surprising that DNSSEC
signatures of AAAA RRs are also somewhat problematic. In cases where
the AAAA RRs would have to be changing very quickly to keep up with
prefix changes, the time required to re-sign the AAAA RRs may be
prohibitive.
Empirical testing by Bill Sommerfeld [Sommerfeld] suggests that
333MHz Celeron laptop with 128KB L2 cache and 64MB RAM running the
BIND-9 dnssec-signzone program under NetBSD can generate roughly 40
1024-bit RSA signatures per second. Extrapolating from this,
assuming one A RR, one AAAA RR, and one NXT RR per host, this
suggests that it would take this laptop a few hours to sign a zone
listing 10**5 hosts, or about a day to sign a zone listing 10**6
hosts using AAAA RRs.
This suggests that the additional effort of re-signing a large zone
full of AAAA RRs during a re-numbering event, while noticeable, is
only likely to be prohibitive in the rapid renumbering case where
AAAA RRs don't work well anyway.
Interactions with Dynamic Update
DNS dynamic update appears to work equally well for AAAA or A6 RRs,
with one minor exception: with A6 RRs, the dynamic update client
needs to know the prefix length and prefix name. At present, no
mechanism exists to inform a dynamic update client of these values,
but presumably such a mechanism could be provided via an extension to
DHCP, or some other equivalent could be devised.
Austein Informational [Page 6]
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
Transition from AAAA to A6 Via AAAA Synthesis
While AAAA is at present more widely deployed than A6, it is possible
to transition from AAAA-aware DNS software to A6-aware DNS software.
A rough plan for this was presented at IETF-50 in Minneapolis and has
been discussed on the ipng mailing list. So if the IETF concludes
that A6's enhanced capabilities are necessary, it should be possible
to transition from AAAA to A6.
The details of this transition have been left to a separate document,
but the general idea is that the resolver that is performing
iterative resolution on behalf of a DNS client program could
synthesize AAAA RRs representing the result of performing the
equivalent A6 queries. Note that in this case it is not possible to
generate an equivalent DNSSEC signature for the AAAA RR, so clients
that care about performing DNSSEC validation for themselves would
have to issue A6 queries directly rather than relying on AAAA
synthesis.
Bitlabels
While the differences between AAAA and A6 RRs have generated most of
the discussion to date, there are also two proposed mechanisms for
building the reverse mapping tree (the IPv6 equivalent of IPv4's IN-
ADDR.ARPA tree).
[RFC1886] proposes a mechanism very similar to the IN-ADDR.ARPA
mechanism used for IPv4 addresses: the RR name is the hexadecimal
representation of the IPv6 address, reversed and concatenated with a
well-known suffix, broken up with a dot between each hexadecimal
digit. The resulting DNS names are somewhat tedious for humans to
type, but are very easy for programs to generate. Making each
hexadecimal digit a separate label means that delegation on arbitrary
bit boundaries will result in a maximum of 16 NS RRsets per label
level; again, the mechanism is somewhat tedious for humans, but is
very easy to program. As with IPv4's IN-ADDR.ARPA tree, the one
place where this scheme is weak is in handling delegations in the
least significant label; however, since there appears to be no real
need to delegate the least significant four bits of an IPv6 address,
this does not appear to be a serious restriction.
[RFC2874] proposed a radically different way of naming entries in the
reverse mapping tree: rather than using textual representations of
addresses, it proposes to use a new kind of DNS label (a "bit label")
to represent binary addresses directly in the DNS. This has the
advantage of being significantly more compact than the textual
representation, and arguably might have been a better solution for
DNS to use for this purpose if it had been designed into the protocol
Austein Informational [Page 7]
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
from the outset. Unfortunately, experience to date suggests that
deploying a new DNS label type is very hard: all of the DNS name
servers that are authoritative for any portion of the name in
question must be upgraded before the new label type can be used, as
must any resolvers involved in the resolution process. Any name
server that has not been upgraded to understand the new label type
will reject the query as being malformed.
Since the main benefit of the bit label approach appears to be an
ability that we don't really need (delegation in the least
significant four bits of an IPv6 address), and since the upgrade
problem is likely to render bit labels unusable until a significant
portion of the DNS code base has been upgraded, it is difficult to
escape the conclusion that the textual solution is good enough.
DNAME RRs
[RFC2874] also proposes using DNAME RRs as a way of providing the
equivalent of A6's fragmented addresses in the reverse mapping tree.
That is, by using DNAME RRs, one can write zone files for the reverse
mapping tree that have the same ability to cope with rapid
renumbering or GSE-style routing that the A6 RR offers in the main
portion of the DNS tree. Consequently, the need to use DNAME in the
reverse mapping tree appears to be closely tied to the need to use
fragmented A6 in the main tree: if one is necessary, so is the other,
and if one isn't necessary, the other isn't either.
Other uses have also been proposed for the DNAME RR, but since they
are outside the scope of the IPv6 address discussion, they will not
be addressed here.
Recommendation
Distilling the above feature comparisons down to their key elements,
the important questions appear to be:
(a) Is IPv6 going to do rapid renumbering or GSE-like routing?
(b) Is the reverse mapping tree for IPv6 going to require delegation
in the least significant four bits of the address?
Question (a) appears to be the key to the debate. This is really a
decision for the IPv6 community to make, not the DNS community.
Question (b) is also for the IPv6 community to make, but it seems
fairly obvious that the answer is "no".
Austein Informational [Page 8]
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
Recommendations based on these questions:
(1) If the IPv6 working groups seriously intend to specify and deploy
rapid renumbering or GSE-like routing, we should transition to
using the A6 RR in the main tree and to using DNAME RRs as
necessary in the reverse tree.
(2) Otherwise, we should keep the simpler AAAA solution in the main
tree and should not use DNAME RRs in the reverse tree.
(3) In either case, the reverse tree should use the textual
representation described in [RFC1886] rather than the bit label
representation described in [RFC2874].
(4) If we do go to using A6 RRs in the main tree and to using DNAME
RRs in the reverse tree, we should write applicability statements
and implementation guidelines designed to discourage excessively
complex uses of these features; in general, any network that can
be described adequately using A6 0 RRs and without using DNAME
RRs should be described that way, and the enhanced features
should be used only when absolutely necessary, at least until we
have much more experience with them and have a better
understanding of their failure modes.
Security Considerations
This note compares two mechanisms with similar security
characteristics, but there are a few security implications to the
choice between these two mechanisms:
(1) The two mechanisms have similar but not identical interactions
with DNSSEC. Please see the section entitled "Interactions with
DNSSEC" (above) for a discussion of these issues.
(2) To the extent that operational complexity is the enemy of
security, the tradeoffs in operational complexity discussed
throughout this note have an impact on security.
(3) To the extent that protocol complexity is the enemy of security,
the additional protocol complexity of [RFC2874] as compared to
[RFC1886] has some impact on security.
IANA Considerations
None, since all of these RR types have already been allocated.
Austein Informational [Page 9]
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
Acknowledgments
This note is based on a number of discussions both public and private
over a period of (at least) eight years, but particular thanks go to
Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun
Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush,
and Sue Thomson, none of whom are responsible for what the author did
with their ideas.
References
[RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support
IP version 6", RFC 1886, December 1995.
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
IPv6 Address Aggregation and Renumbering", RFC 2874,
July 2000.
[Sommerfeld] Private message to the author from Bill Sommerfeld dated
21 March 2001, summarizing the result of experiments he
performed on a copy of the MIT.EDU zone.
[GSE] "GSE" was an evolution of the so-called "8+8" proposal
discussed by the IPng working group in 1996 and 1997.
The GSE proposal itself was written up as an Internet-
Draft, which has long since expired. Readers interested
in the details and history of GSE should review the IPng
working group's mailing list archives and minutes from
that period.
Author's Address
Rob Austein
EMail: sra@hactrn.net
Austein Informational [Page 10]
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
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.
Austein Informational [Page 11]

283
doc/rfc/rfc3425.txt Normal file
View file

@ -0,0 +1,283 @@
Network Working Group D. Lawrence
Request for Comments: 3425 Nominum
Updates: 1035 November 2002
Category: Standards Track
Obsoleting IQUERY
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The IQUERY method of performing inverse DNS lookups, specified in RFC
1035, has not been generally implemented and has usually been
operationally disabled where it has been implemented. Both reflect a
general view in the community that the concept was unwise and that
the widely-used alternate approach of using pointer (PTR) queries and
reverse-mapping records is preferable. Consequently, this document
deprecates the IQUERY operation, declaring it entirely obsolete.
This document updates RFC 1035.
1 - Introduction
As specified in RFC 1035 (section 6.4), the IQUERY operation for DNS
queries is used to look up the name(s) which are associated with the
given value. The value being sought is provided in the query's
answer section and the response fills in the question section with
one or more 3-tuples of type, name and class.
As noted in [RFC1035], section 6.4.3, inverse query processing can
put quite an arduous burden on a server. A server would need to
perform either an exhaustive search of its database or maintain a
separate database that is keyed by the values of the primary
database. Both of these approaches could strain system resource use,
particularly for servers that are authoritative for millions of
names.
Lawrence Standards Track [Page 1]
RFC 3425 Obsoleting IQUERY November 2002
Response packets from these megaservers could be exceptionally large,
and easily run into megabyte sizes. For example, using IQUERY to
find every domain that is delegated to one of the nameservers of a
large ISP could return tens of thousands of 3-tuples in the question
section. This could easily be used to launch denial of service
attacks.
Operators of servers that do support IQUERY in some form (such as
very old BIND 4 servers) generally opt to disable it. This is
largely due to bugs in insufficiently-exercised code, or concerns
about exposure of large blocks of names in their zones by probes such
as inverse MX queries.
IQUERY is also somewhat inherently crippled by being unable to tell a
requester where it needs to go to get the information that was
requested. The answer is very specific to the single server that was
queried. This is sometimes a handy diagnostic tool, but apparently
not enough so that server operators like to enable it, or request
implementation where it is lacking.
No known clients use IQUERY to provide any meaningful service. The
only common reverse mapping support on the Internet, mapping address
records to names, is provided through the use of pointer (PTR)
records in the in-addr.arpa tree and has served the community well
for many years.
Based on all of these factors, this document recommends that the
IQUERY operation for DNS servers be officially obsoleted.
2 - Requirements
The key word "SHOULD" in this document is to be interpreted as
described in BCP 14, RFC 2119, namely that there may exist valid
reasons to ignore a particular item, but the full implications must
be understood and carefully weighed before choosing a different
course.
3 - Effect on RFC 1035
The effect of this document is to change the definition of opcode 1
from that originally defined in section 4.1.1 of RFC 1035, and to
entirely supersede section 6.4 (including subsections) of RFC 1035.
The definition of opcode 1 is hereby changed to:
"1 an inverse query (IQUERY) (obsolete)"
Lawrence Standards Track [Page 2]
RFC 3425 Obsoleting IQUERY November 2002
The text in section 6.4 of RFC 1035 is now considered obsolete. The
following is an applicability statement regarding the IQUERY opcode:
Inverse queries using the IQUERY opcode were originally described as
the ability to look up the names that are associated with a
particular Resource Record (RR). Their implementation was optional
and never achieved widespread use. Therefore IQUERY is now obsolete,
and name servers SHOULD return a "Not Implemented" error when an
IQUERY request is received.
4 - Security Considerations
Since this document obsoletes an operation that was once available,
it is conceivable that someone was using it as the basis of a
security policy. However, since the most logical course for such a
policy to take in the face of a lack of positive response from a
server is to deny authentication/authorization, it is highly unlikely
that removing support for IQUERY will open any new security holes.
Note that if IQUERY is not obsoleted, securing the responses with DNS
Security (DNSSEC) is extremely difficult without out-on-the-fly
digital signing.
5 - IANA Considerations
The IQUERY opcode of 1 should be permanently retired, not to be
assigned to any future opcode.
6 - Acknowledgments
Olafur Gudmundsson instigated this action. Matt Crawford, John
Klensin, Erik Nordmark and Keith Moore contributed some improved
wording in how to handle obsoleting functionality described by an
Internet Standard.
7 - References
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Lawrence Standards Track [Page 3]
RFC 3425 Obsoleting IQUERY November 2002
8 - Author's Address
David C Lawrence
Nominum, Inc.
2385 Bay Rd
Redwood City CA 94063
USA
Phone: +1.650.779.6042
EMail: tale@nominum.com
Lawrence Standards Track [Page 4]
RFC 3425 Obsoleting IQUERY November 2002
9 - Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
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.
Lawrence Standards Track [Page 5]

563
doc/rfc/rfc3445.txt Normal file
View file

@ -0,0 +1,563 @@
Network Working Group D. Massey
Request for Comments: 3445 USC/ISI
Updates: 2535 S. Rose
Category: Standards Track NIST
December 2002
Limiting the Scope of the KEY Resource Record (RR)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document limits the Domain Name System (DNS) KEY Resource Record
(RR) to only keys used by the Domain Name System Security Extensions
(DNSSEC). The original KEY RR used sub-typing to store both DNSSEC
keys and arbitrary application keys. Storing both DNSSEC and
application keys with the same record type is a mistake. This
document removes application keys from the KEY record by redefining
the Protocol Octet field in the KEY RR Data. As a result of removing
application keys, all but one of the flags in the KEY record become
unnecessary and are redefined. Three existing application key sub-
types are changed to reserved, but the format of the KEY record is
not changed. This document updates RFC 2535.
1. Introduction
This document limits the scope of the KEY Resource Record (RR). The
KEY RR was defined in [3] and used resource record sub-typing to hold
arbitrary public keys such as Email, IPSEC, DNSSEC, and TLS keys.
This document eliminates the existing Email, IPSEC, and TLS sub-types
and prohibits the introduction of new sub-types. DNSSEC will be the
only allowable sub-type for the KEY RR (hence sub-typing is
essentially eliminated) and all but one of the KEY RR flags are also
eliminated.
Massey & Rose Standards Track [Page 1]
RFC 3445 Limiting the KEY Resource Record (RR) December 2002
Section 2 presents the motivation for restricting the KEY record and
Section 3 defines the revised KEY RR. Sections 4 and 5 summarize the
changes from RFC 2535 and discuss backwards compatibility. It is
important to note that this document restricts the use of the KEY RR
and simplifies the flags, but does not change the definition or use
of DNSSEC keys.
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. Motivation for Restricting the KEY RR
The KEY RR RDATA [3] consists of Flags, a Protocol Octet, an
Algorithm type, and a Public Key. The Protocol Octet identifies the
KEY RR sub-type. DNSSEC public keys are stored in the KEY RR using a
Protocol Octet value of 3. Email, IPSEC, and TLS keys were also
stored in the KEY RR and used Protocol Octet values of 1,2, and 4
(respectively). Protocol Octet values 5-254 were available for
assignment by IANA and values were requested (but not assigned) for
applications such as SSH.
Any use of sub-typing has inherent limitations. A resolver can not
specify the desired sub-type in a DNS query and most DNS operations
apply only to resource records sets. For example, a resolver can not
directly request the DNSSEC subtype KEY RRs. Instead, the resolver
has to request all KEY RRs associated with a DNS name and then search
the set for the desired DNSSEC sub-type. DNSSEC signatures also
apply to the set of all KEY RRs associated with the DNS name,
regardless of sub-type.
In the case of the KEY RR, the inherent sub-type limitations are
exacerbated since the sub-type is used to distinguish between DNSSEC
keys and application keys. DNSSEC keys and application keys differ
in virtually every respect and Section 2.1 discusses these
differences in more detail. Combining these very different types of
keys into a single sub-typed resource record adds unnecessary
complexity and increases the potential for implementation and
deployment errors. Limited experimental deployment has shown that
application keys stored in KEY RRs are problematic.
This document addresses these issues by removing all application keys
from the KEY RR. Note that the scope of this document is strictly
limited to the KEY RR and this document does not endorse or restrict
the storage of application keys in other, yet undefined, resource
records.
Massey & Rose Standards Track [Page 2]
RFC 3445 Limiting the KEY Resource Record (RR) December 2002
2.1 Differences Between DNSSEC and Application Keys
DNSSEC keys are an essential part of the DNSSEC protocol and are used
by both name servers and resolvers in order to perform DNS tasks. A
DNS zone key, used to sign and authenticate RR sets, is the most
common example of a DNSSEC key. SIG(0) [4] and TKEY [3] also use
DNSSEC keys.
Application keys such as Email keys, IPSEC keys, and TLS keys are
simply another type of data. These keys have no special meaning to a
name server or resolver.
The following table summarizes some of the differences between DNSSEC
keys and application keys:
1. They serve different purposes.
2. They are managed by different administrators.
3. They are authenticated according to different rules.
4. Nameservers use different rules when including them in
responses.
5. Resolvers process them in different ways.
6. Faults/key compromises have different consequences.
1. The purpose of a DNSSEC key is to sign resource records
associated with a DNS zone (or generate DNS transaction signatures in
the case of SIG(0)/TKEY). But the purpose of an application key is
specific to the application. Application keys, such as PGP/email,
IPSEC, TLS, and SSH keys, are not a mandatory part of any zone and
the purpose and proper use of application keys is outside the scope
of DNS.
2. DNSSEC keys are managed by DNS administrators, but application
keys are managed by application administrators. The DNS zone
administrator determines the key lifetime, handles any suspected key
compromises, and manages any DNSSEC key changes. Likewise, the
application administrator is responsible for the same functions for
the application keys related to the application. For example, a user
typically manages her own PGP key and a server manages its own TLS
key. Application key management tasks are outside the scope of DNS
administration.
Massey & Rose Standards Track [Page 3]
RFC 3445 Limiting the KEY Resource Record (RR) December 2002
3. DNSSEC zone keys are used to authenticate application keys, but
by definition, application keys are not allowed to authenticate DNS
zone keys. A DNS zone key is either configured as a trusted key or
authenticated by constructing a chain of trust in the DNS hierarchy.
To participate in the chain of trust, a DNS zone needs to exchange
zone key information with its parent zone [3]. Application keys are
not configured as trusted keys in the DNS and are never part of any
DNS chain of trust. Application key data is not needed by the parent
and does not need to be exchanged with the parent zone for secure DNS
resolution to work. A resolver considers an application key RRset as
authenticated DNS information if it has a valid signature from the
local DNS zone keys, but applications could impose additional
security requirements before the application key is accepted as
authentic for use with the application.
4. It may be useful for nameservers to include DNS zone keys in the
additional section of a response, but application keys are typically
not useful unless they have been specifically requested. For
example, it could be useful to include the example.com zone key along
with a response that contains the www.example.com A record and SIG
record. A secure resolver will need the example.com zone key in
order to check the SIG and authenticate the www.example.com A record.
It is typically not useful to include the IPSEC, email, and TLS keys
along with the A record. Note that by placing application keys in
the KEY record, a resolver would need the IPSEC, email, TLS, and
other key associated with example.com if the resolver intends to
authenticate the example.com zone key (since signatures only apply to
the entire KEY RR set). Depending on the number of protocols
involved, the KEY RR set could grow unwieldy for resolvers, and DNS
administrators to manage.
5. DNS zone keys require special handling by resolvers, but
application keys are treated the same as any other type of DNS data.
The DNSSEC keys are of no value to end applications, unless the
applications plan to do their own DNS authentication. By definition,
secure resolvers are not allowed to use application keys as part of
the authentication process. Application keys have no unique meaning
to resolvers and are only useful to the application requesting the
key. Note that if sub-types are used to identify the application
key, then either the interface to the resolver needs to specify the
sub-type or the application needs to be able to accept all KEY RRs
and pick out the desired sub-type.
6. A fault or compromise of a DNS zone key can lead to invalid or
forged DNS data, but a fault or compromise of an application key
should have no impact on other DNS data. Incorrectly adding or
changing a DNS zone key can invalidate all of the DNS data in the
zone and in all of its subzones. By using a compromised key, an
Massey & Rose Standards Track [Page 4]
RFC 3445 Limiting the KEY Resource Record (RR) December 2002
attacker can forge data from the effected zone and for any of its
sub-zones. A fault or compromise of an application key has
implications for that application, but it should not have an impact
on the DNS. Note that application key faults and key compromises can
have an impact on the entire DNS if the application key and DNS zone
keys are both stored in the KEY RR.
In summary, DNSSEC keys and application keys differ in most every
respect. DNSSEC keys are an essential part of the DNS infrastructure
and require special handling by DNS administrators and DNS resolvers.
Application keys are simply another type of data and have no special
meaning to DNS administrators or resolvers. These two different
types of data do not belong in the same resource record.
3. Definition of the KEY RR
The KEY RR uses type 25 and is used as resource record for storing
DNSSEC keys. The RDATA for a KEY RR consists of flags, a protocol
octet, the algorithm number octet, and the public key itself. The
format is as follows:
---------------------------------------------------------------------
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | protocol | algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KEY RR Format
---------------------------------------------------------------------
In the flags field, all bits except bit 7 are reserved and MUST be
zero. If Bit 7 (Zone bit) is set to 1, then the KEY is a DNS Zone
key. If Bit 7 is set to 0, the KEY is not a zone key. SIG(0)/TKEY
are examples of DNSSEC keys that are not zone keys.
The protocol field MUST be set to 3.
The algorithm and public key fields are not changed.
Massey & Rose Standards Track [Page 5]
RFC 3445 Limiting the KEY Resource Record (RR) December 2002
4. Changes from RFC 2535 KEY RR
The KEY RDATA format is not changed.
All flags except for the zone key flag are eliminated:
The A/C bits (bits 0 and 1) are eliminated. They MUST be set to 0
and MUST be ignored by the receiver.
The extended flags bit (bit 3) is eliminated. It MUST be set to 0
and MUST be ignored by the receiver.
The host/user bit (bit 6) is eliminated. It MUST be set to 0 and
MUST be ignored by the receiver.
The zone bit (bit 7) remains unchanged.
The signatory field (bits 12-15) are eliminated by [5]. They MUST
be set to 0 and MUST be ignored by the receiver.
Bits 2,4,5,8,9,10,11 remain unchanged. They are reserved, MUST be
set to zero and MUST be ignored by the receiver.
Assignment of any future KEY RR Flag values requires a standards
action.
All Protocol Octet values except DNSSEC (3) are eliminated:
Value 1 (Email) is renamed to RESERVED.
Value 2 (IPSEC) is renamed to RESERVED.
Value 3 (DNSSEC) is unchanged.
Value 4 (TLS) is renamed to RESERVED.
Value 5-254 remains unchanged (reserved).
Value 255 (ANY) is renamed to RESERVED.
The authoritative data for a zone MUST NOT include any KEY records
with a protocol octet other than 3. The registry maintained by IANA
for protocol values is closed for new assignments.
Name servers and resolvers SHOULD accept KEY RR sets that contain KEY
RRs with a value other than 3. If out of date DNS zones contain
deprecated KEY RRs with a protocol octet value other than 3, then
simply dropping the deprecated KEY RRs from the KEY RR set would
Massey & Rose Standards Track [Page 6]
RFC 3445 Limiting the KEY Resource Record (RR) December 2002
invalidate any associated SIG record(s) and could create caching
consistency problems. Note that KEY RRs with a protocol octet value
other than 3 MUST NOT be used to authenticate DNS data.
The algorithm and public key fields are not changed.
5. Backward Compatibility
DNSSEC zone KEY RRs are not changed and remain backwards compatible.
A properly formatted RFC 2535 zone KEY would have all flag bits,
other than the Zone Bit (Bit 7), set to 0 and would have the Protocol
Octet set to 3. This remains true under the restricted KEY.
DNSSEC non-zone KEY RRs (SIG(0)/TKEY keys) are backwards compatible,
but the distinction between host and user keys (flag bit 6) is lost.
No backwards compatibility is provided for application keys. Any
Email, IPSEC, or TLS keys are now deprecated. Storing application
keys in the KEY RR created problems such as keys at the apex and
large RR sets and some change in the definition and/or usage of the
KEY RR would have been required even if the approach described here
were not adopted.
Overall, existing nameservers and resolvers will continue to
correctly process KEY RRs with a sub-type of DNSSEC keys.
6. Storing Application Keys in the DNS
The scope of this document is strictly limited to the KEY record.
This document prohibits storing application keys in the KEY record,
but it does not endorse or restrict the storing application keys in
other record types. Other documents can describe how DNS handles
application keys.
7. IANA Considerations
RFC 2535 created an IANA registry for DNS KEY RR Protocol Octet
values. Values 1, 2, 3, 4, and 255 were assigned by RFC 2535 and
values 5-254 were made available for assignment by IANA. This
document makes two sets of changes to this registry.
First, this document re-assigns DNS KEY RR Protocol Octet values 1,
2, 4, and 255 to "reserved". DNS Key RR Protocol Octet Value 3
remains unchanged as "DNSSEC".
Massey & Rose Standards Track [Page 7]
RFC 3445 Limiting the KEY Resource Record (RR) December 2002
Second, new values are no longer available for assignment by IANA and
this document closes the IANA registry for DNS KEY RR Protocol Octet
Values. Assignment of any future KEY RR Protocol Octet values
requires a standards action.
8. Security Considerations
This document eliminates potential security problems that could arise
due to the coupling of DNS zone keys and application keys. Prior to
the change described in this document, a correctly authenticated KEY
set could include both application keys and DNSSEC keys. This
document restricts the KEY RR to DNS security usage only. This is an
attempt to simplify the security model and make it less user-error
prone. If one of the application keys is compromised, it could be
used as a false zone key to create false DNS signatures (SIG
records). Resolvers that do not carefully check the KEY sub-type
could believe these false signatures and incorrectly authenticate DNS
data. With this change, application keys cannot appear in an
authenticated KEY set and this vulnerability is eliminated.
The format and correct usage of DNSSEC keys is not changed by this
document and no new security considerations are introduced.
9. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[3] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
2930, September 2000.
[4] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s)", RFC 2931, September 2000.
[5] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
Massey & Rose Standards Track [Page 8]
RFC 3445 Limiting the KEY Resource Record (RR) December 2002
10. Authors' Addresses
Dan Massey
USC Information Sciences Institute
3811 N. Fairfax Drive
Arlington, VA 22203
USA
EMail: masseyd@isi.edu
Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899-3460
USA
EMail: scott.rose@nist.gov
Massey & Rose Standards Track [Page 9]
RFC 3445 Limiting the KEY Resource Record (RR) December 2002
11. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
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.
Massey & Rose Standards Track [Page 10]

2187
doc/rfc/rfc3493.txt Normal file
View file

File diff suppressed because it is too large Load diff

12
lib/bind/port/cygwin/include/asm/socket.h Normal file
View file

@ -0,0 +1,12 @@
#ifndef _cygwin_asm_socket_h
#define _cygwin_asm_socket_h
#include_next <asm/socket.h>
/* This is a lame cop-out, but cygwin's SIOCGIFCONF doesn't define
IFF_POINTOPOINT, so this should never happen anyway. */
#ifndef SIOCGIFDSTADDR
# define SIOCGIFDSTADDR SIOCGIFADDR
#endif
#endif

2
lib/bind/port/cygwin/include/assert.h Normal file
View file

@ -0,0 +1,2 @@
#include <stdio.h>
#include_next <assert.h>

2
lib/bind/port/cygwin/include/paths.h Normal file
View file

@ -0,0 +1,2 @@
#define _PATH_DEVNULL "/dev/null"

144
lib/bind/port/cygwin/include/sys/cdefs.h Normal file
View file

@ -0,0 +1,144 @@
/*
* ++Copyright++ 1991, 1993
* -
* Copyright (c) 1991, 1993
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
* -
* Portions Copyright (c) 1993 by Digital Equipment Corporation.
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies, and that
* the name of Digital Equipment Corporation not be used in advertising or
* publicity pertaining to distribution of the document or software without
* specific, written prior permission.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
* WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT
* CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
* DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
* PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
* ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
* SOFTWARE.
* -
* --Copyright--
*/
/*
* @(#)cdefs.h 8.1 (Berkeley) 6/2/93
* $Id: cdefs.h,v 1.1 2002/12/27 03:13:51 marka Exp $
*/
#ifndef _CDEFS_H_
#define _CDEFS_H_
#if defined(__cplusplus)
#define __BEGIN_DECLS extern "C" {
#define __END_DECLS };
#else
#define __BEGIN_DECLS
#define __END_DECLS
#endif
/*
* The __CONCAT macro is used to concatenate parts of symbol names, e.g.
* with "#define OLD(foo) __CONCAT(old,foo)", OLD(foo) produces oldfoo.
* The __CONCAT macro is a bit tricky -- make sure you don't put spaces
* in between its arguments. __CONCAT can also concatenate double-quoted
* strings produced by the __STRING macro, but this only works with ANSI C.
*/
#if defined(__STDC__) || defined(__cplusplus)
#define __P(protos) protos /* full-blown ANSI C */
#define __CONCAT(x,y) x ## y
#define __STRING(x) #x
#define __const const /* define reserved names to standard */
#define __signed signed
#define __volatile volatile
#if defined(__cplusplus)
#define __inline inline /* convert to C++ keyword */
#else
#ifndef __GNUC__
#define __inline /* delete GCC keyword */
#endif /* !__GNUC__ */
#endif /* !__cplusplus */
#else /* !(__STDC__ || __cplusplus) */
#define __P(protos) () /* traditional C preprocessor */
#define __CONCAT(x,y) x/**/y
#define __STRING(x) "x"
#ifndef __GNUC__
#define __const /* delete pseudo-ANSI C keywords */
#define __inline
#define __signed
#define __volatile
/*
* In non-ANSI C environments, new programs will want ANSI-only C keywords
* deleted from the program and old programs will want them left alone.
* When using a compiler other than gcc, programs using the ANSI C keywords
* const, inline etc. as normal identifiers should define -DNO_ANSI_KEYWORDS.
* When using "gcc -traditional", we assume that this is the intent; if
* __GNUC__ is defined but __STDC__ is not, we leave the new keywords alone.
*/
#ifndef NO_ANSI_KEYWORDS
#define const /* delete ANSI C keywords */
#define inline
#define signed
#define volatile
#endif
#endif /* !__GNUC__ */
#endif /* !(__STDC__ || __cplusplus) */
/*
* GCC1 and some versions of GCC2 declare dead (non-returning) and
* pure (no side effects) functions using "volatile" and "const";
* unfortunately, these then cause warnings under "-ansi -pedantic".
* GCC2 uses a new, peculiar __attribute__((attrs)) style. All of
* these work for GNU C++ (modulo a slight glitch in the C++ grammar
* in the distribution version of 2.5.5).
*/
#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5
#define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */
#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
#define __dead __volatile
#define __pure __const
#endif
#endif
/* Delete pseudo-keywords wherever they are not available or needed. */
#ifndef __dead
#define __dead
#define __pure
#endif
#endif /* !_CDEFS_H_ */

10
lib/bind/port/cygwin/include/sys/socket.h Normal file
View file

@ -0,0 +1,10 @@
#ifndef _cygwin_sys_socket_h
#define _cygwin_sys_socket_h
#include_next <sys/socket.h>
#ifndef IFF_POINTOPOINT
# define IFF_POINTOPOINT 0x10
#endif
#endif

9
lib/bind/port/cygwin/include/sys/wait.h Normal file
View file

@ -0,0 +1,9 @@
#ifndef _cygwin_sys_wait_h
#include_next <sys/wait.h>
#if !defined (WCOREDUMP)
# define WCOREDUMP(x) (((x) & 0x80) == 0x80)
#endif
#endif

71
lib/isc/win32/include/isc/win32os.h Normal file
View file

@ -0,0 +1,71 @@
/*
* Copyright (C) 2002 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM
* DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
* INTERNET SOFTWARE CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT,
* INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING
* FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
* NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
* WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: win32os.h,v 1.2 2002/08/03 01:36:24 mayer Exp $ */
#ifndef ISC_WIN32OS_H
#define ISC_WIN32OS_H 1
#include <isc/lang.h>
ISC_LANG_BEGINDECLS
/*
* Return the number of CPUs available on the system, or 1 if this cannot
* be determined.
*/
unsigned int
isc_win32os_majorversion(void);
/*
* Major Version of the O/S.
*/
unsigned int
isc_win32os_minorversion(void);
/*
* Minor Version of the O/S.
*/
unsigned int
isc_win32os_servicepackmajor(void);
/*
* Major Version of the Service Pack for O/S.
*/
unsigned int
isc_win32os_servicepackminor(void);
/*
* Minor Version of the Service Pack for O/S.
*/
int
isc_win32os_versioncheck(unsigned int major, unsigned int minor,
unsigned int updatemajor, unsigned int updateminor);
/*
* Checks the current version of the operating system with the
* supplied version information.
* Returns:
* -1 if less than the version information supplied
* 0 if equal to all of the version information supplied
* +1 if greater than the version information supplied
*/
ISC_LANG_ENDDECLS
#endif /* ISC_OS_H */

459
lib/isc/win32/strerror.c Normal file
View file

@ -0,0 +1,459 @@
/*
* Copyright (C) 2002 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM
* DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
* INTERNET SOFTWARE CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT,
* INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING
* FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
* NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
* WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: strerror.c,v 1.5 2002/08/01 03:52:14 mayer Exp $ */
#include <config.h>
#include <stdio.h>
#include <string.h>
#include <winsock2.h>
#include <isc/mutex.h>
#include <isc/once.h>
#include <isc/print.h>
#include <isc/strerror.h>
#include <isc/util.h>
/*
* Forward declarations
*/
char *
FormatError(int error);
char *
GetWSAErrorMessage(int errval);
char *
NTstrerror(int err, BOOL *bfreebuf);
/*
* We need to do this this way for profiled locks.
*/
static isc_mutex_t isc_strerror_lock;
static void init_lock(void) {
RUNTIME_CHECK(isc_mutex_init(&isc_strerror_lock) == ISC_R_SUCCESS);
}
/*
* This routine needs to free up any buffer allocated by FormatMessage
* if that routine gets used.
*/
void
isc__strerror(int num, char *buf, size_t size) {
char *msg;
BOOL freebuf;
unsigned int unum = num;
static isc_once_t once = ISC_ONCE_INIT;
REQUIRE(buf != NULL);
RUNTIME_CHECK(isc_once_do(&once, init_lock) == ISC_R_SUCCESS);
LOCK(&isc_strerror_lock);
freebuf = FALSE;
msg = NTstrerror(num, &freebuf);
if (msg != NULL)
snprintf(buf, size, "%s", msg);
else
snprintf(buf, size, "Unknown error: %u", unum);
if(freebuf && msg != NULL) {
LocalFree(msg);
}
UNLOCK(&isc_strerror_lock);
}
/*
* Note this will cause a memory leak unless the memory allocated here
* is freed by calling LocalFree. isc__strerror does this before unlocking.
* This only gets called if there is a system type of error and will likely
* be an unusual event.
*/
char *
FormatError(int error) {
LPVOID lpMsgBuf = NULL;
FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER |
FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
error,
/* Default language */
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
(LPTSTR) &lpMsgBuf,
0,
NULL);
return (lpMsgBuf);
}
/*
* This routine checks the error value and calls the WSA Windows Sockets
* Error message function GetWSAErrorMessage below if it's within that range
* since those messages are not available in the system error messages.
*/
char *
NTstrerror(int err, BOOL *bfreebuf) {
char *retmsg = NULL;
/* Copy the error value first in case of other errors */
DWORD errval = err;
*bfreebuf = FALSE;
/* Get the Winsock2 error messages */
if (errval >= WSABASEERR && errval <= (WSABASEERR + 1015)) {
retmsg = GetWSAErrorMessage(errval);
if (retmsg != NULL)
return (retmsg);
}
/*
* If it's not one of the standard Unix error codes,
* try a system error message
*/
if (errval > (DWORD) _sys_nerr) {
*bfreebuf = TRUE;
return (FormatError(errval));
} else {
return (strerror(errval));
}
}
/*
* This is a replacement for perror
*/
void __cdecl
NTperror(char *errmsg) {
/* Copy the error value first in case of other errors */
int errval = errno;
BOOL bfreebuf = FALSE;
char *msg;
msg = NTstrerror(errval, &bfreebuf);
fprintf(stderr, "%s: %s\n", errmsg, msg);
if(bfreebuf == TRUE) {
LocalFree(msg);
}
}
/*
* Return the error string related to Winsock2 errors.
* This function is necessary since FormatMessage knows nothing about them
* and there is no function to get them.
*/
char *
GetWSAErrorMessage(int errval) {
char *msg;
switch (errval) {
case WSAEINTR:
msg = "Interrupted system call";
break;
case WSAEBADF:
msg = "Bad file number";
break;
case WSAEACCES:
msg = "Permission denied";
break;
case WSAEFAULT:
msg = "Bad address";
break;
case WSAEINVAL:
msg = "Invalid argument";
break;
case WSAEMFILE:
msg = "Too many open sockets";
break;
case WSAEWOULDBLOCK:
msg = "Operation would block";
break;
case WSAEINPROGRESS:
msg = "Operation now in progress";
break;
case WSAEALREADY:
msg = "Operation already in progress";
break;
case WSAENOTSOCK:
msg = "Socket operation on non-socket";
break;
case WSAEDESTADDRREQ:
msg = "Destination address required";
break;
case WSAEMSGSIZE:
msg = "Message too long";
break;
case WSAEPROTOTYPE:
msg = "Protocol wrong type for socket";
break;
case WSAENOPROTOOPT:
msg = "Bad protocol option";
break;
case WSAEPROTONOSUPPORT:
msg = "Protocol not supported";
break;
case WSAESOCKTNOSUPPORT:
msg = "Socket type not supported";
break;
case WSAEOPNOTSUPP:
msg = "Operation not supported on socket";
break;
case WSAEPFNOSUPPORT:
msg = "Protocol family not supported";
break;
case WSAEAFNOSUPPORT:
msg = "Address family not supported";
break;
case WSAEADDRINUSE:
msg = "Address already in use";
break;
case WSAEADDRNOTAVAIL:
msg = "Can't assign requested address";
break;
case WSAENETDOWN:
msg = "Network is down";
break;
case WSAENETUNREACH:
msg = "Network is unreachable";
break;
case WSAENETRESET:
msg = "Net connection reset";
break;
case WSAECONNABORTED:
msg = "Software caused connection abort";
break;
case WSAECONNRESET:
msg = "Connection reset by peer";
break;
case WSAENOBUFS:
msg = "No buffer space available";
break;
case WSAEISCONN:
msg = "Socket is already connected";
break;
case WSAENOTCONN:
msg = "Socket is not connected";
break;
case WSAESHUTDOWN:
msg = "Can't send after socket shutdown";
break;
case WSAETOOMANYREFS:
msg = "Too many references: can't splice";
break;
case WSAETIMEDOUT:
msg = "Connection timed out";
break;
case WSAECONNREFUSED:
msg = "Connection refused";
break;
case WSAELOOP:
msg = "Too many levels of symbolic links";
break;
case WSAENAMETOOLONG:
msg = "File name too long";
break;
case WSAEHOSTDOWN:
msg = "Host is down";
break;
case WSAEHOSTUNREACH:
msg = "No route to host";
break;
case WSAENOTEMPTY:
msg = "Directory not empty";
break;
case WSAEPROCLIM:
msg = "Too many processes";
break;
case WSAEUSERS:
msg = "Too many users";
break;
case WSAEDQUOT:
msg = "Disc quota exceeded";
break;
case WSAESTALE:
msg = "Stale NFS file handle";
break;
case WSAEREMOTE:
msg = "Too many levels of remote in path";
break;
case WSASYSNOTREADY:
msg = "Network system is unavailable";
break;
case WSAVERNOTSUPPORTED:
msg = "Winsock version out of range";
break;
case WSANOTINITIALISED:
msg = "WSAStartup not yet called";
break;
case WSAEDISCON:
msg = "Graceful shutdown in progress";
break;
/*
case WSAHOST_NOT_FOUND:
msg = "Host not found";
break;
case WSANO_DATA:
msg = "No host data of that type was found";
break;
*/
default:
msg = NULL;
break;
}
return (msg);
}
/*
* These error messages are more informative about CryptAPI Errors than the
* standard error messages
*/
char *
GetCryptErrorMessage(int errval) {
char *msg;
switch (errval) {
case NTE_BAD_FLAGS:
msg = "The dwFlags parameter has an illegal value.";
break;
case NTE_BAD_KEYSET:
msg = "The Registry entry for the key container "
"could not be opened and may not exist.";
break;
case NTE_BAD_KEYSET_PARAM:
msg = "The pszContainer or pszProvider parameter "
"is set to an illegal value.";
break;
case NTE_BAD_PROV_TYPE:
msg = "The value of the dwProvType parameter is out "
"of range. All provider types must be from "
"1 to 999, inclusive.";
break;
case NTE_BAD_SIGNATURE:
msg = "The provider DLL signature did not verify "
"correctly. Either the DLL or the digital "
"signature has been tampered with.";
break;
case NTE_EXISTS:
msg = "The dwFlags parameter is CRYPT_NEWKEYSET, but the key"
" container already exists.";
break;
case NTE_KEYSET_ENTRY_BAD:
msg = "The Registry entry for the pszContainer key container "
"was found (in the HKEY_CURRENT_USER window), but is "
"corrupt. See the section System Administration for "
" etails about CryptoAPI's Registry usage.";
break;
case NTE_KEYSET_NOT_DEF:
msg = "No Registry entry exists in the HKEY_CURRENT_USER "
"window for the key container specified by "
"pszContainer.";
break;
case NTE_NO_MEMORY:
msg = "The CSP ran out of memory during the operation.";
break;
case NTE_PROV_DLL_NOT_FOUND:
msg = "The provider DLL file does not exist or is not on the "
"current path.";
break;
case NTE_PROV_TYPE_ENTRY_BAD:
msg = "The Registry entry for the provider type specified by "
"dwProvType is corrupt. This error may relate to "
"either the user default CSP list or the machine "
"default CSP list. See the section System "
"Administration for details about CryptoAPI's "
"Registry usage.";
break;
case NTE_PROV_TYPE_NO_MATCH:
msg = "The provider type specified by dwProvType does not "
"match the provider type found in the Registry. Note "
"that this error can only occur when pszProvider "
"specifies an actual CSP name.";
break;
case NTE_PROV_TYPE_NOT_DEF:
msg = "No Registry entry exists for the provider type "
"specified by dwProvType.";
break;
case NTE_PROVIDER_DLL_FAIL:
msg = "The provider DLL file could not be loaded, and "
"may not exist. If it exists, then the file is "
"not a valid DLL.";
break;
case NTE_SIGNATURE_FILE_BAD:
msg = "An error occurred while loading the DLL file image, "
"prior to verifying its signature.";
break;
default:
msg = NULL;
break;
}
return msg;
}

101
lib/isc/win32/win32os.c Normal file
View file

@ -0,0 +1,101 @@
/*
* Copyright (C) 2002 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM
* DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
* INTERNET SOFTWARE CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT,
* INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING
* FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
* NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
* WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: win32os.c,v 1.2 2002/08/03 01:36:24 mayer Exp $ */
#include <windows.h>
#include <isc/win32os.h>
static BOOL bInit = FALSE;
static OSVERSIONINFOEX osVer;
static void
initialize_action(void) {
BOOL bSuccess;
if (bInit)
return;
/*
* NOTE: VC++ 6.0 gets this function declaration wrong
* so we compensate by casting the argument
*/
osVer.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);
bSuccess = GetVersionEx((OSVERSIONINFO *) &osVer);
/*
* Versions of NT before NT4.0 SP6 did not return the
* extra info that the EX structure provides and returns
* a failure so we need to retry with the old structure.
*/
if(!bSuccess) {
osVer.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
bSuccess = GetVersionEx((OSVERSIONINFO *) &osVer);
}
bInit = TRUE;
}
unsigned int
isc_win32os_majorversion(void) {
initialize_action();
return ((unsigned int)osVer.dwMajorVersion);
}
unsigned int
isc_win32os_minorversion(void) {
initialize_action();
return ((unsigned int)osVer.dwMinorVersion);
}
unsigned int
isc_win32os_servicepackmajor(void) {
initialize_action();
return ((unsigned int)osVer.wServicePackMajor);
}
unsigned int
isc_win32os_servicepackminor(void) {
initialize_action();
return ((unsigned int)osVer.wServicePackMinor);
}
int
isc_win32os_versioncheck(unsigned int major, unsigned int minor,
unsigned int spmajor, unsigned int spminor) {
initialize_action();
if (major < isc_win32os_majorversion())
return (1);
if (major > isc_win32os_majorversion())
return (-1);
if (minor < isc_win32os_minorversion())
return (1);
if (minor > isc_win32os_minorversion())
return (-1);
if (spmajor < isc_win32os_servicepackmajor())
return (1);
if (spmajor > isc_win32os_servicepackmajor())
return (-1);
if (spminor < isc_win32os_servicepackminor())
return (1);
if (spminor > isc_win32os_servicepackminor())
return (-1);
/* Exact */
return (0);
}