Internet DRAFT - draft-hall-qtype-addr
draft-hall-qtype-addr
INTERNET-DRAFT Eric A. Hall
Document: draft-hall-qtype-addr-01.txt November 2003
Expires: May 2004
DNS Mechanisms for Providing All Address Types
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document defines mechanisms for providing all IP address
resource records (specifically including any A and AAAA resource
records) in DNS response messages. Specifically, this document
defines an "ADDR" query-type which allows a system to issue a
single lookup for all of the addressing resource records
associated with a domain name (explicitly including any IPv4 and
IPv6 resource records), and also defines an algorithm for DNS
servers to use when returning supplemental address data in the
additional-data section of a response message.
Internet Draft draft-hall-qtype-addr-01.txt November 2003
Table of Contents
1. Prerequisites and Terminology..............................2
2. Introduction and Overview..................................2
3. The ADDR Query-Type........................................4
3.1. Basic Handling..........................................4
3.2. Ensuring Valid Answer Sets..............................5
3.3. Time-To-Live Values.....................................6
3.4. CNAME Processing........................................7
3.5. Truncated ADDR Responses................................7
3.6. Error Responses.........................................8
3.7. ADDR Query-Type Examples................................9
4. All-Addresses Additional Data.............................10
4.1. Truncated Additional-Data..............................11
4.2. Additional-Data Examples...............................11
5. Security Considerations...................................12
6. IANA Considerations.......................................12
7. Author's Addresses........................................12
8. Normative References......................................12
9. Informative References....................................12
10. Acknowledgments...........................................12
11. Full Copyright Statement..................................13
1. Prerequisites and Terminology
This specification incorporates elements from multiple existing
specifications. At a minimum, readers of this document need to be
familiar with [RFC1035], [RFC1886], [RFC2181], and [RFC2308].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119.
2. Introduction and Overview
Internet applications have historically only needed to issue a
single query for a single resource record type in order to
determine the IPv4 address of a destination node. As more IPv6 and
dual-stack systems are deployed, however, there is a significant
likelihood that these newer systems will have to issue multiple
queries in order to locate any available addresses, first asking
for the IPv6 addresses of the target host, and then issuing
subsequent queries for any IPv4 addresses in those cases where no
Hall I-D Expires: May 2004 [page 2]
Internet Draft draft-hall-qtype-addr-01.txt November 2003
IPv6 addresses are defined. In these situations, multiple queries
are frequently needed in order for the sending host to determine
the networking capabilities of the target host.
Furthermore, several pre-existing queries and resource records
also return IPv4 address resource records as supplemental data,
but do not return any related IPv6 address resource records (EG,
queries for Mail Exchange resource records usually cause the IPv4
address resource records of the target host to be provided as
supplemental data, but not the IPv6 address resource records of
that host). When these responses are received, the querying host
may be required to issue additional (separate) lookups for any
IPv6 addressing resource records defined for the target host, in
order to determine its networking capabilities.
Individually, each of these additional queries are minor, although
they can cumulatively represent a significant amount of overall
query traffic. Meanwhile, the Internet's history with the Simple
Mail Transfer Protocol (SMTP) [SMTP] illustrates that the use of
multiple resource records can sometimes lead implementers towards
problematic shortcuts, in that they attempt to streamline the
process by issuing a single lookup with the query-type of "ALL",
in the hopes that all of the applicable resource records will be
returned, although this approach can frequently produce incomplete
results. Unfortunately, if history is any indicator of future
trends, this approach is somewhat likely to be pursued by at least
some IPv6-aware applications as well.
In order to prevent these kinds of problems from emerging, this
document defines two mechanisms for providing all of the IPv4 and
IPv6 address resource records associated with a target host in a
single response message, thereby alleviating the need for querying
systems to issue multiple discrete lookups in order to determine
the networking capabilities of the target host. Specifically, this
document defines an "ADDR" query-type which allows a system to
issue a single lookup for all of the addressing resource records
associated with a domain name (explicitly including any IPv4 and
IPv6 resource records), and also defines an algorithm for DNS
servers to use to use when returning supplemental address data in
the additional-data section of a response message.
Note that these mechanisms are intended to serve as transitional
aids, in that they do not require infinite maintenance. If and
when a querying system moves to a single IPv6 stack (as opposed to
the dual-stack approach common during the transitional period),
the use of the ADDR query-type can be discontinued. Similarly, as
Hall I-D Expires: May 2004 [page 3]
Internet Draft draft-hall-qtype-addr-01.txt November 2003
host entries in the DNS move to IPv6 only (as opposed to having
IPv4 and IPv6 addresses simultaneously as is common during the
transitional period), only the IPv6 answer data will be returned.
In this regard, the mechanisms described in this specification
provide built-in exit strategies.
3. The ADDR Query-Type
The ADDR query-type has a code value of [TBD IANA], and the
mnemonic of "ADDR".
ADDR is a query-type only, not a resource record type, and
therefore does not define any data structures.
The following sub-sections define handling rules which MUST be
implemented by a responder which claims to support the ADDR query-
type. If a responder is unable or unwilling to comply with each
and every one of these requirements, it MUST reject queries for
the ADDR query-type with an appropriate error response, as defined
in section 3.6 below.
For undefined cases, the rules defined in [RFC1035] and [RFC2308]
MUST be followed, as appropriate to the scenario at hand.
3.1. Basic Handling
DNS responders which receive and process requests for the ADDR
query-type (including authoritative and non-authoritative servers,
local caches, or any other responding agent) MUST respond with all
of the A and AAAA resource records associated with the domain name
specified in the query name field of the question section.
If the queried domain name is known not to exist, a NXDOMAIN
response MUST be returned, as defined in [RFC2308].
If the queried domain name is known to exist but does not have any
associated AAAA or A resource records, a Type 1 NODATA response
MUST be returned, as defined in [RFC2308].
If the queried domain name is known to exist and has A and AAAA
resource records, those resource records MUST be provided in the
answer section of the response message.
Hall I-D Expires: May 2004 [page 4]
Internet Draft draft-hall-qtype-addr-01.txt November 2003
In those cases where only one type of resource record exists (such
as AAAA resource records, the section of the response MUST contain
the Start-of-Authority resource record for the controlling zone.
The presence of this resource record in conjunction with an
incomplete answer section is intended to provide negative caching
hinting data for the missing resource records, essentially
emulating the Type 1 NODATA response described in [RFC2308].
3.2. Ensuring Valid Answer Sets
This specification requires that a responder only answer ADDR
queries if the responder is capable of obtaining and providing
complete and accurate representations of the canonical A and AAAA
resource records associated with the target domain name. It is
imperative that answers to ADDR queries MUST only be provided in
their complete form. Providing erroneous or incomplete data can
cause significant problems to occur with the users of that data,
and incomplete answers MUST NOT be sent (see the discussion on
truncation in section 3.5 below).
If any of the canonical resource record sets are missing from the
responder's view of the data (either because those resource
records have not yet been obtained or have expired), the missing
data MUST be acquired before the ADDR query is answered.
In the case of authoritative servers responding to ADDR queries,
the answer data can (obviously) be sourced from an authoritative
database. In the case of a cache or forwarding server, however,
this will have to be achieved by either forwarding the original
ADDR query to another server (where it will presumably reach an
authoritative server sooner or later), or by issuing separate
(independent) queries for the AAAA and A resource records
associated with the domain name in question.
Data which has been cached from previous queries SHOULD be used to
answer current queries (assuming that the time-to-live values and
other factors allow it), as per usual DNS behavior.
In those cases where a non-authoritative responder has existing
knowledge of only one resource record, the responder SHOULD issue
the minimum number of queries necessary to fill in gaps (such as
limiting back-end queries to just the missing resource records),
and SHOULD NOT unnecessarily refresh data which is already known.
Hall I-D Expires: May 2004 [page 5]
Internet Draft draft-hall-qtype-addr-01.txt November 2003
If either or both of the canonical A or AAAA resource records have
been discovered not to exist (such as will occur upon receipt of
NODATA responses to any of the above queries), the negative answer
MUST be associated with the missing resource records according to
the rules defined in [RFC2308], with this knowledge being used to
construct the query response.
Note that caches and forwarding agents will sometimes need to
issue discrete queries for the Start-of-Authority resource record
associated with the authoritative zone in order to satisfy these
requirements. In particular, if a responder receives non-Type 1
NODATA responses to discrete A and AAAA lookups, the responder
will need to fetch the SOA resource record in order to provide a
complete and accurate answer.
If all of the answer data is obtained from an authoritative source
as a result of the current ADDR query (regardless of whether or
not discrete lookups were used), the Authoritative Answer flag in
the response message MUST be enabled, as per usual behavior. If
any of the answer data came from a non-authoritative source (EG,
one of resource record sets was already cached), the Authoritative
Answer flag in the response message MUST NOT be enabled.
If a full and complete view of the canonical A and AAAA resource
records cannot be obtained, a positive answer MUST NOT be
returned, and an appropriate error response MUST be returned
instead. Refer to section 3.6 below for more information.
3.3. Time-To-Live Values
Choosing the appropriate time-to-live values for an ADDR response
will be based upon multiple factors, and will therefore vary for
different scenarios.
A responder MUST NOT increase the time-to-live value for any of
the canonical resources record beyond their original values, under
any circumstances.
Each set of AAAA and A resource records MUST be synchronized to
their lowest common values individually, as per the rules set
forth in [RFC2181]. For example, all of the A resource records
MUST have the same time-to-live value, but these are not required
to be the same time-to-live value of the AAAA resource records.
Hall I-D Expires: May 2004 [page 6]
Internet Draft draft-hall-qtype-addr-01.txt November 2003
Responders MAY synchronize the time-to-live values of all resource
records to the lowest common value, but this is not required.
Note that the time-to-live values may be synchronized for reasons
unrelated to the ADDR query-type. For example, resource records
which were learned as referral glue could have had their time-to-
live values synchronized by another responder already, without any
input or effort by the current system.
3.4. CNAME Processing
If the target domain name has a CNAME resource record which
references some other domain name, and if the Recursion Desired
bit has been enabled in the query, and if the responder is willing
to perform recursion on behalf of the querying agent, then the
alias target MUST be queried for any existing A and AAAA resource
records which have been defined. In other combinations, the alias
target MAY be queried for any existing A and AAAA resource
records. If this processing is not performed, either the CNAME
resource record or a referral MUST be returned.
3.5. Truncated ADDR Responses
In those cases where all of the A and AAAA resource records will
not fit within a response message, the responder MUST truncate the
message according to the following rules.
Incomplete resource record sets MUST NOT be provided. If this
means that only one or the other resource record types can be
provided in the answer, then only one of those resource record
sets are to be provided. Both resource record sets MAY be omitted
from the answer section if necessary or desired.
If a responder wishes to include one of the resource record sets
(and assuming that there is room in the response message for that
data), the responder SHOULD give a preference to the network type
which was used to transport the original query. For example, if
the original query was received over an IPv6 network interface,
the responder SHOULD give preference to the AAAA resource records
in the response message.
In any event, truncated answers to ADDR queries MUST have the TC
flag enabled. Clients which receive truncated ADDR responses
SHOULD perform whatever recovery steps are available, possibly
Hall I-D Expires: May 2004 [page 7]
Internet Draft draft-hall-qtype-addr-01.txt November 2003
including retransmitting the query via TCP, or simply requesting
the missing resource record set via a separate query.
Note that resolvers can avoid the penalties of truncation through
a variety of means. At a minimum, applications that do not support
IPv4 and IPv6 addresses could always use discrete queries for the
only supported address type, rather than using ADDR queries in all
cases. Meanwhile, resolvers which are able to determine a
preference for a specific address type may be able to issue
lookups via that network, thereby triggering the truncation
preference mechanism described above (EG, if an application is
able to indicate that it prefers IPv6, the resolver could issue
the lookup using IPv6, and thus the IPv6 resource record would be
preferred in any truncated response). Furthermore, [EDNS] provides
larger DNS message sizes, which can further help to avoid problems
related to truncated responses.
3.6. Error Responses
In general terms, the error responses which are to be used with
ADDR queries conform to the requirements specified in [RFC1035]
and its updates.
If the target domain name is known not to exist, the NXDOMAIN
response described in [RFC2308] MUST be returned.
If the target domain name is known not to have any A or AAAA
resource records associated with it, the absence of that data MUST
be signified through the use of a Type 1 NODATA response, as
described in [RFC2308] and section 3.2 above.
If the responder is unable to obtain full and complete answer data
due to a communications failure, the response message MUST use the
SERVFAIL response code.
If the responder is unwilling to pursue full and complete answer
data, the response message MUST either contain a referral or use
the NOTIMPL response code. Note that this may happen if the
responder is unwilling to perform recursion, or is only willing to
forward ADDR queries but is unwilling to issue multiple discrete
queries in support of downstream clients.
Responders MUST NOT provide incomplete or partial answer data in
any scenario, and MUST return an appropriate referral or error.
Hall I-D Expires: May 2004 [page 8]
Internet Draft draft-hall-qtype-addr-01.txt November 2003
3.7. ADDR Query-Type Examples
The following response message illustrates a domain name that only
has an IPv4 address defined. In that example, the known absence of
any IPv6 address resource records is represented by the presence
of the ADDR query-type in the Question section and the SOA
resource record in the Authority section. The SOA resource record
would be used to cache the negative answer.
--Message Header--
Status: NOERROR
Flags: QR AA RD RA
--Question Section--
Name: host.example.com.
Type: ADDR
--Answer Section--
A: 192.168.2.14 [...]
--Authority Section--
SOA: example.com. [...]
The following response message illustrates a truncated response
message. In that example, the TC flag is enabled, indicating that
the full and complete answer data would not fit within the
message. The presence of a single A resource record indicates that
only one IPv4 address is defined for the target (section 3.5 of
this specification explicitly prohibits incomplete resource record
sets, so this must be the full set).
--Message Header--
Status: NOERROR
Flags: QR AA RD RA TC
--Question Section--
Name: host.example.com.
Type: ADDR
--Answer Section--
A: 192.168.2.14 [...]
Hall I-D Expires: May 2004 [page 9]
Internet Draft draft-hall-qtype-addr-01.txt November 2003
4. All-Addresses Additional Data
Several existing specifications currently define additional-
section processing rules which that IPv4 address resource records
are to be returned as supplemental data in certain responses. For
example, [RFC1035] encourages A resource records to be included
whenever NS resource records are provided as part of a referral,
while [SMTP] endorses similar behavior whenever MX resource
records are returned as answer data. This specification expands
all such uses, so that if any A resource records would be provided
as additional data in a response message, then any known AAAA
resource records for that same domain name SHOULD also be provided
at the same time.
In general terms, resource records which are provided in the
additional-data section of a response message are typically
offered as a convenience for the recipient, in that they can
preclude any expected subsequent queries which would otherwise be
needed. Moreover, the absence of this data is generally non-fatal,
and as such the resource records which are provided in this
section of the message typically have much lower requirements than
data that is provided in most of the other sections. Essentially,
the inclusion or omission of any resource records in this section
is a matter of mutual convenience and efficiency for the parties
involved, and is not usually critical.
If a responder would normally provide A resource records as
additional data, and if that responder also has existing knowledge
of AAAA resource records associated with the same domain name,
then the responder SHOULD provide the AAAA data in the additional-
data section of the response message in addition to the A resource
records which it would already have provided.
Responders SHOULD NOT attempt to chase down this data if it is not
already known. Responders MUST NOT attempt to indicate that the
data is unknown, or that the data is known not to exist.
Clients MAY make use of any addressing resource records which are
provided in the additional-data section, but MUST NOT assume that
the lack of any of resource records indicates full and complete
knowledge of the domain name in question. If any addressing
resource records are missing from the additional-data section of a
response message, it is the client's responsibility to verify that
the addressing resource records do not actually exist, either
Hall I-D Expires: May 2004 [page 10]
Internet Draft draft-hall-qtype-addr-01.txt November 2003
through the use of independent queries for the missing resource
records, or through the use of an ADDR query.
4.1. Truncated Additional-Data
In those cases where all of the A and AAAA resource records will
not fit within a response message, the responder MUST truncate the
message according to the following rules.
Incomplete resource record sets MUST NOT be provided. If this
means that only one or the other resource record types can be
provided as additional data, then only one of those resource
record sets are to be provided. Both resource record sets MAY be
omitted from the additional-data section if necessary or desired.
If a responder wishes to include one of the resource record sets
(and assuming that there is room in the response message for that
data), the responder SHOULD give a preference to the network type
which was used to transport the original query. For example, if
the original query was received over an IPv6 network interface,
the responder SHOULD give preference to the AAAA resource records
in the response message.
Absent other causes, truncated additional data MUST NOT cause the
TC flag to be enabled.
Note that resolvers can avoid the penalties of truncation through
a variety of means. Resolvers which are able to determine a
preference for a specific address type may be able to issue
lookups via that network, thereby triggering the truncation
preference mechanism described above (EG, if an application is
able to indicate that it prefers IPv6, the resolver could issue
the lookup using IPv6, and thus the IPv6 resource record would be
preferred in any truncated response). Furthermore, [EDNS] provides
larger DNS message sizes, which can further help to avoid problems
related to truncated responses.
4.2. Additional-Data Examples
TBD
Hall I-D Expires: May 2004 [page 11]
Internet Draft draft-hall-qtype-addr-01.txt November 2003
5. Security Considerations
None at this time.
6. IANA Considerations
This document defines a new DNS query-type which will require a
code value to be allocated by IANA.
7. Author's Addresses
Eric A. Hall
ehall@ehsco.com
8. Normative References
[RFC1035] Mockapetris, P. "DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION", RFC 1035, November 1997.
[RFC1886] Thomson, S., and Huitema, C. "DNS Extensions to
support IP version 6", RFC 1886, December
1995.
[RFC2181] Elz, R., and Bush, R. "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2308] Andrews, M. "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
9. Informative References
[SMTP] Klensin, J. "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
10. Acknowledgments
Funding for the RFC editor function is currently provided by the
Internet Society.
Hall I-D Expires: May 2004 [page 12]
Internet Draft draft-hall-qtype-addr-01.txt November 2003
11. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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.
Hall I-D Expires: May 2004 [page 13]
