draft-iab-dns-choices-07.txt   draft-iab-dns-choices-08.txt 
Network Working Group IAB Network Working Group IAB
Internet-Draft P. Faltstrom, Ed. Internet-Draft P. Faltstrom, Ed.
Intended status: Informational R. Austein, Ed. Intended status: Informational R. Austein, Ed.
Expires: February 12, 2009 P. Koch, Ed. Expires: September 8, 2009 P. Koch, Ed.
August 11, 2008 March 7, 2009
Design Choices When Expanding DNS Design Choices When Expanding DNS
draft-iab-dns-choices-07 draft-iab-dns-choices-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 February 12, 2009. This Internet-Draft will expire on September 8, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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
skipping to change at page 2, line 24 skipping to change at page 2, line 27
3.4. Add a new Class . . . . . . . . . . . . . . . . . . . . . 7 3.4. Add a new Class . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . 13
7. Creating A New Resource Record Type . . . . . . . . . . . . . 14 7. Creating A New Resource Record Type . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. IAB Members at the time of this writing . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
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 which 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 transfered 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 the
triple {Owner, Resource Record Type, Resource Record Class}. triple {Owner, Resource Record Type, Resource Record Class}.
Historically, extending DNS to store application data 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
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 which use a prefixing scheme in combination with a base
skipping to change at page 3, line 46 skipping to change at page 3, line 46
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 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. An example of new data is key data that already exist in the DNS. Examples of new data are key
information for SSH and data used for authenticating sender of email information for SSH and data used for authenticating the sender of
messages (metadata tied to MX Resource Records). If the new data are email messages (metadata tied to MX Resource Records). If the new
tied to data that already exist in the DNS, an analysis should be data are tied to data that already exist in the DNS, an analysis
made as to whether having (for example) address records and SSH key should be made as to whether having (for example) address records and
information in different DNS zones is a problem or if it is a bonus, SSH key information in different DNS zones is a problem or if it is a
and if it is a problem, whether the specification must require all of bonus, and if it is a problem, whether the specification must require
the related data to be in the same zone. One specific difference all of the related data to be in the same zone. One specific
between having the records in the same zone or not has to do with difference between having the records in the same zone or not has to
maintenance of the records. If they are in the same zone, the same do with maintenance of the records. If they are in the same zone,
maintainer (from a DNS perspective) manages the two records. the same maintainer (from a DNS perspective) manages the two records.
Specifically, they must be signed with the same DNSSEC keys if DNSSEC Specifically, they must be signed with the same DNSSEC keys if DNSSEC
is in use. 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 DNS should be used for service
discovery, or whether DNS should be used for storage of data specific discovery, or whether DNS should be used for storage of data specific
to the service. In general, DNS is a protocol that, apart from to the service. In general, DNS is a protocol that, apart from
holding metadata that makes the DNS itself function (NS, SOA, DNSSEC holding metadata that makes the DNS itself function (NS, SOA, DNSSEC
Resource Record Types, etc), only holds references to service Resource Record Types, etc), only holds references to service
locations (SRV, NAPTR, A, AAAA Resource Record Types) -- though there locations (SRV, NAPTR, A, AAAA Resource Record Types) -- though there
are exceptions, such as MX Resource Records. are exceptions, such as MX Resource Records.
2. Background 2. Background
See RFC 2929 [RFC2929] for a brief summary of DNS query structure. See RFC 5395 [RFC5395] for a brief summary of DNS query structure.
Readers interested in the full story should start with the base DNS Readers interested in the full story should start with the base DNS
specification in RFC 1035 [RFC1035], and continue with the various specification in RFC 1035 [RFC1035], and continue with the various
documents that update, clarify, and extend the base specification. 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. triple: a DNS name, a DNS class, and a DNS Resource Record Type.
Every Resource Record matching a particular name, class and type is Every Resource Record matching a particular name, class and type is
said to belong to the same Resource Record Set (RRSet), and the whole said to belong to the same Resource Record Set (RRSet), and 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,
skipping to change at page 7, line 13 skipping to change at page 7, line 13
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 organisations, 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 when using TXT
records (add reference to DKIM), in other cases when adding new records (e.g. DomainKeys Identified Mail Signatures [RFC4871]), in
Resource Record Types (SRV). other cases when adding new Resource Record Types (SRV).
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
skipping to change at page 7, line 41 skipping to change at page 7, line 41
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 TLD, but the result is equivalent to adding a suffix to the owner
name (instead of creating a TLD one is creating a second level name (instead of creating a TLD, one is creating a second level
domain). 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
used a scheme like this for storing data in the HS class, but only on [Dyer 87] used a scheme like this for storing data in the HS class,
a very small scale (within a single institution), and with an but only on a very small scale (within a single institution), and
administrative fiat requiring that the delegation trees for the IN with an administrative fiat requiring that the delegation trees for
and HS trees be identical. The use of the HS class for such storage the IN and HS trees be identical. The use of the HS class for such
of non-sensitive data was over time replaced by use of LDAP. storage of non-sensitive data was over time replaced by use of the
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 to
store the data. This implies that one might have to mix the prefix store the data.
based selection mechanism with some other mechanism so that the right
Resource Record can be found out of many in a potential larger RRSet.
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 Resource Record implementations, the user interface only accepts Resource Record
Types which it understands (perhaps so that the implementation Types which it understands (perhaps so that the implementation
can attempt to validate the data). Other implementations allow can attempt to validate the data). Other implementations allow
the zone administrator to enter an integer for the Resource the zone administrator to enter an integer for the Resource
Record Type code and the RDATA in Base64 or hexadecimal encoding Record Type code and the RDATA in Base64 or hexadecimal encoding
(or even as raw data). RFC 3597 [RFC3597] specifies a standard (or 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 Types. Historically, some includes records of unknown Resource Record Types. Historically,
implementations have had problems parsing stored copies of the some implementations have had problems parsing stored copies of
zone file after restarting, but those problems have not been seen the zone file after restarting, but those problems have not been
for a few years. seen for a few years. Some implementations use an alternate
mechanism (e.g., LDAP) to transfer Resource Records in a zone,
and are primarily used within corporate environments; in this
case name servers must be able to transfer new Resource Record
Types using whatever mechanism is used. However, today this
alternative mechanism may not support unknown Resource Record
Types. Hence, in Internet environments, unknown Resource Record
Types are supported, but in corporate environments they are
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 which are responses to queries. As mentioned
in RFC 3597 [RFC3597],there are various pitfalls where a in RFC 3597 [RFC3597],there are various pitfalls where a
recursive name server might end up having problems. recursive 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 RFC 1123 [RFC1123] Section
6.1.4.2). Some stub resolver library implementations neglect to 6.1.4.2). Some stub resolver library implementations neglect to
provide this functionality and cannot handle unknown Resource provide this functionality and cannot handle unknown Resource
Record Types, but implementation of a new stub resolver library Record Types, but implementation of a new stub resolver library
is not particularly difficult, and open source libraries that is not particularly difficult, and open source libraries that
already provide this functionality are available. already 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. Review process has been cumbersome, DNS servers have problematic. The review process has been cumbersome, DNS servers
not been able to handle new Resource Record Types, and firewalls have have not been able to handle new Resource Record Types, and firewalls
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 the
ENUM standard reuses the NAPTR Resource Record, a decision that today ENUM standard reuses the NAPTR Resource Record, a decision that today
might have gone to creating a new resource record type instead. 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. Also, the approval that is deployed in general does support it, except in some alternate
process for new Resource Record Types has been updated so the effort mechanisms for transferring Resource Records such as LDAP as noted
that is needed for various Resource Record Types is more predictable. above. Also, the approval process for new Resource Record Types has
been updated [RFC5395] so the effort that is needed for 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.
skipping to change at page 10, line 46 skipping to change at page 11, line 11
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. associates the data with a DNS name and does not require major
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 2929 [RFC2929], 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 RRTYPE is a 16 bit value and hence is a limited mentioning. The Resource Record Type (RRTYPE) is a 16 bit value and
resource. In order to prevent herding the registry has a review hence is a limited resource. In order to prevent hoarding the
based allocation policy [RFC2929], however this may not be sufficient registry has a review based allocation policy [RFC5395], however this
if extension of the DNS by addition of new RR types takes up may not be sufficient if extension of the DNS by addition of new RR
significantly and the registry starts nearing completion. In that types takes up significantly and the registry starts nearing
case the trade-offs with respect to choosing an extension mechanism completion. In that case the trade-offs with respect to choosing an
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 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 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.
skipping to change at page 11, line 51 skipping to change at page 12, line 16
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 draft-cheshire-dnsext-dns-sd
[I-D.cheshire-dnsext-dns-sd], to specify a structured format for TXT [I-D.cheshire-dnsext-dns-sd], to specify a structured format for TXT
Resource Record Types, but no such attempt has reached RFC status. Resource Record Types, but no such attempt has reached RFC status.
Furthermore, the TXT Resource Record can obviously just be used as a Furthermore, the TXT Resource Record can obviously just be used as a
bucket in which to carry around data to be used by some higher level bucket in which to carry around data to be used by some higher level
parser, perhaps in some human readable programming or markup parser, perhaps in some human readable programming or markup
language. Thus, for many applications, TXT Resource Records are the language. Thus, for many applications, TXT Resource Records are the
"obvious" choice. Unfortunately, this conclusion, while "obvious" choice. Unfortunately, this conclusion, while
understandable, is also wrong, 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.
Arguably, the TXT Resource Record is misnamed, and should have been Arguably, the TXT Resource Record is misnamed, and should have been
skipping to change at page 12, line 25 skipping to change at page 12, line 38
means only what the data producer says it means. This is fine, so means only what the data producer says it means. This is fine, so
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 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 a
subtype is reduced to hoping that whatever scheme one has come up 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
skipping to change at page 13, line 36 skipping to change at page 13, line 49
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, and because of that the DNS infrastructure can handle now widespread in the public Internet, and because of that the DNS
new resource record types. The lack of support for unknown Types is infrastructure can handle new Resource Record Types. The lack of
mostly an issue for relatively old provision software and support for unknown Types remains an issue for relatively old
applications that would probably need to be upgraded in any case as provisioning software and in corporate environments.
part of supporting a new feature (that require the new Resource
Record Type). One should also remember that deployed DNS software
today should support DNSSEC, and software recent enough to do so will
likely support both 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 problems can be divided in in some respects the most difficult. Investigations with zone
two, the ability to manage the zone on the master server, and the transfers show that the problem is less difficult for the
ability for secondary servers to do zone transfers (AXFR or IXFR) authoritative name servers themselves than the front-end systems used
with the new data. Investigations show that the problem here is less to enter (and perhaps validate) the data. Hand editing does not work
difficult for the authoritative name servers themselves than the well for maintenance of large zones, so some sort of tool is
front-end systems used to enter (and perhaps validate) the data. necessary, and the tool may not be tightly coupled to the name server
Hand editing does not work well for maintenance of large zones, so implementation itself. Note, however, that this provisioning problem
some sort of tool is necessary, and the tool may not be tightly exists to some degree with any new form of data to be stored in the
coupled to the name server implementation itself. Note, however, DNS, regardless of data format, Resource Record type (even if TXT
that this provisioning problem exists to some degree with any new Resource Record Types are in use), or naming scheme. Adapting front-
form of data to be stored in the DNS, regardless of data format, end systems to support a new Resource Record Type may be a bit more
Resource Record type (even if TXT Resource Record Types are in use), difficult than reusing an existing type, but this appears to be a
or naming scheme. Adapting front-end systems to support a new minor difference in degree rather than a difference in kind.
Resource 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 Resource o on the whole, the best solution is still to use the DNS Resource
Record Type mechanism designed for precisely this purpose, and Record Type mechanism designed for precisely this purpose,
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 is almost certainly the worst. TXT Resource Records for arbitrary names is almost certainly the
This especially for the two reasons outlined above (lack of semantics worst, especially for the two reasons outlined above (lack of
and its implications, and size leading to the need to use TCP). semantics and its implementations, and size leading to the need to
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
draft-ietf-dnsext-2929bis [I-D.ietf-dnsext-2929bis]. RFC 5395 [RFC5395].
8. IANA Considerations 8. IANA Considerations
This document does not require any IANA actions. This document does not require any IANA actions.
9. 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 the DNS. DNSSEC signatures significantly increase the size data in the DNS. DNSSEC signatures significantly increase the size
skipping to change at page 15, line 15 skipping to change at page 15, line 22
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 DNS can be updated to understand
the structure of the new data format (regardless of whether a new the structure of the new data format (regardless of whether a new
Resource Record Type is used or some other mechanism is chosen. Resource Record Type is used or some other mechanism is chosen.
Basic API support for retrieving arbitrary Resource Record Types has Basic API support for retrieving arbitrary Resource Record Types has
been a requirement since 1989[RFC1123]. 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. Because enough not to be riddled with well-known exploitable bugs.
of this, support for new Resource Record Types will not be as hard as
people might think at first.
10. 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 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, Loa Andersson, Mark People that have helped include: Dean Andersson, Mark Andrews, John
Andrews, John Angelmo, Roy Badami, Dan Bernstein, Alex Bligh, Angelmo, Roy Badami, Dan Bernstein, Alex Bligh, Nathaniel Borenstein,
Nathaniel Borenstein, Stephane Bortzmeyer, Brian Carpenter, Leslie Stephane Bortzmeyer, Brian Carpenter, Leslie Daigle, Elwyn Davies,
Daigle, Elwyn Davies, Mark Delany, Richard Draves, Martin Duerst, Mark Delany, Richard Draves, Martin Duerst, Donald Eastlake, Robert
Donald Eastlake, Robert Elz, Jim Fenton, Tony Finch, Jim Gilroy, Elz, Jim Fenton, Tony Finch, Jim Gilroy, Olafur Gudmundsson, Eric
Olafur Gudmundsson, Eric Hall, Philip Hallam-Baker, Ted Hardie, Bob Hall, Philip Hallam-Baker, Ted Hardie, Bob Hinden, Paul Hoffman,
Hinden, Paul Hoffman, Geoff Houston, Christian Huitema, Johan Ihren, Geoff Houston, Christian Huitema, Johan Ihren, John Klensin, Olaf
John Klensin, Olaf Kolkman, Ben Laurie, William Leibzon, John Levine, Kolkman, Ben Laurie, William Leibzon, John Levine, Edward Lewis,
Edward Lewis, David MacQuigg, Allison Manking, Bill Manning, Danny David MacQuigg, Allison Manking, Bill Manning, David Meyer, Pekka
McPherson, David Meyer, Pekka Nikander, Mans Nilsson, Masataka Ohta, Nikander, Mans Nilsson, Masataka Ohta, Douglas Otis, Michael Patton,
Douglas Otis, Michael Patton, Jonathan Rosenberg, Anders Rundgren, Jonathan Rosenberg, Anders Rundgren, Miriam Sapiro, Carsten
Miriam Sapiro, Carsten Strotmann, Pekka Savola, Chip Sharp, James Strotmann, Pekka Savola, Chip Sharp, James Snell, Michael Thomas,
Snell, Dave Thaler, Michael Thomas, Paul Vixie, Sam Weiler, Florian Paul Vixie, Sam Weiler, Florian Weimer, Bert Wijnen, and Dan Wing.
Weimer, Bert Wijnen, and Dan Wing.
Members of the IAB when this document was made available were: Loa 11. IAB Members at the time of this writing
Andersson, Gonzalo Camarillo, Stuart Cheshire, Russ Housley, Olaf
Kolkman, Gregory Lebovitz, Barry Leiba, Kurtis Lindqvist, Andrew
Malis, Danny McPherson, David Oran, Dave Thaler, and Lixia Zhang.
11. References Loa Andersson
Gonzalo Camarillo
Stuart Cheshire
Russ Housley
Olaf Kolkman
Gregory Lebovitz
Barry Leiba
Kurtis Lindqvist
Andrew Malis
Danny McPherson
David Oran
Dave Thaler
Lixia Zhang
11.1. Normative References 12. References
12.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 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, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. 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.
11.2. Informative References [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 5395, November 2008.
12.2. Informative References
[Dyer 87] Dyer, S. and F. Hsu, "Hesiod, Project Athena Technical
Plan - Name Service", Version 1.9, April 1987.
[I-D.cheshire-dnsext-dns-sd] [I-D.cheshire-dnsext-dns-sd]
Cheshire, S. and M. Krochmal, "DNS-Based Service Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", draft-ietf-dnsext-2929bis-06 (work in Discovery", draft-cheshire-dnsext-dns-sd-05 (work in
progress), August 2006. progress), September 2008.
[I-D.ietf-dnsext-2929bis]
Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", draft-cheshire-dnsext-dns-sd-03 (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", STD 3, RFC 1123, October 1989.
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction [RFC1535] Gavron, E., "A Security Problem and Proposed Correction
With Widely Deployed DNS Software", RFC 1535, With Widely Deployed DNS Software", RFC 1535,
October 1993. October 1993.
[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.
[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.
[RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning,
"Domain Name System (DNS) IANA Considerations", BCP 42,
RFC 2929, September 2000.
[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.
[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 Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004. System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[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 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, July 2006. 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)
skipping to change at page 18, line 4 skipping to change at line 788
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
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 39 change blocks. 
124 lines changed or deleted 149 lines changed or added

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