draft-iab-dns-choices-04.txt   draft-iab-dns-choices-05.txt 
Network Working Group P. Faltstrom Network Working Group IAB
Internet-Draft Cisco Internet-Draft P. Faltstrom, Ed.
Intended status: Informational October 23, 2006 Intended status: Standards Track R. Austein, Ed.
Expires: April 26, 2007 Expires: August 21, 2008 P. Koch, Ed.
February 18, 2008
Design Choices When Expanding DNS Design Choices When Expanding DNS
draft-iab-dns-choices-04.txt draft-iab-dns-choices-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 35
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 26, 2007. This Internet-Draft will expire on August 21, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2008).
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 circulates around application. DNS extension discussions too often focus on reuse of
reuse of the TXT record. This document lists different mechanisms to the TXT Resource Record Type. This document lists different
accomplish the extension to DNS, and comes to the conclusion that the mechanisms to extend the DNS, and concludes that the use of a new DNS
use of a new RR Type is the best solution. Resource Record Type is the best solution.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Extension mechanisms . . . . . . . . . . . . . . . . . . . . . 4 3. Extension mechanisms . . . . . . . . . . . . . . . . . . . . . 5
3.1. Place selectors inside the RDATA . . . . . . . . . . . . . 4 3.1. Place selectors inside the RDATA of existing Resource
Record Types . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Add a prefix to the owner name . . . . . . . . . . . . . . 5 3.2. Add a prefix to the owner name . . . . . . . . . . . . . . 5
3.3. Add a suffix to the owner name . . . . . . . . . . . . . . 6 3.3. Add a suffix to the owner name . . . . . . . . . . . . . . 6
3.4. Add a new Class . . . . . . . . . . . . . . . . . . . . . 6 3.4. Add a new Class . . . . . . . . . . . . . . . . . . . . . 7
3.5. Add a new Resource Record Type . . . . . . . . . . . . . . 7 3.5. Add a new Resource Record Type . . . . . . . . . . . . . . 7
4. Conclusion (why adding a new RR type is the answer) . . . . . 8 4. Zone boundaries are invisible to applications . . . . . . . . 8
5. Conclusion and Recommendation . . . . . . . . . . . . . . . . 10 5. Why adding a new Resource Record Type is the preferred
6. New Resource Record Type . . . . . . . . . . . . . . . . . . . 11 solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Conclusion and Recommendation . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Creating A New Resource Record Type . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
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 Resource Records) and data which have to do with mappings
domain names and IP addresses (A, AAAA and PTR). There are other between domain names and IP addresses (A, AAAA and PTR Resource
categories as well, some of which are tied to specific applications Records). There are other categories as well, some of which are tied
like email (MX), while others are generic record types used to convey to specific applications like email (MX Resource Records), while
information for multiple protocols (SRV, NAPTR). others are generic Resource Record Types used to convey information
for multiple protocols (SRV and NAPTR Resource Records).
When storing data in DNS for a new application, the data are usually When storing data in the DNS for a new application, the data are
tied to a "normal" domain name, so the application can query for the usually tied to a "normal" domain name, so that the application can
data it wants, while minimizing the impact on existing applications. query for the data it wants, while minimizing the impact on existing
applications.
Historically, extending DNS to store data for applications tied to a Historically, extending DNS to store application data tied to 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 Resource Records were created as a new Resource Record Type
designed to support electronic mail. SRV records are a generic type specifically designed to support electronic mail. SRV records are a
which use a prefixing scheme in combination with a base domain name. generic type which use a prefixing scheme in combination with a base
Records associated with ENUM use a suffixing scheme. NAPTR records domain name. Records associated with ENUM use a suffixing scheme.
add selection data inside the RDATA. It is clear the way of adding NAPTR records add selection data inside the RDATA. It is clear that
new data to the DNS has been inconsistent, and the purpose of this the methods used to add new data types to the DNS have been
document is to attempt to clarify the implications of each of these inconsistent, and the purpose of this document is to attempt to
methods, both for the applications that use them and for the rest of clarify the implications of each of these methods, both for the
the DNS system. applications that use them and for the rest of the DNS.
Many parts of this document talk about use of wildcards, and many This document talks extensively about use of DNS wildcards. Many
people might think use of wildcards is not something that happens people might think use of wildcards is not something that happens
today. In reality thoug, wildcards are in use, especially for some today. In reality though, wildcards are in use, especially for
specific usages like MX records. Because of this, the choice have to certain application-specific data such as MX Resource Records.
be made with existence of wildcards in mind. Because of this, the choice has to be made with existence of
wildcards in mind.
Another overall issue that have to be taken into account is what the Another overall issue that must be taken into account is what the new
new data in DNS is to describe. In some cases it might be completely data in the DNS are to describe. In some cases they might be
new data. In other cases it might be meta-data that is tied to data completely new data. In other cases they might be metadata tied to
that already exists in DNS. An example of new data is key data that already exist in the DNS. An example of new data is key
information for SSH and data used for fighting spam (meta data that information for SSH and data used for fighting spam (metadata tied to
is connected to the MX record). If the new data has connection to MX Resource Records). If the new data are tied to data that already
data that already exists in DNS, an analysis should be made as to exist in the DNS, an analysis should be made as to whether having
whether having (for example) A record and SSH key information in (for example) address records and SSH key information in different
different zones is a problem, and if it is, whether the owner for the DNS zones is a problem, and if it is, whether the specification must
records by design must be the same for both records. require all of the related data to be in the same zone.
This document does not talk about what one should store in DNS. It This document does not talk about what one should store in the DNS.
also doesn't discuss whether DNS is used for service discovery, or It also doesn't discuss whether DNS should be used for service
whether DNS is (also) used for storage of data specific for the discovery, or whether DNS should be used for storage of data specific
service. In general, DNS is a protocol that apart from holding for the service. In general, DNS is a protocol that, apart from
metadata that makes DNS itself function (NS, SOA, DS RR Types etc) holding metadata that makes the DNS itself function (NS, SOA, DNSSEC
only holds references to where services are located (SRV, NAPTR, A, Resource Record Types, etc), only holds references to service
AAAA RR types). locations (SRV, NAPTR, A, AAAA Resource Record Types), but there are
exceptions (such as MX Resource Records).
2. Background 2. Background
See RFC 2929 [RFC2929] for a brief summary of DNS query structure. See [RFC2929] for a brief summary of DNS query structure. Readers
Readers interested in the full story should start with the base DNS interested in the full story should start with the base DNS
specification in RFC 1035 [RFC1035], and continue with the various specification in [RFC1035], and continue with the various documents
documents which update, clarify, and extend the base specification. that update, clarify, and extend the base specification.
When composing a query against the DNS system, the parameters When composing a DNS query, the parameters used by the protocol are a
actually used by the protocol are a triple: a DNS name, a DNS class, triple: a DNS name, a DNS class, and a DNS record Type. Every
and a DNS record type. Every resource record (RR) matching a Resource Record matching a particular name, type and class is said to
particular name, type and class is said to belong to the same belong to the same "RRSet", and the whole RRSet is always returned to
resource record set (RRSet), and the whole RRSet is always returned the client that queries for it. Splitting an RRSet is a protocol
to the client which queries for it. Splitting an RRSet is a protocol
violation, because it results in coherency problems with the DNS violation, because it results in coherency problems with the DNS
caching mechanism. caching mechanism.
Note that most of the discussions around MTU size is about the size Some discussions around extensions to the DNS include arguments
of the whole DNS packet, and not about the size of an RRSet around MTU size. Note that most discussions about DNS and MTU size
explicitly. A DNS packet is to fit in the MTU size when using UDP, are about the size of the whole DNS packet, not about the size of a
or else a truncated response is given back from the server (at which single RRSet.
point the client can reissue the query over TCP).
Almost all DNS query traffic is carried over UDP, where a DNS message
must fit within a single UDP packet. DNS response messages are
almost always larger than DNS query messages, so message size issues
are almost always about responses, not queries. The base DNS
specification limits DNS messages over UDP to 512 octets; EDNS0
[RFC2671] specifies a mechanism by which a client can signal its
willingness to receive larger responses, but deployment of EDNS0 is
not universal, in part because of firewalls that block fragmented UDP
packets or EDNS0. If a response message won't fit in a single
packet, the name server returns a truncated response, at which point
the client may retry using TCP. DNS queries over TCP are not subject
to this length limitation, but TCP imposes significantly higher per-
query overhead on name servers than UDP. It is also the case that
the policies in deployed firewalls far too often is such that it
blocks DNS over TCP, so using TCP might not in reality be an option.
There are also risks (although possibly small) that a change of
routing while a TCP flow is open create problems when the DNS servers
are deployed in an anycast environment.
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 of existing Resource Record Types
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 Resource Records sharing the same name, type, and class) shared by
applications, and have the different applications use selectors multiple applications, and have the different applications use
within the RR data (RDATA) to determine which records are intended selectors within the Resource Record data (RDATA) to determine which
for which applications. This sort of selector mechanism is usually records are intended for which applications. This sort of selector
referred to "subtyping", because it is in effect creating an mechanism is usually referred to "subtyping", because it is in effect
additional type subsystem within a single DNS RR type. creating an additional type subsystem within a single DNS Resource
Record Type.
Examples of subtyping include NAPTR RRs (see RFC 3761 [RFC3761]) and Examples of subtyping include NAPTR Resource Records (see [RFC3761])
the original DNSSEC KEY RR type (RFC 2535 [RFC2535]) (before it was and the original DNSSEC KEY Resource Record Type ([RFC2535]) (before
updated by RFC 3445 [RFC3445]). it was updated by [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 Resource Records in which it is interested. Furthermore, since
signatures operate on complete RRSets, the entire RRSet must be re- DNSSEC signatures operate on complete RRSets, the entire RRSet must
signed if any RR in it changes. As a result, each application that be re-signed if any Resource Record in it changes. As a result, each
uses a subtyped RR incurs higher overhead than any of the application that uses a subtyped Resource Record incurs higher
applications would have incurred had they not been using a subtyping overhead than any of the applications would have incurred had they
scheme. The fact the RRSet is always passed around as an indivisible not been using a subtyping scheme. The fact the RRSet is always
unit increases the risk the RRSet will not fit in a UDP packet, which passed around as an indivisible unit increases the risk the RRSet
in turn increases the risk that the client will have to retry the will not fit in a UDP packet, which in turn increases the risk that
query with TCP, which substantially increases the load on the name the client will have to retry the query with TCP, which substantially
server. More precisely: Having one query fail over to TCP is not a increases the load on the name server. More precisely: having one
big deal, but since the typical ratio of clients to servers in the query fail over to TCP is not a big deal, but since the typical ratio
DNS system is very high, having a substantial number of DNS messages of clients to servers in today's deployed DNS is very high, having a
fail over to TCP may cause the queried name servers to be overloaded substantial number of DNS messages fail over to TCP may cause the
by TCP overhead. queried name servers to be overloaded by TCP overhead.
To conclude, because of the limitations of the size of one RRSet is Because of the size limitations, using a subtyping scheme to list a
that not all services tied to a domain can be announced, but instead large number of services for a single domain name risks triggering
selected (by the zone administrator). This because all of them can truncation and fallback to TCP, which may in turn force the zone
not be announced at the same time. administrator to announce only a subset of available services.
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 get By adding an application-specific prefix to a domain name, we get a
different name/class/type triples, and therefore different RRSets. different name/class/type triple, and therefore a different RRSet.
One problem with adding prefixes has to do with wildcards, especially One problem with adding prefixes has to do with wildcards, especially
if one has records like 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 (see also [RFC4592]).
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 record type stored in some Resource Record Type. This Resource Record Type can
that can store arbitrary data or a new RR type. This implies that either be a record Type that has an appropriate format to store the
some other selection mechanism has to be applied as well, such as data or a new Resource Record Type. This implies that some other
ability to distinguish between the records in an RR set given they selection mechanism has to be applied as well, such as ability to
have the same RR type (see also draft-ietf-dnsext-wcard-clarify distinguish between the records in an RRSet given they have the same
[wcardclarify] regarding use of wildcards and DNS). Because of this, Resource Record Type. Because of this, one needs to both register a
one needs both register a unique prefix and define what RR type is to unique prefix and define what Resource Record Type is to be used for
be used for this specific service. this specific service.
If the record has some relationship with another record in the zone, If the record has some relationship with another record in the zone,
the fact the two records can be in different zones might have the fact that the two records can be in different zones might have
implications on the trust the application have in the records. implications on the trust the application has in the records. For
Example: example:
example.com. IN MX 10 mail.example.com. example.com. IN MX 10 mail.example.com.
_foo.example.com. IN X-BAR "metadata for the mail service" _foo.example.com. IN X-BAR "metadata for the mail service"
In this example, the two records might be in two different zones, and In this example, the two records might be in two different zones, and
because of this signed by two different organizations when using because of this might be signed by two different organizations when
DNSSEC. 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. In this case, since the query name can be and therefore the RRSet. In this case, since the query name can be
set to exactly the data one wants the size of the RRSet is minimized. set to exactly the data one wants the size of the RRSet is minimized.
The problem with adding a suffix is that it creates a parallel tree The problem with adding a suffix is that it creates a parallel tree
within the IN class. Further, there is no technical mechanism to within the IN class. Further, there is no technical mechanism to
ensure that the delegation for "example.com" and "example.com._bar" ensure that the delegation for "example.com" and "example.com._bar"
are made to the same organization. Furthermore, data associated with are made to the same organization. Furthermore, data associated with
a single entity will now be stored in two different zones, such as a single entity will now be stored in two different zones, such as
"example.com" and "example.com._bar", which, depending on who "example.com" and "example.com._bar", which, depending on who
controls "_bar", can create new synchronization and update controls "_bar", can create new synchronization and update
authorization issues. authorization issues.
One way of solving the administrative issues is by using the DNAME One way of solving the administrative issues is by using the DNAME
resource record type specified in RFC 2672 [RFC2672]. Resource Record Type specified in [RFC2672].
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 Resource Record Type. This Resource Record Type can
record" or a new RR type. This implies that some other mechanism has either be a "kitchen-sink record" or a new Resource Record Type.
to be applied as well, with implications detailed in other parts of This implies that some other mechanism has to be applied as well,
this note. with implications detailed in other parts of this note.
In RFC 2163 [RFC2163] an infix token is inserted directly below the In [RFC2163] an infix token is inserted directly below the TLD, but
TLD, but the result is the same as adding a suffix to the owner name the result is equivalent to adding a suffix to the owner name
(and because of that creation of a new TLD). (instead of creating a TLD one is creating a second level domain).
3.4. Add a new Class 3.4. Add a new Class
DNS zones are class-specific in the sense that all the records in DNS zones are class-specific in the sense that all the records in
that zone share the same class as the zone's SOA record and the that zone share the same class as the zone's SOA record and the
existence of a zone in one class does not guarantee the existence of existence of a zone in one class does not guarantee the existence of
the zone in any other class. In practice, only the IN class has ever the zone in any other class. In practice, only the IN class has ever
seen widespread deployment, and the administrative overhead of seen widespread deployment, and the administrative overhead of
deploying an additional class would almost certainly be prohibitive. deploying an additional class would almost certainly be prohibitive.
Nevertheless, one could in theory use the DNS class mechanism to Nevertheless, one could in theory use the DNS class mechanism to
distinguish between different kinds of data. However, since the DNS distinguish between different kinds of data. However, since the DNS
delegation tree (represented by NS RRs) is itself tied to a specific delegation tree (represented by NS Resource Records) is itself tied
class, attempting to resolve a query by crossing a class boundary may to a specific class, attempting to resolve a query by crossing a
produce unexpected results, because there is no guarantee that the class boundary may produce unexpected results because there is no
name servers for the zone in the new class will be the same as the guarantee that the name servers for the zone in the new class will be
name servers in the IN class. The MIT Hesiod system used a scheme the same as the name servers in the IN class. The MIT Hesiod system
like this for storing data in the HS class, but only on a very small used a scheme like this for storing data in the HS class, but only on
scale (within a single institution), and with an administrative fiat a very small scale (within a single institution), and with an
requiring that the delegation trees for the IN and HS trees be administrative fiat requiring that the delegation trees for the IN
identical. and HS trees be identical.
Even when using a different class, the data will still have to be Even when using a different class, the data will still have to be
stored in some RR type or another. This RR type can either be a stored in some Resource Record Type or another. This Resource Record
"kitchen-sink record" or a new RR type. This implies that some other Type can either be a "kitchen-sink record" or a new Resource Record
mechanism has to be applied as well, with implications detailed in Type. This implies that some other mechanism has to be applied as
other parts of this note. well, with implications detailed in other parts of this note.
3.5. Add a new Resource Record Type 3.5. Add a new Resource Record Type
When adding a new Resource Record type to the system, entities in When adding a new Resource Record Type to the system, entities in
four different roles have to be able to handle the new type: four different roles have to be able to handle the new Type:
1. There must be a way to insert the new resource records into the 1. There must be a way to insert the new Resource Records into the
zone of the Primary Master name server. For some server zone of the Primary Master name server. For some server
implementations, the user interface only accepts record types implementations, the user interface only accepts record Types
which it understands (perhaps so that the implementation can which it understands (perhaps so that the implementation can
attempt to validate the data). Other implementations allow the attempt to validate the data). Other implementations allow the
zone administrator to enter an integer for the resource record zone administrator to enter an integer for the Resource Record
type code and the RDATA in Base64 or hexadecimal encoding (or Type code and the RDATA in Base64 or hexadecimal encoding (or
even as raw data). RFC 3597 [RFC3597] specifies a standard even as raw data). [RFC3597] specifies a standard generic
generic encoding for this purpose. encoding for this purpose.
2. A slave authoritative name server must be able to do a zone 2. A slave authoritative name server must be able to do a zone
transfer, receive the data from some other authoritative name transfer, receive the data from some other authoritative name
server, and serve data from the zone even though the zone server, and serve data from the zone even though the zone
includes records of unknown types. Historically, some includes records of unknown Types. Historically, some
implementations have had problems parsing stored copies of the implementations have had problems parsing stored copies of the
zone file after restarting, but those problems have not been seen zone file after restarting, but those problems have not been seen
for a few years. for a few years.
3. A full service resolver will cache the records which are 3. A caching resolver (most commonly a recursive name server) will
responses to queries. As mentioned in RFC 3597 [RFC3597],there cache the records which are responses to queries. As mentioned
are various pitfalls where a recursive name server might end up in [RFC3597],there are various pitfalls where a recursive name
having problems. server might end up having problems.
4. The application must be able to get the record with a new 4. The application must be able to get the RRSet with a new Resource
resource record type. The application itself may understand the Record Type. The application itself may understand the RDATA,
RDATA, but the resolver library might not. Support for a generic but the resolver library might not. Support for a generic
interface for retrieving arbitrary DNS RR types has been a interface for retrieving arbitrary DNS Resource Record Types has
requirement since 1989 (see RFC 1123 [RFC1123] Section 6.1.4.2). been a requirement since 1989 (see [RFC1123] Section 6.1.4.2).
Some stub resolver library implementations neglect to provide Some stub resolver library implementations neglect to provide
this functionality and cannot handle unknown RR types, but this functionality and cannot handle unknown Resource Record
implementation of a new stub resolver library is not particularly Types, but implementation of a new stub resolver library is not
difficult, and open source libraries that already provide this particularly difficult, and open source libraries that already
functionality are available. provide this functionality are available.
4. Conclusion (why adding a new RR type is the answer) 4. Zone boundaries are invisible to applications
By now, the astute reader will be wondering how to use the issues Regardless of the possible choices above we have seen a number of
presented so far. We will now attempt to clear up the reader's cases where the application made assumptions about the structure of
confusion by following the thought processes of a typical application the namespace and the location where specific information resides.
designer who wishes to store data in DNS, showing how such a designer We take a small sidestep to argue against such approaches.
almost inevitably hits upon the idea of just using TXT RR, and why
this is a bad thing, and instead why a new RR type is to be The DNS namespace is a hierarchy, technically speaking. However,
allocated. this only refers to the way names are built from multiple labels.
DNS hierarchy neither follows nor implies administrative hierarchy.
That said, it cannot be assumed that data attached to a node in the
DNS tree is valid for the whole subtree. Technically, there are zone
boundaries partitioning the namespace and administrative boundaries
(or policy boundaries) may even exist elsewhere.
The false assumption has lead to an approach called "tree climbing",
where a query that does not receive a positive response (either the
requested RRSet was missing or the name did not exist) is retried by
repeatedly stripping off the leftmost label (climbing towards the
root) until the root domain is reached. Sometimes these proposals
try to avoid the query for the root or the TLD level, but still this
approach has severe drawbacks:
o Technically, the DNS was built as a query - response tool without
any search capability [RFC3467]. Adding the search mechanism
imposes additional burden on the technical infrastructure, in the
worst case on TLD and root name servers.
o For reasons similar to those outlined in RFC 1535, querying for
information in a domain outside the control of the intended entity
may lead to incorrect results and may also put security at risk.
Finding the exact policy boundary is impossible without an
explicit marker which does not exist at present. At best,
software can detect zone boundaries (e.g., by looking for SOA
Resource Records), but some TLD registries register names starting
at the second level (e.g., CO.UK), and there are various other
"registry" types at second, third or other level domains that
cannot be identified as such without policy knowledge external to
the DNS.
To restate, the zone boundary is purely a boundary that exists in the
DNS for administrative purposes, and applications should be careful
not to draw unwarranted conclusions from zone boundaries. A
different way of stating this is that the DNS does not support
inheritance, e.g. a wildcard MX RRSet for a TLD will not be valid for
any subdomain of that particular TLD.
5. Why adding a new Resource Record Type is the preferred solution
By now, the astute reader might be be wondering what conclusions to
draw from all the issues presented so far. We will now attempt to
clear up the reader's confusion by following the thought processes of
a typical application designer who wishes to store data in the DNS,
showing how such a designer almost inevitably hits upon the idea of
just using TXT Resource Record, why this is a bad thing, and why a
new Resource Record Type should be allocated instead.
The overall problem with most solutions has to do with two main The overall problem with most solutions has to do with two main
issues: issues:
o No semantics to prevent collision with other use o No semantics to prevent collision with other use
o Space considerations (in the DNS message) o Space considerations in the DNS message
A typical application designer is not interested in the DNS for its A typical application designer is not interested in the DNS for its
own sake, but rather as a distributed database in which application own sake, but rather as a distributed database in which application
data can be stored. As a result, the designer of a new application data can be stored. As a result, the designer of a new application
is usually looking for the easiest way to add whatever new data the is usually looking for the easiest way to add whatever new data the
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 Resource Record Type is the technically correct answer
protocol standpoint (more on this below), but doing so requires some from the DNS protocol standpoint (more on this below), but doing so
DNS expertise, due to the issues listed in Section 3.5. As a result, requires some DNS expertise, due to the issues listed in Section 3.5.
this option is usually considered. Note that according to RFC2929 As a result, this option is usually not considered. Note that
[RFC2929], some types require IETF Consensus, while others only according to [RFC2929], some Types require IETF Consensus, while
require a specification. 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 from
existing RR types in ways incompatible with their defined semantics, reusing existing Resource Record Types in ways incompatible with
but it does tend to steer application designers away from this their defined semantics, but it does tend to steer application
approach. designers away from this approach.
RR Type 40 was registered for the SINK record type. This RR Type was For example, Resource Record Type 40 was registered for the SINK
discussed in the DNSIND working group of the IETF, and it was decided record Type. This Resource Record Type was discussed in the DNSIND
at the 46th IETF to not move the I-D forward to become an RFC. working group of the IETF, and it was decided at the 46th IETF to not
Reason was the risk for large RR sets and the ability for application move the I-D forward to become an RFC because of the risk of
creators to use the SINK RR Type instead of registering a new RR encouraging application designers to use the SINK Resource Record
Type. Type instead of registering a new Resource Record Type, which would
result in infeasibly large SINK RRsets.
Eliminating all of the above leaves the TXT RR type in the IN class. Eliminating all of the above leaves the TXT Resource Record Type in
The TXT RDATA format is free form text, and there are no existing the IN class. The TXT RDATA format is free form text, and there are
semantics to get in the way. Furthermore, the TXT RR can obviously no existing semantics to get in the way. Furthermore, the TXT
just be used as a bucket in which to carry around data to be used by Resource Record can obviously just be used as a bucket in which to
some higher level parser, perhaps in some human readable programming carry around data to be used by some higher level parser, perhaps in
or markup language. Thus, for many applications, TXT RRs are the some human readable programming or markup language. Thus, for many
"obvious" choice. Unfortunately, this conclusion, while applications, TXT Resource Records are the "obvious" choice.
understandable, is also wrong, for several reasons. Unfortunately, this conclusion, while understandable, is also wrong,
for several reasons.
The first reason why TXT RRs are not well suited to such use is The first reason why TXT Resource Records are not well suited to such
precisely the lack of defined semantics that make them so attractive. use is precisely the lack of defined semantics that make them so
Arguably, the TXT RR is misnamed, and should have been called the attractive. Arguably, the TXT Resource Record is misnamed, and
Local Container record, because the lack of defined semantics means should have been called the Local Container record, because the lack
that a TXT RR means precisely what the data producer says it means. of defined semantics means that a TXT Resource Record means precisely
This is fine, so long as TXT RRs are being used by human beings or by what the data producer says it means. This is fine, so long as TXT
private agreement between data producer and data consumer. However, Resource Records are being used by human beings or by private
it becomes a problem once one starts using them for standardized agreement between data producer and data consumer. However, it
becomes a problem once one starts using them for standardized
protocols in which there is no prior relationship between data protocols in which there is no prior relationship between data
producer and data consumer. Reason for this is that there is nothing producer and data consumer. The reason for this is that there is
to prevent collisions with some other incompatible use of TXT RRs. nothing to prevent collisions with some other incompatible use of TXT
This is even worse than the general subtyping problem described in Resource Records. This is even worse than the general subtyping
Section 3.1, because TXT RRs don't even have a standardized selector problem described in Section 3.1, because TXT Resource Records don't
field in which to store the subtype. RFC1464 [RFC1464] tried, but it even have a standardized selector field in which to store the
was not a success. At best a definition of a subtype is reduced to subtype. [RFC1464] tried, but it was not a success. At best a
hoping that whatever scheme one has come up with will not accidently definition of a subtype is reduced to hoping that whatever scheme one
conflict with somebody else's subtyping scheme, and that it will not has come up with will not accidently conflict with somebody else's
be possible to mis-parse one application's use of TXT RRs as data subtyping scheme, and that it will not be possible to mis-parse one
intended for a different application. Any attempt to come up with a application's use of TXT Resource Records as data intended for a
standardized format within the TXT RR format would be at least different application. Any attempt to impose a standardized format
fifteen years too late even if it were put into effect immediately. within the TXT Resource Record format would be at least fifteen years
too late even if it were put into effect immediately; at best, one
can restrict the syntax that a particular application uses within a
TXT Resource Record and accept the risk that unrelated TXT Resource
Record uses will collide with it.
Using one of the naming modifications discussed in Section 3.2 and Using one of the naming modifications discussed in Section 3.2 and
Section 3.3 would address the subtyping problem, but each of these Section 3.3 would address the subtyping problem, but each of these
approaches brings in new problems of its own. The prefix approach approaches brings in new problems of its own. The prefix approach
(such as SRV RRs use) does not work well with wildcards, which is a (that for example SRV Resource Records use) does not work well with
particular problem for mail-related applications, since MX RRs are wildcards, which is a particular problem for mail-related
probably the most common use of DNS wildcards. The suffix approach applications, since MX Resource Records are probably the most common
doesn't have wildcard issues, but, as noted previously, it does have use of DNS wildcards. The suffix approach doesn't have wildcard
synchronization and update authorization issues, since it works by issues, but, as noted previously, it does have synchronization and
creating a second subtree in a different part of the global DNS name update authorization issues, since it works by creating a second
space. subtree in a different part of the global DNS name space.
The next reason why TXT RRs are not well suited to protocol use has The next reason why TXT Resource Records are not well suited to
to do with the limited data space available in a DNS message. As protocol use has to do with the limited data space available in a DNS
alluded to briefly in Section 3.1, typical DNS query traffic patterns message. As alluded to briefly in Section 3.1, typical DNS query
involve a very large number of DNS clients sending queries to a traffic patterns involve a very large number of DNS clients sending
relatively small number of DNS servers. Normal path MTU discovery queries to a relatively small number of DNS servers. Normal path MTU
schemes do little good here, because, from the server's perspective, discovery schemes do little good here because, from the server's
there isn't enough repeat traffic from any one client for it to be perspective, there isn't enough repeat traffic from any one client
worth retaining state. UDP-based DNS is an idempotent query, whereas for it to be worth retaining state. UDP-based DNS is an idempotent
TCP-based DNS requires the server to keep state (in the form of TCP query, whereas TCP-based DNS requires the server to keep state (in
connection state, usually in the server's kernel) and roughly triples the form of TCP connection state, usually in the server's kernel) and
the traffic load. Thus, there's a strong incentive to keep DNS roughly triples the traffic load. Thus, there's a strong incentive
messages short enough to fit in a UDP datagram, preferably a UDP to keep DNS messages short enough to fit in a UDP datagram,
datagram short enough not to require IP fragmentation. preferably a UDP 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 Resource RRSets than necessary, but verbose text
data are also wasteful, since the data they hold can usually be encodings of data are also wasteful, since the data they hold can
represented more compactly in a resource record designed specifically usually be represented more compactly in a Resource Record designed
to support the application's particular data needs. If the data that specifically to support the application's particular data needs. If
need to be carried are so large that there is no way to make them fit the data that need to be carried are so large that there is no way to
comfortably into the DNS regardless of encoding, it is probably make them fit comfortably into the DNS regardless of encoding, it is
better to move the data somewhere else, and just use the DNS as a probably better to move the data somewhere else, and just use the DNS
pointer to the data, as with NAPTR. as a pointer to the data, as with NAPTR.
5. Conclusion and Recommendation 6. Conclusion and Recommendation
Given the problems detailed in Section 4, it is worth reexamining the Given the problems detailed in Section 5, it is worth reexamining the
oft-jumped-to conclusion that specifying a new RR type is hard. oft-jumped-to conclusion that specifying a new Resource Record Type
Historically, this was indeed the case, but recent surveys suggest is hard. Historically, this was indeed the case, but recent surveys
that support for unknown RR types [RFC3597] is now widespread, and suggest that support for unknown Resource Record Types [RFC3597] is
that lack of support for unknown types is mostly an issue for now widespread, and that lack of support for unknown Types is mostly
relatively old software that would probably need to be upgraded in an issue for relatively old software that would probably need to be
any case as part of supporting a new application. One should also upgraded in any case as part of supporting a new application. One
remember that deployed DNS software today should support DNSSEC, and should also remember that deployed DNS software today should support
software recent enough to do so will have higher chance of being able DNSSEC, and software recent enough to do so will likely support both
to also support RFC3597. unknown Resource Record Types [RFC3597] and EDNS0 [RFC2671].
Of all the issues detailed in Section 3.5, provisioning the data is Of all the issues detailed in Section 3.5, provisioning the data is
in some respects the most difficult. The problem here is less the in some respects the most difficult. The problem here is less
authoritative name servers themselves than the front-end systems used difficult for the authoritative name servers themselves than the
to enter (and perhaps validate) the data. Hand editing does not work front-end systems used to enter (and perhaps validate) the data.
well for maintenance of large zones, so some sort of tool is Hand editing does not work well for maintenance of large zones, so
necessary, and the tool may not be tightly coupled to the name server some sort of tool is necessary, and the tool may not be tightly
implementation itself. Note, however, that this provisioning problem coupled to the name server implementation itself. Note, however,
exists to some degree with any new form of data to be stored in DNS, that this provisioning problem exists to some degree with any new
regardless of data format, RR type, or naming scheme. Adapting form of data to be stored in the DNS, regardless of data format,
front-end systems to support a new RR type may be a bit more Resource Record type, or naming scheme. Including the TXT Resource
difficult than reusing an existing type, but this appears to be a Record Type. Adapting front-end systems to support a new Resource
minor difference in degree rather than a difference in kind. Record type may be a bit more difficult than reusing an existing
type, but this appears to be a minor difference in degree rather than
a difference in kind.
Given the various issues described in this note, we believe that: Given the various issues described in this note, we believe that:
o there is no magic solution which allows a completely painless o there is no magic solution which allows a completely painless
addition of new data to the DNS, but addition of new data to the DNS, but
o on the whole, the best solution is still to use the DNS type o on the whole, the best solution is still to use the DNS Resource
mechanism designed for precisely this purpose, and Record Type 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 Resource Records is almost certainly the worst.
This especially for the two reasons outlined above (lack of semantics This especially for the two reasons outlined above (lack of semantics
and its implications, and size leading to the need to use TCP). and its implications, and size leading to the need to use TCP).
6. New Resource Record Type 7. Creating A New Resource Record Type
Creation of a new resource record type is specified in RFC 2929
[RFC2929]. Terminology is from RFC 2434 [RFC2434]. It is specified
in RFC 2929 that not only standards track documents can specify new
resource record types. Also experimental or informational RFC is ok,
and for some numbers "...RFC or other permanent and readily available
reference...".
The following are the rules applicable at the time of writing from
BCP 42 and BCP 26 for various ranges of Resource Record Types.
Type number 1-32767 require IETF Consensus:
IETF Consensus - New values are assigned through the IETF
consensus process. Specifically, new assignments are made via
RFCs approved by the IESG. Typically, the IESG will seek input on
prospective assignments from appropriate persons (e.g., a relevant
Working Group if one exists).
Examples: A record is number 1, and AXFR number 252.
Type number 32768-65279 require specification:
Specification Required - Values and their meaning must be
documented in an RFC or other permanent and readily available
reference, in sufficient detail so that interoperability between
independent implementations is possible.
No Resource Record types are registered in this range.
Type number 65280-65535 is for private use:
Private Use - For private or local use only, with the type and
purpose defined by the local site. No attempt is made to prevent
multiple sites from using the same value in different (and
incompatible) ways. There is no need for IANA to review such
assignments and assignments are not generally useful for
interoperability.
Resource records in this range is not registered centrally at The process for creating a new Resource Record Type is specified in
IANA, and collissions may exist. [I-D.ietf-dnsext-2929bis].
7. IANA Considerations 8. IANA Considerations
This document does not require any IANA actions. This document does not require any IANA actions.
8. Security Considerations 9. 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 DNS. DNSSEC signatures significantly increase the size of data in the DNS. DNSSEC signatures significantly increase the size
the messages transported, and because of this, the DNS message size of the messages transported, and because of this, the DNS message
issues discussed in Section 3.1 and Section 4 are more serious than size issues discussed in Section 3.1 and Section 5 are more serious
they might at first appear. than they might at first appear.
Adding new RR types (as discussed in Section 3.5) might conceivably Adding new Resource Record Types (as discussed in Section 3.5) might
trigger bugs and other bad behavior in software which is not conceivably trigger bugs and other bad behavior in software that is
compliant with RFC 3597 [RFC3597], but most such software is old not compliant with [RFC3597], but most such software is old enough
enough and insecure enough that it should be updated for other and insecure enough that it should be updated for other reasons in
reasons in any case. Basic API support for retrieving arbitrary RR any case. Basic API support for retrieving arbitrary Resource Record
types has been a requirement since 1989 (see RFC 1123 [RFC1123]). Types has been a requirement since 1989 (see [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 Resource Record Types will not be as hard as
think at first. people might think at first.
9. Acknowledgements 10. Acknowledgements
This document has been created during a number of years, with input This document has been created during a number of years, with input
from many people. The question on how to expand and use the DNS is from many people. The question on how to expand and use the DNS is
sensitive, and a document like this can not please everyone. The sensitive, and a document like this can not please everyone. The
goal is instead to describe the architecture, and given this IAB have goal is instead to describe the architecture and tradeoffs, and make
based a number of recommendations. some recommendations about best practices.
People that have helped include: Dean Andersson, Loa Andersson, Mark People that have helped include: Dean Andersson, Loa Andersson, Mark
Andrews, Rob Austein, Roy Badami, Dan Bernstein, Alex Bligh, Andrews, John Angelmo, Roy Badami, Dan Bernstein, Alex Bligh,
Nathaniel Borenstein, Stephane Bortzmeyer, Brian Carpenter, Leslie Nathaniel Borenstein, Stephane Bortzmeyer, Brian Carpenter, Leslie
Daigle, Mark Delany, Richard Draves, Martin Duerst, Donald Eastlake, Daigle, Elwyn Davies, Mark Delany, Richard Draves, Martin Duerst,
Robert Elz, Jim Fenton, Tony Finch, Jim Gilroy, Olafur Gudmundsson, Donald Eastlake, Robert Elz, Jim Fenton, Tony Finch, Jim Gilroy,
Eric Hall, Philip Hallam-Baker, Ted Hardie, Bob Hinden, Paul Hoffman, Olafur Gudmundsson, Eric Hall, Philip Hallam-Baker, Ted Hardie, Bob
Geoff Houston, Christian Huitema, Johan Ihren, John Klensin, Peter Hinden, Paul Hoffman, Geoff Houston, Christian Huitema, Johan Ihren,
Koch, Olaf Kolkman, Ben Laurie, William Leibzon, John Levine, Edward John Klensin, Olaf Kolkman, Ben Laurie, William Leibzon, John Levine,
Lewis, David MacQuigg, Allison Manking, Bill Manning, David Meyer, Edward Lewis, David MacQuigg, Allison Manking, Bill Manning, Danny
Pekka Nikander, Masataka Ohta, Douglas Otis, Michael Patton, Jonathan McPherson, David Meyer, Pekka Nikander, Masataka Ohta, Douglas Otis,
Rosenberg, Anders Rundgren, Miriam Sapiro, Pekka Savola, Chip Sharp, Michael Patton, Jonathan Rosenberg, Anders Rundgren, Miriam Sapiro,
James Snell, Michael Thomas, Paul Vixie, Sam Weiler, Florian Weimer, Pekka Savola, Chip Sharp, James Snell, Dave Thaler, Michael Thomas,
Bert Wijnen, Dan Wing Paul Vixie, Sam Weiler, Florian Weimer, Bert Wijnen, and Dan Wing.
Members of the IAB when this document was made available were: Members of the IAB when this document was made available were: Loa
Bernard Aboba, Loa Andesson, Brian Carpender, Leslie Daigle, Elwyn Andersson, Leslie Daigle, Elwyn Davies, Kevin Fall, Russ Housley,
Davies, Kevin Fall, Olaf Kolkman, Kurtis Lindqvist, David Meyer, Olaf Kolkman, Barry Leiba, Kurtis Lindqvist, Danny McPherson, David
David Oran, Eric Rescorla, Lixia Zhang. Oran, Eric Rescorla, Dave Thaler, and Lixia Zhang.
10. References 11. References
10.1. Normative References 11.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", RFC 1035, STD 13, November 1987.
[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.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake 3rd, D., "Domain Name System Security
RFC 2535, March 1999. Extensions", RFC 2535, March 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999. RFC 2671, August 1999.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003. (RR) Types", RFC 3597, September 2003.
10.2. Informative References 11.2. Informative References
[I-D.ietf-dnsext-2929bis]
3rd, D., "Domain Name System (DNS) IANA Considerations",
draft-ietf-dnsext-2929bis-06 (work in progress),
August 2007.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", RFC 1123, STD 3, October 1989.
[RFC2163] Allocchio, C., "Using the Internet DNS to Distribute MIXER [RFC2163] Allocchio, C., "Using the Internet DNS to Distribute MIXER
Conformant Global Address Mapping (MCGAM)", RFC 2163, Conformant Global Address Mapping (MCGAM)", RFC 2163,
January 1998. January 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
RFC 2672, August 1999. RFC 2672, August 1999.
[RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning, [RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
"Domain Name System (DNS) IANA Considerations", BCP 42, "Domain Name System (DNS) IANA Considerations", RFC 2929,
RFC 2929, September 2000. BCP 42, 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.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers [RFC3467] Klensin, J., "Role of the Domain Name System (DNS)",
Considered Useful", BCP 82, RFC 3692, January 2004. RFC 3467, February 2003.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004. System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[wcardclarify] [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
Lewis, E., "draft-ietf-dnsext-wcard-clarify-11.txt, The System", RFC 4592, July 2006.
Role of Wild Card Domains in the Domain Name System, work
in progress", March 2006.
Author's Address Authors' Addresses
Patrik Faltstrom Internet Architecture Board
Cisco
Email: iab@iab.org
Patrik Faltstrom (editor)
Email: paf@cisco.com Email: paf@cisco.com
Rob Austein (editor)
Email: sra@isc.org
Peter Koch (editor)
Email: pk@denic.de
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
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, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE 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.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 86 change blocks. 
383 lines changed or deleted 431 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/