The Modern DNS Implementation Guide
draft-ietf-dnsext-dns-protocol-profile-01

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 23, 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 software, and to help guide DNS standards' advancement.

Table of Contents

1.  Introduction
    1.1.  Key Approach
    1.2.  Normative Language Usage
2.  General Considerations
3.  Common Requirements
4.  Authoritative Servers
    4.1.  Zones
        4.1.1.  Zone Contents
        4.1.2.  Zone synchronisation
    4.2.  Server and connection management
        4.2.1.  UDP
        4.2.2.  TCP
        4.2.3.  TCP Connection Management
    4.3.  DNS Message processing
    4.4.  Further Query processing
        4.4.1.  Actions based on QTYPE of incoming Query
    4.5.  Additional Data processing
    4.6.  Label compression in RDATA
    4.7.  Truncation handling
    4.8.  NSEC processing
    4.9.  NSID support
5.  Stub Resolvers
6.  Recursive Resolvers
    6.1.  NSID support
7.  Middle-Boxes
8.  IANA Considerations
9.  Acknowledgments
10.  Concordance of references
11.  Changes since the -01 draft
12.  Changes since the -00 draft
13.  References
    13.1.  Normative References
    13.2.  Informational, Formerly Normative References, now obsolete
    13.3.  Non-Normative, DNS related, but not relevant to Implementors References
    13.4.  Informative References Non RFC's
Appendix A.  Formerly Normative, now Obsolete References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

As of the time of writing, the Domain Name Service (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.

• 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.
• 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 DNS Extensions (DNSEXT) working group has been asked by the Real-time Applications and Infrastructure (RAI) Area Directors (AD) and others to document what the basic requirements for 'modern' DNS implementations are.

By reviewing the normative sections of the 'head' documents (i.e. the documents which are current, have not been superseded by another 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 standardisation which required attention were noted, and were addressed in one of the following four ways.

• Firstly, if the revisions were simple enough, a -bis process (where the document is lightly edited to achive the specific desired changes, and is then published as a complete replacement for the original) was used to define the smallest set of changes to the RFC, and a new version rolled, with the old one deprecated.
• 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.
• Thirdly, if the RFC is no longer held to be relevant, it was deprecated without replacement.
• 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 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 when a significant body of new DNS developments have occurred, e.g. to reflect changes in DNS standardisation.

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

Because of the new normative language review, introduced in RFC 4307 (Schiller, J., “Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2),” December 2005.) 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.

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 standards compliant.

{not normative} Because important DNS RFCs pre-date RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) 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 interpreted as 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 2671 (Vixie, P., “Extension Mechanisms for DNS (EDNS0),” August 1999.)] and its -bis document.

{new normative language} Unknown RRtypes MUST be preserved. This is in line with [RFC 3597 (Section 3) (Gustafsson, A., “Handling of Unknown DNS Resource Record (RR) Types,” September 2003.)]. which states:

To enable new RR types to be deployed without server changes, name servers and resolvers MUST handle RRs of unknown type transparently. That is, they must treat the RDATA section of such RRs as unstructured binary data, storing and transmitting it without change.

{new normative language} The DNS Database consistency MUST be maintained. Data MUST NOT leak between zones. {needs normative reference}

{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 of DNS names in US-ASCII range MUST be case-insensitive. [RFC 4343 (Eastlake, D., “Domain Name System (DNS) Case Insensitivity Clarification,” January 2006.)]. also see [RFC 1035 (2.3.3) (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)] and [RFC 1034 (3.1) (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.)].

4.  Authoritative Servers

{Much of this text comes from [NLNet‑1] (Wijngaards, W., “NSD Requirements and Specifications,” July 2006.). 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) (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)] 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) (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)] and subsequent revisions by the following RFCs:

[RFC 1101 (Mockapetris, P., “DNS encoding of network names and other types,” April 1989.)]

[RFC 1122 (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.)]

[RFC 1183 (Everhart, C., Mamakos, L., Ullmann, R., and P. Mockapetris, “New DNS RR Definitions,” October 1990.)]

[RFC 1706 (Manning, B. and R. Colella, “DNS NSAP Resource Records,” October 1994.)]

[RFC 1876 (Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, “A Means for Expressing Location Information in the Domain Name System,” January 1996.)]

[RFC 1982 (Elz, R. and R. Bush, “Serial Number Arithmetic,” August 1996.)]

[RFC 1995 (Ohta, M., “Incremental Zone Transfer in DNS,” August 1996.)]

[RFC 1996 (Vixie, P., “A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY),” August 1996.)]

[RFC 2136 (Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, “Dynamic Updates in the Domain Name System (DNS UPDATE),” April 1997.)]

[RFC 2137 (Eastlake, D., “Secure Domain Name System Dynamic Update,” April 1997.)]

