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, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [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, . [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, . 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]