idnits 2.17.1 draft-pan-dnsop-swild-rr-type-01.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.) == There are 12 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 25, 2017) is 2404 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7719 (Obsoleted by RFC 8499) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop L. Pan 3 Internet-Draft 4 Intended status: Informational Y. Fu 5 Expires: March 29, 2018 CNNIC 6 September 25, 2017 8 SWILD RR Type (Wildcard on Intermediate Nameservers) 9 draft-pan-dnsop-swild-rr-type-01 11 Abstract 13 This document specifies a new SWILD RR type for Intermediate 14 Nameservers to cache subdomain wildcard record, in order to optimize 15 the wildcard domain cache miss, reduce the cache size, and help to 16 defense the DDoS attack. 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 March 29, 2018. 35 Copyright Notice 37 Copyright (c) 2017 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. The SWILD Resource Record . . . . . . . . . . . . . . . . . . 3 55 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4.1. Authoritative Nameserver . . . . . . . . . . . . . . . . 3 57 4.2. Intermediate Nameserver: Recursive Resolver . . . . . . . 4 58 4.2.1. Recursive Resolvers that support SWILD RR . . . . . . 4 59 4.2.2. Recursive Resolvers that not support SWILD RR . . . . 4 60 4.3. Intermediate Nameserver: Forwarding Resolvers . . . . . . 4 61 5. DNS Cache . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 6. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 7. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 7.1. Compare to NSEC aggressiveuse wildcard . . . . . . . . . 5 65 7.2. DNSSEC Deployment . . . . . . . . . . . . . . . . . . . . 6 66 7.3. Hijack Risk . . . . . . . . . . . . . . . . . . . . . . . 6 67 7.4. Stub Validation . . . . . . . . . . . . . . . . . . . . . 6 68 8. Disposable Domain . . . . . . . . . . . . . . . . . . . . . . 6 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 10.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 [RFC1034] and [RFC4592] described wildcard domain name. 79 Nowadays wildcard domain is globally used, take "*.github.io" for 80 example, 82 foo.github.io. 3600 IN CNAME sni.github.map.fastly.net. 83 sni.github.map.fastly.net. 25 IN A 151.101.73.147 85 Wildcard domain is simple configured on Authoritative Nameserver, but 86 Intermediate Nameservers have to cache various domains 87 (xxx.github.io, yyy.github.io, ... ) of the same wildcard domain 88 configuration, with low cache hit rate, increase cache size. 90 This document specifies a new SWILD RR type for Intermediate 91 Nameservers to cache subdomain wildcard record, in order to optimize 92 the wildcard domain cache miss, reduce the cache size, and help to 93 defense the DDoS attack. 95 It is OPT-IN, Intermediate Nameservers can choose not to implement or 96 enable it. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 Basic terms used in this specification are defined in the documents 105 [RFC1034], [RFC1035], [RFC4592], [RFC7719], [RFC7871] and [RFC8020]. 107 Authoritative Nameserver: Described in [RFC1035] Section 6. 109 Intermediate Nameserver: Described in [RFC7871] Section 4. 111 Recursive Resolver: Described in [RFC1035] Section 7. 113 Forwarding Resolver: Described in [RFC2308] Section 1. 115 3. The SWILD Resource Record 117 The presentation format of the SWILD RR is as follows: 119 owner ttl class SWILD target 121 The "target" is a subdomain of the owner, to indicate that all 122 subdomains of the "owner" have the same configuration with the 123 "target". 125 4. Overview 127 Special character "_" to indicate the wildcard domain configuration 128 on Intermediate Nameservers, make all the subdomains CNAME to the "_" 129 subdomain, and generate a SWILD RR "_". 131 If most of Recursive Resolvers support SWILD RR in the future, "_" 132 special character is not strictly used for SWILD target. 134 Take "*.foo.com" for example. 136 4.1. Authoritative Nameserver 138 Authoritative Nameserver configures the zonefile of "foo.com": 140 o add SWILD RR "_" to indicate subdomain wildcard. 142 o configure "_.foo.com". 144 o make "*.foo.com" CNAME to "_.foo.com". 146 Note that, there is not any other subdomain configured in the 147 "foo.com" zone except "_.foo.com". 149 $ORIGIN foo.com. 151 @ 86400 IN SWILD _ 152 _ 3600 IN CNAME map.bar.net. 153 * 600 IN CNAME _ 155 4.2. Intermediate Nameserver: Recursive Resolver 157 4.2.1. Recursive Resolvers that support SWILD RR 159 Recursive Resolver sends "xxx.foo.com" A RR query to Authoritative 160 Nameserver, get subdomain wildcard response: 162 xxx.foo.com. 600 IN CNAME _.foo.com. 163 _.foo.com. 3600 IN CNAME map.bar.net. 164 map.bar.net. 600 IN A 202.38.64.10 165 foo.com. 86400 IN SWILD _.foo.com. 167 Recursive Resolver knows that SWILD RR is for wildcard domain on 168 recursive side, marks "_.foo.com" as wildcard domains of "*.foo.com". 170 In TTL time, if Recursive Resolver receives a "yyy.foo.com" A RR 171 query, it can directly return this subdomain wildcard response: 173 yyy.foo.com. 600 IN CNAME _.foo.com. 174 _.foo.com. 3600 IN CNAME map.bar.net. 175 map.bar.net. 600 IN A 202.38.64.10 176 foo.com. 86400 IN SWILD _.foo.com. 178 4.2.2. Recursive Resolvers that not support SWILD RR 180 Recursive Resolver can deal with DNS response as usual. 182 The next time, Recursive Resolver receives a "yyy.foo.com" A RR 183 query, it can send DNS query to Authoritative Nameserver. 185 4.3. Intermediate Nameserver: Forwarding Resolvers 187 Forwarding Resolver sends query to its next-hop Resolver is similar 188 with Recursive Resolver sends query to Authoritative Nameserver. 190 5. DNS Cache 192 Similar with [RFC8198] Section 6, SWILD can reduce latency and 193 decrease server load: 195 Intermediate Nameservers' cache hit rate will rise, avoid to query 196 Authoritative Nameserver for the same wildcard domain configuration. 198 Intermediate Nameservers' cache size can be reduced, avoid to cache 199 various domains of the same wildcard domain configuration. 201 6. DDoS 203 When Recursive Servers or Second Level Domain(SLD) Authoritative 204 Servers encounter DDoS attack, it will be better for the defense if 205 Recursive Servers know more information. 207 o SWILD can help Recursive Servers to make a fast correct response 208 when the queires of important subdomain wildcards rise suddenly 209 and sharply, on condition that the source clients are hard to be 210 deprecated. 212 o SWILD can help Recursive Servers to response the unvisited 213 important subdomain wildcards queries, when the SLD Authoritative 214 Servers encounter an accident which may cause SERVFAIL, TIMEOUT, 215 or hijack responses. 217 7. DNSSEC 219 Clients and DNSSEC-Enabled Intermediate Nameservers can use DNSSEC to 220 validate all the responses with the Authoritative Nameserver. 222 DNSSEC-Enabled Intermediate Nameservers can only validate the SWILD 223 RRSIG of "foo.com" and the RRSIGs of "_.foo.com", not need to 224 validate the CNAME RRSIG of "yyy.foo.com". 226 7.1. Compare to NSEC aggressiveuse wildcard 228 [RFC8198] wildcard could solve similar wildcard problem: 230 o NSEC/NSEC3 RR: give "NOT EXIST SUBDOMAIN" information. 232 o Cached deduced wildcard: give the default wildcard RR. 234 SWILD: 236 o Directly give "ALL SUBDOMAIN" information, and the default 237 wildcard RR. 239 SWILD can work with NSEC aggressiveuse wildcard, Authoritative 240 Servers can also return NSEC/NSEC3 RR. 242 SWILD is applicable even when Authoritative Nameservers don't give 243 NSEC/NSEC3 RR. 245 SWILD is applicable on non-validating Forwarding Resolvers. 247 7.2. DNSSEC Deployment 249 DNSSEC is designed to protect the integrity of DNS responses, avoid 250 package tampering. 252 How to encourge DNSSEC deployment is an old question, especially on 253 important SLD Authoritative Severs such as google.com, amazon.com. 255 Defense on domain hjiack such as [BankNSHijack] is the biggest 256 motivation to deploy DNSSEC. 258 NSEC aggressiveuse wildcard or SWILD can not make influnence on 259 DNSSEC deployment, but they solve similar subdomain problem under 260 different DNSSEC deployment prerequisites. 262 7.3. Hijack Risk 264 There is concern that SWILD will rise the hijack risk, because it 265 give a response on whole subdomain wildcards, but not a single 266 subdomain. 268 However, there is similar fatal hijack risk on NS and MX, which is 269 configured for the whole zone. 271 The hijack influnence of SWILD will not be larger than NS or MX. 273 7.4. Stub Validation 275 SWILD does not support directly DNSSEC validation on single subdomain 276 wildcard. 278 Forwarding Resolvers must trigger a tranditional DNSSEC resolution if 279 they receive a single subdomain wildcard query with DNSSEC validation 280 option from Stub Resolvers. 282 8. Disposable Domain 284 [DNSNoise] found that disposable domains are widely used by various 285 industries, such as Anti-Virus, DNSBLs, CDN, P2P. 287 They are software-generated subdomains with small target A RRSets, 288 which can be summaried by wildcards for passive DNS databases. 290 Take [McAfeeGTI] for example, *.avqs.mcafee.com's response is from 291 127.0.0.0/16 network, which is a information about the reputation of 292 the queried file. It can be optimized with a unique NAPTR RR, which 293 can offer an service api of the file reputation information, but not 294 use special A RR definition. 296 9. Acknowledgements 298 Thanks comments for Tony Finch, Petr Špaček, Matthew 299 Pounsett, Paul Hoffman, Richard Gibson, Paul Vixie, Dave Crocker, 300 Peter van Dijk, Mark Andrews, Vernon Schryver, Ted Lemon, Mukund 301 Sivaraman, Mikael Abrahamsson, Ralf Weber, Davey Song, Warren Kumari. 303 Thanks to all in the DNSOP mailing list. 305 10. References 307 10.1. Normative References 309 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 310 RFC 1034, November 1987. 312 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 313 Specification", RFC 1035, November 1987. 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", RFC 2119, March 1997. 318 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 319 NCACHE)", RFC 2308, March 1998. 321 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 322 System", RFC 4592, July 2006. 324 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 325 Terminology", RFC 7719, December 2015. 327 [RFC7871] Contavalli, C., van der Gasst, W., Lawrence, D., and W. 328 Kumari, "Client Subnet in DNS Queries", RFC 7871, May 329 2016. 331 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 332 Nothing Underneath", RFC 8020, Nov 2016. 334 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 335 DNSSEC-Validated Cache", RFC 8198, July 2017. 337 10.2. Informative References 339 [BankNSHijack] 340 "Brazilians whacked: Crooks hijack bank's DNS to fleece 341 victims", . 344 [DNSNoise] 345 "DNS Noise: Measuring the Pervasiveness of Disposable 346 Domains in Modern DNS Traffic", 347 . 350 [McAfeeGTI] 351 "McAfee Global Threat Intelligence (GTI) File Reputation", 352 . 355 Authors' Addresses 357 Lanlan Pan 358 Beijing 359 China 361 Email: abbypan@gmail.com 362 URI: https://github.com/abbypan 364 Yu Fu 365 CNNIC 366 No.4 South 4th Street, Zhongguancun 367 Beijing 368 China 370 Email: fuyu@cnnic.cn