[RFC 2181 (Elz, R. and R. Bush, “Clarifications to the DNS Specification,” July 1997.)]

[RFC 2308 (Andrews, M., “Negative Caching of DNS Queries (DNS NCACHE),” March 1998.)]

[RFC 2535 (Eastlake, D., “Domain Name System Security Extensions,” March 1999.)] {this needs to be reviewed, and probably updated to a new RFC}

[RFC 2782 (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.)]

[RFC 2845 (Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, “Secret Key Transaction Authentication for DNS (TSIG),” May 2000.)]

[RFC 3425 (Lawrence, D., “Obsoleting IQUERY,” November 2002.)]

[RFC 3658 (Gudmundsson, O., “Delegation Signer (DS) Resource Record (RR),” December 2003.)]

[RFC 4034 (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.)]

[RFC 4035 (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.)]

The following text has been extracted from [RFC 1035 (section 5.2) (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)] and [RFC 2181 (section 5.2) (Elz, R. and R. Bush, “Clarifications to the DNS Specification,” July 1997.)] and re-written using normative language specified in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.)

[RFC 1035 (Section 5.2) (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)] Rules governing zone content

{new normative text}

1. All RRs in the zone MUST have the same class. [RFC 1035 (Section 5.2 rule 1) (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)]
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) (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)].
3. If delegations are present and glue information is required, it SHOULD be present. [RFC 2181 (Section 5.2 para 2) (Elz, R. and R. Bush, “Clarifications to the DNS Specification,” July 1997.)].
4. The TTLs of all RRs in an RRset MUST be the same. [RFC 2181 (Section 5.2) (Elz, R. and R. Bush, “Clarifications to the DNS Specification,” July 1997.)].
5. You must adhere to [RFC 2672 (Section 3) (Crawford, M., “Non-Terminal DNS Name Redirection,” August 1999.)] and {reference will need updating to published RFC} [I‑D.ietf‑dnsext‑rfc2671bis‑edns0] (Graff, M. and P. Vixie, “Extension Mechanisms for DNS (EDNS0),” March 2010.) in respect of data conflicting with DNAME.
6. There MUST be no data at the same name as a CNAME, and only DNSSEC records with a CNAME. [RFC 4034 (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.)] [RFC 4035 (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.)].
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 synchronisation

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) (Elz, R. and R. Bush, “Clarifications to the DNS Specification,” July 1997.)].

4.2.1.  UDP

The server MUST listen to UDP on port 53 [RFC 2181 (4) (Elz, R. and R. Bush, “Clarifications to the DNS Specification,” July 1997.)].

{ 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 prefixed with a two byte length field which gives the message length, excluding the two byte length field. [RFC 1035 (4.2.2) (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)].

4.2.3.  TCP Connection Management

The following text has been extracted from [RFC 1035 (section 4.2.2) (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)] and re-written using normative language specified in [RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.)].

[RFC 1035 (4.2.2.) (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)] TCP Usage

{new normative text}

• the server SHOULD not block other activities waiting for TCP data
• 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.
• { 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) (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.)].

{ new normative language. there is no explicit reference in existing RFCs to the following} Non parsable messages SHOULD be replied to with a FORMERR.

When UDP transport is used, each UDP datagram MUST contain exactly one DNS Message. UDP datagrams SHOULD be constructed such that they contain no data following the DNS Message. If present, any additional data present following the DNS Message MUST be ignored.

• Incoming DNS messages with the QR bit set to 1 (response) are discarded. [RFC 1035 (sect 7.3) (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)].
• RD is copied into the response [RFC 1035 (4.1.1) (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)] 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 (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)].
  • OPCODE 1 (IQUERY) MUST result in RCODE=4 NOTIMPL [RFC 3425 (Lawrence, D., “Obsoleting IQUERY,” November 2002.)]. {has this actually been deprecated?}
  • OPCODE 2 (STATUS) MUST result in RCODE=4 NOTIMPL [RFC 1035 (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)]. {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 implemented, rather than through use of NOTIMPL
  • OPCODE 4 (NOTIFY) SHOULD+ be supported [RFC 1995 (Ohta, M., “Incremental Zone Transfer in DNS,” August 1996.)].
  • OPCODE 5 (UPDATE) SHOULD+ be supported [RFC 2136 (sect 3) (Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, “Dynamic Updates in the Domain Name System (DNS UPDATE),” April 1997.)].
• {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.
  • The TC bit answer FORMERR MUST not have the TC bit set.
  • RCODES SHOULD ignored.
  • QDCOUNT!=1 SHOULD result in RCODE=1 FORMERR
• Presence of OPT RR in the ADDITIONAL Section indicates support of EDNS [RFC 2671 (Sections 4, 5.1) (Vixie, P., “Extension Mechanisms for DNS (EDNS0),” August 1999.)]. If the VERSION > 0 then the server will respond with an OPT with RCODE=BADVERSION and VERSION=0 (The server supports EDNS0) [RFC 2671 (Section 4.6) (Vixie, P., “Extension Mechanisms for DNS (EDNS0),” August 1999.)]. 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 (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.)] as modified by [RFC 2672 (4) (Crawford, M., “Non-Terminal DNS Name Redirection,” August 1999.)].

DNSSEC Considerations follow [RFC 4035 (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.)].

4.5.  Additional Data processing

{could be a normative MAY}

Additional data may be 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) (Crawford, M. and C. Huitema, “DNS Extensions to Support IPv6 Address Aggregation and Renumbering,” July 2000.)]

