[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                      G. Michaelson
Internet-Draft                                                     APNIC
Expires: July 22, 2008                                  January 19, 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 22, 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
   software, and to help guide DNS standards' advancement.







Michaelson                Expires July 22, 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 synchronisation . . . . . . . . . . . . . . . . .  7
     4.2.  Server and connection management . . . . . . . . . . . . .  7
       4.2.1.  UDP  . . . . . . . . . . . . . . . . . . . . . . . . .  7
       4.2.2.  TCP  . . . . . . . . . . . . . . . . . . . . . . . . .  8
       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 . . . . . . . . . . . . . . . . 10
     4.7.  Truncation handling  . . . . . . . . . . . . . . . . . . . 10
     4.8.  NSEC processing  . . . . . . . . . . . . . . . . . . . . . 10
     4.9.  NSID support . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Stub Resolvers . . . . . . . . . . . . . . . . . . . . . . . . 11
   6.  Recursive Resolvers  . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  NSID support . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Middle-Boxes . . . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   10. Concordance of references  . . . . . . . . . . . . . . . . . . 12
   11. Changes since the -01 draft  . . . . . . . . . . . . . . . . . 12
   12. Changes since the -00 draft  . . . . . . . . . . . . . . . . . 12
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     13.2. Informational, Formerly Normative References, now
           obsolete . . . . . . . . . . . . . . . . . . . . . . . . . 19
     13.3. Non-Normative, DNS related, but not relevant to
           Implementors  References . . . . . . . . . . . . . . . . . 21
     13.4. Informative References Non RFC's . . . . . . . . . . . . . 23
   Appendix A.  Formerly Normative, now Obsolete References . . . . . 24
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
   Intellectual Property and Copyright Statements . . . . . . . . . . 26









Michaelson                Expires July 22, 2008                 [Page 2]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


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



Michaelson                Expires July 22, 2008                 [Page 3]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


      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.

   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+



Michaelson                Expires July 22, 2008                 [Page 4]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


   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 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] and its
   -bis document.

   {new normative language} Unknown RRtypes MUST be preserved.  This is
   in line with [RFC 3597 (Section 3)]. 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.



Michaelson                Expires July 22, 2008                 [Page 5]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


   {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]. also see [RFC 1035 (2.3.3)]
   and [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}





Michaelson                Expires July 22, 2008                 [Page 6]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


      [RFC 2782]
      [RFC 2845]
      [RFC 3425]
      [RFC 3658]
      [RFC 4034]
      [RFC 4035]

   The following text has been extracted from [RFC 1035 (section 5.2)]
   and [RFC 2181 (section 5.2)] and re-written using normative language
   specified in RFC 2119

   [RFC 1035 (Section 5.2)] 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)]
   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 2181
       (Section 5.2)].
   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 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] [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 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)].

4.2.1.  UDP

   The server MUST listen to UDP on port 53 [RFC 2181 (4)].




Michaelson                Expires July 22, 2008                 [Page 7]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


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

4.2.3.  TCP Connection Management

   The following text has been extracted from [RFC 1035 (section 4.2.2)]
   and re-written using normative language specified in [RFC 2119].

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

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



Michaelson                Expires July 22, 2008                 [Page 8]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


      *  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 implemented, rather
         than through use of NOTIMPL
         +  OPCODE 4 (NOTIFY) SHOULD+ be supported [RFC 1995].
         +  OPCODE 5 (UPDATE) SHOULD+ be supported [RFC 2136 (sect 3)].
   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.
      *  The TC bit answer FORMERR MUST not have the TC bit set.
      *  RCODES SHOULD ignored.
      *  QDCOUNT!=1 SHOULD result in RCODE=1 FORMERR
   o  Presence of OPT RR in the ADDITIONAL Section indicates support of
      EDNS [RFC 2671 (Sections 4, 5.1)].  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)].
      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

   {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)]
   o  A
   o  AAAA

   For truncation see section [Truncation handling]





Michaelson                Expires July 22, 2008                 [Page 9]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


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

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

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




Michaelson                Expires July 22, 2008                [Page 10]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


   {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

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

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

   A list of RRtypes, included in the above document is maintained by
   Jelte Jansen, and was also used as input to this document.



Michaelson                Expires July 22, 2008                [Page 11]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


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

   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



Michaelson                Expires July 22, 2008                [Page 12]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


   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

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

   [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



Michaelson                Expires July 22, 2008                [Page 13]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


              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.

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

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



Michaelson                Expires July 22, 2008                [Page 14]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


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

   [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



Michaelson                Expires July 22, 2008                [Page 15]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


              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.

   [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



Michaelson                Expires July 22, 2008                [Page 16]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


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

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




Michaelson                Expires July 22, 2008                [Page 17]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


   [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.,
              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



Michaelson                Expires July 22, 2008                [Page 18]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


              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.

   [RFC4343]  Eastlake, D., "Domain Name System (DNS) Case Insensitivity
              Clarification", RFC 4343, January 2006.

   [RFC4408]  Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
              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.

   [RFC5001]  Austein, R., "DNS Name Server Identifier (NSID) Option",
              RFC 5001, August 2007.

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



Michaelson                Expires July 22, 2008                [Page 19]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


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

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




Michaelson                Expires July 22, 2008                [Page 20]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


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

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

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




Michaelson                Expires July 22, 2008                [Page 21]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


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

   [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



Michaelson                Expires July 22, 2008                [Page 22]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


              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)",
              RFC 3467, February 2003.

   [RFC3675]  Eastlake, D., ".sex Considered Dangerous", RFC 3675,
              February 2004.

13.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/>.




Michaelson                Expires July 22, 2008                [Page 23]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


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











Michaelson                Expires July 22, 2008                [Page 24]


Internet-Draft     The Modern DNS Implementation Guide      January 2008


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 22, 2008                [Page 25]


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 22, 2008                [Page 26]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/