TOC 
Network Working GroupG. Michaelson
Internet-DraftAPNIC
Expires: July 23, 2008January 20, 2008


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



 TOC 

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.


 TOC 

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.


 TOC 

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).


 TOC 

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.


 TOC 

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.)].


 TOC 

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: }


 TOC 

4.1.  Zones


 TOC 

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.

 TOC 

4.1.2.  Zone synchronisation


 TOC 

4.1.2.1.  Timeout management

{referencing RFC details needed} Timeouts on the SOAs for secondary zones according to [RFC...].


 TOC 

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.)].


 TOC 

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.


 TOC 

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.)].


 TOC 

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.


 TOC 

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.


 TOC 

4.4.  Further Query processing


 TOC 

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.)].


 TOC 

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)]


 TOC 

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.


 TOC 

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.


 TOC 

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.)].


 TOC 

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.


 TOC 

5.  Stub Resolvers

TBD


 TOC 

6.  Recursive Resolvers

TBD


 TOC 

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.


 TOC 

7.  Middle-Boxes

TBD


 TOC 

8.  IANA Considerations

None at this time. The goal of the document is to have no IANA actions.


 TOC 

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.


 TOC 

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.


 TOC 

11.  Changes since the -01 draft

[Note: This section is not for publication.]


 TOC 

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)


 TOC 

13.  References


 TOC 

13.1. Normative References

