[Docs] [txt|pdf] [Tracker] [Email] [Nits]



Infrastructure System Engineering Group                          Y. Chen
Internet-Draft                                                     Baidu
Intended status: Informational                            April 17, 2020
Expires: October 17, 2020


               Invisible Canonical Name Implementation
                   draft-yaoyuan-dnsext-idr-adr-00


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/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 October 17, 2020.

Copyright Notice

   Copyright (c) 2020 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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Chen                  Expires October 17, 2020                  [Page 1]


Internet-Draft    Invisible Canonical Name Implementation     April 2020


Abstract

   To accomplish the goal that not exposing redundant and unuseful CNAME
   chains in answers responded to clients, this document describes two
   new DNS resource records called "IDR" and "ADR" for hiding CNAME
   iterative process and better safety consideration.

1.  Introduction

   The CNAME record presented in [RFC1034] and [RFC1035] nowadays is
   widely used to complete different functions. Simultaneously the
   record begins to show signs of weakness when helping engineers solve
   complex technical problems during increasingly complicated network
   environment. There are three fundamental flaws about CNAME and a
   scene which it cannot fit in:

      o Unnecessary and massive consumption of network bandwidth in
        traffic between clients and name resolvers if a chain with
        multi-CNAMEs is contained in answer section. Actually these
        CNAMEs are useless at all for clients.

      o The abuse of canonical names without authentication. Today we
        can easily configure a name redirected to a famous website
        without getting permission of the owner. Although website users
        with dns knowledge finally will know it is an alias after
        looking through the resolving process (someone not) and resource
        servers may take some security defence to deny illegal access,
        it still cause a tort about private intellectual property of
        real service providers. Maybe we can take some measures in dns
        layer.

      o CNAME chains in authoritative name servers MAY cause dns
        hijacking. As a name server will continue to find answers in
        internal cache, the upper servers could give answers those not
        equal to the real authoritative servers without validation.

      o In certain special circumstances or requirements, services
        providers closest to users side are not willing to present the
        intermediate process of the CNAMEs to customers. Certainly they
        MUST ask for permission of the original content administrators
        at first.

   To solve the above problems, we define two new DNS Resource Records
   with some extensions to current DNS rules.The changes are designed to
   be compatible with existing software. The existing support for CNAME
   and DNAME[RFC2672] is retained.





Chen                  Expires October 17, 2020                  [Page 2]


Internet-Draft    Invisible Canonical Name Implementation     April 2020


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

3.  The "IDR" and "ADR" Resource Record

   IDR means "Invisible Direct Reference", it looks like a transparent
   agent who borrows resource records from others. The users cannot feel
   the agency process in detail. IDR means "Allow Direct Reference",
   which supplies a mechanism for safe references with permission. IDR
   and ADR have the following format:

      IDR: <owner> <ttl> <class> IDR <target>
      ADR: <owner> <ttl> <class> ADR <target>

   Like a normal record, all fields are required. The DATA field
   <target> is a fully qualified <domain-name> [RFC1035] which MUST be
   in uncompressed form transferred in dns message. Both of records
   include a TTL value that represents the maximum time-to-live for a
   cached response in a resolver.

   IDR and ADR have the same behaviours as CNAME except the following
   features:

      o when a authoritative server deals with a query, return directly
        back to the asker when an IDR record is found rather than fall
        into deeply more queries process in its own name tree.

      o ADR is only used for authorization check and SHOULD not be
      included in answers when a resolver sends response packets to
      users.

      o When a resolver receives an IDR answer from a server, it MUST
        substitute the QNAME with IDR's <target> and restart an
        additional query of QTYPE ADR. If the answer section includes
        the original QNAME(authentication passed), then the query
        process for original QTYPE can be continued.

      o Such kind of node as present in <owner> of IDL in answers MUST
        be removed if there is an IDR-ADR pair.









Chen                  Expires October 17, 2020                  [Page 3]


Internet-Draft    Invisible Canonical Name Implementation     April 2020


   The co-existence relationships among IDR/ADR and CNAME/DNAME:

      o IDR and ADR: YES

      o IDR and CNAME/DNAME: NO

      o ADR and CNAME/DNAME: YES

      o For each node and leaf on the tree-style domain name space,
        there MUST be at most one IDR record for each <class> in the
        corresponding database, the number of ADR MUST not be limited.

