draft-iab-dns-choices-01.txt   draft-iab-dns-choices-02.txt 
Network Working Group P. Faltstrom Network Working Group P. Faltstrom
Internet-Draft R. Austein Internet-Draft IAB
Expires: September 5, 2005 IAB Expires: December 9, 2005 June 7, 2005
March 7, 2005
Design Choices When Expanding DNS Design Choices When Expanding DNS
draft-iab-dns-choices-01.txt draft-iab-dns-choices-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. 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 other groups may also distribute working documents as Internet-
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 September 5, 2005. This Internet-Draft will expire on December 9, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
This note discusses how to extend the DNS with new data for a new This note discusses how to extend the DNS with new data for a new
application. DNS extension discussion too often circulates around application. DNS extension discussion too often circulates around
reuse of the TXT record. This document lists different mechanisms to reuse of the TXT record. This document lists different mechanisms to
accomplish the extension to DNS, and comes to the conclusion that the accomplish the extension to DNS, and comes to the conclusion that the
use of a new RR Type is the best solution. use of a new RR Type is the best solution.
Table of Contents Table of Contents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
3.1 Place selectors inside the RDATA . . . . . . . . . . . . . 4 3.1 Place selectors inside the RDATA . . . . . . . . . . . . . 4
3.2 Add a prefix to the owner name . . . . . . . . . . . . . . 5 3.2 Add a prefix to the owner name . . . . . . . . . . . . . . 5
3.3 Add a suffix to the owner name . . . . . . . . . . . . . . 6 3.3 Add a suffix to the owner name . . . . . . . . . . . . . . 6
3.4 Add a new Class . . . . . . . . . . . . . . . . . . . . . 6 3.4 Add a new Class . . . . . . . . . . . . . . . . . . . . . 6
3.5 Add a new Resource Record Type . . . . . . . . . . . . . . 7 3.5 Add a new Resource Record Type . . . . . . . . . . . . . . 7
4. Conclusion (why adding a new RR type is the answer) . . . . . 8 4. Conclusion (why adding a new RR type is the answer) . . . . . 8
5. Conclusion and Recommendation . . . . . . . . . . . . . . . . 10 5. Conclusion and Recommendation . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11
8.2 Informative References . . . . . . . . . . . . . . . . . . . 12 8.2 Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 13
1. Introduction 1. Introduction
The DNS stores multiple categories of data. The two most commonly The DNS stores multiple categories of data. The two most commonly
used categories are infrastructure data for the DNS system itself (NS used categories are infrastructure data for the DNS system itself (NS
and SOA records) and data which have to do with mappings between and SOA records) and data which have to do with mappings between
domain names and IP addresses (A, AAAA and PTR). There are other domain names and IP addresses (A, AAAA and PTR). There are other
categories as well, some of which are tied to specific applications categories as well, some of which are tied to specific applications
like email (MX), while others are generic record types used to convey like email (MX), while others are generic record types used to convey
information for multiple protocols (SRV, NAPTR). information for multiple protocols (SRV, NAPTR).
When storing data in the DNS for a new application, the data are When storing data in DNS for a new application, the data are usually
usually tied to a "normal" domain name, so the application can query tied to a "normal" domain name, so the application can query for the
for the data it wants, while minimizing the impact on existing data it wants, while minimizing the impact on existing applications.
applications.
Historically, extending DNS to store data for applications tied to a Historically, extending DNS to store data for applications tied to a
domain name has been done in different ways at different times. MX domain name has been done in different ways at different times. MX
records were created as a new resource record type specifically records were created as a new resource record type specifically
designed to support electronic mail. SRV records are a generic type designed to support electronic mail. SRV records are a generic type
which use a prefixing scheme in combination with a base domain name. which use a prefixing scheme in combination with a base domain name.
Records associated with ENUM use a suffixing scheme. NAPTR records Records associated with ENUM use a suffixing scheme. NAPTR records
add selection data inside the RDATA. It is clear the way of adding add selection data inside the RDATA. It is clear the way of adding
new data to the DNS has been inconsistent, and the purpose of this new data to the DNS has been inconsistent, and the purpose of this
document is to attempt to clarify the implications of each of these document is to attempt to clarify the implications of each of these
skipping to change at page 3, line 41 skipping to change at page 3, line 40
Many parts of this document talk about use of wildcards, and many Many parts of this document talk about use of wildcards, and many
people might think use of wildcards is not something that happens people might think use of wildcards is not something that happens
today. In reality thoug, wildcards are in use, especially for some today. In reality thoug, wildcards are in use, especially for some
specific usages like MX records. Because of this, the choice have to specific usages like MX records. Because of this, the choice have to
be made with existence of wildcards in mind. be made with existence of wildcards in mind.
Another overall issue that have to be taken into account is what the Another overall issue that have to be taken into account is what the
new data in DNS is to describe. In some cases it might be completely new data in DNS is to describe. In some cases it might be completely
new data. In other cases it might be meta-data that is tied to data new data. In other cases it might be meta-data that is tied to data
that already exists in the DNS. Example of new data is key that already exists in DNS. An example of new data is key
information for SSH and data used for fighting spam (meta data that information for SSH and data used for fighting spam (meta data that
is connected to the MX record). If the new data has connection to is connected to the MX record). If the new data has connection to
data that already exists in DNS, an analysis should be made whether data that already exists in DNS, an analysis should be made as to
having (for example) A record and SSH key information in different whether having (for example) A record and SSH key information in
zones is a problem, and if it is, whether the owner for the records different zones is a problem, and if it is, whether the owner for the
by design must be the same for both records. records by design must be the same for both records.
This document do not talk about what one should store in DNS. This document does not talk about what one should store in DNS. It
Whether DNS is used for service discovery, or whether DNS is (also) also doesn't discuss whether DNS is used for service discovery, or
used for storage of application specific data. In general, DNS is a whether DNS is (also) used for storage of data specific for the
protocol that part from holding metadata that makes DNS itself service. In general, DNS is a protocol that apart from holding
function (NS, SOA, DS RR Types etc) only holds references to where metadata that makes DNS itself function (NS, SOA, DS RR Types etc)
services are located (SRV, NAPTR, A, AAAA RR types). only holds references to where services are located (SRV, NAPTR, A,
AAAA RR types).
2. Background 2. Background
See RFC 2929 [RFC2929] for a brief summary of DNS query structure. See RFC 2929 [RFC2929] for a brief summary of DNS query structure.
Readers interested in the full story should start with the base DNS Readers interested in the full story should start with the base DNS
specification in RFC 1035 [RFC1035], and continue with the various specification in RFC 1035 [RFC1035], and continue with the various
documents which update, clarify, and extend the base specification. documents which update, clarify, and extend the base specification.
When composing a query into the DNS system, the parameters actually When composing a query against the DNS system, the parameters
used by the protocol are a triple: a DNS name, a DNS class, and a DNS actually used by the protocol are a triple: a DNS name, a DNS class,
record type. Every resource record (RR) matching a particular name, and a DNS record type. Every resource record (RR) matching a
type and class is said to belong to the same resource record set particular name, type and class is said to belong to the same
(RRSet), and the whole RRSet is always returned to the client which resource record set (RRSet), and the whole RRSet is always returned
queries for it. Splitting an RRSet is a protocol violation, because to the client which queries for it. Splitting an RRSet is a protocol
it results in coherency problems with the DNS caching mechanism. violation, because it results in coherency problems with the DNS
caching mechanism.
Note however that this requirement has nothing to do with the MTU Note that most of the discussions around MTU size is about the size
size and choice of UDP or TCP as the transport protocol. The whole of the whole DNS packet, and not about the size of an RRSet
RRSet always has to be returned, and if it doesn't fit in the MTU in explicitly. A DNS packet is to fit in the MTU size when using UDP,
UDP, TCP has to be used to not break this RRSet atomic requirement. or else a truncated response is given back from the server (at which
point the client can reissue the query over TCP).
3. Extension mechanisms 3. Extension mechanisms
The DNS protocol is intended to be extensible to support new kinds of The DNS protocol is intended to be extensible to support new kinds of
data. This section examines the various ways in which this sort of data. This section examines the various ways in which this sort of
extension can be accomplished. extension can be accomplished.
3.1 Place selectors inside the RDATA 3.1 Place selectors inside the RDATA
For a given query name, one might choose to have a single RRSet (all For a given query name, one might choose to have a single RRSet (all
skipping to change at page 4, line 51 skipping to change at page 5, line 5
additional type subsystem within a single DNS RR type. additional type subsystem within a single DNS RR type.
Examples of subtyping include NAPTR RRs (see RFC 3761 [RFC3761]) and Examples of subtyping include NAPTR RRs (see RFC 3761 [RFC3761]) and
the original DNSSEC KEY RR type (RFC 2535 [RFC2535]) (before it was the original DNSSEC KEY RR type (RFC 2535 [RFC2535]) (before it was
updated by RFC 3445 [RFC3445]). updated by RFC 3445 [RFC3445]).
All DNS subtyping schemes share a common weakness: With subtyping All DNS subtyping schemes share a common weakness: With subtyping
schemes it is impossible for a client to query for just the data it schemes it is impossible for a client to query for just the data it
wants. Instead, the client must fetch the entire RRSet, then select wants. Instead, the client must fetch the entire RRSet, then select
the RRs in which it is interested. Furthermore, since DNSSEC the RRs in which it is interested. Furthermore, since DNSSEC
signatures operate on complete RRSets, the entire RRSet must be signatures operate on complete RRSets, the entire RRSet must be re-
re-signed if any RR in it changes. As a result, each application signed if any RR in it changes. As a result, each application that
that uses a subtyped RR incurs higher overhead than any of the uses a subtyped RR incurs higher overhead than any of the
applications would have incurred had they not been using a subtyping applications would have incurred had they not been using a subtyping
scheme. The fact the RRSet is always passed around as an indivisible scheme. The fact the RRSet is always passed around as an indivisible
unit increases the risk the RRSet will not fit in a UDP packet, which unit increases the risk the RRSet will not fit in a UDP packet, which
in turn increases the risk that the client will have to retry the in turn increases the risk that the client will have to retry the
query with TCP, which substantially increases the load on the name query with TCP, which substantially increases the load on the name
server. More precisely: Having one query fail over to TCP is not a server. More precisely: Having one query fail over to TCP is not a
big deal, but since the typical ratio of clients to servers in the big deal, but since the typical ratio of clients to servers in the
DNS system is very high, having a substantial number of DNS messages DNS system is very high, having a substantial number of DNS messages
fail over to TCP it will cause the relevant name servers to be fail over to TCP may cause the queried name servers to be overloaded
overloaded by TCP overhead. by TCP overhead.
The final result of using a subtyping scheme might be that the zone To conclude, because of the limitations of the size of one RRSet is
administrator has to choose which of the services tied to one domain that not all services tied to a domain can be announced, but instead
name can actually be used, because not all of them can be announced selected (by the zone administrator). This because all of them can
at the same time. not be announced at the same time.
3.2 Add a prefix to the owner name 3.2 Add a prefix to the owner name
By adding an application-specific prefix to a domain name, we will By adding an application-specific prefix to a domain name, we get
get different name/class/type triples, and therefore different different name/class/type triples, and therefore different RRSets.
RRSets. One problem with adding prefixes has to do with wildcards, One problem with adding prefixes has to do with wildcards, especially
especially if one has records like if one has records like
*.example.com. IN MX 1 mail.example.com. *.example.com. IN MX 1 mail.example.com.
and one wants records tied to those names. Suppose one creates the and one wants records tied to those names. Suppose one creates the
prefix "_mail". One would then have to say something like prefix "_mail". One would then have to say something like
_mail.*.example.com. IN X-FOO A B C D _mail.*.example.com. IN X-FOO A B C D
but DNS wildcards only work with the "*" as the leftmost token in the but DNS wildcards only work with the "*" as the leftmost token in the
domain name. domain name.
Even when a specific prefix is chosen, the data will still have to be Even when a specific prefix is chosen, the data will still have to be
stored in some RR type. This RR type can either be a record type stored in some RR type. This RR type can either be a record type
that can store arbitrary data or a new RR type. This implies that that can store arbitrary data or a new RR type. This implies that
some other selection mechanism has to be applied as well, such as some other selection mechanism has to be applied as well, such as
ability to distinguish between the records in an RR set given they ability to distinguish between the records in an RR set given they
have the same RR Type (see also draft-ietf-dnsext-wcard-clarify have the same RR type (see also draft-ietf-dnsext-wcard-clarify
[wcardclarify] regarding use of wildcards and DNS). Because of this [wcardclarify] regarding use of wildcards and DNS). Because of this,
one need to register both a unique prefix and define what RR type is one needs both register a unique prefix and define what RR type is to
to be used for this specific service. be used for this specific service.
If the record has some relationship with another record, the fact the If the record has some relationship with another record in the zone,
original record and this with a prefix can be in different zones the fact the two records can be in different zones might have
might have implications on the trust in the application have on the implications on the trust the application have in the records.
records. Example: Example:
example.com. IN X-FOO "some good thing" example.com. IN MX 10 mail.example.com.
_foo.example.com. IN X-BAR "why the good thing is good" _foo.example.com. IN X-BAR "metadata for the mail service"
In this example, the two records might be in two different zones, and In this example, the two records might be in two different zones, and
because of this signed by two different organizations when using because of this signed by two different organizations when using
DNSSEC. DNSSEC.
3.3 Add a suffix to the owner name 3.3 Add a suffix to the owner name
Adding a suffix to a domain name changes the name/class/type triple, Adding a suffix to a domain name changes the name/class/type triple,
and therefore the RRSet. The query name can be set to exactly the and therefore the RRSet. In this case, since the query name can be
data one wants, and the size of the RRSet is minimized. The problem set to exactly the data one wants the size of the RRSet is minimized.
with adding a suffix is that it creates a parallel tree within the IN The problem with adding a suffix is that it creates a parallel tree
class. There will be no technical mechanism to ensure that the within the IN class. Further, there is no technical mechanism to
delegation for "example.com" and "example.com._bar" are made to the ensure that the delegation for "example.com" and "example.com._bar"
same organization. Furthermore, data associated with a single entity are made to the same organization. Furthermore, data associated with
will now be stored in two different zones, such as "example.com" and a single entity will now be stored in two different zones, such as
"example.com._bar", which, depending on who controls "_bar", can "example.com" and "example.com._bar", which, depending on who
create new synchronization and update authorization issues. controls "_bar", can create new synchronization and update
authorization issues.
Even when using a different name, the data will still have to be Even when using a different name, the data will still have to be
stored in some RR type. This RR type can either be a "kitchen-sink stored in some RR type. This RR type can either be a "kitchen-sink
record" or a new RR type. This implies that some other mechanism has record" or a new RR type. This implies that some other mechanism has
to be applied as well, with implications detailed in other parts of to be applied as well, with implications detailed in other parts of
this note. this note.
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 the same as adding a suffix to the owner name TLD, but the result is the same as adding a suffix to the owner name
(and because of that creation of a new TLD). (and because of that creation of a new TLD).
3.4 Add a new Class 3.4 Add a new Class
DNS zones are class-specific, in the sense that all the records in DNS zones are class-specific in the sense that all the records in
that zone share the same class as the zone's SOA record, and the that zone share the same class as the zone's SOA record and the
existence of a zone in one class does not guarantee the existence of existence of a zone in one class does not guarantee the existence of
the zone in any other class. In practice, only the IN class has ever the zone in any other class. In practice, only the IN class has ever
seen widespread deployment, and the administrative overhead of seen widespread deployment, and the administrative overhead of
deploying an additional class would almost certainly be prohibitive. deploying an additional class would almost certainly be prohibitive.
Nevertheless, one could in theory use the DNS class mechanism to Nevertheless, one could in theory use the DNS class mechanism to
distinguish between different kinds of data. However, since the DNS distinguish between different kinds of data. However, since the DNS
delegation tree (represented by NS RRs) is itself tied to a specific delegation tree (represented by NS RRs) is itself tied to a specific
class, attempting to resolve a query by crossing a class boundary may class, attempting to resolve a query by crossing a class boundary may
produce unexpected results, because there is no guarantee that the produce unexpected results, because there is no guarantee that the
skipping to change at page 8, line 7 skipping to change at page 8, line 8
interface for retrieving arbitrary DNS RR types has been a interface for retrieving arbitrary DNS RR types has been a
requirement since 1989 (see RFC 1123 [RFC1123] Section 6.1.4.2). requirement since 1989 (see RFC 1123 [RFC1123] Section 6.1.4.2).
Some stub resolver library implementations neglect to provide Some stub resolver library implementations neglect to provide
this functionality and cannot handle unknown RR types, but this functionality and cannot handle unknown RR types, but
implementation of a new stub resolver library is not particularly implementation of a new stub resolver library is not particularly
difficult, and open source libraries that already provide this difficult, and open source libraries that already provide this
functionality are available. functionality are available.
4. Conclusion (why adding a new RR type is the answer) 4. Conclusion (why adding a new RR type is the answer)
By now, the astute reader will be wondering about how to use the By now, the astute reader will be wondering how to use the issues
issues presented so far. We will now attempt to clear up the presented so far. We will now attempt to clear up the reader's
reader's confusion by following the thought processes of a typical confusion by following the thought processes of a typical application
application designer who wishes to store stuff in the DNS, showing designer who wishes to store data in DNS, showing how such a designer
how such a designer almost inevitably hits upon the idea of just almost inevitably hits upon the idea of just using TXT RR, and why
using TXT RR, and why this is a bad thing, and instead why a new RR this is a bad thing, and instead why a new RR type is to be
type is to be allocated. allocated.
The overall problem with most solutions has to do with two main
issues:
o No semantics to prevent collision with other use
o Space considerations (in the DNS message)
A typical application designer is not interested in the DNS for its A typical application designer is not interested in the DNS for its
own sake, but rather as a distributed database in which application own sake, but rather as a distributed database in which application
data can be stored. As a result, the designer of a new application data can be stored. As a result, the designer of a new application
is usually looking for the easiest way to add whatever new data the is usually looking for the easiest way to add whatever new data the
application needs to the DNS in a way that naturally associates the application needs to the DNS in a way that naturally associates the
data with a DNS name. data with a DNS name.
As explained in Section 3.4, using the DNS class system as an As explained in Section 3.4, using the DNS class system as an
extension mechanism is not really an option, and in fact most users extension mechanism is not really an option, and in fact most users
of the system don't even realize that the mechanism exists. As a of the system don't even realize that the mechanism exists. As a
practical matter, therefore any extension is likely to be within the practical matter, therefore any extension is likely to be within the
IN class. IN class.
Adding a new RR type is the technically correct answer from the DNS Adding a new RR type is the technically correct answer from the DNS
protocol standpoint (more on this below), but doing so requires some protocol standpoint (more on this below), but doing so requires some
DNS expertise, due to the issues listed in Section 3.5. As a result, DNS expertise, due to the issues listed in Section 3.5. As a result,
this option is usually considered too hard. Note that according to this option is usually considered. Note that according to RFC2929
RFC2929 [RFC2929], some types require IETF Consensus, while others [RFC2929], some types require IETF Consensus, while others only
only require a specification. require a specification.
The application designer is thus left with the prospect of reusing The application designer is thus left with the prospect of reusing
some existing DNS type within the IN class, but when the designer some existing DNS type within the IN class, but when the designer
looks at the existing types, almost all of them have well-defined looks at the existing types, almost all of them have well-defined
semantics, none of which quite match the needs of the new semantics, none of which quite match the needs of the new
application. This has not completely prevented proposals to reuse application. This has not completely prevented proposals to reuse
existing RR types in ways incompatible with their defined semantics, existing RR types in ways incompatible with their defined semantics,
but it does tend to steer application designers away from this but it does tend to steer application designers away from this
approach. approach.
skipping to change at page 10, line 40 skipping to change at page 10, line 47
software recent enough to do so will have higher chance of being able software recent enough to do so will have higher chance of being able
to also support RFC3597. to also support RFC3597.
Of all the issues detailed in Section 3.5, provisioning the data is Of all the issues detailed in Section 3.5, provisioning the data is
in some respects the most difficult. The problem here is less the in some respects the most difficult. The problem here is less 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 DNS,
DNS, regardless of data format, RR type, or naming scheme. Adapting regardless of data format, RR type, or naming scheme. Adapting
front-end systems to support a new RR type may be a bit more front-end systems to support a new RR 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 which allows a completely painless
addition of new data to the DNS, but addition of new data to the DNS, but
o on the whole, the best solution is still to use the DNS type o on the whole, the best solution is still to use the DNS type
mechanism designed for precisely this purpose, and mechanism designed for precisely this purpose, and
o of all the alternate solutions, the "obvious" approach of using o of all the alternate solutions, the "obvious" approach of using
TXT RRs is almost certainly the worst. TXT RRs is almost certainly the worst.
This especially for the two reasons outlined above (lack of semantics
and its implications, and size leading to the need to use TCP).
6. IANA Considerations 6. IANA Considerations
This document does not require any IANA actions. This document does not require any IANA actions.
7. Security Considerations 7. Security Considerations
DNS RRSets can be signed using DNSSEC. DNSSEC is almost certainly DNS RRSets can be signed using DNSSEC. DNSSEC is almost certainly
necessary for any application mechanism that stores authorization necessary for any application mechanism that stores authorization
data in the DNS itself. DNSSEC signatures significantly increase the data in DNS. DNSSEC signatures significantly increase the size of
size of the messages transported, and because of this, the DNS the messages transported, and because of this, the DNS message size
message size issues discussed in Section 3.1 and Section 4 are more issues discussed in Section 3.1 and Section 4 are more serious than
serious than they might at first appear. they might at first appear.
Adding new RR types (as discussed in Section 3.5) might conceivably Adding new RR types (as discussed in Section 3.5) might conceivably
trigger bugs and other bad behavior in software which is not trigger bugs and other bad behavior in software which is not
compliant with RFC 3597 [RFC3597], but most such software is old compliant with RFC 3597 [RFC3597], but most such software is old
enough and insecure enough that it should be updated for other enough and insecure enough that it should be updated for other
reasons in any case. Basic API support for retrieving arbitrary RR reasons in any case. Basic API support for retrieving arbitrary RR
types has been a requirement since 1989 (see RFC 1123 [RFC1123]). types has been a requirement since 1989 (see RFC 1123 [RFC1123]).
Any new protocol that proposes to use the DNS to store data used to Any new protocol that proposes to use the DNS to store data used to
make authorization decisions would be well advised not only to use make authorization decisions would be well advised not only to use
skipping to change at page 11, line 47 skipping to change at page 12, line 6
[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)", RFC [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
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.
8.2 Informative References 8.2 Informative References
[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.
[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.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999. Names", BCP 32, RFC 2606, June 1999.
[RFC2929] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning,
Name System (DNS) IANA Considerations", BCP 42, RFC 2929, "Domain Name System (DNS) IANA Considerations", BCP 42,
September 2000. RFC 2929, September 2000.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002. an On-line Database", RFC 3232, January 2002.
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002. Resource Record (RR)", RFC 3445, December 2002.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004. System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[wcardclarify] [wcardclarify]
Halley, B. and E. Lewis, Halley, B. and E. Lewis,
"draft-ietf-dnsext-wcard-clarify-05.txt, The Role of Wild "draft-ietf-dnsext-wcard-clarify-05.txt, The Role of Wild
Card Domains in the Domain Name System, work in progress", Card Domains in the Domain Name System, work in progress",
September 2003. September 2003.
Authors' Addresses Author's Address
Patrik Faltstrom Patrik Faltstrom
IAB IAB
EMail: paf@cisco.com Email: paf@cisco.com
Rob Austein
IAB
EMail: sra@isc.org
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

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