[I-D.ietf-dnsext-rfc2671bis-edns0] Graff, M. and P. Vixie, “Extension Mechanisms for DNS (EDNS0),” draft-ietf-dnsext-rfc2671bis-edns0-03 (work in progress), March 2010 (TXT).
[RFC1033] Lottor, M., “Domain administrators operations guide,” RFC 1033, November 1987 (TXT).
[RFC1034] Mockapetris, P., “Domain names - concepts and facilities,” STD 13, RFC 1034, November 1987 (TXT).
[RFC1035] Mockapetris, P., “Domain names - implementation and specification,” STD 13, RFC 1035, November 1987 (TXT).
[RFC1122] Braden, R., “Requirements for Internet Hosts - Communication Layers,” STD 3, RFC 1122, October 1989 (TXT).
[RFC1123] Braden, R., “Requirements for Internet Hosts - Application and Support,” STD 3, RFC 1123, October 1989 (TXT).
[RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. Mockapetris, “New DNS RR Definitions,” RFC 1183, October 1990 (TXT).
[RFC1464] Rosenbaum, R., “Using the Domain Name System To Store Arbitrary String Attributes,” RFC 1464, May 1993 (TXT).
[RFC1535] Gavron, E., “A Security Problem and Proposed Correction With Widely Deployed DNS Software,” RFC 1535, October 1993 (TXT).
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller, “Common DNS Implementation Errors and Suggested Fixes,” RFC 1536, October 1993 (TXT).
[RFC1706] Manning, B. and R. Colella, “DNS NSAP Resource Records,” RFC 1706, October 1994 (TXT).
[RFC1713] Romao, A., “Tools for DNS debugging,” RFC 1713, November 1994 (TXT).
[RFC1794] Brisco, T., “DNS Support for Load Balancing,” RFC 1794, April 1995 (TXT).
[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 (TXT).
[RFC1912] Barr, D., “Common DNS Operational and Configuration Errors,” RFC 1912, February 1996 (TXT).
[RFC1982] Elz, R. and R. Bush, “Serial Number Arithmetic,” RFC 1982, August 1996 (TXT).
[RFC1995] Ohta, M., “Incremental Zone Transfer in DNS,” RFC 1995, August 1996 (TXT).
[RFC1996] Vixie, P., “A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY),” RFC 1996, August 1996 (TXT).
[RFC2010] Manning, B. and P. Vixie, “Operational Criteria for Root Name Servers,” RFC 2010, October 1996 (TXT, HTML, XML).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, “Dynamic Updates in the Domain Name System (DNS UPDATE),” RFC 2136, April 1997 (TXT, HTML, XML).
[RFC2163] Allocchio, C., “Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM),” RFC 2163, January 1998 (TXT).
[RFC2181] Elz, R. and R. Bush, “Clarifications to the DNS Specification,” RFC 2181, July 1997 (TXT, HTML, XML).
[RFC2219] Hamilton, M. and R. Wright, “Use of DNS Aliases for Network Services,” BCP 17, RFC 2219, October 1997 (TXT).
[RFC2230] Atkinson, R., “Key Exchange Delegation Record for the DNS,” RFC 2230, November 1997 (TXT, HTML, XML).
[RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri, “Using Domains in LDAP/X.500 Distinguished Names,” RFC 2247, January 1998 (TXT, HTML, XML).
[RFC2276] Sollins, K., “Architectural Principles of Uniform Resource Name Resolution,” RFC 2276, January 1998 (TXT, HTML, XML).
[RFC2308] Andrews, M., “Negative Caching of DNS Queries (DNS NCACHE),” RFC 2308, March 1998 (TXT, HTML, XML).
[RFC2535] Eastlake, D., “Domain Name System Security Extensions,” RFC 2535, March 1999 (TXT).
[RFC2536] Eastlake, D., “DSA KEYs and SIGs in the Domain Name System (DNS),” RFC 2536, March 1999 (TXT).
[RFC2538] Eastlake, D. and O. Gudmundsson, “Storing Certificates in the Domain Name System (DNS),” RFC 2538, March 1999 (TXT).
[RFC2539] Eastlake, D., “Storage of Diffie-Hellman Keys in the Domain Name System (DNS),” RFC 2539, March 1999 (TXT).
[RFC2540] Eastlake, D., “Detached Domain Name System (DNS) Information,” RFC 2540, March 1999 (TXT).
[RFC2541] Eastlake, D., “DNS Security Operational Considerations,” RFC 2541, March 1999 (TXT).
[RFC2671] Vixie, P., “Extension Mechanisms for DNS (EDNS0),” RFC 2671, August 1999 (TXT).
[RFC2672] Crawford, M., “Non-Terminal DNS Name Redirection,” RFC 2672, August 1999 (TXT).
[RFC2673] Crawford, M., “Binary Labels in the Domain Name System,” RFC 2673, August 1999 (TXT).
[RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. Heffernan, “DNS extensions to Network Address Translators (DNS_ALG),” RFC 2694, September 1999 (TXT).
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” RFC 2782, February 2000 (TXT).
[RFC2825] IAB and L. Daigle, “A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols,” RFC 2825, May 2000 (TXT).
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, “Secret Key Transaction Authentication for DNS (TSIG),” RFC 2845, May 2000 (TXT).
[RFC2874] Crawford, M. and C. Huitema, “DNS Extensions to Support IPv6 Address Aggregation and Renumbering,” RFC 2874, July 2000 (TXT).
[RFC2916] Faltstrom, P., “E.164 number and DNS,” RFC 2916, September 2000 (TXT).
[RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning, “Domain Name System (DNS) IANA Considerations,” RFC 2929, September 2000 (TXT).
[RFC2930] Eastlake, D., “Secret Key Establishment for DNS (TKEY RR),” RFC 2930, September 2000 (TXT).
[RFC2931] Eastlake, D., “DNS Request and Transaction Signatures ( SIG(0)s),” RFC 2931, September 2000 (TXT).
[RFC2937] Smith, C., “The Name Service Search Option for DHCP,” RFC 2937, September 2000 (TXT).
[RFC2972] Popp, N., Mealling, M., Masinter, L., and K. Sollins, “Context and Goals for Common Name Resolution,” RFC 2972, October 2000 (TXT).
[RFC3007] Wellington, B., “Secure Domain Name System (DNS) Dynamic Update,” RFC 3007, November 2000 (TXT).
[RFC3008] Wellington, B., “Domain Name System Security (DNSSEC) Signing Authority,” RFC 3008, November 2000 (TXT).
[RFC3090] Lewis, E., “DNS Security Extension Clarification on Zone Status,” RFC 3090, March 2001 (TXT).
[RFC3110] Eastlake, D., “RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS),” RFC 3110, May 2001 (TXT).
[RFC3123] Koch, P., “A DNS RR Type for Lists of Address Prefixes (APL RR),” RFC 3123, June 2001 (TXT).
[RFC3197] Austein, R., “Applicability Statement for DNS MIB Extensions,” RFC 3197, November 2001 (TXT).
[RFC3225] Conrad, D., “Indicating Resolver Support of DNSSEC,” RFC 3225, December 2001 (TXT).
[RFC3226] Gudmundsson, O., “DNSSEC and IPv6 A6 aware server/resolver message size requirements,” RFC 3226, December 2001 (TXT).
[RFC3258] Hardie, T., “Distributing Authoritative Name Servers via Shared Unicast Addresses,” RFC 3258, April 2002 (TXT).
[RFC3263] Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” RFC 3263, June 2002 (TXT).
[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 (TXT).
[RFC3364] Austein, R., “Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6),” RFC 3364, August 2002 (TXT).
[RFC3401] Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS,” RFC 3401, October 2002 (TXT).
[RFC3402] Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm,” RFC 3402, October 2002 (TXT).
[RFC3403] Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database,” RFC 3403, October 2002 (TXT).
[RFC3404] Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI),” RFC 3404, October 2002 (TXT).
[RFC3405] Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures,” BCP 65, RFC 3405, October 2002 (TXT).
[RFC3425] Lawrence, D., “Obsoleting IQUERY,” RFC 3425, November 2002 (TXT).
[RFC3445] Massey, D. and S. Rose, “Limiting the Scope of the KEY Resource Record (RR),” RFC 3445, December 2002 (TXT).
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” RFC 3490, March 2003 (TXT).
[RFC3491] Hoffman, P. and M. Blanchet, “Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN),” RFC 3491, March 2003 (TXT).
[RFC3492] Costello, A., “Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA),” RFC 3492, March 2003 (TXT).
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, “DNS Extensions to Support IP Version 6,” RFC 3596, October 2003 (TXT).
[RFC3597] Gustafsson, A., “Handling of Unknown DNS Resource Record (RR) Types,” RFC 3597, September 2003 (TXT).
[RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., and R. Hall, “Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG),” RFC 3645, October 2003 (TXT).
[RFC3646] Droms, R., “DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” RFC 3646, December 2003 (TXT).
[RFC3655] Wellington, B. and O. Gudmundsson, “Redefinition of DNS Authenticated Data (AD) bit,” RFC 3655, November 2003 (TXT).
[RFC3658] Gudmundsson, O., “Delegation Signer (DS) Resource Record (RR),” RFC 3658, December 2003 (TXT).
[RFC3696] Klensin, J., “Application Techniques for Checking and Transformation of Names,” RFC 3696, February 2004 (TXT).
[RFC3755] Weiler, S., “Legacy Resolver Compatibility for Delegation Signer (DS),” RFC 3755, May 2004 (TXT).
[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 (TXT).
[RFC4025] Richardson, M., “A Method for Storing IPsec Keying Material in DNS,” RFC 4025, March 2005 (TXT).
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” RFC 4033, March 2005 (TXT).
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” RFC 4034, March 2005 (TXT).
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” RFC 4035, March 2005 (TXT).
[RFC4255] Schlyter, J. and W. Griffin, “Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints,” RFC 4255, January 2006 (TXT).
[RFC4307] Schiller, J., “Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2),” RFC 4307, December 2005 (TXT).
[RFC4343] Eastlake, D., “Domain Name System (DNS) Case Insensitivity Clarification,” RFC 4343, January 2006 (TXT).
[RFC4408] Wong, M. and W. Schlitt, “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1,” RFC 4408, April 2006 (TXT).
[RFC4431] Andrews, M. and S. Weiler, “The DNSSEC Lookaside Validation (DLV) DNS Resource Record,” RFC 4431, February 2006 (TXT).
[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 (TXT).
[RFC5001] Austein, R., “DNS Name Server Identifier (NSID) Option,” RFC 5001, August 2007 (TXT).

 TOC 

13.2. Informational, Formerly Normative References, now obsolete

[RFC0882] Mockapetris, P., “Domain names: Concepts and facilities,” RFC 882, November 1983 (TXT).
[RFC0883] Mockapetris, P., “Domain names: Implementation specification,” RFC 883, November 1983 (TXT).
[RFC0973] Mockapetris, P., “Domain system changes and observations,” RFC 973, January 1986 (TXT).
[RFC1348] Manning, B., “DNS NSAP RRs,” RFC 1348, July 1992 (TXT).
[RFC1386] Cooper, A. and J. Postel, “The US Domain,” RFC 1386, December 1992 (TXT).
[RFC1537] Beertema, P., “Common DNS Data File Configuration Errors,” RFC 1537, October 1993 (TXT).
[RFC1637] Manning, B. and R. Colella, “DNS NSAP Resource Records,” RFC 1637, June 1994 (TXT).
[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 (TXT).
[RFC1712] Farrell, C., Schulze, M., Pleitner, S., and D. Baldoni, “DNS Encoding of Geographical Location,” RFC 1712, November 1994 (TXT).
[RFC1811] Federal Networking Council, “U.S,” RFC 1811, June 1995 (TXT).
[RFC1816] Federal Networking Council, “U.S,” RFC 1816, August 1995 (TXT).
[RFC1886] Thomson, S. and C. Huitema, “DNS Extensions to support IP version 6,” RFC 1886, December 1995 (TXT).
[RFC2052] Gulbrandsen, A. and P. Vixie, “A DNS RR for specifying the location of services (DNS SRV),” RFC 2052, October 1996 (TXT).
[RFC2065] Eastlake, D. and C. Kaufman, “Domain Name System Security Extensions,” RFC 2065, January 1997 (TXT).
[RFC2137] Eastlake, D., “Secure Domain Name System Dynamic Update,” RFC 2137, April 1997 (TXT, HTML, XML).
[RFC2168] Daniel, R. and M. Mealling, “Resolution of Uniform Resource Identifiers using the Domain Name System,” RFC 2168, June 1997 (TXT).
[RFC2240] Vaughan, O., “A Legal Basis for Domain Name Allocation,” RFC 2240, November 1997 (TXT, HTML, XML).
[RFC2537] Eastlake, D., “RSA/MD5 KEYs and SIGs in the Domain Name System (DNS),” RFC 2537, March 1999 (TXT).
[RFC2915] Mealling, M. and R. Daniel, “The Naming Authority Pointer (NAPTR) DNS Resource Record,” RFC 2915, September 2000 (TXT).
[RFC3152] Bush, R., “Delegation of IP6.ARPA,” BCP 49, RFC 3152, August 2001 (TXT).

 TOC 

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

[RFC0805] Postel, J., “Computer mail meeting notes,” RFC 805, February 1982 (TXT).
[RFC0811] Harrenstien, K., White, V., and E. Feinler, “Hostnames Server,” RFC 811, March 1982 (TXT).
[RFC0819] Su, Z. and J. Postel, “Domain naming convention for Internet user applications,” RFC 819, August 1982 (TXT).
[RFC0881] Postel, J., “Domain names plan and schedule,” RFC 881, November 1983 (TXT).
[RFC0897] Postel, J., “Domain name system implementation schedule,” RFC 897, February 1984 (TXT).
[RFC0920] Postel, J. and J. Reynolds, “Domain requirements,” RFC 920, October 1984 (TXT).
[RFC0921] Postel, J., “Domain name system implementation schedule - revised,” RFC 921, October 1984 (TXT).
[RFC0974] Partridge, C., “Mail routing and the domain system,” RFC 974, January 1986 (TXT).
[RFC1032] Stahl, M., “Domain administrators guide,” RFC 1032, November 1987 (TXT).
[RFC1101] Mockapetris, P., “DNS encoding of network names and other types,” RFC 1101, April 1989 (TXT).
[RFC1178] Libes, D., “Choosing a name for your computer,” RFC 1178, August 1990 (TXT).
[RFC1480] Cooper, A. and J. Postel, “The US Domain,” RFC 1480, June 1993 (TXT).
[RFC1591] Postel, J., “Domain Name System Structure and Delegation,” RFC 1591, March 1994 (TXT).
[RFC1611] Austein, R. and J. Saperia, “DNS Server MIB Extensions,” RFC 1611, May 1994 (TXT).
[RFC1612] Austein, R. and J. Saperia, “DNS Resolver MIB Extensions,” RFC 1612, May 1994 (TXT).
[RFC1956] Engebretson, D. and R. Plzak, “Registration in the MIL Domain,” RFC 1956, June 1996 (TXT).
[RFC2053] Der-Danieliantz, E., “The AM (Armenia) Domain,” RFC 2053, October 1996 (TXT).
[RFC2100] Ashworth, J., “The Naming of Hosts,” RFC 2100, April 1 1997 (TXT).
[RFC2142] Crocker, D., “MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS,” RFC 2142, May 1997 (TXT, HTML, XML).
[RFC2146] Federal Networking Council, “U.S. Government Internet Domain Names,” RFC 2146, May 1997 (TXT, HTML, XML).
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, “Selection and Operation of Secondary DNS Servers,” BCP 16, RFC 2182, July 1997 (TXT, HTML, XML).
[RFC2307] Howard, L., “An Approach for Using LDAP as a Network Information Service,” RFC 2307, March 1998 (TXT, HTML, XML).
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, “Classless IN-ADDR.ARPA delegation,” BCP 20, RFC 2317, March 1998 (TXT, HTML, XML).
[RFC2345] Klensin, J., Jr, T., and G. Oglesby, “Domain Names and Company Name Retrieval,” RFC 2345, May 1998 (TXT, HTML, XML).
[RFC2352] Vaughan, O., “A Convention For Using Legal Names as Domain Names,” RFC 2352, May 1998 (TXT, HTML, XML).
[RFC2377] Grimstad, A., Huber, R., Sataluri, S., and M. Wahl, “Naming Plan for Internet Directory-Enabled Applications,” RFC 2377, September 1998 (TXT, HTML, XML).
[RFC2517] Moats, R. and R. Huber, “Building Directories from DNS: Experiences from WWWSeeker,” RFC 2517, February 1999 (TXT).
[RFC2606] Eastlake, D. and A. Panitz, “Reserved Top Level DNS Names,” BCP 32, RFC 2606, June 1999 (TXT).
[RFC2826] Internet Architecture Board, “IAB Technical Comment on the Unique DNS Root,” RFC 2826, May 2000 (TXT).
[RFC2832] Hollenbeck, S. and M. Srivastava, “NSI Registry Registrar Protocol (RRP) Version 1.1.0,” RFC 2832, May 2000 (TXT).
[RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, “Root Name Server Operational Requirements,” BCP 40, RFC 2870, June 2000 (TXT).
[RFC3071] Klensin, J., “Reflections on the DNS, RFC 1591, and Categories of Domains,” RFC 3071, February 2001 (TXT).
[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 (TXT).
[RFC3254] Alvestrand, H., “Definitions for talking about directories,” RFC 3254, April 2002 (TXT).
[RFC3352] Zeilenga, K., “Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status,” RFC 3352, March 2003 (TXT).
[RFC3367] Popp, N., Mealling, M., and M. Moseley, “Common Name Resolution Protocol (CNRP),” RFC 3367, August 2002 (TXT).
[RFC3368] Mealling, M., “The 'go' URI Scheme for the Common Name Resolution Protocol,” RFC 3368, August 2002 (TXT).
[RFC3467] Klensin, J., “Role of the Domain Name System (DNS),” RFC 3467, February 2003 (TXT).
[RFC3675] Eastlake, D., “.sex Considered Dangerous,” RFC 3675, February 2004 (TXT).

 TOC 

13.4. Informative References Non RFC's

[Jelte-1] Jansen, J., “RRtypes,” August 2007.
[NLNet-1] Wijngaards, W., “NSD Requirements and Specifications,” July 2006.
[Salaman-1] Salaman, A., “DNS related RFCs,” June 2004.

 TOC 

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.)


 TOC 

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

 TOC 

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.