4.  Query Processing

   To complete the IDR/ADR mechanism the updating algorithms [RFC2136]
   and the name running algorithms [RFC1034][RFC2672] must be modified
   slightly for both servers and resolvers.

4.1.  Processing By Primary Master Servers

   The following comparison rule SHOULD be added in the end of chapter
   1.1.5. in [RFC2136].

      IDL  compare only NAME, CLASS, and TYPE -- it is not possible
           to have more than one IDL RR, even if their data fields
           differ.

   Meanwhile, ADLs SHOULD be allowed to co-exist with CNAME, DNAME, NS.

4.2.  Processing By Authoritative Servers

   For a server performing non-recursive service steps 3.a and 5 of
   section 4.3.2 [RFC1034][RFC2672] are changed to check for a IDL
   record after checking for a CNAME type, and to make a pretreatment
   before packaging response message.

   DNS clients sending Extended DNS [EDNS0] queries with Version 0 or
   non-extended queries are presumed not to understand the semantics of
   the IDR/ADR record, so a server which implements this specification,
   when answering a non-extended query, SHOULD give out a CNAME record
   for each IDR record encountered during query processing to help the
   client reach the correct DNS data.  The behaviour of clients and
   servers under Extended DNS versions greater than 0 will be specified
   when those versions are defined.







Chen                  Expires October 17, 2020                  [Page 4]


Internet-Draft    Invisible Canonical Name Implementation     April 2020


   The revised server algorithm is:

   1. Set or clear the value of recursion available in the response
      depending on whether the name server is willing to provide
      recursive service.  If recursive service is available and
      requested via the RD bit in the query, go to step 5, otherwise
      step 2.

   2. Search the available zones for the zone which is the nearest
      ancestor to QNAME.  If such a zone is found, go to step 3,
      otherwise step 4.

   3. Start matching down, label by label, in the zone.  The matching
      process can terminate several ways:

      a. If the whole of QNAME is matched, we have found the node.

         If the data at the node is a CNAME, and QTYPE doesn't match
         CNAME, copy the CNAME RR into the answer section of the
         response, change QNAME to the canonical name in the CNAME RR,
         and go back to step 1.

         Else if the data at the node is a IDL, and QTYPE doesn't match
         IDL, copy the IDL RR into the answer section of the
         response. If the query was not
         extended [EDNS0] with a Version indicating understanding of the
         IDL record, the server SHOULD make a substitution of CNAME for
         <type> of RR already put in answer, then go back to step 6. The
         reason of not going back to step 1 is
         that it prevents the upper servers from hijacking dns data
         which SHOULD be responded by others who are authorized to
         answer.

         Otherwise, copy all RRs which match QTYPE into the answer
         section and go to step 6.

      b. If a match would take us out of the authoritative data, we have
         a referral.  This happens when we encounter a node with NS RRs
         marking cuts along the bottom of a zone.

         Copy the NS RRs for the subzone into the authority section of
         the reply.  Put whatever addresses are available into the
         additional section, using glue RRs if the addresses are not
         available from authoritative data or the cache.  Go to step 4.







Chen                  Expires October 17, 2020                  [Page 5]


Internet-Draft    Invisible Canonical Name Implementation     April 2020


      c. If at some label, a match is impossible (i.e., the
         corresponding label does not exist), look to see whether the
         last label matched has a DNAME record.

         If a DNAME record exists at that point, copy that record into
         the answer section.  If substitution of its <target> for its
         <owner> in QNAME would overflow the legal size for a <domain-
         name>, set RCODE to YXDOMAIN and exit; otherwise
         perform the substitution and continue.  If the query was not
         extended [EDNS0] with a Version indicating understanding of the
         DNAME record, the server SHOULD synthesize a CNAME record as
         described above and include it in the answer section.  Go back
         to step 1.

         If there was no DNAME record, look to see if the "*" label
         exists.

         If the "*" label does not exist, check whether the name we are
         looking for is the original QNAME in the query or a name we
         have followed due to a CNAME.  If the name is original, set an
         authoritative name error in the response and exit.  Otherwise
         just exit.

         If the "*" label does exist, match RRs at that node against
         QTYPE.  If any match, copy them into the answer section, but
         set the owner of the RR to be QNAME, and not the node with the
         "*" label.  Go to step 6.

   4. Start matching down in the cache.  If QNAME is found in the cache,
      copy all RRs attached to it that match QTYPE into the answer
      section.  If QNAME is not found in the cache but a DNAME record is
      present at an ancestor of QNAME, copy that DNAME record into the
      answer section.  If there was no delegation from authoritative
      data, look for the best one from the cache, and put it in the
      authority section.  Go to step 6.

   5. Use the local resolver or a copy of its algorithm (see resolver
      section of this memo) to answer the query.  Store the results,
      including any intermediate CNAMEs, DNAMEs in the answer section of
      the response, including two nodes which are connected
      by an IDL/ADL pair(not added) pointing to each other.

   6. Using local data only, attempt to add other RRs which may be
      useful to the additional section of the query.  Exit.

   Note that the IDLs SHOULD be also sent to clients with status
   "refused" if there are not corresponding ADLs found.




