Internet DRAFT - draft-yao-dnsop-smallzone-junk-query

draft-yao-dnsop-smallzone-junk-query







dnsop                                                             J. Yao
Internet-Draft                                                     CNNIC
Intended status: Standards Track                            July 8, 2019
Expires: January 9, 2020


 A Mechanism to Reduce the junky queries to Authoritative Name Servers
                        Serving Small Size Zones
                draft-yao-dnsop-smallzone-junk-query-00

Abstract

   Some zones are small, public and stable, but very important.  They
   might deal with millions of queries every day.  But many of the
   queries are junky.  For examples, many queries DNS root servers
   receive are junky.  The queried junky names are not in the root, but
   the root servers have to waste a lot of resources to deal with them.
   It has been an obstacle to increase the performance of DNS root
   query.  In order to save the resource caused by the DNS junky
   queries, this document proposes a new mechanism by aggressive use of
   the owner name list of the DNS zone.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 9, 2020.

Copyright Notice

   Copyright (c) 2019 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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Yao                      Expires January 9, 2020                [Page 1]

Internet-Draft               root-junk-query                   July 2019


   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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Design Overview . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Onldigest Resource Record . . . . . . . . . . . . . . . . . .   4
   5.  Create the Owner Name list and Calculate the Digest . . . . .   4
   6.  Requirements for the resolver . . . . . . . . . . . . . . . .   5
   7.  Requirements for the Authoritative Name Servers . . . . . . .   5
   8.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   6
   11. Change History  . . . . . . . . . . . . . . . . . . . . . . .   7
     11.1.  draft-yao-dnsop-smallzone-junk-query: Version 00 . . . .   7
   12. Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Some zones are small, public and stable, but very important.  They
   might deal with millions of queries every day.  But many of the
   queries are junky.  For examples, many queries DNS root servers
   receive are junky.  The queried junky names are not in the root, but
   the root servers have to waste a lot of resources to deal with them.
   It has been an obstacle to increase the performance of DNS root
   query.

   In order to save the resource caused by the DNS junky queries, this
   document proposes a new mechanism by aggressive use of the owner name
   list of the DNS zone.  This document proposes an owner name list of



Yao                      Expires January 9, 2020                [Page 2]

Internet-Draft               root-junk-query                   July 2019


   the DNS zone, and introduces a new RR type that serves as a
   cryptographic message digest of the owner name list of the DNS zone.
   The digest allows a receiver of the owner name list of the zone to
   verify the owner name list.

2.  Terminology

   The basic key words such as "MUST", "MUST NOT", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "MAY", and "MAYNOT" are to be interpreted as
   described in [RFC2119] [RFC8174].

   The basic DNS terms used in this specification are defined in the
   documents [RFC1034] and [RFC1035].

3.  Design Overview

   This document introduces a new mechanism which uses the owner name
   list of a zone to produce the negative response.  When the resolver
   receives the query for the specific zone, it checks its owner name
   list of that zone before doing further query.  If the name queried is
   in the owner name list, it will be sent to that zone for furhter
   query; otherwise, the responder will generate the negative response
   if it is not in the owner name list.  This document introduces a new
   Resource Record type designed to convey a message digest of the owner
   name list of a zone.  The digest is calculated at the time of zone
   publication.  Ideally the zone is signed with DNSSEC to guarantee
   that any modifications of the digest can be detected.  The procedures
   for digest calculation and DNSSEC signing are similar, which require
   the similar ordering of RRs.  Many small zones'owner name list keeps
   stable, although the DNS RR's type or RDATA may change day by day.
   The mechanism is designed to be used on zones that are relatively
   stable and have infrequent updates.  As currently specified, the
   digest is re-calculated over the entire zone when the owner names are
   updated.  It is expected that verification of digest of owner name
   list of a zone would be implemented in name servers and the
   resolvers.  That is, a name server can verify the zone owner name
   list it was given and refuse to serve a zone which fails
   verification; a resolver can verify the zone owner name list it was
   given and refuse to serve a zone owner name list which fails
   verification.  For signed zones, the name server needs a trust anchor
   to perform DNSSEC validation.  A server for a specifical zone can
   publish the owner name list or the full zone.  A resolver can get the
   owner name list for a specifical zone or get the full zone and create
   the owner name list for this zone according to the rules set by this
   document.

   The goal of our design is that the junk-queried names can be
   recognized as soon as possible before sending to the specifized zone.



Yao                      Expires January 9, 2020                [Page 3]

Internet-Draft               root-junk-query                   July 2019


   The mechanism proposed by this dcoument will decrease the work load
   of authoritative name servers serving the specific zone efficently.

4.  Onldigest Resource Record

   This record is designed for the cryptographic message digest of the
   owner name list of the DNS zone.  The Onldigest RDATA wire format is
   encoded as follows:


                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Digest Type  |                                               |
      +-+-+-+-+-+-+-+-+                                               |
      |                             Digest                            |
      /                                                               /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 1.  Onldigest RDATA Wire Format

   o  The Digest Type field is an 8-bit unsigned integer that identifies
      the algorithm used to construct the digest.

   o  The Digest field is a variable-length sequence of octets
      containing the message digest.  The Digest field MUST NOT be
      empty.

