draft-iab-dns-choices-00.txt   draft-iab-dns-choices-01.txt 
Network Working Group P. Faltstrom Network Working Group P. Faltstrom
Internet-Draft R. Austein Internet-Draft R. Austein
Expires: April 11, 2005 IAB Expires: September 5, 2005 IAB
October 11, 2004 March 7, 2005
Design Choices When Expanding DNS Design Choices When Expanding DNS
draft-iab-dns-choices-00.txt draft-iab-dns-choices-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 11, 2005. This Internet-Draft will expire on September 5, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This note discusses how to extend the DNS with new data for a new This note discusses how to extend the DNS with new data for a new
application. DNS extension discussion too often circulate around application. DNS extension discussion too often circulates around
reuse of the TXT record. This document lists different mechanisms to reuse of the TXT record. This document lists different mechanisms to
accomplish the extension to DNS, and comes to the conclusion use of a accomplish the extension to DNS, and comes to the conclusion that the
new RR Type is the best solution. use of a new RR Type is the best solution.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Extension mechanisms . . . . . . . . . . . . . . . . . . . . . 4 3. Extension mechanisms . . . . . . . . . . . . . . . . . . . . . 4
3.1 Place selectors inside the RDATA . . . . . . . . . . . . . 4 3.1 Place selectors inside the RDATA . . . . . . . . . . . . . 4
3.2 Add a prefix to the owner name . . . . . . . . . . . . . . 4 3.2 Add a prefix to the owner name . . . . . . . . . . . . . . 5
3.3 Add a suffix to the owner name . . . . . . . . . . . . . . 5 3.3 Add a suffix to the owner name . . . . . . . . . . . . . . 6
3.4 Add a new Class . . . . . . . . . . . . . . . . . . . . . 5 3.4 Add a new Class . . . . . . . . . . . . . . . . . . . . . 6
3.5 Add a new Resource Record Type . . . . . . . . . . . . . . 6 3.5 Add a new Resource Record Type . . . . . . . . . . . . . . 7
4. Conclusion (why adding a new RR type is the answer) . . . . . 7 4. Conclusion (why adding a new RR type is the answer) . . . . . 8
5. Conclusion and Recommendation . . . . . . . . . . . . . . . . 9 5. Conclusion and Recommendation . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12 8.2 Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 13
1. Introduction 1. Introduction
The DNS stores multiple categories of data. The two most commonly The DNS stores multiple categories of data. The two most commonly
used categories are infrastructure data for the DNS system itself (NS used categories are infrastructure data for the DNS system itself (NS
and SOA records) and data which have to do with mappings between and SOA records) and data which have to do with mappings between
domain names and IP addresses (A, AAAA and PTR). There are other domain names and IP addresses (A, AAAA and PTR). There are other
categories as well, some of which are tied to specific applications categories as well, some of which are tied to specific applications
like email (MX), while others are generic record types used to convey like email (MX), while others are generic record types used to convey
information for multiple protocols (SRV, NAPTR). information for multiple protocols (SRV, NAPTR).
When storing data in the DNS for a new application, the data are When storing data in the DNS for a new application, the data are
usually tied to a "normal" domain name, so the application can query usually tied to a "normal" domain name, so the application can query
for the data it wants, while minimizing the impact on existing for the data it wants, while minimizing the impact on existing
applications. applications.
Historically, extension of DNS to store data for applications tied to Historically, extending DNS to store data for applications tied to a
a domain name has been done in different ways at different times. MX domain name has been done in different ways at different times. MX
records were created as a new resource record type specifically records were created as a new resource record type specifically
designed to support electronic mail. SRV records are a generic type designed to support electronic mail. SRV records are a generic type
which use a prefixing scheme in combination with a base domain name. which use a prefixing scheme in combination with a base domain name.
Records associated with ENUM use a suffixing scheme. NAPTR records Records associated with ENUM use a suffixing scheme. NAPTR records
add selection data inside the RDATA. It is clear the way of adding add selection data inside the RDATA. It is clear the way of adding
new data to the DNS has been inconsistent, and the purpose of this new data to the DNS has been inconsistent, and the purpose of this
document is to attempt to clarify the implications of each of these document is to attempt to clarify the implications of each of these
methods, both for the applications that use them and for the rest of methods, both for the applications that use them and for the rest of
the DNS system. the DNS system.
Many parts of this document talk about use of wildcards, and many
people might think use of wildcards is not something that happens
today. In reality thoug, wildcards are in use, especially for some
specific usages like MX records. Because of this, the choice have to
be made with existence of wildcards in mind.
Another overall issue that have to be taken into account is what the
new data in DNS is to describe. In some cases it might be completely
new data. In other cases it might be meta-data that is tied to data
that already exists in the DNS. Example of new data is key
information for SSH and data used for fighting spam (meta data that
is connected to the MX record). If the new data has connection to
data that already exists in DNS, an analysis should be made whether
having (for example) A record and SSH key information in different
zones is a problem, and if it is, whether the owner for the records
by design must be the same for both records.
This document do not talk about what one should store in DNS.
Whether DNS is used for service discovery, or whether DNS is (also)
used for storage of application specific data. In general, DNS is a
protocol that part from holding metadata that makes DNS itself
function (NS, SOA, DS RR Types etc) only holds references to where
services are located (SRV, NAPTR, A, AAAA RR types).
2. Background 2. Background
See RFC 2929 [RFC2929] for a brief summary of DNS query structure. See RFC 2929 [RFC2929] for a brief summary of DNS query structure.
Readers interested in the full story should start with the base DNS Readers interested in the full story should start with the base DNS
specification in RFC 1035 [RFC1035], and continue with the various specification in RFC 1035 [RFC1035], and continue with the various
documents which update, clarify, and extend the base specification. documents which update, clarify, and extend the base specification.
When composing a query into the DNS system, the parameters actually When composing a query into the DNS system, the parameters actually
used by the protocol are a triple: a DNS name, a DNS class, and a DNS used by the protocol are a triple: a DNS name, a DNS class, and a DNS
record type. Every resource record (RR) matching a particular name, record type. Every resource record (RR) matching a particular name,
type and class is said to belong to the same resource record set type and class is said to belong to the same resource record set
(RRset), and the whole RRset is always returned to the client which (RRSet), and the whole RRSet is always returned to the client which
queries for it. Splitting an RRset is a protocol violation, because queries for it. Splitting an RRSet is a protocol violation, because
it results in coherency problems with the DNS caching mechanism. it results in coherency problems with the DNS caching mechanism.
Note however that this requirement has nothing to do with the MTU Note however that this requirement has nothing to do with the MTU
size and choice of UDP or TCP as the transport protocol. The whole size and choice of UDP or TCP as the transport protocol. The whole
RRset always has to be returned, and if it doesn't fit in the MTU in RRSet always has to be returned, and if it doesn't fit in the MTU in
UDP, TCP has to be used to not break this RRset atomic requirement. UDP, TCP has to be used to not break this RRSet atomic requirement.
3. Extension mechanisms 3. Extension mechanisms
The DNS protocol is intended to be extensible to support new kinds of The DNS protocol is intended to be extensible to support new kinds of
data. This section examines the various ways in which this sort of data. This section examines the various ways in which this sort of
extension can be accomplished. extension can be accomplished.
3.1 Place selectors inside the RDATA 3.1 Place selectors inside the RDATA
For a given query name, one might choose to have a single RRset (all For a given query name, one might choose to have a single RRSet (all
sharing the same name, type, and class) shared by multiple sharing the same name, type, and class) shared by multiple
applications, and have the different applications use selectors applications, and have the different applications use selectors
within the RR data (RDATA) to determine which records are intended within the RR data (RDATA) to determine which records are intended
for which applications. This sort of selector mechanism is usually for which applications. This sort of selector mechanism is usually
referred to "subtyping", because it is in effect creating an referred to "subtyping", because it is in effect creating an
additional type subsystem within a single DNS RR type. additional type subsystem within a single DNS RR type.
Examples of subtyping include NAPTR RRs (see RFC 2916 [RFC2916]) and Examples of subtyping include NAPTR RRs (see RFC 3761 [RFC3761]) and
the original DNSSEC KEY RR type (RFC 2535 [RFC2535]) (before it was the original DNSSEC KEY RR type (RFC 2535 [RFC2535]) (before it was
updated by RFC 3445 [RFC3445]). updated by RFC 3445 [RFC3445]).
All DNS subtyping schemes share a common weakness: With subtyping All DNS subtyping schemes share a common weakness: With subtyping
schemes it is impossible for a client to query for just the data it schemes it is impossible for a client to query for just the data it
wants. Instead, the client must fetch the entire RRset, then select wants. Instead, the client must fetch the entire RRSet, then select
the RRs in which it is interested. Furthermore, since DNSSEC the RRs in which it is interested. Furthermore, since DNSSEC
signatures operate on complete RRsets, the entire RRset must be signatures operate on complete RRSets, the entire RRSet must be
re-signed if any RR in it changes. As a result, each application re-signed if any RR in it changes. As a result, each application
that uses a subtyped RR incurs higher overhead than any of the that uses a subtyped RR incurs higher overhead than any of the
applications would have incurred had they not been using a subtyping applications would have incurred had they not been using a subtyping
scheme. The fact the RRset is always passed around as an indivisible scheme. The fact the RRSet is always passed around as an indivisible
unit increases the risk the RRset will not fit in a UDP packet, which unit increases the risk the RRSet will not fit in a UDP packet, which
in turn increases the risk that the client will have to retry the in turn increases the risk that the client will have to retry the
query with TCP, which substantially increases the load on the name query with TCP, which substantially increases the load on the name
server. More precisely: Having one query fail over to TCP is not a server. More precisely: Having one query fail over to TCP is not a
big deal, but since the typical ratio of clients to servers in the big deal, but since the typical ratio of clients to servers in the
DNS system is very high, having a substantial number of DNS messages DNS system is very high, having a substantial number of DNS messages
fail over to TCP it will cause the relevant name servers to be fail over to TCP it will cause the relevant name servers to be
overloaded by TCP overhead. overloaded by TCP overhead.
The final result of using a subtyping scheme might be that the zone The final result of using a subtyping scheme might be that the zone
administrator has to choose which of the services tied to one domain administrator has to choose which of the services tied to one domain
name can actually be used, because not all of them can be announced name can actually be used, because not all of them can be announced
at the same time. at the same time.
3.2 Add a prefix to the owner name 3.2 Add a prefix to the owner name
By adding an application-specific prefix to a domain name, we will By adding an application-specific prefix to a domain name, we will
get different name/class/type triples, and therefore different get different name/class/type triples, and therefore different
RRsets. The problem with adding prefixes has to do with wildcards, RRSets. One problem with adding prefixes has to do with wildcards,
especially if one has records like especially if one has records like
*.example.com. IN MX 1 mail.example.com. *.example.com. IN MX 1 mail.example.com.
and one wants records tied to those names. Suppose one creates the and one wants records tied to those names. Suppose one creates the
prefix "_mail". One would then have to say something like prefix "_mail". One would then have to say something like
_mail.*.example.com. IN X-FOO A B C D _mail.*.example.com. IN X-FOO A B C D
but DNS wildcards only work with the "*" as the leftmost token in the but DNS wildcards only work with the "*" as the leftmost token in the
domain name. domain name.
Even when a specific prefix is chosen, the data will still have to be Even when a specific prefix is chosen, the data will still have to be
stored in some RR type. This RR type can either be a "kitchen-sink stored in some RR type. This RR type can either be a record type
record" or a new RR type. This implies that some other mechanism has that can store arbitrary data or a new RR type. This implies that
to be applied as well, with implications detailed in other parts of some other selection mechanism has to be applied as well, such as
this note (see also draft-ietf-dnsext-wcard-clarify [wcardclarify] ability to distinguish between the records in an RR set given they
regarding use of wildcards and DNS). have the same RR Type (see also draft-ietf-dnsext-wcard-clarify
[wcardclarify] regarding use of wildcards and DNS). Because of this
one need to register both a unique prefix and define what RR type is
to be used for this specific service.
If the record has some relationship with another record, the fact the
original record and this with a prefix can be in different zones
might have implications on the trust in the application have on the
records. Example:
example.com. IN X-FOO "some good thing"
_foo.example.com. IN X-BAR "why the good thing is good"
In this example, the two records might be in two different zones, and
because of this signed by two different organizations when using
DNSSEC.
3.3 Add a suffix to the owner name 3.3 Add a suffix to the owner name
Adding a suffix to a domain name changes the name/class/type triple, Adding a suffix to a domain name changes the name/class/type triple,
and therefore the RRset. The query name can be set to exactly the and therefore the RRSet. The query name can be set to exactly the
data one wants, and the size of the RRset is minimized. The problem data one wants, and the size of the RRSet is minimized. The problem
with adding a suffix is that it creates a parallel tree within the IN with adding a suffix is that it creates a parallel tree within the IN
class. There will be no technical mechanism to ensure that the class. There will be no technical mechanism to ensure that the
delegation for "example.com" and "example.com._bar" are made to the delegation for "example.com" and "example.com._bar" are made to the
same organization. Furthermore, data associated with a single entity same organization. Furthermore, data associated with a single entity
will now be stored in two different zones, such as "example.com" and will now be stored in two different zones, such as "example.com" and
"example.com._bar", which, depending on who controls "_bar", can "example.com._bar", which, depending on who controls "_bar", can
create new synchronization and update authorization issues. create new synchronization and update authorization issues.
Even when using a different name, the data will still have to be Even when using a different name, the data will still have to be
stored in some RR type. This RR type can either be a "kitchen-sink stored in some RR type. This RR type can either be a "kitchen-sink
skipping to change at page 7, line 37 skipping to change at page 8, line 29
application needs to the DNS in a way that naturally associates the application needs to the DNS in a way that naturally associates the
data with a DNS name. data with a DNS name.
As explained in Section 3.4, using the DNS class system as an As explained in Section 3.4, using the DNS class system as an
extension mechanism is not really an option, and in fact most users extension mechanism is not really an option, and in fact most users
of the system don't even realize that the mechanism exists. As a of the system don't even realize that the mechanism exists. As a
practical matter, therefore any extension is likely to be within the practical matter, therefore any extension is likely to be within the
IN class. IN class.
Adding a new RR type is the technically correct answer from the DNS Adding a new RR type is the technically correct answer from the DNS
protocol standpoint (more on this below), doing so requires some DNS protocol standpoint (more on this below), but doing so requires some
expertise, due to the issues listed in Section 3.5. As a result, DNS expertise, due to the issues listed in Section 3.5. As a result,
this option is usually considered too hard. this option is usually considered too hard. Note that according to
RFC2929 [RFC2929], some types require IETF Consensus, while others
only require a specification.
The application designer is thus left with the prospect of reusing The application designer is thus left with the prospect of reusing
some existing DNS type within the IN class, but when the designer some existing DNS type within the IN class, but when the designer
looks at the existing types, almost all of them have well-defined looks at the existing types, almost all of them have well-defined
semantics, none of which quite match the needs of the new semantics, none of which quite match the needs of the new
application. This has not completely prevented proposals to reuse application. This has not completely prevented proposals to reuse
existing RR types in ways incompatible with their defined semantics, existing RR types in ways incompatible with their defined semantics,
but it does tend to steer application designers away from this but it does tend to steer application designers away from this
approach. approach.
skipping to change at page 9, line 18 skipping to change at page 10, line 11
schemes do little good here, because, from the server's perspective, schemes do little good here, because, from the server's perspective,
there isn't enough repeat traffic from any one client for it to be there isn't enough repeat traffic from any one client for it to be
worth retaining state. UDP-based DNS is an idempotent query, whereas worth retaining state. UDP-based DNS is an idempotent query, whereas
TCP-based DNS requires the server to keep state (in the form of TCP TCP-based DNS requires the server to keep state (in the form of TCP
connection state, usually in the server's kernel) and roughly triples connection state, usually in the server's kernel) and roughly triples
the traffic load. Thus, there's a strong incentive to keep DNS the traffic load. Thus, there's a strong incentive to keep DNS
messages short enough to fit in a UDP datagram, preferably a UDP messages short enough to fit in a UDP datagram, preferably a UDP
datagram short enough not to require IP fragmentation. datagram short enough not to require IP fragmentation.
Subtyping schemes are therefore again problematic, because they Subtyping schemes are therefore again problematic, because they
produce larger RRsets than necessary, but verbose text encodings of produce larger RRSets than necessary, but verbose text encodings of
data are also wasteful, since the data they hold can usually be data are also wasteful, since the data they hold can usually be
represented more compactly in a resource record designed specifically represented more compactly in a resource record designed specifically
to support the application's particular data needs. If the data that to support the application's particular data needs. If the data that
need to be carried are so large that there is no way to make them fit need to be carried are so large that there is no way to make them fit
comfortably into the DNS regardless of encoding, it is probably comfortably into the DNS regardless of encoding, it is probably
better to move the data somewhere else, and just use the DNS as a better to move the data somewhere else, and just use the DNS as a
pointer to the data, as with NAPTR. pointer to the data, as with NAPTR.
5. Conclusion and Recommendation 5. Conclusion and Recommendation
skipping to change at page 10, line 19 skipping to change at page 11, line 13
mechanism designed for precisely this purpose, and mechanism designed for precisely this purpose, and
o of all the alternate solutions, the "obvious" approach of using o of all the alternate solutions, the "obvious" approach of using
TXT RRs is almost certainly the worst. TXT RRs is almost certainly the worst.
6. IANA Considerations 6. IANA Considerations
This document does not require any IANA actions. This document does not require any IANA actions.
7. Security Considerations 7. Security Considerations
DNS RRsets can be signed using DNSSEC. DNSSEC is almost certainly DNS RRSets can be signed using DNSSEC. DNSSEC is almost certainly
necessary for any application mechanism that stores authorization necessary for any application mechanism that stores authorization
data in the DNS itself. DNSSEC signatures significantly increase the data in the DNS itself. DNSSEC signatures significantly increase the
size of the messages transported, and because of this, the DNS size of the messages transported, and because of this, the DNS
message size issues discussed in Section 3.1 and Section 4 are more message size issues discussed in Section 3.1 and Section 4 are more
serious than they might at first appear. serious than they might at first appear.
Adding new RR types (as discussed in Section 3.5) might conceivably Adding new RR types (as discussed in Section 3.5) might conceivably
trigger bugs and other bad behavior in software which is not trigger bugs and other bad behavior in software which is not
compliant with RFC 3597 [RFC3597], but most such software is old compliant with RFC 3597 [RFC3597], but most such software is old
enough and insecure enough that it should be updated for other enough and insecure enough that it should be updated for other
reasons in any case. Basic API support for retrieving arbitrary RR reasons in any case. Basic API support for retrieving arbitrary RR
types has been a requirement since 1989 (see RFC 1123 [RFC1123]). types has been a requirement since 1989 (see RFC 1123 [RFC1123]).
Any new protocol that proposes to use the DNS to store data used to Any new protocol that proposes to use the DNS to store data used to
make authorization decisions would be well advised not only to use make authorization decisions would be well advised not only to use
DNSSEC but also to encourage upgrades to DNS server software recent DNSSEC but also to encourage upgrades to DNS server software recent
enough not to be riddled with well-known exploitable bugs. Because enough not to be riddled with well-known exploitable bugs. Because
of this, support for new RR Types will not be as hard as people might of this, support for new RR Types will not be as hard as people might
think at first. think at first.
8 References 8. References
8.1 Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store
Arbitrary String Attributes", RFC 1464, May 1993. Arbitrary String Attributes", RFC 1464, May 1993.
[RFC2163] Allocchio, C., "Using the Internet DNS to Distribute MIXER
Conformant Global Address Mapping (MCGAM)", RFC 2163,
January 1998.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999. 2671, August 1999.
[RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
2000. (RR) Types", RFC 3597, September 2003.
8.2 Informative References
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC2163] Allocchio, C., "Using the Internet DNS to Distribute MIXER
Conformant Global Address Mapping (MCGAM)", RFC 2163,
January 1998.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999.
[RFC2929] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain [RFC2929] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain
Name System (DNS) IANA Considerations", BCP 42, RFC 2929, Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
September 2000. September 2000.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002. Resource Record (RR)", RFC 3445, December 2002.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
(RR) Types", RFC 3597, September 2003. Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[wcardclarify] [wcardclarify]
Halley, B. and E. Lewis, Halley, B. and E. Lewis,
"draft-ietf-dnsext-wcard-clarify-02.txt, Clarifying the "draft-ietf-dnsext-wcard-clarify-05.txt, The Role of Wild
Role of Wild Card Domains in the Domain Name System, work Card Domains in the Domain Name System, work in progress",
in progress", September 2003. September 2003.
Authors' Addresses Authors' Addresses
Patrik Faltstrom Patrik Faltstrom
IAB IAB
EMail: paf@cisco.com EMail: paf@cisco.com
Rob Austein Rob Austein
IAB IAB
skipping to change at page 12, line 41 skipping to change at page 13, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/