Network Working Group G. Michaelson
Internet-Draft APNIC
Expires: July 13, 2008 January 10, 2008
The Modern DNS Implementation Guide
draft-ietf-dnsext-dns-protocol-profile-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
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.
This Internet-Draft will expire on July 13, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
A structured catalogue of relevant DNS RFCs is presented with
references to the specific normative sections which should be
followed in a modern DNS implementation. This document is to be used
as guide for DNS implementors, for testing and compliance of DNS-
functioning software, and to help guide DNS standards advancement.
Michaelson Expires July 13, 2008 [Page 1]
Internet-Draft The Modern DNS Implementation Guide January 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Key Approach . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Normative Language Usage . . . . . . . . . . . . . . . . . 4
2. General Considerations . . . . . . . . . . . . . . . . . . . . 5
3. Common Requirements . . . . . . . . . . . . . . . . . . . . . 5
4. Authoritative Servers . . . . . . . . . . . . . . . . . . . . 6
4.1. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Zone Contents . . . . . . . . . . . . . . . . . . . . 6
4.1.2. Zone synchronization . . . . . . . . . . . . . . . . . 7
4.2. Server and connection management . . . . . . . . . . . . . 7
4.2.1. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.2. TCP . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.3. TCP Connection Management . . . . . . . . . . . . . . 8
4.3. DNS Message processing . . . . . . . . . . . . . . . . . . 8
4.4. Further Query processing . . . . . . . . . . . . . . . . . 9
4.4.1. Actions based on QTYPE of incoming Query . . . . . . . 9
4.5. Additional Data processing . . . . . . . . . . . . . . . . 9
4.6. Label compression in RDATA . . . . . . . . . . . . . . . . 9
4.7. Truncation handling . . . . . . . . . . . . . . . . . . . 10
4.8. NSEC processing . . . . . . . . . . . . . . . . . . . . . 10
5. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Recursive Resolvers . . . . . . . . . . . . . . . . . . . . . 10
7. Middle-Boxes . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. Concordance of references . . . . . . . . . . . . . . . . . . 11
11. Changes since the -00 draft . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . . 11
12.2. Informational, Formerly Normative References, now
obsolete . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.3. Non-Normative, DNS related, but not relevant to
Implementors References . . . . . . . . . . . . . . . . . 19
12.4. Informative References Non RFC's . . . . . . . . . . . . . 22
Appendix A. Formerly Normative, now Obsolete References . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
Michaelson Expires July 13, 2008 [Page 2]
Internet-Draft The Modern DNS Implementation Guide January 2008
1. Introduction
The DNS is almost 25 years old. In that time a significant amount of
change has occurred in the collection of RFCs which document how DNS
systems should be implemented and operated.
o Developers of DNS systems need a single reference which can be
used consistently to review interoperability between
implementations and to guide implementation of DNS systems.
o Operators of DNS systems need a reference which can be used to
understand existing DNS systems conformance and to guide
acquisition and management of new DNS systems.
Accordingly, the DNSEXT working group has been asked by the RAI ADs
and others to document what the basic requirements for 'modern' DNS
implementations are.
By reviewing the normative sections of the 'head' documents (ie the
documents which are current, have not been superseded by a -bis or a
different document, explicitly deprecated or fallen into disrepair)
the DNSEXT working group identified the set of references into those
documents which specify all of the 'directives' which define how the
'modern' DNS system should work.
In the process of review, areas of attention were identified. These
represent normative directing text(s) in the RFCs, or the entire RFCs
themselves, which required change, to reflect the current state of
the DNS.
During this documents development, areas of standardization which
required attention were noted, and were addressed in one of the
following four ways.
o Firstly, if the revisions were simple enough, a -bis process was
used to define the smallest set of changes to the RFC, and a new
version rolled, with the old one deprecated.
o Secondly, if the revisions were complex, or so many exist that a
complete re-write would be more effective, a more lengthy process
was used to re-define the complete set of behaviors as a working
group activity. The outcome is the same: A new RFC was created,
and the old RFC can be deprecated.
o Thirdly, if the RFC is no longer held to be relevant, it was
deprecated without replacement.
o Lastly, if the change was too small to justify revision of the
head document then the inclusion of normative language was
appropriate in this document. For instance, allowed
interpretations of pre-RFC2119 non-normative texts.
This document is not intended to be used to guide operation of DNS
systems, nor to guide creation and maintenance of DNS zones, or the
Michaelson Expires July 13, 2008 [Page 3]
Internet-Draft The Modern DNS Implementation Guide January 2008
DNS namespace. In particular, normative directions on features which
must be implemented may still be, (in many cases) disabled under
operational control.
1.1. Key Approach
Normally in an RFC or draft, a section of boilerplate directs the
meaning of normative language and how it relates to the standard
usages. In that respect, this document is no different.
However, as a general principle, this document seeks to avoid
directly creating new normative text. Instead, it is a collation of
references to the normative text of other documents.
As far as possible, no new normative language should have been
created in this document. Where it is seen, it needs to be clearly
understood to be either derived from a prior document (and referenced
accordingly) or else clearly marked as being originated in this
document.
As far as possible, the document should be structured and maintained
in an overall manner which allows it to be subject to future
revision. For example, the likelihood of subsequent changes to Hash
function lifetimes means that it is foreseeable the documents
normative language references to cryptographic algorithms will
require future revision. New developments in DNS will require
consideration for their normative language and should be reviewed
against each section of this document.
Therefore, this document should be actively maintained, and updated
to reflect changes in DNS standardization.
1.2. Normative Language Usage
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.
Because of the new normative language review, introduced in RFC 4307
it was also possible to refine normative language in this document,
as a "step along the road" to final resolution. Therefore some
instances of normative language in this document revise the reference
by changing a MUST into a MUST-, or a SHOULD into a SHOULD+
reference. This provides a signal that implementors need to be aware
of change in the compliance status of the behaviour under
consideration, and therefore need to be working towards a future goal
of a stronger (or weaker) normative binding in that area.
Michaelson Expires July 13, 2008 [Page 4]
Internet-Draft The Modern DNS Implementation Guide January 2008
Since the normative language includes SHOULD and MAY directives, DNS
Implementors are strongly encouraged to identify completely all
optional elements of their systems, including both positive (MAY and
SHOULD directives which have been followed) as well as negative (MAY
and SHOULD directives which have been ignored).
2. General Considerations
{new normative language} This document catalogs the compliance issues
for an implementation of any component of the DNS. Implementors MUST
adhere to the collected state of these directives to be considered
fully compliant to DNS RFCs and STDs.
{not normative} Because important DNS RFCs pre-date RFC 2119 this
document explicitly shows where their text is to be re-interpreted in
line with RFC2119 normative language
The document is organized into five major sections, addressing Common
Requirements, Authoritative Servers, Stub Resolvers, Recursive
Resolvers and Middle-boxes. DNS Implementors should read all
sections carefully since subsequent sections refer back to prior
sections and catalog variances as well as new requirements.
Application specific considerations are not normatively addressed by
this document. Where mentioned, the text should be considered
guidance only.
3. Common Requirements
{new normative language. the -bis document needs its reference
confirmed.} EDNS0 MUST be implemented by all DNS systems. Its use is
an operational decision. This is is line with [RFC 1996] and its
-bis document.
{new normative language} Unknown RRtypes MUST be preserved. This is
in line with [RFC 3597]
{new normative language} The DNS Database consistency MUST be
maintained. Data MUST NOT leak between zones. [RFC 1997]
{non normative} The following documents define registries of DNS RR
types. All new record types can be treated as unknown RRs as above.
{list of RR-types refs. Just the IANA registry, rather than all RFCs
has been suggested by Olafur}
{new normative language} Processing if dns names in US-ASCII range
Michaelson Expires July 13, 2008 [Page 5]
Internet-Draft The Modern DNS Implementation Guide January 2008
MUST be case insensitive. [RFC 1035 (2.3.3)] also see [RFC 1034
(3.1)]
4. Authoritative Servers
{Much of this text comes from [NLNet-1]. These requirements are in
order of importance: }
4.1. Zones
4.1.1. Zone Contents
{non normative} The zone file format as specified in [RFC 1035 (5.1)]
is optional. It is used as a common presentation format only.
{new normative language: needs RFC reference} A served zone SHOULD
not contain errors, or produce unpredictable results when RRs that
are obsolete, or not implemented are encountered.
Zones MUST follow the rules as defined in [RFC 1035 (5.2)] and
subsequent revisions by the following RFCs:
[RFC 1101]
[RFC 1122]
[RFC 1183]
[RFC 1706]
[RFC 1876]
[RFC 1982]
[RFC 1995]
[RFC 1996]
[RFC 2136]
[RFC 2137]
[RFC 2181]
[RFC 2308]
[RFC 2535] {this needs to be reviewed, and probably updated to a
new RFC}
[RFC 2782]
[RFC 2845]
[RFC 3425]
[RFC 3658]
[RFC 4034]
[RFC 4035]
from [RFC 1035 (section 5.2)] and [RFC 2181 (section 5.2)] the
following text has been extracted, and re-written in line with RFC
2119 normative language.
[RFC 1035 (Section 5.2)] Rules governing zone content
Michaelson Expires July 13, 2008 [Page 6]
Internet-Draft The Modern DNS Implementation Guide January 2008
{new normative text}
1. All RRs in the file MUST have the same class. [RFC 1035 (Section
5.2 rule 1)]
2. Exactly one SOA RR MUST be present at the top of the zone
(meaning the delegation point). [RFC 1035 (Section 5.2 rule 2)]
3. If delegations are present and glue information is required, it
SHOULD be present. [RFC 2181 (Section 5.2 para 2)]
4. The TTLs of all RRs in an RRSet MUST be the same. {RFC reference
required}
5. You must adhere to [RFC 2672 (Section 3)] and {reference will
need updating to published RFC}
[I-D.ietf-dnsext-rfc2671bis-edns0] in respect of data below
DNAME.
6. There MUST be no data below CNAME, and only DNSSEC records with
CNAME. [RFC 4034] [RFC 4035]
7. {new non-normative informational text} Information present
outside of the authoritative nodes in the zone is glue
information, rather than the result of an origin or similar
error.
4.1.2. Zone synchronization
4.1.2.1. Timeout management
{referencing RFC details needed} Timeouts on the SOAs for secondary
zones according to [RFC...].
4.2. Server and connection management
DNS servers MUST comply with [RFC 2181 (4)]
4.2.1. UDP
The server MUST listen to UDP on port 53 [RFC 2181 (4)]
{ new normative language, but implied from EDNS0 is a MUST. should
have an RFC reference} Large packet sizes SHOULD be supported.
4.2.2. TCP
{new normative language, maybe.. } The server MAY accept TCP
connections. {? what is the correct wording and reference?}
Note that there may be one or more DNS messages in the stream. Each
message is prepended with a 2 byte size servers follow [RFC 1035
(4.2.2)]
Michaelson Expires July 13, 2008 [Page 7]
Internet-Draft The Modern DNS Implementation Guide January 2008
4.2.3. TCP Connection Management
from [RFC 1035 (section 4.2.2)] the following text has been
extracted, and re-written in line with RFC2119 normative language.
[RFC 1035 (4.2.2.)] TCP Usage
{new normative text}
o the server SHOULD not block other activities waiting for TCP data
o The server SHOULD assume that the client will initiate connection
closing and SHOULD delay closing its end of the connection until
all outstanding client requests have been satisfied.
o { this is 25 year old advice. is this still relevant or what
should it be? } For closing dormant connections the timeout should
be in the order of 2 minutes.
4.3. DNS Message processing
DNS messages should be processed in line with the precepts of [RFC
1034 (Section 4.3.1)]
{ new normative language. there is no explicit reference in existing
RFCs to the following} Non parsable messages SHOULD be replied to
with a FORMERR.
Each UDP packet only carries one DNS Message. Any data behind the
DNS message SHOULD be considered garbage and SHOULD be ignored.
{better text requested}
o Incoming DNS messages with the QR bit set to 1 (response) are
discarded. [RFC 1035 (sect 7.3)]
o RD is copied into the response [RFC 1035 (4.1.1)] the RA bit is
set to 0 and the QUERYID is copied into the response message as
follows:
* OPCODE 0 (QUERY) MUST be supported [RFC 1035]
* OPCODE 1 (IQUERY) MUST result in RCODE=4 NOTIMPL [RFC 3425]
{has this actually been deprecated?}
* OPCODE 2 (STATUS) MUST result in RCODE=4 NOTIMPL [RFC 1035]
{new normative language, not explicitly brought out}
* OPCODE 3 (RESERVED) MUST result in RCODE=4 NOTIMPL {requires an
RFC reference}
* {new normative language} The following are optional but
recommended techologies, which SHOULD be handled gracefully,
rather than through use of NOTIMPL
+ OPCODE 4 (NOTIFY) SHOULD+ be supported [RFC 1995]
+ OPCODE 5 (UPDATE) SHOULD+ be supported [RFC 2136 (sect 3)]
Michaelson Expires July 13, 2008 [Page 8]
Internet-Draft The Modern DNS Implementation Guide January 2008
o {no RFC/normatives found, need guidance}
* AA bit in query packet SHOULD be ignored.
* TC bit set in a query packet SHOULD+ be answered with FORMERR.
* RCODES SHOULD ignored.
* QDCOUNT!=1 SHOULD result in RCODE=1 FORMERR
o Presence of OPT RR indicates support of EDNS [RFC 2671]. If the
VERSION > 0 then the server will respond with an OPT with
RCODE=BADVERSION and VERSION=0 (The server supports EDNS0) In
further processing ENDS0 support is taken into account.
4.4. Further Query processing
4.4.1. Actions based on QTYPE of incoming Query
Further processing of the packet is based on the algorithm from [RFC
1034] as modified by [RFC 2672 (4)].
DNSSEC Considerations follow [RFC 4035]
4.5. Additional Data processing
Additional data is added as long as there is space in the packet.
{need reference}
When processing the additional section priority is as specified in
[RFC 2874 (4)]
o A
o AAAA
For truncation see section [Truncation handling]
4.6. Label compression in RDATA
[RFC 1035 (section 3.3. and 4.4.1)] ("Pointers can only be used for
occurrences of a domain name where the format is not class
specific.")
Do label compression for labels in rdata for which this is
specifically mentioned in the RFC defining the RR.
o NS, SOA, CNAME, and PTR [RFC 1035 (3.3)]
o Others defined in [RFC 1035 (3.3)]are not compressed.
o MB, MG, MR, MINFO, MX also have compressed dnames. These RRs and
their compression are described in [RFC 1035].
o AFSDB, RP, RT [RFC 1183, (Section 1,2 & 3.3.3)]
o You MUST follow the rules in [RFC 3597].
Michaelson Expires July 13, 2008 [Page 9]
Internet-Draft The Modern DNS Implementation Guide January 2008
4.7. Truncation handling
Truncation handling is as specified in [RFC 2181 (9)]
{TBD normative text for this section. RFC references required.} If
inclusion of a RR set that is REQUIRED in either the answer or
authority section leads to message truncation. The section is left
empty and the truncation (TC) bit is set. If the DO bit is set RRSIG
RRs are required in the answer and authority section.
If inclusion of an RRset in the Additional section is not possible
RRs are omitted one by one. This may lead to incomplete RRsets.
Omission of RRs from the Additional section because of message size
constraints will NOT lead to setting of the TC bit. [RFC 2181 (9)]
{RFC references required.} Implementations need to allow for
incomplete RRsets in the additional section.
4.8. NSEC processing
{section reference required.} The NSEC record is required to be in
the authority section if a QNAME or a QTYPE cannot be matched [RFC
4035 (section ?)].
{this text needs to be moved out of authoritative servers. Not clear
which section its in yet.} Note that on a QNAME match the NS records
are not copied into the AUTH section (This is a requirement from step
4 'matching down the cache' from [RFC 1034 (Section 4.3.2)]. This is
a requirement only for caching servers.
5. Stub Resolvers
TBD
6. Recursive Resolvers
TBD
7. Middle-Boxes
TBD
Michaelson Expires July 13, 2008 [Page 10]
Internet-Draft The Modern DNS Implementation Guide January 2008
8. IANA Considerations
None at this time. The goal of the document is to have no IANA
actions.
9. Acknowledgments
Much of the initial ideas, and structure of the text reflect ideas
taken from a design document developed by NLNet Labs, in the process
of developing NSD. This was written by Dr. Wouter C.A. Wijngaards
and Jaap Akkerhuis. [NLNet-1].
A list of RRtypes, included in the above document is maintained by
Jelte Jansen, and was also used as input to this document.
[Jelte-1].
A list of DNS standards was developed in 2004 by AndrA!s Salamon and
was used as input to this document. [Salaman-1].
10. Concordance of references
To assist in compiling automated checkers, this document includes as
an appendix a concordance of normative references. This provides a
handy reference to the sections of this document which depend on each
cited RFC, and vice-versa.
To add new dependencies into the modern DNS Implementation Guide this
concordance should be used to identify related documents and review
if any have been superseded, and also to check where else in this
document a related dependency may exist.
11. Changes since the -00 draft
[Note: This section is not for publication.]
12. References
12.1. Normative References
[I-D.ietf-dnsext-rfc2671bis-edns0]
Vixie, P., "Revised extension mechanisms for DNS (EDNS0)",
draft-ietf-dnsext-rfc2671bis-edns0-00 (work in progress),
December 2007.
Michaelson Expires July 13, 2008 [Page 11]
Internet-Draft The Modern DNS Implementation Guide January 2008
[RFC1033] Lottor, M., "Domain administrators operations guide",
RFC 1033, November 1987.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P.
Mockapetris, "New DNS RR Definitions", RFC 1183,
October 1990.
[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store
Arbitrary String Attributes", RFC 1464, May 1993.
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction
With Widely Deployed DNS Software", RFC 1535,
October 1993.
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
Miller, "Common DNS Implementation Errors and Suggested
Fixes", RFC 1536, October 1993.
[RFC1706] Manning, B. and R. Colella, "DNS NSAP Resource Records",
RFC 1706, October 1994.
[RFC1713] Romao, A., "Tools for DNS debugging", RFC 1713,
November 1994.
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794,
April 1995.
[RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A
Means for Expressing Location Information in the Domain
Name System", RFC 1876, January 1996.
[RFC1912] Barr, D., "Common DNS Operational and Configuration
Errors", RFC 1912, February 1996.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.
Michaelson Expires July 13, 2008 [Page 12]
Internet-Draft The Modern DNS Implementation Guide January 2008
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996.
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
Communities Attribute", RFC 1997, August 1996.
[RFC2010] Manning, B. and P. Vixie, "Operational Criteria for Root
Name Servers", RFC 2010, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2163] Allocchio, C., "Using the Internet DNS to Distribute MIXER
Conformant Global Address Mapping (MCGAM)", RFC 2163,
January 1998.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2219] Hamilton, M. and R. Wright, "Use of DNS Aliases for
Network Services", BCP 17, RFC 2219, October 1997.
[RFC2230] Atkinson, R., "Key Exchange Delegation Record for the
DNS", RFC 2230, November 1997.
[RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
Sataluri, "Using Domains in LDAP/X.500 Distinguished
Names", RFC 2247, January 1998.
[RFC2276] Sollins, K., "Architectural Principles of Uniform Resource
Name Resolution", RFC 2276, January 1998.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
Michaelson Expires July 13, 2008 [Page 13]
Internet-Draft The Modern DNS Implementation Guide January 2008
[RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in
the Domain Name System (DNS)", RFC 2538, March 1999.
[RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
Domain Name System (DNS)", RFC 2539, March 1999.
[RFC2540] Eastlake, D., "Detached Domain Name System (DNS)
Information", RFC 2540, March 1999.
[RFC2541] Eastlake, D., "DNS Security Operational Considerations",
RFC 2541, March 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
RFC 2672, August 1999.
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.
[RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A.
Heffernan, "DNS extensions to Network Address Translators
(DNS_ALG)", RFC 2694, September 1999.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC2825] IAB and L. Daigle, "A Tangled Web: Issues of I18N, Domain
Names, and the Other Internet protocols", RFC 2825,
May 2000.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
IPv6 Address Aggregation and Renumbering", RFC 2874,
July 2000.
[RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916,
September 2000.
[RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning,
"Domain Name System (DNS) IANA Considerations", BCP 42,
RFC 2929, September 2000.
Michaelson Expires July 13, 2008 [Page 14]
Internet-Draft The Modern DNS Implementation Guide January 2008
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.
[RFC2937] Smith, C., "The Name Service Search Option for DHCP",
RFC 2937, September 2000.
[RFC2972] Popp, N., Mealling, M., Masinter, L., and K. Sollins,
"Context and Goals for Common Name Resolution", RFC 2972,
October 2000.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
Signing Authority", RFC 3008, November 2000.
[RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone
Status", RFC 3090, March 2001.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
Name System (DNS)", RFC 3110, May 2001.
[RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes
(APL RR)", RFC 3123, June 2001.
[RFC3197] Austein, R., "Applicability Statement for DNS MIB
Extensions", RFC 3197, November 2001.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
RFC 3225, December 2001.
[RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
message size requirements", RFC 3226, December 2001.
[RFC3258] Hardie, T., "Distributing Authoritative Name Servers via
Shared Unicast Addresses", RFC 3258, April 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)", RFC 3363,
August 2002.
Michaelson Expires July 13, 2008 [Page 15]
Internet-Draft The Modern DNS Implementation Guide January 2008
[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
Support for Internet Protocol version 6 (IPv6)", RFC 3364,
August 2002.
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm", RFC 3402, October 2002.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database",
RFC 3403, October 2002.
[RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Four: The Uniform Resource Identifiers (URI)",
RFC 3404, October 2002.
[RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Five: URI.ARPA Assignment Procedures", BCP 65,
RFC 3405, October 2002.
[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425,
November 2002.
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names (IDN)",
RFC 3491, March 2003.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, March 2003.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J.,
Michaelson Expires July 13, 2008 [Page 16]
Internet-Draft The Modern DNS Implementation Guide January 2008
and R. Hall, "Generic Security Service Algorithm for
Secret Key Transaction Authentication for DNS (GSS-TSIG)",
RFC 3645, October 2003.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
Authenticated Data (AD) bit", RFC 3655, November 2003.
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003.
[RFC3696] Klensin, J., "Application Techniques for Checking and
Transformation of Names", RFC 3696, February 2004.
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer (DS)", RFC 3755, May 2004.
[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
System KEY (DNSKEY) Resource Record (RR) Secure Entry
Point (SEP) Flag", RFC 3757, April 2004.
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, March 2005.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely
Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
January 2006.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
Michaelson Expires July 13, 2008 [Page 17]
Internet-Draft The Modern DNS Implementation Guide January 2008
for Authorizing Use of Domains in E-Mail, Version 1",
RFC 4408, April 2006.
[RFC4431] Andrews, M. and S. Weiler, "The DNSSEC Lookaside
Validation (DLV) DNS Resource Record", RFC 4431,
February 2006.
[RFC4701] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource
Record (RR) for Encoding Dynamic Host Configuration
Protocol (DHCP) Information (DHCID RR)", RFC 4701,
October 2006.
12.2. Informational, Formerly Normative References, now obsolete
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities",
RFC 882, November 1983.
[RFC0883] Mockapetris, P., "Domain names: Implementation
specification", RFC 883, November 1983.
[RFC0973] Mockapetris, P., "Domain system changes and observations",
RFC 973, January 1986.
[RFC1348] Manning, B., "DNS NSAP RRs", RFC 1348, July 1992.
[RFC1386] Cooper, A. and J. Postel, "The US Domain", RFC 1386,
December 1992.
[RFC1537] Beertema, P., "Common DNS Data File Configuration Errors",
RFC 1537, October 1993.
[RFC1637] Manning, B. and R. Colella, "DNS NSAP Resource Records",
RFC 1637, June 1994.
[RFC1664] Allocchio, C., Bonito, A., Cole, B., Giordano, S., and R.
Hagens, "Using the Internet DNS to Distribute RFC1327 Mail
Address Mapping Tables", RFC 1664, August 1994.
[RFC1712] Farrell, C., Schulze, M., Pleitner, S., and D. Baldoni,
"DNS Encoding of Geographical Location", RFC 1712,
November 1994.
[RFC1811] Federal Networking Council, "U.S", RFC 1811, June 1995.
[RFC1816] Federal Networking Council, "U.S", RFC 1816, August 1995.
[RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP
version 6", RFC 1886, December 1995.
Michaelson Expires July 13, 2008 [Page 18]
Internet-Draft The Modern DNS Implementation Guide January 2008
[RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996.
[RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
Extensions", RFC 2065, January 1997.
[RFC2137] Eastlake, D., "Secure Domain Name System Dynamic Update",
RFC 2137, April 1997.
[RFC2168] Daniel, R. and M. Mealling, "Resolution of Uniform
Resource Identifiers using the Domain Name System",
RFC 2168, June 1997.
[RFC2240] Vaughan, O., "A Legal Basis for Domain Name Allocation",
RFC 2240, November 1997.
[RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
System (DNS)", RFC 2537, March 1999.
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000.
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
August 2001.
12.3. Non-Normative, DNS related, but not relevant to Implementors
References
[RFC0805] Postel, J., "Computer mail meeting notes", RFC 805,
February 1982.
[RFC0811] Harrenstien, K., White, V., and E. Feinler, "Hostnames
Server", RFC 811, March 1982.
[RFC0819] Su, Z. and J. Postel, "Domain naming convention for
Internet user applications", RFC 819, August 1982.
[RFC0881] Postel, J., "Domain names plan and schedule", RFC 881,
November 1983.
[RFC0897] Postel, J., "Domain name system implementation schedule",
RFC 897, February 1984.
[RFC0920] Postel, J. and J. Reynolds, "Domain requirements",
RFC 920, October 1984.
[RFC0921] Postel, J., "Domain name system implementation schedule -
revised", RFC 921, October 1984.
Michaelson Expires July 13, 2008 [Page 19]
Internet-Draft The Modern DNS Implementation Guide January 2008
[RFC0974] Partridge, C., "Mail routing and the domain system",
RFC 974, January 1986.
[RFC1032] Stahl, M., "Domain administrators guide", RFC 1032,
November 1987.
[RFC1101] Mockapetris, P., "DNS encoding of network names and other
types", RFC 1101, April 1989.
[RFC1178] Libes, D., "Choosing a name for your computer", RFC 1178,
August 1990.
[RFC1480] Cooper, A. and J. Postel, "The US Domain", RFC 1480,
June 1993.
[RFC1591] Postel, J., "Domain Name System Structure and Delegation",
RFC 1591, March 1994.
[RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions",
RFC 1611, May 1994.
[RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions",
RFC 1612, May 1994.
[RFC1956] Engebretson, D. and R. Plzak, "Registration in the MIL
Domain", RFC 1956, June 1996.
[RFC2053] Der-Danieliantz, E., "The AM (Armenia) Domain", RFC 2053,
October 1996.
[RFC2100] Ashworth, J., "The Naming of Hosts", RFC 2100, April 1
1997.
[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
FUNCTIONS", RFC 2142, May 1997.
[RFC2146] Federal Networking Council, "U.S. Government Internet
Domain Names", RFC 2146, May 1997.
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
July 1997.
[RFC2307] Howard, L., "An Approach for Using LDAP as a Network
Information Service", RFC 2307, March 1998.
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
Michaelson Expires July 13, 2008 [Page 20]
Internet-Draft The Modern DNS Implementation Guide January 2008
[RFC2345] Klensin, J., Jr, T., and G. Oglesby, "Domain Names and
Company Name Retrieval", RFC 2345, May 1998.
[RFC2352] Vaughan, O., "A Convention For Using Legal Names as Domain
Names", RFC 2352, May 1998.
[RFC2377] Grimstad, A., Huber, R., Sataluri, S., and M. Wahl,
"Naming Plan for Internet Directory-Enabled Applications",
RFC 2377, September 1998.
[RFC2517] Moats, R. and R. Huber, "Building Directories from DNS:
Experiences from WWWSeeker", RFC 2517, February 1999.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999.
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the
Unique DNS Root", RFC 2826, May 2000.
[RFC2832] Hollenbeck, S. and M. Srivastava, "NSI Registry Registrar
Protocol (RRP) Version 1.1.0", RFC 2832, May 2000.
[RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root
Name Server Operational Requirements", BCP 40, RFC 2870,
June 2000.
[RFC3071] Klensin, J., "Reflections on the DNS, RFC 1591, and
Categories of Domains", RFC 3071, February 2001.
[RFC3245] Klensin, J. and IAB, "The History and Context of Telephone
Number Mapping (ENUM) Operational Decisions: Informational
Documents Contributed to ITU-T Study Group 2 (SG2)",
RFC 3245, March 2002.
[RFC3254] Alvestrand, H., "Definitions for talking about
directories", RFC 3254, April 2002.
[RFC3352] Zeilenga, K., "Connection-less Lightweight Directory
Access Protocol (CLDAP) to Historic Status", RFC 3352,
March 2003.
[RFC3367] Popp, N., Mealling, M., and M. Moseley, "Common Name
Resolution Protocol (CNRP)", RFC 3367, August 2002.
[RFC3368] Mealling, M., "The 'go' URI Scheme for the Common Name
Resolution Protocol", RFC 3368, August 2002.
[RFC3467] Klensin, J., "Role of the Domain Name System (DNS)",
Michaelson Expires July 13, 2008 [Page 21]
Internet-Draft The Modern DNS Implementation Guide January 2008
RFC 3467, February 2003.
[RFC3675] Eastlake, D., ".sex Considered Dangerous", RFC 3675,
February 2004.
12.4. Informative References Non RFC's
[Jelte-1] Jansen, J., "RRtypes", August 2007,
<http://tjeb.nl/Projects/RRTypes>.
[NLNet-1] Wijngaards, W., "NSD Requirements and Specifications",
July 2006, </dev/null>.
[Salaman-1]
Salaman, A., "DNS related RFCs", June 2004,
<http://www.dns.net/dnsrd/rfc/>.
Appendix A. Formerly Normative, now Obsolete References
RFC 882
RFC 883
RFC 973
These RFCs were all obsoleted by RFC 1034 and RFC 1035
RFC 1348
This RFC was obsoleted by RFC 1706
RFC 1386
This RFC was obsoleted by RFC 1480
RFC 1537
This RFC was obsoleted by RFC 1912
RFC 1637
This RFC was obsoleted by RFC 1706
RFC 1664
This RFC was obsoleted by RFC 2163
RFC 1712
This RFC was obsoleted by RFC 1876
RFC 1811
This RFC was obsoleted by RFC 1816
and subsequently RFC 2146
RFC 1816
This RFC was obsoleted by RFC 2146
RFC 1886
This RFC was obsoleted by RFC 3596
RFC 2052
This RFC was obsoleted by RFC 2782
RFC 2065
This RFC was obsoleted by RFC 2535
Michaelson Expires July 13, 2008 [Page 22]
Internet-Draft The Modern DNS Implementation Guide January 2008
RFC 2137
This RFC was obsoleted by RFC 3007
RFC 2168
This RFC was obsoleted by RFC 3401 RFC 3402 RFC 3403 and RFC 3404
RFC 2240
This RFC was obsoleted by RFC 2352
RFC 2537
This RFC was obsoleted by RFC 3110
RFC 2915
This RFC was obsoleted by RFC 3401 RFC 3402 RFC 3403 and RFC 3404
RFC 3152
This RFC was obsoleted by RFC 3596
Author's Address
George Michaelson
Asia Pacific Network Information Centre
Level 1, 33 Park Road
Milton, Queensland 4064
AU
Phone: +61 7 3858 3100
Email: ggm@apnic.net
Michaelson Expires July 13, 2008 [Page 23]
Internet-Draft The Modern DNS Implementation Guide January 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Michaelson Expires July 13, 2008 [Page 24]