5.  Create the Owner Name list and Calculate the Digest

   The owner name list digest is calculated by concatenating the
   canonical on-the- wire form (without name compression) of all RRs in
   the zone, and then applying the digest algorithm.  Some rules are:

   o  All of owner names of RRs with NS type should be prefixed with
      "*." before putting into the owner name list.  It means that if
      example.com has NS type, the owner name will become
      "*.example.com".

   o  For ordering of owner names in the zone, this document adopts
      DNSSEC's canonical ordering for names (Section 6.1 of [RFC4034]),

   o  It is meaningless for an owner name list to have multiple same
      owner names.  In the interest of consistency and interoperability,
      such duplicate owner names MUST NOT be included in the owner name
      list.



Yao                      Expires January 9, 2020                [Page 4]

Internet-Draft               root-junk-query                   July 2019


   o  All other owner names which are not descendants of the zone apex
      name, including glue records, MUST not be included.

   The owner name list Should have the following format:

   o  owner-name-list = RR(1); | RR(2);| RR(3); | ...

   o  digest = digest_algorithm( owner-name-list )

   o  where "|" denotes concatenation, and ";" is an added separator.

6.  Requirements for the resolver

   In order to implement the mechanism described in this document:

   o  The resolver should get the owner name list for a specific zone
      either in band or out of band.  It can also get a full zone and
      create the owner name list for a specific zone.

   o  The resolver should verify the zone owner name list using the
      Onldigest record.

   o  The resolver should refresh the Onldigest record befor it expires.
      When the Onldigest record's Digest field is updated, it means that
      the owner name list was updated and the resolve should get a new
      one.

   o  For a non DNSSEC query, if the queried name is not on the owner
      name list for the specifical zone, it means that that name is not
      on that zone or its sub-zone and the resolver can create a none
      existent name response to the query.

   o  For a DNSSEC query, if the queried name is not on the owner name
      list for the specifical zone, it means that that name is not on
      that zone or its sub-zone and the resolver can create a none
      existent name response to the query.  The resolver can verify the
      Onldigest record's relative RRSIG and the owner name list with the
      Onldigest record.  If it is successful, it can be regarded as the
      DNSSEC verification.

7.  Requirements for the Authoritative Name Servers

   In order to reduce the workload and get the faster response, the
   Authoritative Name Servers may choose the similar strategies adopted
   by the resolvers.  For a non DNSSEC query, if the queried name is not
   on the owner name list for the specifical zone, it means that that
   name is not on that zone or its sub-zone and the servers can create a
   none existent name response to the query.  For a DNSSEC query, if the



Yao                      Expires January 9, 2020                [Page 5]

Internet-Draft               root-junk-query                   July 2019


   queried name is not on the owner name list for the specifical zone,
   the servers need to find the NSEC or NSEC3 records before responding.

8.  Use Cases

   The mechanism proposed in this document has the following use cases
   (you can help to add more):

   o  Root Zone: The root zone are small, public and stable where the
      owner name are not likely to be changed for a long time.

   o  Important Companies' zone: These company's zones are small and
      where the owner name are not likely to be changed for a period of
      time.  For examples, CNNIC's owner name list for cnnic.cn are kept
      stable for a long time.  But sometimes, the attacker may choose
      name server serving cnnic.cn zone for random name DDOS attack.
      CNNIC also runs a resolver which can be configured to use this
      mechanism to help to deduce the flooding to the CNNIC's
      authoritative name server.

   o  Public DNS Resolver: The public DNS resolver can provide the
      value-added service to some specific companies' zone.  Some online
      company may choose to coporate with some public DNS resolvers to
      reduce the possible DDOS attack to their companies' authoritative
      name servers.

9.  IANA Considerations

   This document defines a new DNS RR type, Onldigest, whose value **
   has been allocated by IANA from the "Resource Record (RR) TYPEs"
   subregistry of the "Domain Name System (DNS) Parameters" registry:

   Type: Onldigest

   Value: **

   Meaning: Owner name list digest

   Reference: This document

10.  Security Considerations

   The mechansime designed in this document is useful for small, public
   and stable zone, where owner names are likely to kept stable.  It is
   not useful for big, private and dynamic zone, where owner names are
   too many or likely to kept dynamical.





Yao                      Expires January 9, 2020                [Page 6]

Internet-Draft               root-junk-query                   July 2019


   The resolver needs to know the owner name list via the public zones
   or the one published by the zone owners.

11.  Change History

   RFC Editor: Please remove this section.

11.1.  draft-yao-dnsop-smallzone-junk-query: Version 00

   o  Help to reduce the workload of junk-query to the authoritative
      name servers.

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

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              DOI 10.17487/RFC1321, April 1992,
              <https://www.rfc-editor.org/info/rfc1321>.

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

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/info/rfc4033>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <https://www.rfc-editor.org/info/rfc4034>.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <https://www.rfc-editor.org/info/rfc4035>.






Yao                      Expires January 9, 2020                [Page 7]

Internet-Draft               root-junk-query                   July 2019


Author's Address

   Jiankang Yao
   CNNIC
   4 South 4th     Street,Zhongguancun,Haidian     District
   Beijing, Beijing  100190
   China

   Phone: +86 10   5881 3007
   Email: yaojk@cnnic.cn









































Yao                      Expires January 9, 2020                [Page 8]