Chen                  Expires October 17, 2020                  [Page 6]


Internet-Draft    Invisible Canonical Name Implementation     April 2020


4.3.  Processing By Resolvers

   A resolver or a server providing recursive service MUST be modified
   to treat a IDL as somewhat analogous to a CNAME with some
   differences.
   The resolver algorithm of [RFC1034][RFC2672] section 5.3.3 is
   modified to renumber step 4.e as 4.f, 4.d as 4.e  and insert a new
   4.d. The complete algorithm becomes:

   1. See if the answer is in local information, and if so return it to
      the client.

   2. Find the best servers to ask.

   3. Send them queries until one returns a response.

   4. Analyze the response, either:

      a. if the response answers the question or contains a name error,
         cache the data as well as returning it back to the client.

      b. if the response contains a better delegation to other servers,
         cache the delegation information, and go to step 2.

      c. if the response shows a CNAME and that is not the answer
         itself, cache the CNAME, change the SNAME to the canonical name
         in the CNAME RR and go to step 1.

      d. if the response shows a IDL and that is not the answer
         itself, cache the IDL, preserve the original QNAME and QTYPE,
         change the QNAME with the <target> in the IDL RR and restart an
         ADL query in local database or outside name servers. If
         returned results do not contain a ADL, terminate the process
         with RCODE refused. Else if one or more ADLs are found, cache
         them and judge if the original QNAME is included. If YES,
         change back to original QTYPE and go to step 1, else return
         the answer to the client with RCODE refused.

      e. if the response shows a DNAME and that is not the answer
         itself, cache the DNAME.  If substitution of the DNAME's
         <target> for its <owner> in the SNAME would overflow the legal
         size for a <domain-name>, return an implementation-dependent
         error to the application; otherwise perform the substitution
         and go to step 1.

      f. if the response shows a server failure or other bizarre
         contents, delete the server from the SLIST and go back to step
         3.



Chen                  Expires October 17, 2020                  [Page 7]


Internet-Draft    Invisible Canonical Name Implementation     April 2020


   Before sending the records in answer section to the client, we MUST
   eliminate such kind of nodes which own this feature: the node is the
   <target> in a IDL record, and it allows the <owner> to reference the
   records inside the node. In other words, the node has a IDL
   redirecting to another node which also has a ADL to authorize the
   jumping behaviour.

5.  Examples of Use

5.1.  Simple Mapping

   If the zone data for the FOO.EXAMPLE domain contains:

      WWW.FOO.EXAMPLE  IDL   WWW.BAR.EXAMPLE

   And the zone data for the BAR.EXAMPLE domain contains:

      WWW.BAR.EXAMPLE  ADL   WWW.FOO.EXAMPLE
                       A     1.2.3.4

   When a client send a query of type A for WWW.FOO.EXAMPLE, it will get
   a response as:

      WWW.FOO.EXAMPLE  A     1.2.3.4

   The client will not feel the existence of the intermediate node
   WWW.BAR.EXAMPLE when receiving answer from a resolver. We suggest a
   dns software which implements this specification could provide a
   method to present the detailed query process since it is convenient
   for operations staff to locate and solve problems related to dns.

5.2.  Multilayer Mapping

   If dns name space includes the chain structure below:

                        IDL      IDL      IDL      IDL
                      ------>  ------>  ------>  ------>  matched calss
   entrance node --->    N1       N2       N3  ...  Nn    ------> target
                      <------  <------  <------  <------  matched type
                        ADL      ADL      ADL       ADL

   According to the processing rules, clients will only see the target
   in answer section with original QTYPE eventually. The nodes from N1
   to Nn will be silently removed by resolvers when encoding the
   response packets.






