One document matched: draft-iab-dns-choices-05.xml
<?xml version="1.0"?>
<!-- $Id: draft-iab-dns-choices.xml 345 2008-01-25 16:39:28Z sra $ -->
<?rfc compact="yes"?><?rfc toc="yes"?><?rfc symrefs="yes"?><?rfc sortrefs="yes"?><rfc ipr="full3978" docName="draft-iab-dns-choices-05" category="std">
<front>
<title abbrev="Design Choices When Expanding DNS"> Design Choices When Expanding DNS</title>
<author>
<organization abbrev="IAB">Internet Architecture Board</organization>
<address><email> iab@iab.org </email></address>
</author>
<author role="editor" fullname="Patrik Faltstrom" initials="P." surname="Faltstrom">
<organization/>
<address><email> paf@cisco.com </email></address>
</author>
<author role="editor" initials="R." surname="Austein" fullname="Rob Austein">
<organization/>
<address><email> sra@isc.org </email></address>
</author>
<author role="editor" initials="P." surname="Koch" fullname="Peter Koch">
<organization/>
<address><email> pk@denic.de </email></address>
</author>
<date month="February" year="2008"/>
<keyword>DNS</keyword>
<keyword>Info</keyword>
<keyword>RFC</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>
This note discusses how to extend the DNS with new data for a
new application. DNS extension discussions too often focus on
reuse of the TXT Resource Record Type. This document lists
different mechanisms to extend the DNS, and concludes that the
use of a new DNS Resource Record Type is the best solution.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
The DNS stores multiple categories of data. The two most
commonly used categories are infrastructure data for the DNS
system itself (NS and SOA Resource Records) and data which
have to do with mappings between domain names and IP addresses
(A, AAAA and PTR Resource Records). There are other categories
as well, some of which are tied to specific applications like
email (MX Resource Records), while others are generic Resource
Record Types used to convey information for multiple protocols
(SRV and NAPTR Resource Records).
</t>
<t>
When storing data in the DNS for a new application,
the data are usually tied to a "normal" domain name,
so that the application can query for the data it
wants, while minimizing the impact on existing
applications.
</t>
<t>
Historically, extending DNS to store application data
tied to a domain name has been done in different ways
at different times. MX Resource Records were created as a new
Resource Record Type specifically designed to support
electronic mail. SRV records are a generic type which
use a prefixing scheme in combination with a base
domain name. Records associated with ENUM use a
suffixing scheme. NAPTR records add selection data
inside the RDATA. It 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
clarify the implications of each of these methods,
both for the applications that use them and for the
rest of the DNS.
</t>
<t>
This document talks extensively about use of DNS
wildcards. Many people might think use of wildcards
is not something that happens today. In reality
though, wildcards are in use, especially for certain
application-specific data such as MX Resource Records. Because of
this, the choice has to be made with existence of
wildcards in mind.
</t>
<t>
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 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 information for SSH and data used for fighting
spam (metadata tied to MX Resource Records). If the new data are
tied to data that already exist in the DNS, an
analysis should be made as to whether having (for
example) address records and SSH key information in
different DNS zones is a problem, and if it is,
whether the specification must require all of the
related data to be in the same zone.
</t>
<t>
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 discovery, or whether DNS should be used for storage
of data specific for the service. In general, DNS is a
protocol that, apart from holding metadata that makes the DNS
itself function (NS, SOA, DNSSEC Resource Record Types, etc),
only holds references to service locations (SRV, NAPTR, A,
AAAA Resource Record Types), but there are exceptions (such as
MX Resource Records).
</t>
</section>
<section title="Background">
<t>
See <xref target="RFC2929"/> for a brief summary of DNS query
structure. Readers interested in the full story should start
with the base DNS specification in <xref target="RFC1035"/>,
and continue with the various documents that update, clarify,
and extend the base specification.
</t>
<t>
When composing a DNS query, the parameters used by the
protocol are a triple: a DNS name, a DNS class, and a DNS
record Type. Every Resource Record matching a particular name,
type and class is said to belong to the same "RRSet", and the
whole RRSet is always returned to the client that queries for
it. Splitting an RRSet is a protocol violation, because it
results in coherency problems with the DNS caching mechanism.
</t>
<t>
Some discussions around extensions to the DNS include
arguments 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 single RRSet.
</t>
<t>
Almost all DNS query traffic is carried over UDP, where a DNS
message must fit within a single UDP packet. DNS response messages
are almost always larger than DNS query messages, so message size
issues are almost always about responses, not queries. The base DNS
specification limits DNS messages over UDP to 512 octets; EDNS0
<xref target="RFC2671"/> specifies a mechanism by which a client can
signal its willingness to receive larger responses, but deployment
of EDNS0 is not universal, in part because of firewalls that block
fragmented UDP packets or EDNS0. If a response message won't fit in
a single packet, the name server returns a truncated response, at
which point the client may retry using TCP. DNS queries over TCP are
not subject to this length limitation, but TCP imposes significantly
higher per-query overhead on name servers than UDP. It is also the
case that the policies in deployed firewalls far too often is such
that it blocks DNS over TCP, so using TCP might not in reality be an
option. There are also risks (although possibly small) that a change
of routing while a TCP flow is open create problems when the DNS
servers are deployed in an anycast environment.
</t>
</section>
<section title="Extension mechanisms">
<t>
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 extension can be
accomplished.
</t>
<section anchor="add_subtype" title="Place selectors inside the RDATA of existing Resource Record Types">
<t>
For a given query name, one might choose to have a
single RRSet (all Resource Records sharing the same name, type,
and class) shared by multiple applications, and
have the different applications use selectors
within the Resource Record data (RDATA) to determine which
records are intended for which applications. This
sort of selector mechanism is usually referred to
"subtyping", because it is in effect creating an
additional type subsystem within a single DNS Resource Record
Type.
</t>
<t>
Examples of subtyping include NAPTR Resource Records (see
<xref target="RFC3761"/>) and the original DNSSEC
KEY Resource Record Type (<xref target="RFC2535"/>) (before it
was updated by <xref target="RFC3445"/>).
</t>
<t>
All DNS subtyping schemes share a common weakness:
With subtyping 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 the Resource Records in which it is
interested. Furthermore, since DNSSEC signatures
operate on complete RRSets, the entire RRSet must
be re-signed if any Resource Record in it changes. As a result,
each application that uses a subtyped Resource Record incurs
higher overhead than any of the applications would
have incurred had they not been using a subtyping
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 in
turn increases the risk that the client will have
to retry the query with TCP, which substantially
increases the load on the name 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 today's deployed DNS is
very high, having a substantial number of DNS
messages fail over to TCP may cause the queried
name servers to be overloaded by TCP overhead.
</t>
<t>
Because of the size limitations, using a subtyping
scheme to list a large number of services for a
single domain name risks triggering truncation and
fallback to TCP, which may in turn force the zone
administrator to announce only a subset of
available services.
</t>
</section>
<section anchor="add_prefix" title="Add a prefix to the owner name">
<t>
By adding an application-specific prefix to a
domain name, we get a different name/class/type
triple, and therefore a different RRSet. One
problem with adding prefixes has to do with
wildcards, especially if one has records like
</t>
<figure>
<artwork>
*.example.com. IN MX 1 mail.example.com.
</artwork>
</figure>
<t>
and one wants records tied to those names. Suppose
one creates the prefix "_mail". One would then have
to say something like
</t>
<figure>
<artwork>
_mail.*.example.com. IN X-FOO A B C D
</artwork>
</figure>
<t>
but DNS wildcards only work with the "*" as the
leftmost token in the domain name (see also
<xref target="RFC4592"/>).
</t>
<t>
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 either be a record Type that has
an appropriate format to store the data or a new Resource
Record Type. This implies that some other selection
mechanism has to be applied as well, such as ability to
distinguish between the records in an RRSet given they
have the same 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 this specific
service.
</t>
<t>
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 implications
on the trust the application has in the
records. For example:
</t>
<figure>
<artwork>
example.com. IN MX 10 mail.example.com.
_foo.example.com. IN X-BAR "metadata for the mail service"
</artwork>
</figure>
<t>
In this example, the two records might be in two
different zones, and because of this might be
signed by two different organizations when using
DNSSEC.
</t>
</section>
<section anchor="add_suffix" title="Add a suffix to the owner name">
<t>
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 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 within the IN
class. Further, there is no technical mechanism to
ensure that the delegation for "example.com" and
"example.com._bar" are made to the same
organization. Furthermore, data associated with a
single entity will now be stored in two different
zones, such as "example.com" and "example.com._bar",
which, depending on who controls "_bar", can create
new synchronization and update authorization issues.
</t>
<t>
One way of solving the administrative issues is by
using the DNAME Resource Record Type specified in
<xref target="RFC2672"/>.
</t>
<t>
Even when using a different name, the data will still have
to be stored in some Resource Record Type. This Resource
Record Type can either be a "kitchen-sink record" or a new
Resource Record Type. This implies that some other
mechanism has to be applied as well, with implications
detailed in other parts of this note.
</t>
<t>
In <xref target="RFC2163"/> an infix token is
inserted directly below the 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 domain).
</t>
</section>
<section anchor="add_class" title="Add a new Class">
<t>
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 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 seen widespread deployment, and the
administrative overhead of deploying an additional
class would almost certainly be prohibitive.
</t>
<t>
Nevertheless, one could in theory use the DNS class
mechanism to distinguish between different kinds of
data. However, since the DNS delegation tree
(represented by NS Resource Records) is itself tied to a specific
class, attempting to resolve a query by crossing a
class boundary may produce unexpected results
because there is no 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 used a scheme like this for storing data in
the HS class, but only on a very small scale (within
a single institution), and with an administrative
fiat requiring that the delegation trees for the IN
and HS trees be identical.
</t>
<t>
Even when using a different class, the data will
still have to be stored in some Resource Record Type or
another. This Resource Record Type can either be a "kitchen-sink
record" or a new Resource Record Type. This implies that some
other mechanism has to be applied as well, with
implications detailed in other parts of this note.
</t>
</section>
<section anchor="add_type" title="Add a new Resource Record Type">
<t>
When adding a new Resource Record Type to the
system, entities in four different roles have to be
able to handle the new Type:
</t>
<t>
<list style="numbers">
<t>
There must be a way to insert the new
Resource Records into the zone of the
Primary Master name server. For some server
implementations, the user interface only
accepts record Types which it understands
(perhaps so that the implementation can
attempt to validate the data). Other
implementations allow the zone administrator
to enter an integer for the Resource Record
Type code and the RDATA in Base64 or
hexadecimal encoding (or even as raw
data). <xref target="RFC3597"/> specifies a
standard generic encoding for this purpose.
</t>
<t>
A slave authoritative name server must be
able to do a zone transfer, receive the data
from some other authoritative name server,
and serve data from the zone even though the
zone includes records of unknown
Types. Historically, some implementations
have had problems parsing stored copies of
the zone file after restarting, but those
problems have not been seen for a few years.
</t>
<t>
A caching resolver (most commonly a
recursive name server) will cache the
records which are responses to queries. As
mentioned in <xref target="RFC3597"/>,there
are various pitfalls where a recursive name
server might end up having problems.
</t>
<t>
The application must be able to get the
RRSet with a new Resource Record Type. The
application itself may understand the RDATA,
but the resolver library might not. Support
for a generic interface for retrieving
arbitrary DNS Resource Record Types has been a
requirement since 1989 (see
<xref target="RFC1123"/> Section
6.1.4.2). Some stub resolver library
implementations neglect to provide this
functionality and cannot handle unknown Resource Record
Types, but implementation of a new stub
resolver library is not particularly
difficult, and open source libraries that
already provide this functionality are
available.
</t>
</list>
</t>
</section>
</section>
<section title="Zone boundaries are invisible to applications">
<t>
Regardless of the possible choices above we have
seen a number of cases where the application made
assumptions about the structure of the namespace and
the location where specific information resides. We
take a small sidestep to argue against such
approaches.
</t>
<t>
The DNS namespace is a hierarchy, technically
speaking. However, this only refers to the way
names are built from multiple labels. DNS hierarchy
neither follows nor implies administrative
hierarchy. That said, it cannot be assumed that data
attached to a node in the DNS tree is valid for the
whole subtree. Technically, there are zone
boundaries partitioning the namespace and
administrative boundaries (or policy boundaries) may
even exist elsewhere.
</t>
<t>
The false assumption has lead to an approach called
"tree climbing", where a query that does not receive
a positive response (either the requested RRSet was
missing or the name did not exist) is retried by
repeatedly stripping off the leftmost label
(climbing towards the root) until the root domain is
reached. Sometimes these proposals try to avoid the
query for the root or the TLD level, but still this
approach has severe drawbacks:
</t>
<t>
<list style="symbols">
<t>
Technically, the DNS was built as a query -
response tool without any search capability
<xref target="RFC3467"/>. Adding the search
mechanism imposes additional burden on the
technical infrastructure, in the worst case
on TLD and root name servers.
</t>
<t>
For reasons similar to those outlined in
RFC 1535, querying for information in a
domain outside the control of the intended
entity may lead to incorrect results and
may also put security at risk. Finding the
exact policy boundary is impossible
without an explicit marker which does not
exist at present. At best, software can
detect zone boundaries (e.g., by looking for
SOA Resource Records), but some TLD registries register
names starting at the second level (e.g.,
CO.UK), and there are various other
"registry" types at second, third or other
level domains that cannot be identified as
such without policy knowledge external to
the DNS.
</t>
</list>
</t>
<t>
To restate, the zone boundary is purely a
boundary that exists in the DNS for administrative
purposes, and applications should be careful not
to draw unwarranted conclusions from zone
boundaries. A different way of stating this is
that the DNS does not support inheritance, e.g. a
wildcard MX RRSet for a TLD will not be valid for
any subdomain of that particular TLD.
</t>
</section>
<section anchor="txt_evil" title="Why adding a new Resource Record Type is the preferred solution">
<t>
By now, the astute reader might be be wondering what
conclusions to draw from all the issues presented so far. We
will now attempt to clear up the reader's confusion by
following the thought processes of a typical application
designer who wishes to store data in the DNS, showing how such
a designer almost inevitably hits upon the idea of just using
TXT Resource Record, why this is a bad thing, and why a new Resource Record Type should
be allocated instead.
</t>
<t>
The overall problem with most solutions has to do with
two main issues: <list style="symbols">
<t>
No semantics to prevent collision with other use
</t>
<t>
Space considerations in the DNS message
</t>
</list>
</t>
<t>
A typical application designer is not interested in the
DNS for its own sake, but rather as a distributed
database in which 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
application needs to the DNS in a way that naturally
associates the data with a DNS name.
</t>
<t>
As explained in <xref target="add_class"/>, using the
DNS class system as an 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 practical
matter, therefore any extension is likely to be within
the IN class.
</t>
<t>
Adding a new Resource Record Type is the technically correct
answer from the DNS protocol standpoint (more on this below),
but doing so requires some DNS expertise, due to the issues
listed in <xref target="add_type"/>. As a result, this option
is usually not considered. Note that according to <xref
target="RFC2929"/>, some Types require IETF Consensus, while
others only require a specification.
</t>
<t>
The application designer is thus left with the prospect
of reusing some existing DNS Type within the IN class,
but when the designer looks at the existing Types,
almost all of them have well-defined semantics, none of
which quite match the needs of the new application. This
has not completely prevented proposals from reusing existing
Resource Record Types in ways incompatible with their defined
semantics, but it does tend to steer application
designers away from this approach.
</t>
<t>
For example, Resource Record Type 40 was registered for the SINK record
Type. This Resource Record Type was discussed in the 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 encouraging application designers to
use the SINK Resource Record Type instead of registering a new Resource Record
Type, which would result in infeasibly large SINK
RRsets.
</t>
<t>
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 no existing semantics to get in the way.
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 parser, perhaps in some human readable
programming or markup language. Thus, for many
applications, TXT Resource Records are the "obvious"
choice. Unfortunately, this conclusion, while
understandable, is also wrong, for several reasons.
</t>
<t>
The first reason why TXT Resource Records are not well suited to
such use is precisely the lack of defined semantics
that make them so attractive. Arguably, the TXT Resource Record is
misnamed, and should have been called the Local
Container record, because the lack of defined
semantics means that a TXT Resource Record means precisely what the
data producer says it means. This is fine, so long as
TXT Resource Records are being used by human beings or by private
agreement between data producer and data
consumer. However, it becomes a problem once one
starts using them for standardized protocols in which
there is no prior relationship between data producer
and data consumer. The reason for this is that there is
nothing to prevent collisions with some other
incompatible use of TXT Resource Records. This is even worse than
the general subtyping problem described in <xref target="add_subtype"/>, because TXT Resource Records don't even
have a standardized selector field in which to store
the subtype. <xref target="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 with will not accidently conflict with somebody
else's subtyping scheme, and that it will not be
possible to mis-parse one application's use of TXT Resource Records
as data intended for a different application. Any
attempt to impose a standardized format within the TXT
Resource Record format would be at least fifteen years too late
even if it were put into effect immediately; at best,
one can restrict the syntax that a particular
application uses within a TXT Resource Record and accept the risk
that unrelated TXT Resource Record uses will collide with it.
</t>
<t>
Using one of the naming modifications discussed in <xref
target="add_prefix"/> and <xref target="add_suffix"/> would
address the subtyping problem, but each of these approaches
brings in new problems of its own. The prefix approach (that
for example SRV Resource Records use) does not work well with
wildcards, which is a particular problem for mail-related
applications, since MX Resource Records are probably the most
common use of DNS wildcards. The suffix approach doesn't have
wildcard issues, but, as noted previously, it does have
synchronization and update authorization issues, since it
works by creating a second subtree in a different part of the
global DNS name space.
</t>
<t>
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 message. As alluded to briefly in
<xref target="add_subtype"/>, typical DNS query traffic
patterns involve a very large number of DNS clients
sending queries to a relatively small number of DNS
servers. Normal path MTU discovery schemes do little
good here because, from the server's perspective, there
isn't enough repeat traffic from any one client for it
to be worth retaining state. UDP-based DNS is an
idempotent query, whereas TCP-based DNS requires the
server to keep state (in the form of TCP connection
state, usually in the server's kernel) and roughly
triples the traffic load. Thus, there's a strong
incentive to keep DNS messages short enough to fit in a
UDP datagram, preferably a UDP datagram short enough not
to require IP fragmentation.
</t>
<t>
Subtyping schemes are therefore again problematic
because they produce larger Resource RRSets than necessary, but
verbose text encodings of data are also wasteful, since
the data they hold can usually be represented more
compactly in a Resource Record designed 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 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 as a
pointer to the data, as with NAPTR.
</t>
</section>
<section title="Conclusion and Recommendation">
<t>
Given the problems detailed in
<xref target="txt_evil"/>, it is worth reexamining the
oft-jumped-to conclusion that specifying a new Resource Record Type
is hard. Historically, this was indeed the case, but
recent surveys suggest that support for unknown Resource Record
Types <xref target="RFC3597"/> is now widespread, and
that lack of support for unknown Types is mostly an
issue for relatively old software that would probably
need to be upgraded in any case as part of supporting
a new application. 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 <xref target="RFC3597"/> and EDNS0 <xref target="RFC2671"/>.
</t>
<t>
Of all the issues detailed in <xref target="add_type"/>,
provisioning the data is in some respects the most difficult.
The problem here is less difficult for the authoritative name
servers themselves than the front-end systems used to enter
(and perhaps validate) the data. Hand editing does not work
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 implementation itself. Note, however, that this
provisioning problem exists to some degree with any new form
of data to be stored in the DNS, regardless of data format,
Resource Record type, or naming scheme. Including the TXT
Resource Record Type. Adapting front-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 minor
difference in degree rather than a difference in kind.
</t>
<t>
Given the various issues described in this note, we
believe that: <list style="symbols">
<t>
there is no magic solution which allows a
completely painless addition of new data to the
DNS, but
</t>
<t>
on the whole, the best solution is still to use the
DNS Resource Record Type mechanism designed for
precisely this purpose, and
</t>
<t>
of all the alternate solutions, the "obvious" approach
of using TXT Resource Records is almost certainly the
worst.
</t>
</list>
This especially for the two reasons outlined above (lack
of semantics and its implications, and size leading to
the need to use TCP).
</t>
</section>
<section title="Creating A New Resource Record Type">
<t>
The process for creating a new Resource Record Type is
specified in <xref target="I-D.ietf-dnsext-2929bis"/>.
</t>
</section>
<section title="IANA Considerations">
<t>
This document does not require any IANA actions.
</t>
</section>
<section title="Security Considerations">
<t>
DNS RRSets can be signed using DNSSEC. DNSSEC is almost
certainly necessary for any application mechanism that
stores authorization data in the DNS. DNSSEC signatures
significantly increase the size of the messages
transported, and because of this, the DNS message size
issues discussed in <xref target="add_subtype"/> and
<xref target="txt_evil"/> are more serious than they
might at first appear.
</t>
<t>
Adding new Resource Record Types (as discussed in
<xref target="add_type"/>) might conceivably trigger
bugs and other bad behavior in software that is not
compliant with <xref target="RFC3597"/>, but most such
software is old enough and insecure enough that it
should be updated for other reasons in any case. Basic
API support for retrieving arbitrary Resource Record Types has been
a requirement since 1989 (see
<xref target="RFC1123"/>).
</t>
<t>
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 DNSSEC but also to encourage
upgrades to DNS server software recent enough not to be
riddled with well-known exploitable bugs. Because of
this, support for new Resource Record Types will not be as hard as
people might think at first.
</t>
</section>
<section title="Acknowledgements">
<t>
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 sensitive, and a document like
this can not please everyone. The goal is instead to
describe the architecture and tradeoffs, and make some
recommendations about best practices.
</t>
<t>
People that have helped include:
Dean Andersson,
Loa Andersson,
Mark Andrews,
John Angelmo,
Roy Badami,
Dan Bernstein,
Alex Bligh,
Nathaniel Borenstein,
Stephane Bortzmeyer,
Brian Carpenter,
Leslie Daigle,
Elwyn Davies,
Mark Delany,
Richard Draves,
Martin Duerst,
Donald Eastlake,
Robert Elz,
Jim Fenton,
Tony Finch,
Jim Gilroy,
Olafur Gudmundsson,
Eric Hall,
Philip Hallam-Baker,
Ted Hardie,
Bob Hinden,
Paul Hoffman,
Geoff Houston,
Christian Huitema,
Johan Ihren,
John Klensin,
Olaf Kolkman,
Ben Laurie,
William Leibzon,
John Levine,
Edward Lewis,
David MacQuigg,
Allison Manking,
Bill Manning,
Danny McPherson,
David Meyer,
Pekka Nikander,
Masataka Ohta,
Douglas Otis,
Michael Patton,
Jonathan Rosenberg,
Anders Rundgren,
Miriam Sapiro,
Pekka Savola,
Chip Sharp,
James Snell,
Dave Thaler,
Michael Thomas,
Paul Vixie,
Sam Weiler,
Florian Weimer,
Bert Wijnen,
and
Dan Wing.
</t>
<t>
Members of the IAB when this document was made available
were:
Loa Andersson,
Leslie Daigle,
Elwyn Davies,
Kevin Fall,
Russ Housley,
Olaf Kolkman,
Barry Leiba,
Kurtis Lindqvist,
Danny McPherson,
David Oran,
Eric Rescorla,
Dave Thaler,
and
Lixia Zhang.
</t>
</section>
</middle>
<back xmlns:xi="http://www.w3.org/2001/XInclude">
<references title="Normative References">
<reference anchor="RFC1035" xml:base="../rfc2629tools/xml/rfc/reference.RFC.1035.xml">
<front>
<title>Domain names - implementation and specification</title>
<author fullname="P.V. Mockapetris" initials="P.V." surname="Mockapetris">
<organization/>
</author>
<date month="November" year="1987"/>
<keyword> DOMAIN</keyword>
<abstract>
<t>This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1035"/>
<seriesInfo name="STD" value="13"/>
<format type="TXT" octets="125626" target="http://www.rfc-editor.org/rfc/rfc1035.txt"/>
<!-- obsoletes RFC0973 RFC0882 RFC0883 -->
<!-- updated-by RFC1101 RFC1183 RFC1348 RFC1876 RFC1982 RFC1995 RFC1996 RFC2065 RFC2136 RFC2181 RFC2137 RFC2308 RFC2535 RFC2845 RFC3425 RFC3658 RFC4033 RFC4034 RFC4035 RFC4343 -->
<!-- current-status STANDARD -->
<!-- publication-status STANDARD -->
</reference>
<reference anchor="RFC1464" xml:base="../rfc2629tools/xml/rfc/reference.RFC.1464.xml">
<front>
<title>Using the Domain Name System To Store Arbitrary String Attributes</title>
<author fullname="R. Rosenbaum" initials="R." surname="Rosenbaum">
<organization/>
</author>
<date month="May" year="1993"/>
<keyword>DNS</keyword>
<keyword>TXT </keyword>
<abstract>
<t>This paper describes a simple means to associate arbitrary string information (ASCII text) with attributes that have not been defined by the DNS. This memo defines an Experimental Protocol for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1464"/>
<format type="TXT" octets="7953" target="http://www.rfc-editor.org/rfc/rfc1464.txt"/>
<!-- current-status EXPERIMENTAL -->
<!-- publication-status EXPERIMENTAL -->
</reference>
<reference anchor="RFC2535" xml:base="../rfc2629tools/xml/rfc/reference.RFC.2535.xml">
<front>
<title>Domain Name System Security Extensions</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd">
<organization/>
</author>
<date month="March" year="1999"/>
<keyword> DNS-SECEXT</keyword>
<keyword>dns</keyword>
<keyword>authentication </keyword>
<abstract>
<t>This document incorporates feedback on RFC 2065 from early implementers and potential users. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2535"/>
<format type="TXT" octets="110958" target="http://www.rfc-editor.org/rfc/rfc2535.txt"/>
<!-- obsoletes RFC2065 -->
<!-- obsoleted-by RFC4033 RFC4034 RFC4035 -->
<!-- updates RFC2181 RFC1035 RFC1034 -->
<!-- updated-by RFC2931 RFC3007 RFC3008 RFC3090 RFC3226 RFC3445 RFC3597 RFC3655 RFC3658 RFC3755 RFC3757 RFC3845 -->
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference> <!-- Obsoleted, OK -->
<reference anchor="RFC2671" xml:base="../rfc2629tools/xml/rfc/reference.RFC.2671.xml">
<front>
<title>Extension Mechanisms for DNS (EDNS0)</title>
<author fullname="P. Vixie" initials="P." surname="Vixie">
<organization/>
</author>
<date month="August" year="1999"/>
<keyword> EDNS0</keyword>
<keyword>domain</keyword>
<keyword>name</keyword>
<keyword>system</keyword>
<keyword>resource</keyword>
<keyword>records</keyword>
<keyword>opt </keyword>
<abstract>
<t>The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2671"/>
<format type="TXT" octets="15257" target="http://www.rfc-editor.org/rfc/rfc2671.txt"/>
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference>
<reference anchor="RFC3597" xml:base="../rfc2629tools/xml/rfc/reference.RFC.3597.xml">
<front>
<title>Handling of Unknown DNS Resource Record (RR) Types</title>
<author fullname="A. Gustafsson" initials="A." surname="Gustafsson">
<organization/>
</author>
<date month="September" year="2003"/>
<keyword>domain name system</keyword>
<keyword>name server software</keyword>
<keyword>compression</keyword>
<keyword>transparency </keyword>
<abstract>
<t>Extending the Domain Name System (DNS) with new Resource Record (RR) Types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR Types transparently. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3597"/>
<format type="TXT" octets="17559" target="http://www.rfc-editor.org/rfc/rfc3597.txt"/>
<!-- updates RFC2163 RFC2535 -->
<!-- updated-by RFC4033 RFC4034 RFC4035 -->
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference>
</references>
<references title="Informative References">
<!-- Automatically generated, do not edit. --><reference anchor="I-D.ietf-dnsext-2929bis" xml:base="../rfc2629tools/xml/draft/reference.I-D.ietf-dnsext-2929bis.xml">
<front>
<title>Domain Name System (DNS) IANA Considerations</title>
<author initials="D.E." surname="3rd" fullname="Donald Eastlake 3rd"><organization/></author>
<date day="9" month="August" year="2007"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsext-2929bis-06"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-dnsext-2929bis-06.txt"/>
</reference>
<reference anchor="RFC1123" xml:base="../rfc2629tools/xml/rfc/reference.RFC.1123.xml">
<front>
<title>Requirements for Internet Hosts - Application and Support</title>
<author fullname="R. Braden" initials="R." surname="Braden">
<organization/>
</author>
<date month="October" year="1989"/>
<keyword>applicability </keyword>
<abstract>
<t>This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1123"/>
<seriesInfo name="STD" value="3"/>
<format type="TXT" octets="245503" target="http://www.rfc-editor.org/rfc/rfc1123.txt"/>
<!-- updates RFC0822 -->
<!-- updated-by RFC1349 RFC2181 -->
<!-- current-status STANDARD -->
<!-- publication-status STANDARD -->
</reference>
<reference anchor="RFC2163" xml:base="../rfc2629tools/xml/rfc/reference.RFC.2163.xml">
<front>
<title>Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM)</title>
<author fullname="C. Allocchio" initials="C." surname="Allocchio">
<organization/>
</author>
<date month="January" year="1998"/>
<keyword> DNS-MCGAM</keyword>
<keyword>mime</keyword>
<keyword>internet</keyword>
<keyword>enhanced</keyword>
<keyword>Relay</keyword>
<keyword>Multipurpose</keyword>
<keyword>internet</keyword>
<keyword>mail</keyword>
<keyword>extensions</keyword>
<keyword>x.400</keyword>
<keyword>mixer </keyword>
<abstract>
<t>This memo is the complete technical specification to store in the Internet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2163"/>
<format type="TXT" octets="58789" target="http://www.rfc-editor.org/rfc/rfc2163.txt"/>
<!-- obsoletes RFC1664 -->
<!-- updated-by RFC3597 -->
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference>
<reference anchor="RFC2672" xml:base="../rfc2629tools/xml/rfc/reference.RFC.2672.xml">
<front>
<title>Non-Terminal DNS Name Redirection</title>
<author fullname="M. Crawford" initials="M." surname="Crawford">
<organization/>
</author>
<date month="August" year="1999"/>
<keyword>domain</keyword>
<keyword>name</keyword>
<keyword>system</keyword>
<keyword>dname</keyword>
<keyword>resource</keyword>
<keyword>records </keyword>
<abstract>
<t>This document defines a new DNS Resource Record called "DNAME", which provides the capability to map an entire subtree of the DNS name space to another domain. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2672"/>
<format type="TXT" octets="18321" target="http://www.rfc-editor.org/rfc/rfc2672.txt"/>
<!-- updated-by RFC4592 -->
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference>
<reference anchor="RFC2929" xml:base="../rfc2629tools/xml/rfc/reference.RFC.2929.xml">
<front>
<title>Domain Name System (DNS) IANA Considerations</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd">
<organization/>
</author>
<author fullname="E. Brunner-Williams" initials="E." surname="Brunner-Williams">
<organization/>
</author>
<author fullname="B. Manning" initials="B." surname="Manning">
<organization/>
</author>
<date month="September" year="2000"/>
<keyword> internet assigned numbers authority</keyword>
<keyword>resource records</keyword>
<keyword>RRs </keyword>
<abstract>
<t>This document discusses the Internet Assigned Number Authority (IANA) parameter assignment considerations given for the allocation of Domain Name System (DNS) classes, Resource Record (RR) Types, operation codes, error codes, etc. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2929"/>
<seriesInfo name="BCP" value="42"/>
<format type="TXT" octets="22454" target="http://www.rfc-editor.org/rfc/rfc2929.txt"/>
<!-- current-status BEST CURRENT PRACTICE -->
<!-- publication-status BEST CURRENT PRACTICE -->
</reference>
<reference anchor="RFC3445" xml:base="../rfc2629tools/xml/rfc/reference.RFC.3445.xml">
<front>
<title>Limiting the Scope of the KEY Resource Record (RR)</title>
<author fullname="D. Massey" initials="D." surname="Massey">
<organization/>
</author>
<author fullname="S. Rose" initials="S." surname="Rose">
<organization/>
</author>
<date month="December" year="2002"/>
<keyword> DNS-SECEXT</keyword>
<keyword>dns</keyword>
<keyword>authentication </keyword>
<abstract>
<t>This document limits the Domain Name System (DNS) KEY Resource Record (RR) to only keys used by the Domain Name System Security Extensions (DNSSEC). The original KEY RR used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys with the same record Type is a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RR Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are redefined. Three existing application key sub-types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3445"/>
<format type="TXT" octets="20947" target="http://www.rfc-editor.org/rfc/rfc3445.txt"/>
<!-- obsoleted-by RFC4033 RFC4034 RFC4035 -->
<!-- updates RFC2535 -->
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference> <!-- Obsoleted, OK -->
<reference anchor="RFC3467" xml:base="../rfc2629tools/xml/rfc/reference.RFC.3467.xml">
<front>
<title>Role of the Domain Name System (DNS)</title>
<author fullname="J. Klensin" initials="J." surname="Klensin">
<organization/>
</author>
<date month="February" year="2003"/>
<keyword> history</keyword>
<keyword>internationalization</keyword>
<keyword>unicode</keyword>
<keyword>ascii</keyword>
<keyword>multilingual names </keyword>
<abstract>
<t>This document reviews the original function and purpose of the domain name system (DNS). It contrasts that history with some of the purposes for which the DNS has recently been applied and some of the newer demands being placed upon it or suggested for it. A framework for an alternative to placing these additional stresses on the DNS is then outlined. This document and that framework are not a proposed solution, only a strong suggestion that the time has come to begin thinking more broadly about the problems we are encountering and possible approaches to solving them. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3467"/>
<format type="TXT" octets="84570" target="http://www.rfc-editor.org/rfc/rfc3467.txt"/>
<!-- current-status INFORMATIONAL -->
<!-- publication-status INFORMATIONAL -->
</reference>
<reference anchor="RFC3761" xml:base="../rfc2629tools/xml/rfc/reference.RFC.3761.xml">
<front>
<title>The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)</title>
<author fullname="P. Faltstrom" initials="P." surname="Faltstrom">
<organization/>
</author>
<author fullname="M. Mealling" initials="M." surname="Mealling">
<organization/>
</author>
<date month="April" year="2004"/>
<keyword>domain name system </keyword>
<abstract>
<t>This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3761"/>
<format type="TXT" octets="41559" target="http://www.rfc-editor.org/rfc/rfc3761.txt"/>
<!-- obsoletes RFC2916 -->
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference>
<reference anchor="RFC4592" xml:base="../rfc2629tools/xml/rfc/reference.RFC.4592.xml">
<front>
<title>The Role of Wildcards in the Domain Name System</title>
<author fullname="E. Lewis" initials="E." surname="Lewis">
<organization/>
</author>
<date month="July" year="2006"/>
<keyword>cname</keyword>
<abstract>
<t>This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4592"/>
<format type="TXT" octets="43991" target="http://www.rfc-editor.org/rfc/rfc4592.txt"/>
<!-- updates RFC1034 RFC2672 -->
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference>
<!-- Not referenced:
<xi:include href="reference.RFC.2434.xml"/>
<xi:include href="reference.RFC.2606.xml"/>
<xi:include href="reference.RFC.3232.xml"/>
<xi:include href="reference.RFC.3692.xml"/>
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:41:30 |