draft-iab-dns-choices-08.txt   rfc5507.txt 
Network Working Group IAB Network Working Group IAB
Internet-Draft P. Faltstrom, Ed. Request for Comments: 5507 P. Faltstrom, Ed.
Intended status: Informational R. Austein, Ed. Category: Informational R. Austein, Ed.
Expires: September 8, 2009 P. Koch, Ed. P. Koch, Ed.
March 7, 2009 April 2009
Design Choices When Expanding DNS
draft-iab-dns-choices-08
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Design Choices When Expanding the DNS
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 8, 2009. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 10 skipping to change at page 2, line 7
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 discussions too often focus on reuse of application. DNS extension discussions too often focus on reuse of
the TXT Resource Record Type. This document lists different the TXT Resource Record Type. This document lists different
mechanisms to extend the DNS, and concludes that the use of a new DNS mechanisms to extend the DNS, and concludes that the use of a new DNS
Resource Record 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 . . . . . . . . . . . . . . . . . . . . . 5 3. Extension Mechanisms ............................................5
3.1. Place selectors inside the RDATA of existing Resource 3.1. Place Selectors inside the RDATA of Existing
Record Types . . . . . . . . . . . . . . . . . . . . . . . 5 Resource Record Types ......................................5
3.2. Add a prefix to the owner name . . . . . . . . . . . . . . 6 3.2. Add a Prefix to the Owner Name .............................6
3.3. Add a suffix to the owner name . . . . . . . . . . . . . . 7 3.3. Add a Suffix to the Owner Name .............................7
3.4. Add a new Class . . . . . . . . . . . . . . . . . . . . . 7 3.4. Add a New Class ............................................8
3.5. Add a new Resource Record Type . . . . . . . . . . . . . . 8 3.5. Add a New Resource Record Type .............................8
4. Zone boundaries are invisible to applications . . . . . . . . 9 4. Zone Boundaries are Invisible to Applications ...................9
5. Why adding a new Resource Record Type is the preferred 5. Why Adding a New Resource Record Type Is the Preferred
solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Solution .......................................................10
6. Conclusion and Recommendation . . . . . . . . . . . . . . . . 13 6. Conclusion and Recommendation ..................................14
7. Creating A New Resource Record Type . . . . . . . . . . . . . 14 7. Creating a New Resource Record Type ............................14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations ........................................15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements ...............................................15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. IAB Members at the Time of This Writing .......................16
11. IAB Members at the time of this writing . . . . . . . . . . . 16 11. References ....................................................16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References .....................................16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.2. Informative References ...................................16
12.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
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 Resource Records) and data which have to do with mappings and SOA Resource Records) and data that have to do with mappings
between domain names and IP addresses (A, AAAA and PTR Resource between domain names and IP addresses (A, AAAA, and PTR Resource
Records). There are other categories as well, some of which are tied Records). There are other categories as well, some of which are tied
to specific applications like email (MX Resource Records), while to specific applications like email (MX Resource Records), while
others are generic Resource Record Types used to convey information others are generic Resource Record Types used to convey information
for multiple protocols (SRV and NAPTR Resource Records). for multiple protocols (SRV and NAPTR Resource Records).
When storing data in the DNS for a new application, the goal must be When storing data in the DNS for a new application, the goal must be
to store data in such a way that the application can query for the to store data in such a way that the application can query for the
data it wants, while minimizing both the impact on existing data it wants, while minimizing both the impact on existing
applications and the amount of extra data transferred to the client. applications and the amount of extra data transferred to the client.
This implies that a number of design choices have to be made, where This implies that a number of design choices have to be made, where
the most important is to ensure that a precise selection of what data the most important is to ensure that a precise selection of what data
to return must be made already in the query. A query consists of the to return must be made already in the query. A query consists of a
triple {Owner, Resource Record Type, Resource Record Class}. triple: {Owner (or name), Resource Record Class, Resource Record
Type}.
Historically, extending DNS to store application data tied to a Historically, extending the 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
Resource Records were created as a new Resource Record Type Resource Records were created as a new Resource Record Type
specifically designed to support electronic mail. SRV records are a specifically designed to support electronic mail. SRV records are a
generic type which use a prefixing scheme in combination with a base generic type that use a prefixing scheme in combination with a base
domain name. NAPTR records add selection data inside the RDATA. It domain name. NAPTR records add selection data inside the RDATA. It
is clear that the methods used to add new data types to the DNS have is clear that the methods used to add new data types to the DNS have
been inconsistent, and the purpose of this document is to attempt to been inconsistent, and the purpose of this document is to attempt to
clarify the implications of each of these methods, both for the clarify the implications of each of these methods, both for the
applications that use them and for the rest of the DNS. applications that use them and for the rest of the DNS.
This document talks extensively about use of DNS wildcards. 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 though, wildcards are in use, especially for today. In reality though, wildcards are in use, especially for
certain application-specific data such as MX Resource Records. certain application-specific data such as MX Resource Records.
Because of this, the choice has to be made with existence of Because of this, the choice has to be made with the existence of
wildcards in mind. wildcards in mind.
Another overall issue that must be taken into account is what the new Another overall issue that must be taken into account is what the new
data in the DNS are to describe. In some cases they might be data in the DNS are to describe. In some cases, they might be
completely new data. In other cases they might be metadata tied to completely new data. In other cases, they might be metadata tied to
data that already exist in the DNS. Examples of new data are key data that already exist in the DNS. Examples of new data are key
information for SSH and data used for authenticating the sender of information for the Secure SHell (SSH) Protocol and data used for
email messages (metadata tied to MX Resource Records). If the new authenticating the sender of email messages (metadata tied to MX
data are tied to data that already exist in the DNS, an analysis Resource Records). If the new data are tied to data that already
should be made as to whether having (for example) address records and exist in the DNS, an analysis should be made as to whether having
SSH key information in different DNS zones is a problem or if it is a (for example) address records and SSH key information in different
bonus, and if it is a problem, whether the specification must require DNS zones is a problem or if it is a bonus, and if it is a problem,
all of the related data to be in the same zone. One specific whether the specification must require all of the related data to be
difference between having the records in the same zone or not has to in the same zone. One specific difference between having the records
do with maintenance of the records. If they are in the same zone, in the same zone or not has to do with maintenance of the records.
the same maintainer (from a DNS perspective) manages the two records. If they are in the same zone, the same maintainer (from a DNS
Specifically, they must be signed with the same DNSSEC keys if DNSSEC perspective) manages the two records. Specifically, they must be
is in use. signed with the same DNSSEC keys if DNSSEC is in use.
This document does not talk about what one should store in the DNS. This document does not talk about what one should store in the DNS.
It also doesn't discuss whether DNS should be used for service It also doesn't discuss whether the DNS should be used for service
discovery, or whether DNS should be used for storage of data specific discovery, or whether the DNS should be used for storage of data
to the service. In general, DNS is a protocol that, apart from specific to the service. In general, the DNS is a protocol that,
holding metadata that makes the DNS itself function (NS, SOA, DNSSEC apart from holding metadata that makes the DNS itself function (NS,
Resource Record Types, etc), only holds references to service SOA, DNSSEC Resource Record Types, etc.), only holds references to
locations (SRV, NAPTR, A, AAAA Resource Record Types) -- though there service locations (SRV, NAPTR, A, AAAA Resource Record Types) --
are exceptions, such as MX Resource Records. though there are exceptions, such as MX Resource Records.
2. Background 2. Background
See RFC 5395 [RFC5395] for a brief summary of DNS query structure. See RFC 5395 [RFC5395] for a brief summary of the DNS query
Readers interested in the full story should start with the base DNS structure. Readers interested in the full story should start with
specification in RFC 1035 [RFC1035], and continue with the various the base DNS specification in RFC 1035 [RFC1035] and continue with
documents that update, clarify, and extend the base specification. the various documents that update, clarify, and extend the base
specification.
When composing a DNS query, the parameters used by the protocol are a When composing a DNS query, the parameters used by the protocol are a
triple: a DNS name, a DNS class, and a DNS Resource Record Type. {owner, class, type} triple. Every Resource Record matching such a
Every Resource Record matching a particular name, class and type is triple is said to belong to the same Resource Record Set (RRSet), and
said to belong to the same Resource Record Set (RRSet), and the whole the whole RRSet is always returned to the client that queries for it.
RRSet is always returned to the client that queries for it.
Splitting an RRSet is a protocol violation (sending a partial RRSet, Splitting an RRSet is a protocol violation (sending a partial RRSet,
not truncating the DNS response), because it can result in coherency not truncating the DNS response), because it can result in coherency
problems with the DNS caching mechanism. See RFC 2181 section 5 problems with the DNS caching mechanism. See Section 5 of [RFC2181]
[RFC2181] for more information. for more information.
Some discussions around extensions to the DNS include arguments Some discussions around extensions to the DNS include arguments
around MTU size. Note that most discussions about DNS and MTU size around MTU size. Note that most discussions about DNS and MTU size
are about the size of the whole DNS packet, not about the size of a are about the size of the whole DNS packet, not about the size of a
single RRSet. single RRSet.
Almost all DNS query traffic is carried over UDP, where a DNS message Almost all DNS query traffic is carried over UDP, where a DNS message
must fit within a single UDP packet. DNS response messages are must fit within a single UDP packet. DNS response messages are
almost always larger than DNS query messages, so message size issues almost always larger than DNS query messages, so message size issues
are almost always about responses, not queries. The base DNS are almost always about responses, not queries. The base DNS
specification limits DNS messages over UDP to 512 octets; EDNS0 specification limits DNS messages over UDP to 512 octets; EDNS0
[RFC2671] specifies a mechanism by which a client can signal its [RFC2671] specifies a mechanism by which a client can signal its
willingness to receive larger responses, but deployment of EDNS0 is willingness to receive larger responses, but deployment of EDNS0 is
not universal, in part because of firewalls that block fragmented UDP not universal, in part because of firewalls that block fragmented UDP
packets or EDNS0. If a response message won't fit in a single packets or EDNS0. If a response message won't fit in a single
packet, the name server returns a truncated response, at which point packet, the name server returns a truncated response, at which point
the client may retry using TCP. DNS queries over TCP are not subject the client may retry using TCP. DNS queries over TCP are not subject
to this length limitation, but TCP imposes significantly higher per- to this length limitation, but TCP imposes significantly higher per-
query overhead on name servers than UDP. It is also the case that query overhead on name servers than UDP. It is also the case that
the policies in deployed firewalls far too often are such that it the policies in deployed firewalls far too often are such that they
blocks DNS over TCP, so using TCP might not in reality be an option. block DNS over TCP, so using TCP might not in reality be an option.
There are also risks (although possibly small) that a change of There are also risks (although possibly small) that a change of
routing while a TCP flow is open creates problems when the DNS routing while a TCP flow is open creates problems when the DNS
servers are deployed in an anycast environment. 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 of existing Resource Record Types 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
Resource Records sharing the same name, class and type) shared by Resource Records sharing the same {owner, class, type} triple) shared
multiple applications, and have the different applications use by multiple applications, and have the different applications use
selectors within the Resource Record data (RDATA) to determine which selectors within the Resource Record data (RDATA) to determine which
records are intended for which applications. This sort of selector records are intended for which applications. This sort of selector
mechanism is usually referred to "subtyping", because it is in effect mechanism is usually referred to "subtyping", because it is in effect
creating an additional type subsystem within a single DNS Resource creating an additional type subsystem within a single DNS Resource
Record Type. Record Type.
Examples of subtyping include NAPTR Resource Records [RFC3761] and Examples of subtyping include NAPTR Resource Records [RFC3761] and
the original DNSSEC KEY Resource Record Type [RFC2535] (which was the original DNSSEC KEY Resource Record Type [RFC2535] (which was
later updated by RFC 3445 [RFC3445]). later updated by RFC 3445 [RFC3445], and obsoleted by RFC 4033
[RFC4033], RFC 4034 [RFC4034] and RFC 4035 [RFC4035]).
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 Resource Records in which it is interested. Furthermore, since the Resource Records in which it is interested. Furthermore, since
DNSSEC signatures operate on complete RRSets, the entire RRSet must DNSSEC signatures operate on complete RRSets, the entire RRSet must
be re-signed if any Resource Record in it changes. As a result, each be re-signed if any Resource Record in it changes. As a result, each
application that uses a subtyped Resource Record incurs higher application that uses a subtyped Resource Record incurs higher
overhead than any of the applications would have incurred had they overhead than any of the applications would have incurred had they
not been using a subtyping scheme. The fact the RRSet is always not been using a subtyping scheme. The fact the RRSet is always
passed around as an indivisible unit increases the risk the RRSet passed around as an indivisible unit increases the risk the RRSet
will not fit in a UDP packet, which in turn increases the risk that will not fit in a UDP packet, which in turn increases the risk that
the client will have to retry the query with TCP, which substantially the client will have to retry the query with TCP, which substantially
skipping to change at page 6, line 11 skipping to change at page 6, line 13
query fail over to TCP is not a big deal, but since the typical ratio query fail over to TCP is not a big deal, but since the typical ratio
of clients to servers in today's deployed DNS is very high, having a of clients to servers in today's deployed DNS is very high, having a
substantial number of DNS messages fail over to TCP may cause the substantial number of DNS messages fail over to TCP may cause the
queried name servers to be overloaded by TCP overhead. queried name servers to be overloaded by TCP overhead.
Because of the size limitations, using a subtyping scheme to list a Because of the size limitations, using a subtyping scheme to list a
large number of services for a single domain name risks triggering large number of services for a single domain name risks triggering
truncation and fallback to TCP, which may in turn force the zone truncation and fallback to TCP, which may in turn force the zone
administrator to announce only a subset of available services. 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 a By adding an application-specific prefix to a domain name, we get a
different name/class/type triple, and therefore a different RRSet. different {owner, class, type} triple, and therefore a different
One problem with adding prefixes has to do with wildcards, especially RRSet. One problem with adding prefixes has to do with wildcards,
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 (see also RFC 4592 [RFC4592]). domain name (see also RFC 4592 [RFC4592]).
There have been proposals to deal with the problem that DNS wild- There have been proposals to deal with the problem that DNS wildcards
cards are always terminal records. These proposals introduce an are always terminal records. These proposals introduce an additional
additional set of trade-offs that would need to be taken into account set of trade-offs that would need to be taken into account when
when assessing which extension mechanism to choose. Aspects of extra assessing which extension mechanism to choose. Aspects of extra
response time needed to perform the extra queries, costs of pre- response time needed to perform the extra queries, costs of pre-
calculation of possible answers, or the costs induced to the system calculation of possible answers, or the costs induced to the system
as a whole come to mind. At the time of writing none of these as a whole come to mind. At the time of writing, none of these
proposals has been published as standards-track RFCs. proposals has been published as Standards Track RFCs.
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 Resource Record Type. This Resource Record Type can stored in some Resource Record Type. This Resource Record Type can
either be a new Resource Record Type or an existing Resource Record be either a new Resource Record Type or an existing Resource Record
Type that has an appropriate format to store the data. One also Type that has an appropriate format to store the data. One also
might need some other selection mechanism, such as the ability to might need some other selection mechanism, such as the ability to
distinguish between the records in an RRSet given they have the same distinguish between the records in an RRSet, given they have the same
Resource Record Type. Because of this, one needs to both register a Resource Record Type. Because of this, one needs to both register a
unique prefix and define what Resource Record Type is to be used for unique prefix and define what Resource Record Type is to 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 that 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 has in the records. For 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
as a result might be administered by two different organisations, and as a result might be administered by two different organizations, and
signed by two different entities when using DNSSEC. For these two signed by two different entities when using DNSSEC. For these two
reasons, using a prefix has recently become a very interesting reasons, using a prefix has recently become a very interesting
solution for many protocol designers. In some cases when using TXT solution for many protocol designers. In some cases, e.g.,
records (e.g. DomainKeys Identified Mail Signatures [RFC4871]), in DomainKeys Identified Mail Signatures [RFC4871], TXT records have
other cases when adding new Resource Record Types (SRV). been used. In others, such as SRV, entirely new Resource Record
Types have been added.
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 {owner, class, type}
and therefore the RRSet. In this case, since the query name can be triple, and therefore the RRSet. In this case, since the query name
set to exactly the data one wants the size of the RRSet is minimized. can be set to exactly the data one wants, the size of the RRSet is
The problem with adding a suffix is that it creates a parallel tree minimized. The problem with adding a suffix is that it creates a
within the IN class. Further, there is no technical mechanism to parallel tree within the IN class. Further, there is no technical
ensure that the delegation for "example.com" and "example.com._bar" mechanism to ensure that the delegation for "example.com" and
are made to the same organization. Furthermore, data associated with "example.com._bar" are made to the same organization. Furthermore,
a single entity will now be stored in two different zones, such as data associated with a single entity will now be stored in two
"example.com" and "example.com._bar", which, depending on who different zones, such as "example.com" and "example.com._bar", which,
controls "_bar", can create new synchronization and update depending on who controls "_bar", can create new synchronization and
authorization issues. update 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 RFC 2672 [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 Resource Record Type that has an appropriate format to stored in some Resource Record Type that has an appropriate format to
store the data. This implies that one might have to mix the prefix store the data. This implies that one might have to mix the prefix
based selection mechanism with some other mechanism so that the right based selection mechanism with some other mechanism so that the right
Resource Record can be found out of many in a potential larger RRSet. Resource Record can be found out of many in a potential larger RRSet.
In RFC 2163 [RFC2163] an infix token is inserted directly below the In RFC 2163 [RFC2163] an infix token is inserted directly below the
TLD, but the result is equivalent to adding a suffix to the owner Top-Level Domain (TLD), but the result is equivalent to adding a
name (instead of creating a TLD, one is creating a second level suffix to the owner name (instead of creating a TLD, one is creating
domain). 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 Resource Records) is itself tied delegation tree (represented by NS Resource Records) is itself tied
to a specific class, attempting to resolve a query by crossing a to a specific class, attempting to resolve a query by crossing a
class boundary may produce unexpected results because there is no class boundary may produce unexpected results because there is no
guarantee that the name servers for the zone in the new class will be guarantee that the name servers for the zone in the new class will be
the same as the name servers in the IN class. The MIT Hesiod system the same as the name servers in the IN class. The MIT Hesiod system
[Dyer 87] used a scheme like this for storing data in the HS class, [Dyer87] used a scheme like this for storing data in the HS class,
but only on a very small scale (within a single institution), and but only on a very small scale (within a single institution), and
with an administrative fiat requiring that the delegation trees for with an administrative fiat requiring that the delegation trees for
the IN and HS trees be identical. The use of the HS class for such the IN and HS trees be identical. The use of the HS class for such
storage of non-sensitive data was over time replaced by use of the storage of non-sensitive data was, over time, replaced by use of the
Lightweight Directory Access Protocol (LDAP) [RFC4511]. Lightweight Directory Access Protocol (LDAP) [RFC4511].
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 Resource Record Type that has an appropriate format to stored in some Resource Record Type that has an appropriate format.
store the data.
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 at the Primary Master name server. For some server
implementations, the user interface only accepts Resource Record implementations, the user interface only accepts Resource Record
Types which it understands (perhaps so that the implementation Types that it understands (perhaps so that the implementation can
can attempt to validate the data). Other implementations allow attempt to validate the data). Other implementations allow the
the zone administrator to enter an integer for the Resource zone administrator to enter an integer for the Resource Record
Record Type code and the RDATA in Base64 or hexadecimal encoding Type code and the RDATA in Base64 or hexadecimal encoding (or
(or even as raw data). RFC 3597 [RFC3597] specifies a standard even as raw data). RFC 3597 [RFC3597] specifies a standard
generic encoding for this purpose. generic 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 Resource Record Types. Historically, includes records of unknown Resource Record Types. Historically,
some implementations have had problems parsing stored copies of some implementations have had problems parsing stored copies of
the zone file after restarting, but those problems have not been the zone file after restarting, but those problems have not been
seen for a few years. Some implementations use an alternate seen for a few years. Some implementations use an alternate
mechanism (e.g., LDAP) to transfer Resource Records in a zone, mechanism (e.g., LDAP) to transfer Resource Records in a zone,
and are primarily used within corporate environments; in this and are primarily used within corporate environments; in this
case name servers must be able to transfer new Resource Record case, name servers must be able to transfer new Resource Record
Types using whatever mechanism is used. However, today this Types using whatever mechanism is used. However, today this
alternative mechanism may not support unknown Resource Record alternative mechanism may not support unknown Resource Record
Types. Hence, in Internet environments, unknown Resource Record Types. Hence, in Internet environments, unknown Resource Record
Types are supported, but in corporate environments they are Types are supported, but in corporate environments they are
problematic. problematic.
3. A caching resolver (most commonly a recursive name server) will 3. A caching resolver (most commonly a recursive name server) will
cache the records which are responses to queries. As mentioned cache the records that are responses to queries. As mentioned in
in RFC 3597 [RFC3597], there are various pitfalls where a RFC 3597 [RFC3597], there are various pitfalls where a recursive
recursive name server might end up having problems. name server might end up having problems.
4. The application must be able to get the RRSet with a new Resource 4. The application must be able to get the RRSet with a new Resource
Record Type. The application itself may understand the RDATA, Record Type. The application itself may understand the 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 Resource Record Types has interface for retrieving arbitrary DNS Resource Record Types has
been a requirement since 1989 (see RFC 1123 [RFC1123] Section been a requirement since 1989 (see Section 6.1.4.2 of [RFC1123]).
6.1.4.2). Some stub resolver library implementations neglect to Some stub resolver library implementations neglect to provide
provide this functionality and cannot handle unknown Resource this functionality and cannot handle unknown Resource Record
Record Types, but implementation of a new stub resolver library Types, but implementation of a new stub resolver library is not
is not particularly difficult, and open source libraries that particularly difficult, and open source libraries that already
already provide this functionality are available. provide this functionality are available.
Historically, adding a new Resource Record Type has been very Historically, adding a new Resource Record Type has been very
problematic. The review process has been cumbersome, DNS servers problematic. The review process has been cumbersome, DNS servers
have not been able to handle new Resource Record Types, and firewalls have not been able to handle new Resource Record Types, and firewalls
have dropped queries or responses with Resource Record Types that are have dropped queries or responses with Resource Record Types that are
unknown to the firewall. This is for example one of the reasons the unknown to the firewall. This is, for example, one of the reasons
ENUM standard reuses the NAPTR Resource Record, a decision that today the ENUM standard reuses the NAPTR Resource Record, a decision that
might have gone to creating a new Resource Record Type instead. today might have gone to creating a new Resource Record Type instead.
Today, there is a requirement that DNS software handle unknown Today, there is a requirement that DNS software handle unknown
Resource Record Types, and investigations have shown that software Resource Record Types, and investigations have shown that software
that is deployed in general does support it, except in some alternate that is deployed, in general, does support it, except in some
mechanisms for transferring Resource Records such as LDAP as noted alternate mechanisms for transferring Resource Records such as LDAP,
above. Also, the approval process for new Resource Record Types has as noted above. Also, the approval process for new Resource Record
been updated [RFC5395] so the effort that is needed for various Types has been updated [RFC5395] so the effort that is needed for
Resource Record Types is more predictable. various Resource Record Types is more predictable.
4. Zone boundaries are invisible to applications 4. Zone Boundaries are Invisible to Applications
Regardless of the possible choices above we have seen a number of Regardless of the possible choices above, we have seen a number of
cases where the application made assumptions about the structure of cases where the application made assumptions about the structure of
the namespace and the location where specific information resides. the namespace and the location where specific information resides.
We take a small sidestep to argue against such approaches. We take a small sidestep to argue against such approaches.
The DNS namespace is a hierarchy, technically speaking. However, The DNS namespace is a hierarchy, technically speaking. However,
this only refers to the way names are built from multiple labels. this only refers to the way names are built from multiple labels.
DNS hierarchy neither follows nor implies administrative hierarchy. DNS hierarchy neither follows nor implies administrative hierarchy.
Because of that, it cannot be assumed that data attached to a node in Because of that, it cannot be assumed that data attached to a node in
the DNS tree is valid for the whole subtree. Technically, there are the DNS tree is valid for the whole subtree. Technically, there are
zone boundaries partitioning the namespace, and administrative zone boundaries partitioning the namespace, and administrative
boundaries (or policy boundaries) may even exist elsewhere. boundaries (or policy boundaries) may even exist elsewhere.
The false assumption has lead to an approach called "tree climbing", The false assumption has lead to an approach called "tree climbing",
where a query that does not receive a positive response (either the 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 requested RRSet was missing or the name did not exist) is retried by
repeatedly stripping off the leftmost label (climbing towards the repeatedly stripping off the leftmost label (climbing towards the
root) until the root domain is reached. Sometimes these proposals 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 try to avoid the query for the root or the TLD level, but still this
approach has severe drawbacks: approach has severe drawbacks:
o Technically, the DNS was built as a query - response tool without o Technically, the DNS was built as a query-response tool without
any search capability [RFC3467]. Adding the search mechanism any search capability [RFC3467]. Adding the search mechanism
imposes additional burden on the technical infrastructure, in the imposes additional burden on the technical infrastructure, in the
worst case on TLD and root name servers. worst case on TLD and root name servers.
o For reasons similar to those outlined in RFC 1535 [RFC1535], o For reasons similar to those outlined in RFC 1535 [RFC1535],
querying for information in a domain outside the control of the querying for information in a domain outside the control of the
intended entity may lead to incorrect results and may also put intended entity may lead to incorrect results and may also put
security at risk. Finding the exact policy boundary is impossible security at risk. Finding the exact policy boundary is impossible
without an explicit marker which does not exist at present. At without an explicit marker, which does not exist at present. At
best, software can detect zone boundaries (e.g., by looking for best, software can detect zone boundaries (e.g., by looking for
SOA Resource Records), but some TLD registries register names SOA Resource Records), but some TLD registries register names
starting at the second level (e.g., CO.UK), and there are various starting at the second level (e.g., CO.UK), and there are various
other "registry" types at second, third or other level domains other "registry" types at second, third, or other level domains
that cannot be identified as such without policy knowledge that cannot be identified as such without policy knowledge
external to the DNS. external to the DNS.
To restate, the zone boundary is purely a boundary that exists in the To restate, the zone boundary is purely a boundary that exists in the
DNS for administrative purposes, and applications should be careful DNS for administrative purposes, and applications should be careful
not to draw unwarranted conclusions from zone boundaries. A not to draw unwarranted conclusions from zone boundaries. A
different way of stating this is that the DNS does not support 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 inheritance, e.g., an MX RRSet for a TLD will not be valid for any
any subdomain of that particular TLD. subdomain of that particular TLD.
5. Why adding a new Resource Record Type is the preferred solution 5. Why Adding a New Resource Record Type Is the Preferred Solution
By now, the astute reader might be wondering what conclusions to draw By now, the astute reader might be wondering what conclusions to draw
from the issues presented so far. We will now attempt to clear up from the issues presented so far. We will now attempt to clear up
the reader's confusion by following the thought processes of a the reader's confusion by following the thought processes of a
typical application designer who wishes to store data in the DNS. typical application designer who wishes to store data in the DNS.
We'll show how such a designer almost inevitably hits upon the idea We'll show how such a designer almost inevitably hits upon the idea
of just using a TXT Resource Record, why this is a bad thing, and why of just using a TXT Resource Record, why this is a bad thing, and why
a new Resource Record Type should be allocated instead. And we'll a new Resource Record Type should be allocated instead. We'll also
also explain how the reuse of an existing resource record, including explain how the reuse of an existing Resource Record, including TXT,
TXT, can be made less harmful. can be made less harmful.
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 regards it as a distributed database in which own sake, but rather regards it 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 application is usually looking for the easiest way to add whatever
new data the application needs to the DNS in a way that naturally new data the application needs to the DNS in a way that naturally
associates the data with a DNS name and does not require major associates the data with a DNS name and does not require major
changes to DNS servers. changes to DNS servers.
skipping to change at page 11, line 15 skipping to change at page 11, line 24
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 regards it as a distributed database in which own sake, but rather regards it 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 application is usually looking for the easiest way to add whatever
new data the application needs to the DNS in a way that naturally new data the application needs to the DNS in a way that naturally
associates the data with a DNS name and does not require major associates the data with a DNS name and does not require major
changes to DNS servers. changes to DNS servers.
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 Resource Record Type is the technically correct answer Adding a new Resource Record Type is the technically correct answer
from the DNS protocol standpoint (more on this below), but doing so from the DNS protocol standpoint (more on this below), but doing so
requires some DNS expertise, due to the issues listed in Section 3.5. requires some DNS expertise, due to the issues listed in Section 3.5.
Consequently, this option is often rejected. Note that according to Consequently, this option is often rejected. Note that according to
RFC 5395 [RFC5395], some Types require IETF Consensus, while others RFC 5395 [RFC5395], some Types require IETF Consensus, while others
only require a specification. only require a specification.
There is a drawback to defining new RR types that is worth There is a drawback to defining new RR types that is worth
mentioning. The Resource Record Type (RRTYPE) is a 16 bit value and mentioning. The Resource Record Type (RRTYPE) is a 16-bit value and
hence is a limited resource. In order to prevent hoarding the hence is a limited resource. In order to prevent hoarding the
registry has a review based allocation policy [RFC5395], however this registry has a review-based allocation policy [RFC5395]; however,
may not be sufficient if extension of the DNS by addition of new RR this may not be sufficient if extension of the DNS by addition of new
types takes up significantly and the registry starts nearing RR types takes up significantly and the registry starts nearing
completion. In that case the trade-offs with respect to choosing an completion. In that case, the trade-offs with respect to choosing an
extension mechanism may need to change. extension mechanism may need to change.
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 Types 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 from application. This has not completely prevented proposals from
reusing existing Resource Record Types in ways incompatible with reusing existing Resource Record Types in ways incompatible with
their defined semantics, but it does tend to steer application their defined semantics, but it does tend to steer application
designers away from this approach. designers away from this approach.
For example, Resource Record Type 40 was registered for the SINK For example, Resource Record Type 40 was registered for the SINK
Resource Record Type. This Resource Record Type was discussed in the Resource Record Type. This Resource Record Type was discussed in the
DNSIND working group of the IETF, and it was decided at the 46th IETF DNSIND working group of the IETF, and it was decided at the 46th IETF
to not move the I-D forward to become an RFC because of the risk of to not move the I-D forward to become an RFC because of the risk of
encouraging application designers to use the SINK Resource Record encouraging application designers to use the SINK Resource Record
Type instead of registering a new Resource Record Type, which would Type instead of registering a new Resource Record Type, which would
result in infeasibly large SINK RRsets. result in infeasibly large SINK RRsets.
Eliminating all of the above leaves the TXT Resource Record Type in Eliminating all of the above leaves the TXT Resource Record Type in
the IN class. The TXT RDATA format is free form text, and there are the IN class. The TXT RDATA format is free form text, and there are
no existing semantics to get in the way. Some attempts have been no existing semantics to get in the way. Some attempts have been
made, for example in draft-cheshire-dnsext-dns-sd made, for example, in [DNSEXT-DNS-SD], to specify a structured format
[I-D.cheshire-dnsext-dns-sd], to specify a structured format for TXT for TXT Resource Record Types, but no such attempt has reached RFC
Resource Record Types, but no such attempt has reached RFC status. status. Furthermore, the TXT Resource Record can obviously just be
Furthermore, the TXT Resource Record can obviously just be used as a used as a bucket in which to carry around data to be used by some
bucket in which to carry around data to be used by some higher level higher-level parser, perhaps in some human-readable programming or
parser, perhaps in some human readable programming or markup markup language. Thus, for many applications, TXT Resource Records
language. Thus, for many applications, TXT Resource Records are the are the "obvious" choice. Unfortunately, this conclusion, while
"obvious" choice. Unfortunately, this conclusion, while
understandable, is also problematic, for several reasons. understandable, is also problematic, for several reasons.
The first reason why TXT Resource Records are not well suited to such The first reason why TXT Resource Records are not well suited to such
use is precisely what makes them so attractive: the lack of pre- use is precisely what makes them so attractive: the lack of pre-
defined common syntax or structure. As a result, each application defined common syntax or structure. As a result, each application
that uses them creates its own syntax/structure, and that makes it that uses them creates its own syntax/structure, and that makes it
difficult to reliably distinguish one application's record from difficult to reliably distinguish one application's record from
others, and for its parser to avoid problems when it encounters other others, and for its parser to avoid problems when it encounters other
TXT records. TXT records.
skipping to change at page 12, line 39 skipping to change at page 12, line 49
long as TXT Resource Records are being used by human beings or by long as TXT Resource Records are being used by human beings or by
private agreement between data producer and data consumer. However, private agreement between data producer and data consumer. However,
it becomes a problem once one starts using them for standardized 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. If TXT records are used without one of producer and data consumer. If TXT records are used without one of
the naming modifications discussed earlier (and in some cases even if the naming modifications discussed earlier (and in some cases even if
one uses such naming mechanisms), there is nothing to prevent one uses such naming mechanisms), there is nothing to prevent
collisions with some other incompatible use of TXT Resource Records. collisions with some other incompatible use of TXT Resource Records.
This is even worse than the general subtyping problem described in This is even worse than the general subtyping problem described in
Section 3.1, because TXT Resource Records don't even have a Section 3.1 because TXT Resource Records don't even have a
standardized selector field in which to store the subtype. RFC 1464 standardized selector field in which to store the subtype. RFC 1464
[RFC1464] tried, but it was not a success. At best a definition of a [RFC1464] tried, but it was not a success. At best, a definition of
subtype is reduced to hoping that whatever scheme one has come up a subtype is reduced to hoping that whatever scheme one has come up
with will not accidently conflict with somebody else's subtyping with will not accidently conflict with somebody else's subtyping
scheme, and that it will not be possible to mis-parse one scheme, and that it will not be possible to mis-parse one
application's use of TXT Resource Records as data intended for a application's use of TXT Resource Records as data intended for a
different application. Any attempt to impose a standardized format different application. Any attempt to impose a standardized format
within the TXT Resource Record format would be at least fifteen years 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 too late, even if it were put into effect immediately; at best, one
can restrict the syntax that a particular application uses within a can restrict the syntax that a particular application uses within a
TXT Resource Record and accept the risk that unrelated TXT Resource TXT Resource Record and accept the risk that unrelated TXT Resource
Record uses will collide with it. 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, (and have been used Section 3.3 would address the subtyping problem, (and have been used
in combinations with reuse of TXT record, such as for the dns/txt in combinations with reuse of TXT record, such as for the dns/txt
lookup mechanism in DKIM) but each of these approaches brings in new lookup mechanism in Domain Keys Identified Mail (DKIM)) but each of
problems of its own. The prefix approach (that for example SRV these approaches brings in new problems of its own. The prefix
Resource Records use) does not work well with wildcards, which is a approach (that for example SRV Resource Records use) does not work
particular problem for mail-related applications, since MX Resource well with wildcards, which is a particular problem for mail-related
Records are probably the most common use of DNS wildcards. The applications, since MX Resource Records are probably the most common
suffix approach doesn't have wildcard issues, but, as noted use of DNS wildcards. The suffix approach doesn't have wildcard
previously, it does have synchronization and update authorization issues, but, as noted previously, it does have synchronization and
issues, since it works by creating a second subtree in a different update authorization issues, since it works by creating a second
part of the global DNS name space. subtree in a different part of the global DNS namespace.
The next reason why TXT Resource Records are not well suited to The next reason why TXT Resource Records are not well suited to
protocol use has to do with the limited data space available in a DNS protocol use has to do with the limited data space available in a DNS
message. As alluded to briefly in Section 3.1, typical DNS query message. As alluded to briefly in Section 3.1, typical DNS query
traffic patterns involve a very large number of DNS clients sending traffic patterns involve a very large number of DNS clients sending
queries to a relatively small number of DNS servers. Normal path MTU queries to a relatively small number of DNS servers. Normal path MTU
discovery schemes do little good here because, from the server's discovery schemes do little good here because, from the server's
perspective, there isn't enough repeat traffic from any one client perspective, there isn't enough repeat traffic from any one client
for it to be worth retaining state. UDP-based DNS is an idempotent for it to be worth retaining state. UDP-based DNS is an idempotent
query, whereas TCP-based DNS requires the server to keep state (in query, whereas TCP-based DNS requires the server to keep state (in
the form of TCP connection state, usually in the server's kernel) and the form of TCP connection state, usually in the server's kernel) and
roughly triples the traffic load. Thus, there's a strong incentive roughly triples the traffic load. Thus, there's a strong incentive
to keep DNS messages short enough to fit in a UDP datagram, to keep DNS messages short enough to fit in a UDP datagram,
preferably a UDP datagram short enough not to require IP preferably a UDP datagram short enough not to require IP
fragmentation. fragmentation.
Subtyping schemes are therefore again problematic because they Subtyping schemes are therefore again problematic because they
produce larger Resource RRSets than necessary, but verbose text produce larger Resource RRSets than necessary, but verbose text
encodings of data are also wasteful, since the data they hold can encodings of data are also wasteful since the data they hold can
usually be represented more compactly in a Resource Record designed usually be represented more compactly in a Resource Record designed
specifically to support the application's particular data needs. If specifically 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 the data that 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 make them fit comfortably into the DNS regardless of encoding, it is
probably better to move the data somewhere else, and just use the DNS probably better to move the data somewhere else, and just use the DNS
as a pointer to the data, as with NAPTR. as a pointer to the data, as with NAPTR.
6. Conclusion and Recommendation 6. Conclusion and Recommendation
Given the problems detailed in Section 5, 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 Resource Record Type oft-jumped-to conclusion that specifying a new Resource Record Type
is hard. Historically, this was indeed the case, but recent surveys is hard. Historically, this was indeed the case, but recent surveys
suggest that support for unknown Resource Record Types [RFC3597] is suggest that support for unknown Resource Record Types [RFC3597] is
now widespread in the public Internet, and because of that the DNS now widespread in the public Internet, and because of that, the DNS
infrastructure can handle new Resource Record Types. The lack of infrastructure can handle new Resource Record Types. The lack of
support for unknown Types remains an issue for relatively old support for unknown Types remains an issue for relatively old
provisioning software and in corporate environments. provisioning software and in corporate environments.
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. Investigations with zone in some respects the most difficult. Investigations with zone
transfers show that the problem is less difficult for the transfers show that the problem is less difficult for the
authoritative name servers themselves than the front-end systems used authoritative name servers themselves than the front-end systems used
to enter (and perhaps validate) the data. Hand editing does not work to enter (and perhaps validate) the data. Hand editing does not work
well for maintenance of large zones, so some sort of tool is well for maintenance of large zones, so some sort of tool is
necessary, and the tool may not be tightly coupled to the name server necessary, and the tool may not be tightly coupled to the name server
implementation itself. Note, however, that this provisioning problem implementation itself. Note, however, that this provisioning problem
exists to some degree with any new form of data to be stored in the exists to some degree with any new form of data to be stored in the
DNS, regardless of data format, Resource Record type (even if TXT DNS, regardless of data format, Resource Record type (even if TXT
Resource Record Types are in use), or naming scheme. Adapting front- Resource Record Types are in use), or naming scheme. Adapting front-
end systems to support a new Resource Record Type may be a bit more end systems to support a new Resource Record Type may be a bit more
difficult than reusing an existing type, but this appears to be a difficult than reusing an existing type, but this appears to be a
minor difference in degree rather than a difference in kind. 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 that 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 Resource o on the whole, the best solution is still to use the DNS Resource
Record Type mechanism designed for precisely this purpose, Record Type mechanism designed for precisely this purpose,
whenever possible, and whenever possible, and
o of all the alternate solutions, the "obvious" approach of using o of all the alternate solutions, the "obvious" approach of using
TXT Resource Records for arbitrary names is almost certainly the TXT Resource Records for arbitrary names is almost certainly the
worst, especially for the two reasons outlined above (lack of worst, especially for the two reasons outlined above (lack of
semantics and its implementations, and size leading to the need to semantics and its implementations, and size leading to the need to
use TCP). use TCP).
7. Creating A New Resource Record Type 7. Creating a New Resource Record Type
The process for creating a new Resource Record Type is specified in The process for creating a new Resource Record Type is specified in
RFC 5395 [RFC5395]. RFC 5395 [RFC5395].
8. IANA Considerations 8. Security Considerations
This document does not require any IANA actions.
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 the DNS. DNSSEC signatures significantly increase the size data in the DNS. DNSSEC signatures significantly increase the size
of the messages transported, and because of this, the DNS message of the messages transported, and because of this, the DNS message
size issues discussed in Section 3.1 and Section 5 are more serious size issues discussed in Sections 3.1 and 5 are more serious than
than they might at first appear. they might at first appear.
Adding new Resource Record Types (as discussed in Section 3.5) can Adding new Resource Record Types (as discussed in Section 3.5) can
create two different kinds of problems. In DNS software and in create two different kinds of problems: in the DNS software and in
applications. In the DNS software, it might conceivably trigger bugs applications. In the DNS software, it might conceivably trigger bugs
and other bad behavior in software that is not compliant with RFC and other bad behavior in software that is not compliant with RFC
3597 [RFC3597], but most such DNS software is old enough and insecure 3597 [RFC3597], but most such DNS software is old enough and insecure
enough that it should be updated for other reasons in any case. In enough that it should be updated for other reasons in any case. In
applications and provisioning software, the changes for the new applications and provisioning software, the changes for the new
features that need the new data in DNS can be updated to understand features that need the new data in the DNS can be updated to
the structure of the new data format (regardless of whether a new understand the structure of the new data format (regardless of
Resource Record Type is used or some other mechanism is chosen. whether a new Resource Record Type is used or some other mechanism is
Basic API support for retrieving arbitrary Resource Record Types has chosen). Basic API support for retrieving arbitrary Resource Record
been a requirement since 1989 [RFC1123]. Types has been a requirement since 1989 [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. enough not to be riddled with well-known exploitable bugs.
10. Acknowledgements 9. Acknowledgements
This document has been created during a number of years, with input This document has been created over 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 tradeoffs, and make goal is instead to describe the architecture and tradeoffs, and make
some recommendations about best practices. some recommendations about best practices.
People that have helped include: Dean Andersson, Mark Andrews, John People that have helped include: Dean Anderson, Mark Andrews, John
Angelmo, Roy Badami, Dan Bernstein, Alex Bligh, Nathaniel Borenstein, Angelmo, Roy Badami, Dan Bernstein, Alex Bligh, Nathaniel Borenstein,
Stephane Bortzmeyer, Brian Carpenter, Leslie Daigle, Elwyn Davies, Stephane Bortzmeyer, Brian Carpenter, Leslie Daigle, Elwyn Davies,
Mark Delany, Richard Draves, Martin Duerst, Donald Eastlake, Robert Mark Delany, Richard Draves, Martin Duerst, Donald Eastlake, Robert
Elz, Jim Fenton, Tony Finch, Jim Gilroy, Olafur Gudmundsson, Eric Elz, Jim Fenton, Tony Finch, Jim Gilroy, Olafur Gudmundsson, Eric
Hall, Philip Hallam-Baker, Ted Hardie, Bob Hinden, Paul Hoffman, Hall, Phillip Hallam-Baker, Ted Hardie, Bob Hinden, Paul Hoffman,
Geoff Houston, Christian Huitema, Johan Ihren, John Klensin, Olaf Geoff Houston, Christian Huitema, Johan Ihren, John Klensin, Ben
Kolkman, Ben Laurie, William Leibzon, John Levine, Edward Lewis, Laurie, William Leibzon, John Levine, Edward Lewis, David MacQuigg,
David MacQuigg, Allison Manking, Bill Manning, David Meyer, Pekka Allison Mankin, Bill Manning, David Meyer, Pekka Nikander, Mans
Nikander, Mans Nilsson, Masataka Ohta, Douglas Otis, Michael Patton, Nilsson, Masataka Ohta, Douglas Otis, Michael Patton, Jonathan
Jonathan Rosenberg, Anders Rundgren, Miriam Sapiro, Carsten Rosenberg, Anders Rundgren, Miriam Sapiro, Carsten Strotmann, Pekka
Strotmann, Pekka Savola, Chip Sharp, James Snell, Michael Thomas, Savola, Chip Sharp, James Snell, Michael Thomas, Paul Vixie, Sam
Paul Vixie, Sam Weiler, Florian Weimer, Bert Wijnen, and Dan Wing. Weiler, Florian Weimer, Bert Wijnen, and Dan Wing.
11. IAB Members at the time of this writing 10. IAB Members at the Time of This Writing
Loa Andersson Loa Andersson
Gonzalo Camarillo Gonzalo Camarillo
Stuart Cheshire Stuart Cheshire
Russ Housley Russ Housley
Olaf Kolkman Olaf Kolkman
Gregory Lebovitz Gregory Lebovitz
Barry Leiba Barry Leiba
Kurtis Lindqvist Kurtis Lindqvist
Andrew Malis Andrew Malis
Danny McPherson Danny McPherson
David Oran David Oran
Dave Thaler Dave Thaler
Lixia Zhang Lixia Zhang
12. References 11. References
12.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", STD 13, RFC 1035, November 1987.
[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store [RFC1464] Rosenbaum, R., "Using the Domain Name System To
Arbitrary String Attributes", RFC 1464, May 1993. Store Arbitrary String Attributes", RFC 1464,
May 1993.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, 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
(RR) Types", RFC 3597, September 2003. Record (RR) Types", RFC 3597, September 2003.
[RFC5395] Eastlake, D., "Domain Name System (DNS) IANA [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 5395, November 2008. Considerations", BCP 42, RFC 5395, November 2008.
12.2. Informative References 11.2. Informative References
[Dyer 87] Dyer, S. and F. Hsu, "Hesiod, Project Athena Technical [DNSEXT-DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service
Plan - Name Service", Version 1.9, April 1987. Discovery", Work in Progress, September 2008.
[I-D.cheshire-dnsext-dns-sd] [Dyer87] Dyer, S. and F. Hsu, "Hesiod, Project Athena
Cheshire, S. and M. Krochmal, "DNS-Based Service Technical Plan - Name Service", Version 1.9,
Discovery", draft-cheshire-dnsext-dns-sd-05 (work in April 1987.
progress), September 2008.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts -
and Support", STD 3, RFC 1123, October 1989. Application and Support", STD 3, RFC 1123,
October 1989.
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction [RFC1535] Gavron, E., "A Security Problem and Proposed
With Widely Deployed DNS Software", RFC 1535, Correction With Widely Deployed DNS Software",
October 1993. RFC 1535, October 1993.
[RFC2163] Allocchio, C., "Using the Internet DNS to Distribute MIXER [RFC2163] Allocchio, C., "Using the Internet DNS to Distribute
Conformant Global Address Mapping (MCGAM)", RFC 2163, MIXER Conformant Global Address Mapping (MCGAM)",
January 1998. RFC 2163, January 1998.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997. Specification", RFC 2181, July 1997.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
RFC 2672, August 1999. RFC 2672, August 1999.
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the
Resource Record (RR)", RFC 3445, December 2002. KEY Resource Record (RR)", RFC 3445, December 2002.
[RFC3467] Klensin, J., "Role of the Domain Name System (DNS)", [RFC3467] Klensin, J., "Role of the Domain Name System (DNS)",
RFC 3467, February 2003. 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
System (DDDS) Application (ENUM)", RFC 3761, April 2004. Discovery System (DDDS) Application (ENUM)",
RFC 3761, April 2004.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and
(LDAP): The Protocol", RFC 4511, June 2006. S. Rose, "DNS Security Introduction and
Requirements", RFC 4033, March 2005.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and
System", RFC 4592, July 2006. S. Rose, "Resource Records for the DNS Security
Extensions", RFC 4034, March 2005.
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and
J., and M. Thomas, "DomainKeys Identified Mail (DKIM) S. Rose, "Protocol Modifications for the DNS
Signatures", RFC 4871, May 2007. Security Extensions", RFC 4035, March 2005.
[RFC4511] Sermersheim, J., "Lightweight Directory Access
Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, July 2006.
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M.,
Fenton, J., and M. Thomas, "DomainKeys Identified
Mail (DKIM) Signatures", RFC 4871, May 2007.
Authors' Addresses Authors' Addresses
Internet Architecture Board Internet Architecture Board
Email: iab@iab.org EMail: iab@iab.org
Patrik Faltstrom (editor) Patrik Faltstrom (editor)
Email: paf@cisco.com EMail: paf@cisco.com
Rob Austein (editor) Rob Austein (editor)
Email: sra@isc.org EMail: sra@isc.org
Peter Koch (editor) Peter Koch (editor)
Email: pk@denic.de EMail: pk@denic.de
 End of changes. 109 change blocks. 
277 lines changed or deleted 277 lines changed or added

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