• A
• AAAA

For truncation see section [Truncation handling (Truncation handling)]

4.6.  Label compression in RDATA

[RFC 1035 (section 3.3. and 4.4.1) (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)] ("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.

• NS, SOA, CNAME, and PTR [RFC 1035 (3.3) (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)].
• Others defined in [RFC 1035 (3.3) (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)]are not compressed.
• MB, MG, MR, MINFO, MX also have compressed dnames. These RRs and their compression are described in [RFC 1035 (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)].
• AFSDB, RP, RT [RFC 1183, (Section 1,2 & 3.3.3) (Everhart, C., Mamakos, L., Ullmann, R., and P. Mockapetris, “New DNS RR Definitions,” October 1990.)].
• You MUST follow the rules in [RFC 3597 (Gustafsson, A., “Handling of Unknown DNS Resource Record (RR) Types,” September 2003.)].

4.7.  Truncation handling

Truncation handling is as specified in [RFC 2181 (9) (Elz, R. and R. Bush, “Clarifications to the DNS Specification,” July 1997.)].

{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) (Elz, R. and R. Bush, “Clarifications to the DNS Specification,” July 1997.)].

{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 ?) (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.)].

4.9.  NSID support

{new non-normative language. This could be normative, in which case it needs to be decided if its a MAY/SHOULD/SHOULD+/MUST}

An authoritative server may implement DNS Name Server Identifier (NSID) Option processing. This should be implemented in line with [RFC 5001 (Section 2.2) (Austein, R., “DNS Name Server Identifier (NSID) Option,” August 2007.)].

{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) (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.)]. This is a requirement only for caching servers.

5.  Stub Resolvers

TBD

6.  Recursive Resolvers

TBD

6.1.  NSID support

{new non-normative language. This could be normative, in which case it needs to be decided if its a MAY/SHOULD/SHOULD+/MUST}

A recursive server may implement DNS Name Server Identifier (NSID) Option processing. This should be implemented in line with [RFC 5001 (Section 2.1) (Austein, R., “DNS Name Server Identifier (NSID) Option,” August 2007.)].

NSID option processing is non-transitive.

7.  Middle-Boxes

TBD

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] (Wijngaards, W., “NSD Requirements and Specifications,” July 2006.).

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] (Jansen, J., “RRtypes,” August 2007.).

A list of DNS standards was developed in 2004 by András Salamon and was used as input to this document. [Salaman‑1] (Salaman, A., “DNS related RFCs,” June 2004.).

The editor thanks Joe Abley and Wouter Wijngaards for feedback and extensive comments on this document.

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 -01 draft

[Note: This section is not for publication.]

12.  Changes since the -00 draft

Spelling, improved language and other editorial changes (which did not alter the substance of normative language) from the namedroppers list were incorporated wholesale. (jabley)

incorrect normative reference to 1997 removed. (jabley).

text from 3597 on Transparancy for unknown RRtypes included (jabley).

Better normative language for 4.1.1 (TCP Connection Management) adopted (jabley).

Better normative language for 4.2.2 (TCP) adopted (jabley).

Better normative language for 4.3 (UDP DNS Message Processing) adopted (jabley).

References for OPT processing clarified (jabley).

A section addressing [RFC 5001] in respect of NSID was added to the Server section and the Recursive Resolver section. (jabley) incorporated.

Editorial from ml adopted for key approach section (wijngaards)

incorrect normative reference to 1997 corrected to 2671 (wijngaards)

added normative reference to 4343 (wijngaards)

added normative reference to RRset TTL (wijngaards)

editoral text in respect of NOTIFY/UPDATE (wijngaards)

normative editorial text in respect of FORMERR TC bit (wijngaards)

13.  References

13.1. Normative References

13.2. Informational, Formerly Normative References, now obsolete

13.3. Non-Normative, DNS related, but not relevant to Implementors References

13.4. Informative References Non RFC's

Appendix A.  Formerly Normative, now Obsolete References

