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