idnits 2.17.1
draft-pan-dnsop-swild-rr-type-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.)
== 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 (March 27, 2018) is 2222 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: September 28, 2018 CNNIC
6 March 27, 2018
8 SWILD RR Type (Wildcard on Intermediate Nameservers)
9 draft-pan-dnsop-swild-rr-type-02
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 September 28, 2018.
35 Copyright Notice
37 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . 7
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 NSEC aggressiveuse wildcard should be dealed more carefully, to avoid
263 flaws such as [CVE-2017-15105].
265 7.3. Hijack Risk
267 There is concern that SWILD will rise the hijack risk, because it
268 give a response on whole subdomain wildcards, but not a single
269 subdomain.
271 However, there is similar fatal hijack risk on NS and MX, which is
272 configured for the whole zone.
274 The hijack influnence of SWILD will not be larger than NS or MX.
276 7.4. Stub Validation
278 SWILD does not support directly DNSSEC validation on single subdomain
279 wildcard.
281 Forwarding Resolvers must trigger a tranditional DNSSEC resolution if
282 they receive a single subdomain wildcard query with DNSSEC validation
283 option from Stub Resolvers.
285 8. Disposable Domain
287 [DNSNoise] found that disposable domains are widely used by various
288 industries, such as Anti-Virus, DNSBLs, CDN, P2P.
290 They are software-generated subdomains with small target A RRSets,
291 which can be summaried by wildcards for passive DNS databases.
293 Take [McAfeeGTI] for example, *.avqs.mcafee.com's response is from
294 127.0.0.0/16 network, which is a information about the reputation of
295 the queried file. It can be optimized with a unique NAPTR RR, which
296 can offer an service api of the file reputation information, but not
297 use special A RR definition.
299 9. Acknowledgements
301 Thanks comments for Tony Finch, Petr Špaček, Matthew
302 Pounsett, Paul Hoffman, Richard Gibson, Paul Vixie, Dave Crocker,
303 Peter van Dijk, Mark Andrews, Vernon Schryver, Ted Lemon, Mukund
304 Sivaraman, Mikael Abrahamsson, Ralf Weber, Davey Song, Warren Kumari.
306 Thanks to all in the DNSOP mailing list.
308 10. References
310 10.1. Normative References
312 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
313 RFC 1034, November 1987.
315 [RFC1035] Mockapetris, P., "Domain Names - Implementation and
316 Specification", RFC 1035, November 1987.
318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
319 Requirement Levels", RFC 2119, March 1997.
321 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
322 NCACHE)", RFC 2308, March 1998.
324 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
325 System", RFC 4592, July 2006.
327 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
328 Terminology", RFC 7719, December 2015.
330 [RFC7871] Contavalli, C., van der Gasst, W., Lawrence, D., and W.
331 Kumari, "Client Subnet in DNS Queries", RFC 7871, May
332 2016.
334 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
335 Nothing Underneath", RFC 8020, Nov 2016.
337 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
338 DNSSEC-Validated Cache", RFC 8198, July 2017.
340 10.2. Informative References
342 [BankNSHijack]
343 "Brazilians whacked: Crooks hijack bank's DNS to fleece
344 victims", .
347 [CVE-2017-15105]
348 "An improperly validated wildcard NSEC record",
349 .
351 [DNSNoise]
352 "DNS Noise: Measuring the Pervasiveness of Disposable
353 Domains in Modern DNS Traffic",
354 .
357 [McAfeeGTI]
358 "McAfee Global Threat Intelligence (GTI) File Reputation",
359 .
362 Authors' Addresses
364 Lanlan Pan
365 Beijing
366 China
368 Email: abbypan@gmail.com
369 URI: https://github.com/abbypan
371 Yu Fu
372 CNNIC
373 No.4 South 4th Street, Zhongguancun
374 Beijing
375 China
377 Email: fuyu@cnnic.cn