doc: Add RFC documents

1 files changed, 842 insertions, 0 deletions

diff --git a/doc/rfc/rfc2181.txt b/doc/rfc/rfc2181.txt
new file mode 100644
index 0000000..7899e1c
--- /dev/null
+++ b/doc/rfc/rfc2181.txt
@@ -0,0 +1,842 @@
+
+
+
+
+
+
+Network Working Group                                             R. Elz
+Request for Comments: 2181                       University of Melbourne
+Updates: 1034, 1035, 1123                                        R. Bush
+Category: Standards Track                                    RGnet, Inc.
+                                                               July 1997
+
+
+                Clarifications to the DNS Specification
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+1. Abstract
+
+   This document considers some areas that have been identified as
+   problems with the specification of the Domain Name System, and
+   proposes remedies for the defects identified.  Eight separate issues
+   are considered:
+
+     + IP packet header address usage from multi-homed servers,
+     + TTLs in sets of records with the same name, class, and type,
+     + correct handling of zone cuts,
+     + three minor issues concerning SOA records and their use,
+     + the precise definition of the Time to Live (TTL)
+     + Use of the TC (truncated) header bit
+     + the issue of what is an authoritative, or canonical, name,
+     + and the issue of what makes a valid DNS label.
+
+   The first six of these are areas where the correct behaviour has been
+   somewhat unclear, we seek to rectify that.  The other two are already
+   adequately specified, however the specifications seem to be sometimes
+   ignored.  We seek to reinforce the existing specifications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 1]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+
+
+Contents
+
+    1  Abstract  ...................................................   1
+    2  Introduction  ...............................................   2
+    3  Terminology  ................................................   3
+    4  Server Reply Source Address Selection  ......................   3
+    5  Resource Record Sets  .......................................   4
+    6  Zone Cuts  ..................................................   8
+    7  SOA RRs  ....................................................  10
+    8  Time to Live (TTL)  .........................................  10
+    9  The TC (truncated) header bit  ..............................  11
+   10  Naming issues  ..............................................  11
+   11  Name syntax  ................................................  13
+   12  Security Considerations  ....................................  14
+   13  References  .................................................  14
+   14  Acknowledgements  ...........................................  15
+   15  Authors' Addresses  .........................................  15
+
+
+
+
+2. Introduction
+
+   Several problem areas in the Domain Name System specification
+   [RFC1034, RFC1035] have been noted through the years [RFC1123].  This
+   document addresses several additional problem areas.  The issues here
+   are independent.  Those issues are the question of which source
+   address a multi-homed DNS server should use when replying to a query,
+   the issue of differing TTLs for DNS records with the same label,
+   class and type, and the issue of canonical names, what they are, how
+   CNAME records relate, what names are legal in what parts of the DNS,
+   and what is the valid syntax of a DNS name.
+
+   Clarifications to the DNS specification to avoid these problems are
+   made in this memo.  A minor ambiguity in RFC1034 concerned with SOA
+   records is also corrected, as is one in the definition of the TTL
+   (Time To Live) and some possible confusion in use of the TC bit.
+
+
+
+
+
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 2]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+3. Terminology
+
+   This memo does not use the oft used expressions MUST, SHOULD, MAY, or
+   their negative forms.  In some sections it may seem that a
+   specification is worded mildly, and hence some may infer that the
+   specification is optional.  That is not correct.  Anywhere that this
+   memo suggests that some action should be carried out, or must be
+   carried out, or that some behaviour is acceptable, or not, that is to
+   be considered as a fundamental aspect of this specification,
+   regardless of the specific words used.  If some behaviour or action
+   is truly optional, that will be clearly specified by the text.
+
+4. Server Reply Source Address Selection
+
+   Most, if not all, DNS clients, expect the address from which a reply
+   is received to be the same address as that to which the query
+   eliciting the reply was sent.  This is true for servers acting as
+   clients for the purposes of recursive query resolution, as well as
+   simple resolver clients.  The address, along with the identifier (ID)
+   in the reply is used for disambiguating replies, and filtering
+   spurious responses.  This may, or may not, have been intended when
+   the DNS was designed, but is now a fact of life.
+
+   Some multi-homed hosts running DNS servers generate a reply using a
+   source address that is not the same as the destination address from
+   the client's request packet.  Such replies will be discarded by the
+   client because the source address of the reply does not match that of
+   a host to which the client sent the original request.  That is, it
+   appears to be an unsolicited response.
+
+4.1. UDP Source Address Selection
+
+   To avoid these problems, servers when responding to queries using UDP
+   must cause the reply to be sent with the source address field in the
+   IP header set to the address that was in the destination address
+   field of the IP header of the packet containing the query causing the
+   response.  If this would cause the response to be sent from an IP
+   address that is not permitted for this purpose, then the response may
+   be sent from any legal IP address allocated to the server.  That
+   address should be chosen to maximise the possibility that the client
+   will be able to use it for further queries.  Servers configured in
+   such a way that not all their addresses are equally reachable from
+   all potential clients need take particular care when responding to
+   queries sent to anycast, multicast, or similar, addresses.
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 3]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+4.2. Port Number Selection
+
+   Replies to all queries must be directed to the port from which they
+   were sent.  When queries are received via TCP this is an inherent
+   part of the transport protocol.  For queries received by UDP the
+   server must take note of the source port and use that as the
+   destination port in the response.  Replies should always be sent from
+   the port to which they were directed.  Except in extraordinary
+   circumstances, this will be the well known port assigned for DNS
+   queries [RFC1700].
+
+5. Resource Record Sets
+
+   Each DNS Resource Record (RR) has a label, class, type, and data.  It
+   is meaningless for two records to ever have label, class, type and
+   data all equal - servers should suppress such duplicates if
+   encountered.  It is however possible for most record types to exist
+   with the same label, class and type, but with different data.  Such a
+   group of records is hereby defined to be a Resource Record Set
+   (RRSet).
+
+5.1. Sending RRs from an RRSet
+
+   A query for a specific (or non-specific) label, class, and type, will
+   always return all records in the associated RRSet - whether that be
+   one or more RRs.  The response must be marked as "truncated" if the
+   entire RRSet will not fit in the response.
+
+5.2. TTLs of RRs in an RRSet
+
+   Resource Records also have a time to live (TTL).  It is possible for
+   the RRs in an RRSet to have different TTLs.  No uses for this have
+   been found that cannot be better accomplished in other ways.  This
+   can, however, cause partial replies (not marked "truncated") from a
+   caching server, where the TTLs for some but not all the RRs in the
+   RRSet have expired.
+
+   Consequently the use of differing TTLs in an RRSet is hereby
+   deprecated, the TTLs of all RRs in an RRSet must be the same.
+
+   Should a client receive a response containing RRs from an RRSet with
+   differing TTLs, it should treat this as an error.  If the RRSet
+   concerned is from a non-authoritative source for this data, the
+   client should simply ignore the RRSet, and if the values were
+   required, seek to acquire them from an authoritative source.  Clients
+   that are configured to send all queries to one, or more, particular
+   servers should treat those servers as authoritative for this purpose.
+   Should an authoritative source send such a malformed RRSet, the
+
+
+
+Elz & Bush                  Standards Track                     [Page 4]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   client should treat the RRs for all purposes as if all TTLs in the
+   RRSet had been set to the value of the lowest TTL in the RRSet.  In
+   no case may a server send an RRSet with TTLs not all equal.
+
+5.3. DNSSEC Special Cases
+
+   Two of the record types added by DNS Security (DNSSEC) [RFC2065]
+   require special attention when considering the formation of Resource
+   Record Sets.  Those are the SIG and NXT records.  It should be noted
+   that DNS Security is still very new, and there is, as yet, little
+   experience with it.  Readers should be prepared for the information
+   related to DNSSEC contained in this document to become outdated as
+   the DNS Security specification matures.
+
+5.3.1. SIG records and RRSets
+
+   A SIG record provides signature (validation) data for another RRSet
+   in the DNS.  Where a zone has been signed, every RRSet in the zone
+   will have had a SIG record associated with it.  The data type of the
+   RRSet is included in the data of the SIG RR, to indicate with which
+   particular RRSet this SIG record is associated.  Were the rules above
+   applied, whenever a SIG record was included with a response to
+   validate that response, the SIG records for all other RRSets
+   associated with the appropriate node would also need to be included.
+   In some cases, this could be a very large number of records, not
+   helped by their being rather large RRs.
+
+   Thus, it is specifically permitted for the authority section to
+   contain only those SIG RRs with the "type covered" field equal to the
+   type field of an answer being returned.  However, where SIG records
+   are being returned in the answer section, in response to a query for
+   SIG records, or a query for all records associated with a name
+   (type=ANY) the entire SIG RRSet must be included, as for any other RR
+   type.
+
+   Servers that receive responses containing SIG records in the
+   authority section, or (probably incorrectly) as additional data, must
+   understand that the entire RRSet has almost certainly not been
+   included.  Thus, they must not cache that SIG record in a way that
+   would permit it to be returned should a query for SIG records be
+   received at that server.  RFC2065 actually requires that SIG queries
+   be directed only to authoritative servers to avoid the problems that
+   could be caused here, and while servers exist that do not understand
+   the special properties of SIG records, this will remain necessary.
+   However, careful design of SIG record processing in new
+   implementations should permit this restriction to be relaxed in the
+   future, so resolvers do not need to treat SIG record queries
+   specially.
+
+
+
+Elz & Bush                  Standards Track                     [Page 5]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   It has been occasionally stated that a received request for a SIG
+   record should be forwarded to an authoritative server, rather than
+   being answered from data in the cache.  This is not necessary - a
+   server that has the knowledge of SIG as a special case for processing
+   this way would be better to correctly cache SIG records, taking into
+   account their characteristics.  Then the server can determine when it
+   is safe to reply from the cache, and when the answer is not available
+   and the query must be forwarded.
+
+5.3.2. NXT RRs
+
+   Next Resource Records (NXT) are even more peculiar.  There will only
+   ever be one NXT record in a zone for a particular label, so
+   superficially, the RRSet problem is trivial.  However, at a zone cut,
+   both the parent zone, and the child zone (superzone and subzone in
+   RFC2065 terminology) will have NXT records for the same name.  Those
+   two NXT records do not form an RRSet, even where both zones are
+   housed at the same server.  NXT RRSets always contain just a single
+   RR.  Where both NXT records are visible, two RRSets exist.  However,
+   servers are not required to treat this as a special case when
+   receiving NXT records in a response.  They may elect to notice the
+   existence of two different NXT RRSets, and treat that as they would
+   two different RRSets of any other type.  That is, cache one, and
+   ignore the other.  Security aware servers will need to correctly
+   process the NXT record in the received response though.
+
+5.4. Receiving RRSets
+
+   Servers must never merge RRs from a response with RRs in their cache
+   to form an RRSet.  If a response contains data that would form an
+   RRSet with data in a server's cache the server must either ignore the
+   RRs in the response, or discard the entire RRSet currently in the
+   cache, as appropriate.  Consequently the issue of TTLs varying
+   between the cache and a response does not cause concern, one will be
+   ignored.  That is, one of the data sets is always incorrect if the
+   data from an answer differs from the data in the cache.  The
+   challenge for the server is to determine which of the data sets is
+   correct, if one is, and retain that, while ignoring the other.  Note
+   that if a server receives an answer containing an RRSet that is
+   identical to that in its cache, with the possible exception of the
+   TTL value, it may, optionally, update the TTL in its cache with the
+   TTL of the received answer.  It should do this if the received answer
+   would be considered more authoritative (as discussed in the next
+   section) than the previously cached answer.
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 6]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+5.4.1. Ranking data
+
+   When considering whether to accept an RRSet in a reply, or retain an
+   RRSet already in its cache instead, a server should consider the
+   relative likely trustworthiness of the various data.  An
+   authoritative answer from a reply should replace cached data that had
+   been obtained from additional information in an earlier reply.
+   However additional information from a reply will be ignored if the
+   cache contains data from an authoritative answer or a zone file.
+
+   The accuracy of data available is assumed from its source.
+   Trustworthiness shall be, in order from most to least:
+
+     + Data from a primary zone file, other than glue data,
+     + Data from a zone transfer, other than glue,
+     + The authoritative data included in the answer section of an
+       authoritative reply.
+     + Data from the authority section of an authoritative answer,
+     + Glue from a primary zone, or glue from a zone transfer,
+     + Data from the answer section of a non-authoritative answer, and
+       non-authoritative data from the answer section of authoritative
+       answers,
+     + Additional information from an authoritative answer,
+       Data from the authority section of a non-authoritative answer,
+       Additional information from non-authoritative answers.
+
+   Note that the answer section of an authoritative answer normally
+   contains only authoritative data.  However when the name sought is an
+   alias (see section 10.1.1) only the record describing that alias is
+   necessarily authoritative.  Clients should assume that other records
+   may have come from the server's cache.  Where authoritative answers
+   are required, the client should query again, using the canonical name
+   associated with the alias.
+
+   Unauthenticated RRs received and cached from the least trustworthy of
+   those groupings, that is data from the additional data section, and
+   data from the authority section of a non-authoritative answer, should
+   not be cached in such a way that they would ever be returned as
+   answers to a received query.  They may be returned as additional
+   information where appropriate.  Ignoring this would allow the
+   trustworthiness of relatively untrustworthy data to be increased
+   without cause or excuse.
+
+   When DNS security [RFC2065] is in use, and an authenticated reply has
+   been received and verified, the data thus authenticated shall be
+   considered more trustworthy than unauthenticated data of the same
+   type.  Note that throughout this document, "authoritative" means a
+   reply with the AA bit set.  DNSSEC uses trusted chains of SIG and KEY
+
+
+
+Elz & Bush                  Standards Track                     [Page 7]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   records to determine the authenticity of data, the AA bit is almost
+   irrelevant.  However DNSSEC aware servers must still correctly set
+   the AA bit in responses to enable correct operation with servers that
+   are not security aware (almost all currently).
+
+   Note that, glue excluded, it is impossible for data from two
+   correctly configured primary zone files, two correctly configured
+   secondary zones (data from zone transfers) or data from correctly
+   configured primary and secondary zones to ever conflict.  Where glue
+   for the same name exists in multiple zones, and differs in value, the
+   nameserver should select data from a primary zone file in preference
+   to secondary, but otherwise may choose any single set of such data.
+   Choosing that which appears to come from a source nearer the
+   authoritative data source may make sense where that can be
+   determined.  Choosing primary data over secondary allows the source
+   of incorrect glue data to be discovered more readily, when a problem
+   with such data exists.  Where a server can detect from two zone files
+   that one or more are incorrectly configured, so as to create
+   conflicts, it should refuse to load the zones determined to be
+   erroneous, and issue suitable diagnostics.
+
+   "Glue" above includes any record in a zone file that is not properly
+   part of that zone, including nameserver records of delegated sub-
+   zones (NS records), address records that accompany those NS records
+   (A, AAAA, etc), and any other stray data that might appear.
+
+5.5. Sending RRSets (reprise)
+
+   A Resource Record Set should only be included once in any DNS reply.
+   It may occur in any of the Answer, Authority, or Additional
+   Information sections, as required.  However it should not be repeated
+   in the same, or any other, section, except where explicitly required
+   by a specification.  For example, an AXFR response requires the SOA
+   record (always an RRSet containing a single RR) be both the first and
+   last record of the reply.  Where duplicates are required this way,
+   the TTL transmitted in each case must be the same.
+
+6. Zone Cuts
+
+   The DNS tree is divided into "zones", which are collections of
+   domains that are treated as a unit for certain management purposes.
+   Zones are delimited by "zone cuts".  Each zone cut separates a
+   "child" zone (below the cut) from a "parent" zone (above the cut).
+   The domain name that appears at the top of a zone (just below the cut
+   that separates the zone from its parent) is called the zone's
+   "origin".  The name of the zone is the same as the name of the domain
+   at the zone's origin.  Each zone comprises that subset of the DNS
+   tree that is at or below the zone's origin, and that is above the
+
+
+
+Elz & Bush                  Standards Track                     [Page 8]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   cuts that separate the zone from its children (if any).  The
+   existence of a zone cut is indicated in the parent zone by the
+   existence of NS records specifying the origin of the child zone.  A
+   child zone does not contain any explicit reference to its parent.
+
+6.1. Zone authority
+
+   The authoritative servers for a zone are enumerated in the NS records
+   for the origin of the zone, which, along with a Start of Authority
+   (SOA) record are the mandatory records in every zone.  Such a server
+   is authoritative for all resource records in a zone that are not in
+   another zone.  The NS records that indicate a zone cut are the
+   property of the child zone created, as are any other records for the
+   origin of that child zone, or any sub-domains of it.  A server for a
+   zone should not return authoritative answers for queries related to
+   names in another zone, which includes the NS, and perhaps A, records
+   at a zone cut, unless it also happens to be a server for the other
+   zone.
+
+   Other than the DNSSEC cases mentioned immediately below, servers
+   should ignore data other than NS records, and necessary A records to
+   locate the servers listed in the NS records, that may happen to be
+   configured in a zone at a zone cut.
+
+6.2. DNSSEC issues
+
+   The DNS security mechanisms [RFC2065] complicate this somewhat, as
+   some of the new resource record types added are very unusual when
+   compared with other DNS RRs.  In particular the NXT ("next") RR type
+   contains information about which names exist in a zone, and hence
+   which do not, and thus must necessarily relate to the zone in which
+   it exists.  The same domain name may have different NXT records in
+   the parent zone and the child zone, and both are valid, and are not
+   an RRSet.  See also section 5.3.2.
+
+   Since NXT records are intended to be automatically generated, rather
+   than configured by DNS operators, servers may, but are not required
+   to, retain all differing NXT records they receive regardless of the
+   rules in section 5.4.
+
+   For a secure parent zone to securely indicate that a subzone is
+   insecure, DNSSEC requires that a KEY RR indicating that the subzone
+   is insecure, and the parent zone's authenticating SIG RR(s) be
+   present in the parent zone, as they by definition cannot be in the
+   subzone.  Where a subzone is secure, the KEY and SIG records will be
+   present, and authoritative, in that zone, but should also always be
+   present in the parent zone (if secure).
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 9]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   Note that in none of these cases should a server for the parent zone,
+   not also being a server for the subzone, set the AA bit in any
+   response for a label at a zone cut.
+
+7. SOA RRs
+
+   Three minor issues concerning the Start of Zone of Authority (SOA)
+   Resource Record need some clarification.
+
+7.1. Placement of SOA RRs in authoritative answers
+
+   RFC1034, in section 3.7, indicates that the authority section of an
+   authoritative answer may contain the SOA record for the zone from
+   which the answer was obtained.  When discussing negative caching,
+   RFC1034 section 4.3.4 refers to this technique but mentions the
+   additional section of the response.  The former is correct, as is
+   implied by the example shown in section 6.2.5 of RFC1034.  SOA
+   records, if added, are to be placed in the authority section.
+
+7.2. TTLs on SOA RRs
+
+   It may be observed that in section 3.2.1 of RFC1035, which defines
+   the format of a Resource Record, that the definition of the TTL field
+   contains a throw away line which states that the TTL of an SOA record
+   should always be sent as zero to prevent caching.  This is mentioned
+   nowhere else, and has not generally been implemented.
+   Implementations should not assume that SOA records will have a TTL of
+   zero, nor are they required to send SOA records with a TTL of zero.
+
+7.3. The SOA.MNAME field
+
+   It is quite clear in the specifications, yet seems to have been
+   widely ignored, that the MNAME field of the SOA record should contain
+   the name of the primary (master) server for the zone identified by
+   the SOA.  It should not contain the name of the zone itself.  That
+   information would be useless, as to discover it, one needs to start
+   with the domain name of the SOA record - that is the name of the
+   zone.
+
+8. Time to Live (TTL)
+
+   The definition of values appropriate to the TTL field in STD 13 is
+   not as clear as it could be, with respect to how many significant
+   bits exist, and whether the value is signed or unsigned.  It is
+   hereby specified that a TTL value is an unsigned number, with a
+   minimum value of 0, and a maximum value of 2147483647.  That is, a
+   maximum of 2^31 - 1.  When transmitted, this value shall be encoded
+   in the less significant 31 bits of the 32 bit TTL field, with the
+
+
+
+Elz & Bush                  Standards Track                    [Page 10]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   most significant, or sign, bit set to zero.
+
+   Implementations should treat TTL values received with the most
+   significant bit set as if the entire value received was zero.
+
+   Implementations are always free to place an upper bound on any TTL
+   received, and treat any larger values as if they were that upper
+   bound.  The TTL specifies a maximum time to live, not a mandatory
+   time to live.
+
+9. The TC (truncated) header bit
+
+   The TC bit should be set in responses only when an RRSet is required
+   as a part of the response, but could not be included in its entirety.
+   The TC bit should not be set merely because some extra information
+   could have been included, but there was insufficient room.  This
+   includes the results of additional section processing.  In such cases
+   the entire RRSet that will not fit in the response should be omitted,
+   and the reply sent as is, with the TC bit clear.  If the recipient of
+   the reply needs the omitted data, it can construct a query for that
+   data and send that separately.
+
+   Where TC is set, the partial RRSet that would not completely fit may
+   be left in the response.  When a DNS client receives a reply with TC
+   set, it should ignore that response, and query again, using a
+   mechanism, such as a TCP connection, that will permit larger replies.
+
+10. Naming issues
+
+   It has sometimes been inferred from some sections of the DNS
+   specification [RFC1034, RFC1035] that a host, or perhaps an interface
+   of a host, is permitted exactly one authoritative, or official, name,
+   called the canonical name.  There is no such requirement in the DNS.
+
+10.1. CNAME resource records
+
+   The DNS CNAME ("canonical name") record exists to provide the
+   canonical name associated with an alias name.  There may be only one
+   such canonical name for any one alias.  That name should generally be
+   a name that exists elsewhere in the DNS, though there are some rare
+   applications for aliases with the accompanying canonical name
+   undefined in the DNS.  An alias name (label of a CNAME record) may,
+   if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no
+   other data.  That is, for any label in the DNS (any domain name)
+   exactly one of the following is true:
+
+
+
+
+
+
+Elz & Bush                  Standards Track                    [Page 11]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+     + one CNAME record exists, optionally accompanied by SIG, NXT, and
+       KEY RRs,
+     + one or more records exist, none being CNAME records,
+     + the name exists, but has no associated RRs of any type,
+     + the name does not exist at all.
+
+10.1.1. CNAME terminology
+
+   It has been traditional to refer to the label of a CNAME record as "a
+   CNAME".  This is unfortunate, as "CNAME" is an abbreviation of
+   "canonical name", and the label of a CNAME record is most certainly
+   not a canonical name.  It is, however, an entrenched usage.  Care
+   must therefore be taken to be very clear whether the label, or the
+   value (the canonical name) of a CNAME resource record is intended.
+   In this document, the label of a CNAME resource record will always be
+   referred to as an alias.
+
+10.2. PTR records
+
+   Confusion about canonical names has lead to a belief that a PTR
+   record should have exactly one RR in its RRSet.  This is incorrect,
+   the relevant section of RFC1034 (section 3.6.2) indicates that the
+   value of a PTR record should be a canonical name.  That is, it should
+   not be an alias.  There is no implication in that section that only
+   one PTR record is permitted for a name.  No such restriction should
+   be inferred.
+
+   Note that while the value of a PTR record must not be an alias, there
+   is no requirement that the process of resolving a PTR record not
+   encounter any aliases.  The label that is being looked up for a PTR
+   value might have a CNAME record.  That is, it might be an alias.  The
+   value of that CNAME RR, if not another alias, which it should not be,
+   will give the location where the PTR record is found.  That record
+   gives the result of the PTR type lookup.  This final result, the
+   value of the PTR RR, is the label which must not be an alias.
+
+10.3. MX and NS records
+
+   The domain name used as the value of a NS resource record, or part of
+   the value of a MX resource record must not be an alias.  Not only is
+   the specification clear on this point, but using an alias in either
+   of these positions neither works as well as might be hoped, nor well
+   fulfills the ambition that may have led to this approach.  This
+   domain name must have as its value one or more address records.
+   Currently those will be A records, however in the future other record
+   types giving addressing information may be acceptable.  It can also
+   have other RRs, but never a CNAME RR.
+
+
+
+
+Elz & Bush                  Standards Track                    [Page 12]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   Searching for either NS or MX records causes "additional section
+   processing" in which address records associated with the value of the
+   record sought are appended to the answer.  This helps avoid needless
+   extra queries that are easily anticipated when the first was made.
+
+   Additional section processing does not include CNAME records, let
+   alone the address records that may be associated with the canonical
+   name derived from the alias.  Thus, if an alias is used as the value
+   of an NS or MX record, no address will be returned with the NS or MX
+   value.  This can cause extra queries, and extra network burden, on
+   every query.  It is trivial for the DNS administrator to avoid this
+   by resolving the alias and placing the canonical name directly in the
+   affected record just once when it is updated or installed.  In some
+   particular hard cases the lack of the additional section address
+   records in the results of a NS lookup can cause the request to fail.
+
+11. Name syntax
+
+   Occasionally it is assumed that the Domain Name System serves only
+   the purpose of mapping Internet host names to data, and mapping
+   Internet addresses to host names.  This is not correct, the DNS is a
+   general (if somewhat limited) hierarchical database, and can store
+   almost any kind of data, for almost any purpose.
+
+   The DNS itself places only one restriction on the particular labels
+   that can be used to identify resource records.  That one restriction
+   relates to the length of the label and the full name.  The length of
+   any one label is limited to between 1 and 63 octets.  A full domain
+   name is limited to 255 octets (including the separators).  The zero
+   length full name is defined as representing the root of the DNS tree,
+   and is typically written and displayed as ".".  Those restrictions
+   aside, any binary string whatever can be used as the label of any
+   resource record.  Similarly, any binary string can serve as the value
+   of any record that includes a domain name as some or all of its value
+   (SOA, NS, MX, PTR, CNAME, and any others that may be added).
+   Implementations of the DNS protocols must not place any restrictions
+   on the labels that can be used.  In particular, DNS servers must not
+   refuse to serve a zone because it contains labels that might not be
+   acceptable to some DNS client programs.  A DNS server may be
+   configurable to issue warnings when loading, or even to refuse to
+   load, a primary zone containing labels that might be considered
+   questionable, however this should not happen by default.
+
+   Note however, that the various applications that make use of DNS data
+   can have restrictions imposed on what particular values are
+   acceptable in their environment.  For example, that any binary label
+   can have an MX record does not imply that any binary name can be used
+   as the host part of an e-mail address.  Clients of the DNS can impose
+
+
+
+Elz & Bush                  Standards Track                    [Page 13]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   whatever restrictions are appropriate to their circumstances on the
+   values they use as keys for DNS lookup requests, and on the values
+   returned by the DNS.  If the client has such restrictions, it is
+   solely responsible for validating the data from the DNS to ensure
+   that it conforms before it makes any use of that data.
+
+   See also [RFC1123] section 6.1.3.5.
+
+12. Security Considerations
+
+   This document does not consider security.
+
+   In particular, nothing in section 4 is any way related to, or useful
+   for, any security related purposes.
+
+   Section 5.4.1 is also not related to security.  Security of DNS data
+   will be obtained by the Secure DNS [RFC2065], which is mostly
+   orthogonal to this memo.
+
+   It is not believed that anything in this document adds to any
+   security issues that may exist with the DNS, nor does it do anything
+   to that will necessarily lessen them.  Correct implementation of the
+   clarifications in this document might play some small part in
+   limiting the spread of non-malicious bad data in the DNS, but only
+   DNSSEC can help with deliberate attempts to subvert DNS data.
+
+13. References
+
+   [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.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts - application
+               and support", STD 3, RFC 1123, January 1989.
+
+   [RFC1700]   Reynolds, J., Postel, J., "Assigned Numbers",
+               STD 2, RFC 1700, October 1994.
+
+   [RFC2065]   Eastlake, D., Kaufman, C., "Domain Name System Security
+               Extensions", RFC 2065, January 1997.
+
+
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                    [Page 14]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+14. Acknowledgements
+
+   This memo arose from discussions in the DNSIND working group of the
+   IETF in 1995 and 1996, the members of that working group are largely
+   responsible for the ideas captured herein.  Particular thanks to
+   Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the
+   DNSSEC issues in this document, and to John Gilmore for pointing out
+   where the clarifications were not necessarily clarifying.  Bob Halley
+   suggested clarifying the placement of SOA records in authoritative
+   answers, and provided the references.  Michael Patton, as usual, and
+   Mark Andrews, Alan Barrett and Stan Barber provided much assistance
+   with many details.  Josh Littlefield helped make sure that the
+   clarifications didn't cause problems in some irritating corner cases.
+
+15. Authors' Addresses
+
+   Robert Elz
+   Computer Science
+   University of Melbourne
+   Parkville, Victoria, 3052
+   Australia.
+
+   EMail: kre@munnari.OZ.AU
+
+
+   Randy Bush
+   RGnet, Inc.
+   5147 Crystal Springs Drive NE
+   Bainbridge Island, Washington,  98110
+   United States.
+
+   EMail: randy@psg.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                    [Page 15]