Internet DRAFT - draft-pfrc-2181-resource-record-sets

draft-pfrc-2181-resource-record-sets



 



INTERNET-DRAFT                                       Declan Ma, Ed.
Intended Status: Proposed Standard                        zDNS Ltd.
Expires: 2015-10-15                                      2015-05-27


                        DNS Resource Record Sets
                draft-pfrc-2181-resource-record-sets-00


Abstract

   RFC 2181 collected eight independent considerations and created a single
   docuement to address each of them in turn.  Over the following two decades
   it has become clear that each of these items should be considered and evovolve
   in its own right, as suggested in RFC 2181. This document extracts the exact 
   text from RFC 2181 and places it into its own track.


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
 


Declan Ma, Ed.                 Expires 2015-10-15                  [Page 1]

INTERNET DRAFT          DNS Resource Record Sets            2015-05-22


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3  Sending RRs from an RRSet . . . . . . . . . . . . . . . . . . .  3
   4  TTLs of RRs in an RRSet . . . . . . . . . . . . . . . . . . . .  3
   5  DNSSEC Special Cases  . . . . . . . . . . . . . . . . . . . . .  4
     5.1  SIG records and RRSets  . . . . . . . . . . . . . . . . . .  4
     5.2  NXT RRs . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   6  Receiving RRSets  . . . . . . . . . . . . . . . . . . . . . . .  5
     6.1  Ranking data  . . . . . . . . . . . . . . . . . . . . . . .  6
   7  Sending RRSets (reprise)  . . . . . . . . . . . . . . . . . . .  7
   8  Security Considerations . . . . . . . . . . . . . . . . . . . .  7
   9  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   10  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  8




























 


Declan Ma, Ed.                 Expires 2015-10-15                  [Page 2]

INTERNET DRAFT          DNS Resource Record Sets            2015-05-22


1  Introduction

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

   This document is intended to specify how to process DNS RRSets during
   DNS operations.


2  Terminology

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


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


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


Declan Ma, Ed.                 Expires 2015-10-15                  [Page 3]

INTERNET DRAFT          DNS Resource Record Sets            2015-05-22


   Should an authoritative source send such a malformed RRSet, the
   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  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.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
 


Declan Ma, Ed.                 Expires 2015-10-15                  [Page 4]

INTERNET DRAFT          DNS Resource Record Sets            2015-05-22


   specially.

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


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

 


Declan Ma, Ed.                 Expires 2015-10-15                  [Page 5]

INTERNET DRAFT          DNS Resource Record Sets            2015-05-22


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


Declan Ma, Ed.                 Expires 2015-10-15                  [Page 6]

INTERNET DRAFT          DNS Resource Record Sets            2015-05-22


   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.

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

8  Security Considerations

   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.


9  References
 


Declan Ma, Ed.                 Expires 2015-10-15                  [Page 7]

INTERNET DRAFT          DNS Resource Record Sets            2015-05-22


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

   [RFC2065]  Eastlake 3rd, D. and C. Kaufman, "Domain Name System
              Security Extensions", RFC 2065, January 1997.

   [RFC2199]  Ramos, A., "Request for Comments Summary RFC Numbers 2100-
              2199", RFC 2199, January 1998.



10  Authors' Addresses

       Declan Ma, Ed.

        ZDNS Ltd.
        4, South 4th Street, Zhongguancun, 
        Haidian, Beijing 100190,
        China




























Declan Ma, Ed.                 Expires 2015-10-15                  [Page 8]