idnits 2.17.1 draft-yao-dnsop-smallzone-junk-query-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o All other owner names which are not descendants of the zone apex name, including glue records, MUST not be included. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 2019) is 1747 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC8174' is mentioned on line 106, but not defined == Unused Reference: 'RFC1321' is defined on line 310, but no explicit reference was found in the text == Unused Reference: 'RFC4033' is defined on line 319, but no explicit reference was found in the text == Unused Reference: 'RFC4035' is defined on line 329, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop J. Yao 3 Internet-Draft CNNIC 4 Intended status: Standards Track July 8, 2019 5 Expires: January 9, 2020 7 A Mechanism to Reduce the junky queries to Authoritative Name Servers 8 Serving Small Size Zones 9 draft-yao-dnsop-smallzone-junk-query-00 11 Abstract 13 Some zones are small, public and stable, but very important. They 14 might deal with millions of queries every day. But many of the 15 queries are junky. For examples, many queries DNS root servers 16 receive are junky. The queried junky names are not in the root, but 17 the root servers have to waste a lot of resources to deal with them. 18 It has been an obstacle to increase the performance of DNS root 19 query. In order to save the resource caused by the DNS junky 20 queries, this document proposes a new mechanism by aggressive use of 21 the owner name list of the DNS zone. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 9, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 3 72 4. Onldigest Resource Record . . . . . . . . . . . . . . . . . . 4 73 5. Create the Owner Name list and Calculate the Digest . . . . . 4 74 6. Requirements for the resolver . . . . . . . . . . . . . . . . 5 75 7. Requirements for the Authoritative Name Servers . . . . . . . 5 76 8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 79 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 7 80 11.1. draft-yao-dnsop-smallzone-junk-query: Version 00 . . . . 7 81 12. Normative References . . . . . . . . . . . . . . . . . . . . 7 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 84 1. Introduction 86 Some zones are small, public and stable, but very important. They 87 might deal with millions of queries every day. But many of the 88 queries are junky. For examples, many queries DNS root servers 89 receive are junky. The queried junky names are not in the root, but 90 the root servers have to waste a lot of resources to deal with them. 91 It has been an obstacle to increase the performance of DNS root 92 query. 94 In order to save the resource caused by the DNS junky queries, this 95 document proposes a new mechanism by aggressive use of the owner name 96 list of the DNS zone. This document proposes an owner name list of 97 the DNS zone, and introduces a new RR type that serves as a 98 cryptographic message digest of the owner name list of the DNS zone. 99 The digest allows a receiver of the owner name list of the zone to 100 verify the owner name list. 102 2. Terminology 104 The basic key words such as "MUST", "MUST NOT", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "MAY", and "MAYNOT" are to be interpreted as 106 described in [RFC2119] [RFC8174]. 108 The basic DNS terms used in this specification are defined in the 109 documents [RFC1034] and [RFC1035]. 111 3. Design Overview 113 This document introduces a new mechanism which uses the owner name 114 list of a zone to produce the negative response. When the resolver 115 receives the query for the specific zone, it checks its owner name 116 list of that zone before doing further query. If the name queried is 117 in the owner name list, it will be sent to that zone for furhter 118 query; otherwise, the responder will generate the negative response 119 if it is not in the owner name list. This document introduces a new 120 Resource Record type designed to convey a message digest of the owner 121 name list of a zone. The digest is calculated at the time of zone 122 publication. Ideally the zone is signed with DNSSEC to guarantee 123 that any modifications of the digest can be detected. The procedures 124 for digest calculation and DNSSEC signing are similar, which require 125 the similar ordering of RRs. Many small zones'owner name list keeps 126 stable, although the DNS RR's type or RDATA may change day by day. 127 The mechanism is designed to be used on zones that are relatively 128 stable and have infrequent updates. As currently specified, the 129 digest is re-calculated over the entire zone when the owner names are 130 updated. It is expected that verification of digest of owner name 131 list of a zone would be implemented in name servers and the 132 resolvers. That is, a name server can verify the zone owner name 133 list it was given and refuse to serve a zone which fails 134 verification; a resolver can verify the zone owner name list it was 135 given and refuse to serve a zone owner name list which fails 136 verification. For signed zones, the name server needs a trust anchor 137 to perform DNSSEC validation. A server for a specifical zone can 138 publish the owner name list or the full zone. A resolver can get the 139 owner name list for a specifical zone or get the full zone and create 140 the owner name list for this zone according to the rules set by this 141 document. 143 The goal of our design is that the junk-queried names can be 144 recognized as soon as possible before sending to the specifized zone. 146 The mechanism proposed by this dcoument will decrease the work load 147 of authoritative name servers serving the specific zone efficently. 149 4. Onldigest Resource Record 151 This record is designed for the cryptographic message digest of the 152 owner name list of the DNS zone. The Onldigest RDATA wire format is 153 encoded as follows: 155 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Digest Type | | 159 +-+-+-+-+-+-+-+-+ | 160 | Digest | 161 / / 162 / / 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Figure 1. Onldigest RDATA Wire Format 167 o The Digest Type field is an 8-bit unsigned integer that identifies 168 the algorithm used to construct the digest. 170 o The Digest field is a variable-length sequence of octets 171 containing the message digest. The Digest field MUST NOT be 172 empty. 174 5. Create the Owner Name list and Calculate the Digest 176 The owner name list digest is calculated by concatenating the 177 canonical on-the- wire form (without name compression) of all RRs in 178 the zone, and then applying the digest algorithm. Some rules are: 180 o All of owner names of RRs with NS type should be prefixed with 181 "*." before putting into the owner name list. It means that if 182 example.com has NS type, the owner name will become 183 "*.example.com". 185 o For ordering of owner names in the zone, this document adopts 186 DNSSEC's canonical ordering for names (Section 6.1 of [RFC4034]), 188 o It is meaningless for an owner name list to have multiple same 189 owner names. In the interest of consistency and interoperability, 190 such duplicate owner names MUST NOT be included in the owner name 191 list. 193 o All other owner names which are not descendants of the zone apex 194 name, including glue records, MUST not be included. 196 The owner name list Should have the following format: 198 o owner-name-list = RR(1); | RR(2);| RR(3); | ... 200 o digest = digest_algorithm( owner-name-list ) 202 o where "|" denotes concatenation, and ";" is an added separator. 204 6. Requirements for the resolver 206 In order to implement the mechanism described in this document: 208 o The resolver should get the owner name list for a specific zone 209 either in band or out of band. It can also get a full zone and 210 create the owner name list for a specific zone. 212 o The resolver should verify the zone owner name list using the 213 Onldigest record. 215 o The resolver should refresh the Onldigest record befor it expires. 216 When the Onldigest record's Digest field is updated, it means that 217 the owner name list was updated and the resolve should get a new 218 one. 220 o For a non DNSSEC query, if the queried name is not on the owner 221 name list for the specifical zone, it means that that name is not 222 on that zone or its sub-zone and the resolver can create a none 223 existent name response to the query. 225 o For a DNSSEC query, if the queried name is not on the owner name 226 list for the specifical zone, it means that that name is not on 227 that zone or its sub-zone and the resolver can create a none 228 existent name response to the query. The resolver can verify the 229 Onldigest record's relative RRSIG and the owner name list with the 230 Onldigest record. If it is successful, it can be regarded as the 231 DNSSEC verification. 233 7. Requirements for the Authoritative Name Servers 235 In order to reduce the workload and get the faster response, the 236 Authoritative Name Servers may choose the similar strategies adopted 237 by the resolvers. For a non DNSSEC query, if the queried name is not 238 on the owner name list for the specifical zone, it means that that 239 name is not on that zone or its sub-zone and the servers can create a 240 none existent name response to the query. For a DNSSEC query, if the 241 queried name is not on the owner name list for the specifical zone, 242 the servers need to find the NSEC or NSEC3 records before responding. 244 8. Use Cases 246 The mechanism proposed in this document has the following use cases 247 (you can help to add more): 249 o Root Zone: The root zone are small, public and stable where the 250 owner name are not likely to be changed for a long time. 252 o Important Companies' zone: These company's zones are small and 253 where the owner name are not likely to be changed for a period of 254 time. For examples, CNNIC's owner name list for cnnic.cn are kept 255 stable for a long time. But sometimes, the attacker may choose 256 name server serving cnnic.cn zone for random name DDOS attack. 257 CNNIC also runs a resolver which can be configured to use this 258 mechanism to help to deduce the flooding to the CNNIC's 259 authoritative name server. 261 o Public DNS Resolver: The public DNS resolver can provide the 262 value-added service to some specific companies' zone. Some online 263 company may choose to coporate with some public DNS resolvers to 264 reduce the possible DDOS attack to their companies' authoritative 265 name servers. 267 9. IANA Considerations 269 This document defines a new DNS RR type, Onldigest, whose value ** 270 has been allocated by IANA from the "Resource Record (RR) TYPEs" 271 subregistry of the "Domain Name System (DNS) Parameters" registry: 273 Type: Onldigest 275 Value: ** 277 Meaning: Owner name list digest 279 Reference: This document 281 10. Security Considerations 283 The mechansime designed in this document is useful for small, public 284 and stable zone, where owner names are likely to kept stable. It is 285 not useful for big, private and dynamic zone, where owner names are 286 too many or likely to kept dynamical. 288 The resolver needs to know the owner name list via the public zones 289 or the one published by the zone owners. 291 11. Change History 293 RFC Editor: Please remove this section. 295 11.1. draft-yao-dnsop-smallzone-junk-query: Version 00 297 o Help to reduce the workload of junk-query to the authoritative 298 name servers. 300 12. Normative References 302 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 303 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 304 . 306 [RFC1035] Mockapetris, P., "Domain names - implementation and 307 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 308 November 1987, . 310 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 311 DOI 10.17487/RFC1321, April 1992, 312 . 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, 316 DOI 10.17487/RFC2119, March 1997, 317 . 319 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 320 Rose, "DNS Security Introduction and Requirements", 321 RFC 4033, DOI 10.17487/RFC4033, March 2005, 322 . 324 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 325 Rose, "Resource Records for the DNS Security Extensions", 326 RFC 4034, DOI 10.17487/RFC4034, March 2005, 327 . 329 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 330 Rose, "Protocol Modifications for the DNS Security 331 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 332 . 334 Author's Address 336 Jiankang Yao 337 CNNIC 338 4 South 4th Street,Zhongguancun,Haidian District 339 Beijing, Beijing 100190 340 China 342 Phone: +86 10 5881 3007 343 Email: yaojk@cnnic.cn