Chen                  Expires October 17, 2020                  [Page 8]


Internet-Draft    Invisible Canonical Name Implementation     April 2020


5.3.  Interaction with CNAME

   If the zone data for the FOO.EXAMPLE domain contains:

      WWW.FOO.EXAMPLE  CNAME   WWW.BAR.EXAMPLE

   The zone data for the BAR.EXAMPLE domain contains:

      WWW.BAR.EXAMPLE  IDL   WWW.BAZ.EXAMPLE

   The zone data for the BAR.EXAMPLE domain contains:

      WWW.BAZ.EXAMPLE  ADL   WWW.BAR.EXAMPLE
                       CNAME WWW.QUX.EXAMPLE

   And the zone data for the QUX.EXAMPLE domain contains:

      WWW.QUX.EXAMPLE  A     1.2.3.4

   When a client send a query of type A for WWW.FOO.EXAMPLE, it will get
   a response as:

      WWW.FOO.EXAMPLE  CNAME   WWW.BAR.EXAMPLE
      WWW.BAR.EXAMPLE  CNAME   WWW.QUX.EXAMPLE
      WWW.QUX.EXAMPLE  A       1.2.3.4

5.4.  Interaction with DNAME

   If the zone data for the FOO.EXAMPLE domain contains:

      WWW.FOO.EXAMPLE  IDL   WWW.FROBOZZ.EXAMPLE

   The zone data for the FROBOZZ.EXAMPLE domain contains:

      WWW.FROBOZZ.EXAMPLE ADL WWW.FOO.EXAMPLE
      FROBOZZ.EXAMPLE  DNAME   FROBOZZ-DIVISION.ACME.EXAMPLE

   The zone data for the ACME.EXAMPLE domain contains:

      WWW.FROBOZZ-DIVISION.ACME.EXAMPLE  A     1.2.3.4

   When a client send a query of type A for WWW.FOO.EXAMPLE, it will get
   a response as:

      WWW.FOO.EXAMPLE  CNAME   WWW.FROBOZZ-DIVISION.ACME.EXAMPLE
      WWW.FROBOZZ-DIVISION.ACME.EXAMPLE  A     1.2.3.4





Chen                  Expires October 17, 2020                  [Page 9]


Internet-Draft    Invisible Canonical Name Implementation     April 2020


   The ADL record MUST be arranged in the zone file of domain
   "FROBOZZ.EXAMPLE", otherwise it will meet a DNAME and terminate the
   query process because of the non-existance of ADL.

   The above examples are based on an extended recursive queries with
   EDNS over Version 0 from clients.

5.5.  Handling queries with non-extended EDNS or EDNS with Version 0

   When authoritative Servers see such a kind of query, they MUST treat
   IDL as a normal CNAME if exist.
   ADLs MUST be ignored and RCODE MUST be set to NXDOMAIN if there are
   not other kinds of records at all except ADLs inside the node.

6.  Security Considerations

   The IDL/ADL records are similar to the CNAME record with regard to
   quoting resource records which have existed in other domains,
   differing in that the usage is safer than CNAME and do good to
   lighten pressure on network load.

7.  IANA Considerations

   IANA may agree the allocation of these two records in the dns type
   registry if the specification is proved to be reasonable in the
   future.

























Chen                  Expires October 17, 2020                 [Page 10]


Internet-Draft    Invisible Canonical Name Implementation     April 2020


8.  References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification",
              STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987,
              <https://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, DOI 10.17487/RFC2136, April 1997,
              <https://www.rfc-editor.org/info/rfc2136>.

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
              RFC 2671, DOI 10.17487/RFC2671, August 1999,
              <https://www.rfc-editor.org/info/rfc2671>.

   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",
              RFC 2672, DOI 10.17487/RFC2672, August 1999,
              <https://www.rfc-editor.org/info/rfc2672>.



Authors' Addresses

   Yaoyuan Chen
   Beijing Baidu Netcom Science Technology Co., Ltd
   No. 10 Shangdi 10th Street, Haidian District
   Beijing of China

   Phone: +86-18801393917
   Email: chenyaoyuan@baidu.com











Chen                  Expires October 17, 2020                 [Page 11]


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