RFC 882 (Mockapetris, P., “Domain names: Concepts and facilities,” November 1983.)

RFC 883 (Mockapetris, P., “Domain names: Implementation specification,” November 1983.)

RFC 973 (Mockapetris, P., “Domain system changes and observations,” January 1986.)

These RFCs were all obsoleted by RFC 1034 (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.) and RFC 1035 (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)

RFC 1348 (Manning, B., “DNS NSAP RRs,” July 1992.)

This RFC was obsoleted by RFC 1706 (Manning, B. and R. Colella, “DNS NSAP Resource Records,” October 1994.)

RFC 1386 (Cooper, A. and J. Postel, “The US Domain,” December 1992.)

This RFC was obsoleted by RFC 1480 (Cooper, A. and J. Postel, “The US Domain,” June 1993.)

RFC 1537 (Beertema, P., “Common DNS Data File Configuration Errors,” October 1993.)

This RFC was obsoleted by RFC 1912 (Barr, D., “Common DNS Operational and Configuration Errors,” February 1996.)

RFC 1637 (Manning, B. and R. Colella, “DNS NSAP Resource Records,” June 1994.)

This RFC was obsoleted by RFC 1706 (Manning, B. and R. Colella, “DNS NSAP Resource Records,” October 1994.)

RFC 1664 (Allocchio, C., Bonito, A., Cole, B., Giordano, S., and R. Hagens, “Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables,” August 1994.)

This RFC was obsoleted by RFC 2163 (Allocchio, C., “Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM),” January 1998.)

RFC 1712 (Farrell, C., Schulze, M., Pleitner, S., and D. Baldoni, “DNS Encoding of Geographical Location,” November 1994.)

This RFC was obsoleted by RFC 1876 (Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, “A Means for Expressing Location Information in the Domain Name System,” January 1996.)

RFC 1811 (Federal Networking Council, “U.S,” June 1995.)

This RFC was obsoleted by RFC 1816 (Federal Networking Council, “U.S,” August 1995.)

and subsequently RFC 2146 (Federal Networking Council, “U.S. Government Internet Domain Names,” May 1997.)

RFC 1816 (Federal Networking Council, “U.S,” August 1995.)

This RFC was obsoleted by RFC 2146 (Federal Networking Council, “U.S. Government Internet Domain Names,” May 1997.)

RFC 1886 (Thomson, S. and C. Huitema, “DNS Extensions to support IP version 6,” December 1995.)

This RFC was obsoleted by RFC 3596 (Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, “DNS Extensions to Support IP Version 6,” October 2003.)

RFC 2052 (Gulbrandsen, A. and P. Vixie, “A DNS RR for specifying the location of services (DNS SRV),” October 1996.)

This RFC was obsoleted by RFC 2782 (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.)

RFC 2065 (Eastlake, D. and C. Kaufman, “Domain Name System Security Extensions,” January 1997.)

This RFC was obsoleted by RFC 2535 (Eastlake, D., “Domain Name System Security Extensions,” March 1999.)

RFC 2137 (Eastlake, D., “Secure Domain Name System Dynamic Update,” April 1997.)

This RFC was obsoleted by RFC 3007 (Wellington, B., “Secure Domain Name System (DNS) Dynamic Update,” November 2000.)

RFC 2168 (Daniel, R. and M. Mealling, “Resolution of Uniform Resource Identifiers using the Domain Name System,” June 1997.)

This RFC was obsoleted by RFC 3401 (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS,” October 2002.) RFC 3402 (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm,” October 2002.) RFC 3403 (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database,” October 2002.) and RFC 3404 (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI),” October 2002.)

RFC 2240 (Vaughan, O., “A Legal Basis for Domain Name Allocation,” November 1997.)

This RFC was obsoleted by RFC 2352 (Vaughan, O., “A Convention For Using Legal Names as Domain Names,” May 1998.)

RFC 2537 (Eastlake, D., “RSA/MD5 KEYs and SIGs in the Domain Name System (DNS),” March 1999.)

This RFC was obsoleted by RFC 3110 (Eastlake, D., “RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS),” May 2001.)

RFC 2915 (Mealling, M. and R. Daniel, “The Naming Authority Pointer (NAPTR) DNS Resource Record,” September 2000.)

This RFC was obsoleted by RFC 3401 (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS,” October 2002.) RFC 3402 (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm,” October 2002.) RFC 3403 (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database,” October 2002.) and RFC 3404 (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI),” October 2002.)

RFC 3152 (Bush, R., “Delegation of IP6.ARPA,” August 2001.)

This RFC was obsoleted by RFC 3596 (Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, “DNS Extensions to Support IP Version 6,” October 2003.)

Author's Address

Full Copyright Statement

Copyright © 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.