idnits 2.17.1 draft-fujiwara-dnsop-ds-query-increase-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 20, 2014) is 3721 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Operations(dnsop) K. Fujiwara 3 Internet-Draft JPRS 4 Intended status: Informational January 20, 2014 5 Expires: July 24, 2014 7 Side effect of DNSSEC: an increase of DS queries 8 draft-fujiwara-dnsop-ds-query-increase-02.txt 10 Abstract 12 An increase of periodic DS queries is observed at top level domain 13 (TLD) DNS servers. The reason of the increase is low NCACHE TTL 14 value and DS nonexistence. This memo presents issues with DNSSEC and 15 small NCACHE TTL value, including possible countermeasures in order 16 to prepare future increase of DS queries. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 24, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Possible affected domain names . . . . . . . . . . . . . . . 3 55 4. Possible measures . . . . . . . . . . . . . . . . . . . . . . 3 56 4.1. Dummy DS idea . . . . . . . . . . . . . . . . . . . . . . 4 57 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 1. Introduction 61 A significant increase of DS queries is observed at JP TLD DNS 62 servers. 4.5% of queries are DS queries at JP TLD DNS servers in 63 Dec., 2013 and they are still increasing. Almost all query names of 64 DS queries are unsigned zone cuts. These DS queries are useless for 65 DNSSEC validation because they are unsigned delegations. Very small 66 number of IP addresses send most of DS queries and the DS queries are 67 periodic. The reason of the increase is low NCACHE TTL value and DS 68 nonexistence. Details are described in Section 2. Possible affected 69 domain names are described in Section 3. Possible countermeasures 70 are described in Section 4. 72 2. Problem statement 74 Many TLDs have supported DNSSEC. However, many delegations do not 75 have DS resource records. Some of full-resolvers support DNSSEC 76 validation. 78 The conditions of the DS query increase are as follows. 80 o TLD's TTL value is relatively high, e.g., 86400. 82 o TLD's NCACHE TTL value is low, e.g., 900. 84 o There are many popular query names whose resource record TTLs are 85 low, e.g., 300, and they are unsigned. 87 o DNSSEC validators receive queries of popular names frequently, 88 e.g. every 5 minutes. 90 An unsigned delegation does not have a DS RR in its TLD zone. DNSSEC 91 validation process starts when the validator receives a query and it 92 does not exist in the validator's cache. DNSSEC validators need to 93 know DS RR existence for each query name. The DS RR nonexistence 94 information is cached within NCACHE TTL. As a result, each DNSSEC 95 validator may send DS queries to TLD DNS servers one zone cut per 96 NCACHE TTL seconds. 98 This phenomena is DNSSEC protocol and DNS parameter issue. DS 99 queries will increase as DNSSEC validators will increase. 101 JP TLD case, NS and glue TTL is 86400 and NCACHE TTL is 900. There 102 are many popular names which are unsigned domain names and whose TTLs 103 are low. TTL of "www.yahoo.co.jp" A is 60 (CNAME TTL is 900 and TTL 104 of aliased name is 60) and TTL of "www.google.co.jp" A is 300. Busy 105 full-resolvers receive both queries every minutes or more. When a 106 busy full-resolver enables DNSSEC validation, it will send 107 "yahoo.co.jp" and "google.co.jp" DS queries every 900 seconds. 108 "yahoo.co.jp" NS and "google.co.jp" NS are cached in a day (86400 109 seconds). As a result, queries to JP DNS servers may increase 96 110 (86400 / 900) times at the maximum. This is DNSSEC protocol and 111 parameter issue. 113 3. Possible affected domain names 115 Possible affected domain names are delegation centric domain names 116 which support DNSSEC, whose NCACHE TTL is low, and which has popular 117 domain names which are not signed and use low TTL values. 119 TLDs: com, net, org, jp use 900 as NCACHE TTL value. Magnification 120 is 96 or more. 122 Reverse DNS: 193.in-addr.arpa uses 3600 as NCACHE TTL value. 123 Magnification is 48. 125 The root is affected a little because popular TLDs have already been 126 signed and the magnification is not high, 8 or 24 (86400 / 10800 or 127 86400 / 3600). 129 4. Possible measures 131 There are no good solutions and five possible measures to the 132 problem. 134 1. Reinforce DNS infrastructures. 136 2. Sign popular domain names. If popular domain names are signed, 137 their DS RRs are cached. However, a TLD can not control them. 138 Some TLDs have been trying to increase signed delegations by 139 price or security campaigns. 141 3. Lengthen resource record TTL of popular names. However, a TLD 142 can not control. 144 4. Lengthen NCACHE TTL value. However, the value is chosen by the 145 TLD's policy and this approach can not stop the increase of DS 146 queries. Section 5 of DNS NCACHE [RFC2308] recommends negative 147 cache time limit as values of one to three hours. Lengthening 148 NCACHE TTL value over 10800 is useless. Magnification can only 149 be lowered. (JP case, from 96 to 8 or 24.) 151 5. Update DNS/DNSSEC protocol to reduce unnecessary DS queries. 152 There are some idea. 154 1. Changing validator's caching algorithms. 156 2. Adding dummy DS to popular unsigned delegations. Details are 157 described in Section 4.1. 159 Without protocol modifications, we need to reinforce DNS 160 infrastructures and try to increase signed delegations. 162 4.1. Dummy DS idea 164 "Adding dummy DS to popular unsigned delegations." Dummy DS RR may 165 be ignored by traditional DNSSEC validators and it indicates that the 166 delegation is an unsigned delegation. Dummy DS TTL value is 167 controllable. This proposal requires new digest type. 169 Dummy DS RR will be ignored by traditional DNSSEC validators because 170 Section 5.2 of DNSSEC Protocol [RFC4035] defines that the resolver 171 should treat unknown digest type as no DS RRset exists. BIND 9 and 172 Unbound validators ignored dummy DS RR whose digest type is 255. 174 However, there are many considerations. 176 o Dummy DS RRs may be treated as a DNSSEC error. Google public DNS 177 reports validation error at dummy DSs. BIND 9 and Unbound 178 validators ignore dummy DSs. DNSSEC Protocol [RFC4035] may be 179 ambiguous. 181 o Dummy DS RRs increase signing costs because most of TLDs use opt- 182 out technique defined in NSEC3 [RFC5155] to reduce signed domain 183 names. 185 o Newly added DS RRs may be used within dummy DSs' TTL seconds (for 186 example, it will be 1 day). Without dummy DS RRs, newly added DS 187 RRs are used within NCACHE TTL (900 or 10800 seconds). 189 o Is it allowed that TLDs add dummy DS RRs without registrants' 190 consent? If adding dummy DS is same as 'NO DS', it is possible. 191 Otherwise, TLDs cannot add dummy DS RRs without registrants' 192 consent. 194 5. References 196 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 197 NCACHE)", RFC 2308, March 1998. 199 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 200 Rose, "Protocol Modifications for the DNS Security 201 Extensions", RFC 4035, March 2005. 203 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 204 Security (DNSSEC) Hashed Authenticated Denial of 205 Existence", RFC 5155, March 2008. 207 Author's Address 209 Kazunori Fujiwara 210 Japan Registry Services Co., Ltd. 211 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 212 Chiyoda-ku, Tokyo 101-0065 213 Japan 215 Phone: +81 3 5215 8451 216 EMail: fujiwara@jprs.co.jp