1 Internet Engineering Task Force (IETF) C. Contavalli
2 Request for Comments: 7871 W. van der Gaast
3 Category: Informational Google
4 ISSN: 2070-1721 D. Lawrence
5 Akamai Technologies
6 W. Kumari
7 Google
8 May 2016
9
10
11 Client Subnet in DNS Queries
12
13 Abstract
14
15 This document describes an Extension Mechanisms for DNS (EDNS0)
16 option that is in active use to carry information about the network
17 that originated a DNS query and the network for which the subsequent
18 response can be cached. Since it has some known operational and
19 privacy shortcomings, a revision will be worked through the IETF for
20 improvement.
21
22 Status of This Memo
23
24 This document is not an Internet Standards Track specification; it is
25 published for informational purposes.
26
27 This document is a product of the Internet Engineering Task Force
28 (IETF). It represents the consensus of the IETF community. It has
29 received public review and has been approved for publication by the
30 Internet Engineering Steering Group (IESG). Not all documents
31 approved by the IESG are a candidate for any level of Internet
32 Standard; see Section 2 of RFC 5741.
33
34 Information about the current status of this document, any errata,
35 and how to provide feedback on it may be obtained at
36 http://www.rfc-editor.org/info/rfc7871.
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Contavalli, et al. Informational [Page 1]
53 RFC 7871 Client Subnet in DNS Queries May 2016
54
55
56 Copyright Notice
57
58 Copyright (c) 2016 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Contavalli, et al. Informational [Page 2]
108 RFC 7871 Client Subnet in DNS Queries May 2016
109
110
111 Table of Contents
112 1. Introduction ....................................................4
113 2. Privacy Note ....................................................5
114 3. Requirements Notation ...........................................5
115 4. Terminology .....................................................6
116 5. Overview ........................................................7
117 6. Option Format ...................................................8
118 7. Protocol Description ............................................9
119 7.1. Originating the Option .....................................9
120 7.1.1. Recursive Resolvers .................................9
121 7.1.2. Stub Resolvers .....................................10
122 7.1.3. Forwarding Resolvers ...............................11
123 7.2. Generating a Response .....................................11
124 7.2.1. Authoritative Nameserver ...........................11
125 7.2.2. Intermediate Nameserver ............................13
126 7.3. Handling ECS Responses and Caching ........................14
127 7.3.1. Caching the Response ...............................15
128 7.3.2. Answering from Cache ...............................16
129 7.4. Delegations and Negative Answers ..........................17
130 7.5. Transitivity ..............................................18
131 8. IANA Considerations ............................................18
132 9. DNSSEC Considerations ..........................................19
133 10. NAT Considerations ............................................19
134 11. Security Considerations .......................................20
135 11.1. Privacy ..................................................20
136 11.2. Birthday Attacks .........................................21
137 11.3. Cache Pollution ..........................................22
138 12. Sending the Option ............................................23
139 12.1. Probing ..................................................23
140 12.2. Whitelist ................................................24
141 13. Example .......................................................24
142 14. References ....................................................26
143 14.1. Normative References .....................................26
144 14.2. Informative References ...................................27
145 Acknowledgements ..................................................28
146 Contributors ......................................................29
147 Authors' Addresses ................................................30
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162 Contavalli, et al. Informational [Page 3]
163 RFC 7871 Client Subnet in DNS Queries May 2016
164
165
166 1. Introduction
167
168 Many Authoritative Nameservers today return different responses based
169 on the perceived topological location of the user. These servers use
170 the IP address of the incoming query to identify that location.
171
172 Since most queries come from Intermediate Recursive Resolvers, the
173 source address is that of the Recursive Resolver rather than of the
174 query originator.
175
176 Traditionally, and probably still in the majority of instances,
177 Recursive Resolvers are reasonably close in the topological sense to
178 the Stub Resolvers or Forwarding Resolvers that are the source of
179 queries. For these resolvers, using their own IP address is
180 sufficient for Authoritative Nameservers that tailor responses based
181 upon location of the querier.
182
183 Increasingly, though, a class of Recursive Resolvers has arisen that
184 handles query sources that are often not topologically close. The
185 motivation for having such Centralized Resolvers varies but is
186 usually because of some enhanced experience, such as greater cache
187 security or applying policies regarding where users may connect.
188 (Although political censorship usually comes to mind here, the same
189 actions may be used by a parent when setting controls on where a
190 minor may connect.) Similarly, many ISPs and other organizations use
191 a Centralized Resolver infrastructure that can be distant from the
192 clients the resolvers serve. These cases all lead to less than
193 desirable responses from topology-sensitive Authoritative
194 Nameservers.
195
196 This document defines an EDNS0 [RFC6891] option to convey network
197 information that is relevant to the DNS message. It will carry
198 sufficient network information about the originator for the
199 Authoritative Nameserver to tailor responses. It will also provide
200 for the Authoritative Nameserver to indicate the scope of network
201 addresses for which the tailored answer is intended. This EDNS0
202 option is intended for those Recursive Resolvers and Authoritative
203 Nameservers that would benefit from the extension and not for general
204 purpose deployment. This is completely optional and can safely be
205 ignored by servers that choose not to implement or enable it.
206
207 This document also includes guidelines on how best to cache those
208 results, and it provides recommendations on when this protocol
209 extension should be used.
210
211 At least a dozen different client and server implementations have
212 been written based on earlier draft versions of this specification.
213 The protocol is in active production use today. While the
214
215
216
217 Contavalli, et al. Informational [Page 4]
218 RFC 7871 Client Subnet in DNS Queries May 2016
219
220
221 implementations interoperate, there is varying behavior around edge
222 cases that were poorly specified. Known incompatibilities are
223 described in this document, and the authors believe that it is better
224 to describe the system as it is working today, even if not everyone
225 agrees with the details of the original specification
226 ([VANDERGAAST]). The alternative is an undocumented and proprietary
227 system.
228
229 A revised proposal to improve upon the minor flaws in this protocol
230 will be forthcoming to the IETF.
231
232 2. Privacy Note
233
234 If we were just beginning to design this mechanism, and not
235 documenting existing protocol, it is unlikely that we would have done
236 things exactly this way.
237
238 The IETF is actively working on enhancing DNS privacy
239 [DPRIVE_Working_Group] and the reinjection of metadata [METADATA] has
240 been identified as a problematic design pattern.
241
242 As noted above however, this document primarily describes existing
243 behavior of a deployed method to further the understanding of the
244 Internet community.
245
246 We recommend that the feature be turned off by default in all
247 nameserver software, and that operators only enable it explicitly in
248 those circumstances where it provides a clear benefit for their
249 clients. We also encourage the deployment of means to allow users to
250 make use of the opt-out provided. Finally, we recommend that others
251 avoid techniques that may introduce additional metadata in future
252 work, as it may damage user trust.
253
254 Regrettably, support for the opt-out provisions of this specification
255 are currently limited. Only one stub resolver, getdns, is known to
256 be able to originate queries with anonymity requested, and as yet no
257 applications are known to be able to indicate that user preference to
258 the stub resolver.
259
260 3. Requirements Notation
261
262 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
263 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
264 document are to be interpreted as described in [RFC2119].
265
266
267
268
269
270
271
272 Contavalli, et al. Informational [Page 5]
273 RFC 7871 Client Subnet in DNS Queries May 2016
274
275
276 4. Terminology
277
278 ECS: EDNS Client Subnet.
279
280 Client: A Stub Resolver, Forwarding Resolver, or Recursive Resolver.
281 A client to a Recursive Resolver or a Forwarding Resolver.
282
283 Server: A Forwarding Resolver, Recursive Resolver, or Authoritative
284 Nameserver.
285
286 Stub Resolver: A simple DNS protocol implementation on the client
287 side as described in [RFC1034], Section 5.3.1. A client to a
288 Recursive Resolver or a Forwarding Resolver.
289
290 Authoritative Nameserver: A nameserver that has authority over one
291 or more DNS zones. These are normally not contacted by Stub
292 Resolver or end user clients directly but by Recursive Resolvers.
293 Described in [RFC1035], Section 6.
294
295 Recursive Resolver: A nameserver that is responsible for resolving
296 domain names for clients by following the domain's delegation
297 chain. Recursive Resolvers frequently use caches to be able to
298 respond to client queries quickly. Described in [RFC1035],
299 Section 7.
300
301 Forwarding Resolver: A nameserver that does not do iterative
302 resolution itself, but instead passes that responsibility to
303 another Recursive Resolver, called a "Forwarder" in [RFC2308],
304 Section 1.
305
306 Intermediate Nameserver: Any nameserver in between the Stub Resolver
307 and the Authoritative Nameserver, such as a Recursive Resolver or
308 a Forwarding Resolver.
309
310 Centralized Resolvers: Intermediate Nameservers that serve a
311 topologically diverse network address space.
312
313 Tailored Response: A response from a nameserver that is customized
314 for the node that sent the query, often based on performance
315 (i.e., lowest latency, least number of hops, topological distance,
316 etc.).
317
318 Topologically Close: Refers to two hosts being close in terms of the
319 number of hops or the time it takes for a packet to travel from
320 one host to the other. The concept of topological distance is
321 only loosely related to the concept of geographical distance: two
322
323
324
325
326
327 Contavalli, et al. Informational [Page 6]
328 RFC 7871 Client Subnet in DNS Queries May 2016
329
330
331 geographically close hosts can still be very distant from a
332 topological perspective, and two geographically distant hosts can
333 be quite close on the network.
334
335 For a more comprehensive treatment of DNS terms, please see
336 [RFC7719].
337
338 5. Overview
339
340 The general idea of this document is to provide an EDNS0 option to
341 allow Recursive Resolvers, if they are willing, to forward details
342 about the origin network from which a query is coming when talking to
343 other nameservers.
344
345 The format of the edns-client-subnet (ECS) EDNS0 option is described
346 in Section 6 and is meant to be added in queries sent by Intermediate
347 Nameservers in a way that is transparent to Stub Resolvers and end
348 users, as described in Section 7.1. ECS is only defined for the
349 Internet (IN) DNS class.
350
351 As described in Section 7.2, an Authoritative Nameserver could use
352 ECS as a hint to the end user's network location and provide a better
353 answer. Its response would also contain an ECS option, clearly
354 indicating that the server made use of this information, and that the
355 answer is tied to the client's network.
356
357 As described in Section 7.3, Intermediate Nameservers would use this
358 information to cache the response.
359
360 Some Intermediate Nameservers may also have to be able to forward ECS
361 queries they receive, as described in Section 7.5.
362
363 The mechanisms provided by ECS raise various security-related
364 concerns related to cache growth, the ability to spoof EDNS0 options,
365 and privacy. Section 11 explores various mitigation techniques.
366
367 The expectation, however, is that this option will primarily be used
368 between Recursive Resolvers and Authoritative Nameservers that are
369 sensitive to network location issues. Most Recursive Resolvers,
370 Authoritative Nameservers, and Stub Resolvers will never need to know
371 about this option and will continue working as they had been.
372
373 Failure to support this option or its improper handling will, at
374 worst, cause suboptimal identification of client network location,
375 which is a common occurrence in current Content Delivery Network
376 (CDN) setups.
377
378
379
380
381
382 Contavalli, et al. Informational [Page 7]
383 RFC 7871 Client Subnet in DNS Queries May 2016
384
385
386 Section 7.1 also provides a mechanism for Stub Resolvers to signal
387 Recursive Resolvers that they do not want ECS treatment for specific
388 queries.
389
390 Additionally, operators of Intermediate Nameservers with ECS enabled
391 are allowed to choose how many bits of the address of received
392 queries to forward or to reduce the number of bits forwarded for
393 queries already including an ECS option.
394
395 6. Option Format
396
397 This protocol uses an EDNS0 [RFC6891] option to include client
398 address information in DNS messages. The option is structured as
399 follows:
400
401 +0 (MSB) +1 (LSB)
402 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
403 0: | OPTION-CODE |
404 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
405 2: | OPTION-LENGTH |
406 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
407 4: | FAMILY |
408 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
409 6: | SOURCE PREFIX-LENGTH | SCOPE PREFIX-LENGTH |
410 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
411 8: | ADDRESS... /
412 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
413
414 o (Defined in [RFC6891]) OPTION-CODE, 2 octets, for ECS is 8 (0x00
415 0x08).
416
417 o (Defined in [RFC6891]) OPTION-LENGTH, 2 octets, contains the
418 length of the payload (everything after OPTION-LENGTH) in octets.
419
420 o FAMILY, 2 octets, indicates the family of the address contained in
421 the option, using address family codes as assigned by IANA in
422 Address Family Numbers [Address_Family_Numbers].
423
424 The format of the address part depends on the value of FAMILY. This
425 document only defines the format for FAMILY 1 (IPv4) and FAMILY 2
426 (IPv6), which are as follows:
427
428 o SOURCE PREFIX-LENGTH, an unsigned octet representing the leftmost
429 number of significant bits of ADDRESS to be used for the lookup.
430 In responses, it mirrors the same value as in the queries.
431
432
433
434
435
436
437 Contavalli, et al. Informational [Page 8]
438 RFC 7871 Client Subnet in DNS Queries May 2016
439
440
441 o SCOPE PREFIX-LENGTH, an unsigned octet representing the leftmost
442 number of significant bits of ADDRESS that the response covers.
443 In queries, it MUST be set to 0.
444
445 o ADDRESS, variable number of octets, contains either an IPv4 or
446 IPv6 address, depending on FAMILY, which MUST be truncated to the
447 number of bits indicated by the SOURCE PREFIX-LENGTH field,
448 padding with 0 bits to pad to the end of the last octet needed.
449
450 o A server receiving an ECS option that uses either too few or too
451 many ADDRESS octets, or that has non-zero ADDRESS bits set beyond
452 SOURCE PREFIX-LENGTH, SHOULD return FORMERR to reject the packet,
453 as a signal to the software developer making the request to fix
454 their implementation.
455
456 All fields are in network byte order ("big-endian", per [RFC1700],
457 Data Notation).
458
459 7. Protocol Description
460
461 7.1. Originating the Option
462
463 The ECS option should generally be added by Recursive Resolvers when
464 querying Authoritative Nameservers, as described in Section 12. The
465 option can also be initialized by a Stub Resolver or Forwarding
466 Resolver.
467
468 7.1.1. Recursive Resolvers
469
470 The setup of the ECS option in a Recursive Resolver depends on the
471 client query that triggered the resolution process.
472
473 In the usual case, where no ECS option was present in the client
474 query, the Recursive Resolver initializes the option by setting
475 FAMILY of the client's address. It then uses the value of its
476 maximum cacheable prefix length to set SOURCE PREFIX-LENGTH. For
477 privacy reasons, and because the whole IP address is rarely required
478 to determine a tailored response, this length SHOULD be shorter than
479 the full address, as described in Section 11.
480
481 If the triggering query included an ECS option itself, it MUST be
482 examined for its SOURCE PREFIX-LENGTH. The Recursive Resolver's
483 outgoing query MUST then set SOURCE PREFIX-LENGTH to the shorter of
484 the incoming query's SOURCE PREFIX-LENGTH or the server's maximum
485 cacheable prefix length.
486
487
488
489
490
491
492 Contavalli, et al. Informational [Page 9]
493 RFC 7871 Client Subnet in DNS Queries May 2016
494
495
496 Finally, in both cases, SCOPE PREFIX-LENGTH is set to 0 and ADDRESS
497 is then added up to SOURCE PREFIX-LENGTH number of bits, with
498 trailing 0 bits added, if needed, to fill the final octet. The total
499 number of octets used MUST only be enough to cover SOURCE PREFIX-
500 LENGTH bits, rather than the full width that would normally be used
501 by addresses in FAMILY.
502
503 FAMILY and ADDRESS information MAY be used from the ECS option in the
504 incoming query. Passing the existing address data is supportive of
505 the Recursive Resolver being used as the target of a Forwarding
506 Resolver, but could possibly run into policy problems with regard to
507 usage agreements between the Recursive Resolver and Authoritative
508 Nameserver. See Section 12.2 for more discussion on this point. If
509 the Recursive Resolver will not forward FAMILY and ADDRESS data from
510 the incoming ECS option, it SHOULD return a REFUSED response.
511
512 Subsequent queries to refresh the data MUST, if unrestricted by an
513 incoming SOURCE PREFIX-LENGTH, specify the longest SOURCE PREFIX-
514 LENGTH that the Recursive Resolver is willing to cache, even if a
515 previous response indicated that a shorter prefix length was
516 sufficient.
517
518 7.1.2. Stub Resolvers
519
520 A Stub Resolver MAY generate DNS queries with an ECS option that sets
521 SOURCE PREFIX-LENGTH to limit how network information should be
522 revealed. An Intermediate Nameserver that receives such a query MUST
523 NOT make queries that include more bits of client address than in the
524 originating query.
525
526 A SOURCE PREFIX-LENGTH value of 0 means that the Recursive Resolver
527 MUST NOT add the client's address information to its queries. The
528 subsequent Recursive Resolver query to the Authoritative Nameserver
529 will then either not include an ECS option or MAY optionally include
530 its own address information, which is what the Authoritative
531 Nameserver will almost certainly use to generate any Tailored
532 Response in lieu of an option. This allows the answer to be handled
533 by the same caching mechanism as other queries, with an explicit
534 indicator of the applicable scope. Subsequent Stub Resolver queries
535 for /0 can then be answered from this cached response.
536
537 A Stub Resolver MUST set SCOPE PREFIX-LENGTH to 0. It MAY include
538 FAMILY and ADDRESS data, but should be prepared to handle a REFUSED
539 response if the Intermediate Nameserver that it queries has a policy
540 that denies forwarding of ADDRESS. If there is no ADDRESS set, i.e.,
541 SOURCE PREFIX-LENGTH is set to 0, then FAMILY SHOULD be set to the
542 transport over which the query is sent. This is for
543
544
545
546
547 Contavalli, et al. Informational [Page 10]
548 RFC 7871 Client Subnet in DNS Queries May 2016
549
550
551 interoperability; at least one major authoritative server will ignore
552 the option if FAMILY is not 1 or 2, even though it is irrelevant if
553 there are no ADDRESS bits.
554
555 7.1.3. Forwarding Resolvers
556
557 Forwarding Resolvers essentially appear to be Stub Resolvers to
558 whatever Recursive Resolver is ultimately handling the query, but
559 they look like a Recursive Resolver to their client. A Forwarding
560 Resolver using this option MUST prepare it as described in
561 Section 7.1.1, "Recursive Resolvers". In particular, a Forwarding
562 Resolver that implements this protocol MUST honor SOURCE PREFIX-
563 LENGTH restrictions indicated in the incoming query from its client.
564 See also Section 7.5.
565
566 Since the Recursive Resolver it contacts will treat the Forwarding
567 Resolver like a Stub Resolver, the Recursive Resolver's policies
568 regarding incoming ADDRESS information will apply in the same way.
569 If the Forwarding Resolver receives a REFUSED response when it sends
570 a query that includes a non-zero ADDRESS, it MUST retry with no
571 ADDRESS.
572
573 7.2. Generating a Response
574
575 7.2.1. Authoritative Nameserver
576
577 When a query containing an ECS option is received, an Authoritative
578 Nameserver supporting ECS MAY use the address information specified
579 in the option to generate a tailored response.
580
581 Authoritative Nameservers that have not implemented or enabled
582 support for the ECS option ought to safely ignore it within incoming
583 queries, per [RFC6891], Section 6.1.2. Such a server MUST NOT
584 include an ECS option within replies to indicate lack of support for
585 it. Implementers of Intermediate Nameservers should be aware,
586 however, that some nameservers incorrectly echo back unknown EDNS0
587 options. In this protocol, that should be mostly harmless, as the
588 SCOPE PREFIX-LENGTH should come back as 0, thus marking the response
589 as covering all networks.
590
591 A query with a wrongly formatted option (e.g., an unknown FAMILY)
592 MUST be rejected and a FORMERR response MUST be returned to the
593 sender, as described in [RFC6891], "Transport Considerations".
594
595 An Authoritative Nameserver that implements this protocol and
596 receives an ECS option MUST include an ECS option in its response to
597 indicate that it SHOULD be cached accordingly, regardless of whether
598 the client information was needed to formulate an answer. (Note that
599
600
601
602 Contavalli, et al. Informational [Page 11]
603 RFC 7871 Client Subnet in DNS Queries May 2016
604
605
606 the requirement in [RFC6891] to reserve space for the OPT record
607 could mean that the Answer section of the response will be truncated
608 and fall back to TCP indicated accordingly.) If an ECS option was
609 not included in a query, one MUST NOT be included in the response
610 even if the server is providing a Tailored Response -- presumably
611 based on the address from which it received the query.
612
613 FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS in the response MUST match
614 those in the query. Echoing back these values helps to mitigate
615 certain attack vectors, as described in Section 11.
616
617 SCOPE PREFIX-LENGTH in the response indicates the network for which
618 the answer is intended.
619
620 A SCOPE PREFIX-LENGTH value longer than SOURCE PREFIX-LENGTH
621 indicates that the provided prefix length was not specific enough to
622 select the most appropriate Tailored Response. Future queries for
623 the name within the specified network SHOULD use the longer SCOPE
624 PREFIX-LENGTH. Factors affecting whether the Recursive Resolver
625 would use the longer length include the amount of privacy masking the
626 operator wants to provide their users, and the additional resource
627 implications for the cache.
628
629 Conversely, a shorter SCOPE PREFIX-LENGTH indicates that more bits
630 than necessary were provided, and the answer is suitable for a
631 broader range of addresses. This could be as short as 0, to indicate
632 that the answer is suitable for all addresses in FAMILY.
633
634 As the logical topology of any part of the network with regard to the
635 tailored response can vary, an Authoritative Nameserver may return
636 different values of SCOPE PREFIX-LENGTH for different networks.
637
638 Since some queries can result in multiple RRsets being added to the
639 response, there is an unfortunate ambiguity from the original
640 specification as to how SCOPE PREFIX-LENGTH would apply to each
641 individual RRset. For example, multiple types in response to an ANY
642 metaquery could all have different applicable SCOPE PREFIX-LENGTH
643 values, but this protocol only has the ability to signal one. The
644 response SHOULD therefore, include the longest relevant PREFIX-LENGTH
645 of any RRset in the answer, which could have the unfortunate side
646 effect of redundantly caching some data that could be cached more
647 broadly. For the specific case of a Canonical Name (CNAME) chain,
648 the Authoritative Nameserver SHOULD only place the initial CNAME
649 record in the Answer section, to have it cached unambiguously and
650 appropriately. Most modern Recursive Resolvers restart the query
651 with the CNAME, so the remainder of the chain is typically ignored
652
653
654
655
656
657 Contavalli, et al. Informational [Page 12]
658 RFC 7871 Client Subnet in DNS Queries May 2016
659
660
661 anyway. For message-focused resolvers, rather than RRset-focused
662 ones, this will mean caching the entire CNAME chain at the longest
663 PREFIX-LENGTH of any RRset in the chain.
664
665 The specific logic that an Authoritative Nameserver uses to choose a
666 tailored response is not in the scope of this document. Implementers
667 are encouraged, however, to carefully consider their selection of
668 SCOPE PREFIX-LENGTH for the response in the event that the best
669 tailored response cannot be determined, and what the implications
670 would be over the life of the TTL.
671
672 Authoritative Nameservers might have situations where one Tailored
673 Response is appropriate for a relatively broad address range, such as
674 an IPv4 /20, except for some exceptions, such as a few /24 ranges
675 within that /20. Because it can't be guaranteed that queries for all
676 longer prefix lengths would arrive before one that would be answered
677 by the shorter prefix length, an Authoritative Nameserver MUST NOT
678 overlap prefixes.
679
680 When the Authoritative Nameserver has a longer prefix length Tailored
681 Response within a shorter prefix length Tailored Response, then
682 implementations can either:
683
684 1. Deaggregate the shorter prefix response into multiple longer
685 prefix responses, or
686
687 2. Alert the operator that the order of queries will determine which
688 answers get cached, and either warn and continue or treat this as
689 an error and refuse to load the configuration.
690
691 This choice should be documented for the operator, for example, in
692 the user manual.
693
694 When deaggregating to correct the overlap, prefix lengths should be
695 optimized to use the minimum necessary to cover the address space, in
696 order to reduce the overhead that results from having multiple copies
697 of the same answer. As a trivial example, if the Tailored Response
698 for 1.2.0/20 is A but there is one exception of 1.2.3/24 for B, then
699 the Authoritative Nameserver would need to provide Tailored Responses
700 for 1.2.0/23, 1.2.2/24, 1.2.4/22, and 1.2.8/21 all pointing to A, and
701 1.2.3/24 to B.
702
703 7.2.2. Intermediate Nameserver
704
705 When an Intermediate Nameserver uses ECS, whether it passes an ECS
706 option in its own response to its client is predicated on whether the
707 client originally included the option. Because a client that did not
708 use an ECS option might not be able to understand it, the server MUST
709
710
711
712 Contavalli, et al. Informational [Page 13]
713 RFC 7871 Client Subnet in DNS Queries May 2016
714
715
716 NOT provide one in its response. If the client query did include the
717 option, the server MUST include one in its response, especially as it
718 could be talking to a Forwarding Resolver, which would need the
719 information for its own caching.
720
721 If an Intermediate Nameserver receives a response that has a longer
722 SCOPE PREFIX-LENGTH than SOURCE PREFIX-LENGTH that it provided in its
723 query, it SHOULD still provide the result as the answer to the
724 triggering client request even if the client is in a different
725 address range. The Intermediate Nameserver MAY instead opt to retry
726 with a longer SOURCE PREFIX-LENGTH to get a better reply before
727 responding to its client, as long as it does not exceed a SOURCE
728 PREFIX-LENGTH specified in the query that triggered resolution, but
729 this obviously has implications for the latency of the overall
730 lookup.
731
732 The logic for using the cache to determine whether the Intermediate
733 Nameserver already knows the response to provide to its client is
734 covered in the next section.
735
736 7.3. Handling ECS Responses and Caching
737
738 When an Intermediate Nameserver receives a response containing an ECS
739 option and without the TC bit set, it SHOULD cache the result based
740 on the data in the option. If the TC bit was set, the Intermediate
741 Resolver SHOULD retry the query over TCP to get the complete Answer
742 section for caching.
743
744 If FAMILY, SOURCE PREFIX-LENGTH, and SOURCE PREFIX-LENGTH bits of
745 ADDRESS in the response don't match the non-zero fields in the
746 corresponding query, the full response MUST be dropped, as described
747 in Section 11. In a response to a query that specified only SOURCE
748 PREFIX-LENGTH for privacy masking, the FAMILY and ADDRESS fields MUST
749 contain the appropriate non-zero information that the Authoritative
750 Nameserver used to generate the answer, so that it can be cached
751 accordingly.
752
753 If no ECS option is contained in the response, the Intermediate
754 Nameserver SHOULD treat this as being equivalent to having received a
755 SCOPE PREFIX-LENGTH of 0, which is an answer suitable for all client
756 addresses. See further discussion on the security implications of
757 this in Section 11.
758
759 If a REFUSED response is received from an Authoritative Nameserver,
760 an ECS-aware resolver MUST retry the query without ECS to distinguish
761 the response from one where the Authoritative Nameserver is not
762 responsible for the name, which is a common convention for the
763 REFUSED status. Similarly, a client of a Recursive Resolver SHOULD
764
765
766
767 Contavalli, et al. Informational [Page 14]
768 RFC 7871 Client Subnet in DNS Queries May 2016
769
770
771 retry after receiving a REFUSED response because it is not
772 sufficiently clear whether the REFUSED response was because of the
773 ECS option or some other reason.
774
775 7.3.1. Caching the Response
776
777 In the cache, all resource records in the Answer section MUST be tied
778 to the network specified in the response. The appropriate prefix
779 length depends on the relationship between SOURCE PREFIX-LENGTH,
780 SCOPE PREFIX-LENGTH, and the maximum cacheable prefix length
781 configured for the cache.
782
783 If SCOPE PREFIX-LENGTH is not longer than SOURCE PREFIX-LENGTH, store
784 SCOPE PREFIX-LENGTH bits of ADDRESS, and then mark the response as
785 valid for all addresses that fall within that range.
786
787 Similarly, if SOURCE PREFIX-LENGTH is the maximum configured for the
788 cache, store SOURCE PREFIX-LENGTH bits of ADDRESS, and then mark the
789 response as valid for all addresses that fall within that range.
790
791 If SOURCE PREFIX-LENGTH is shorter than the configured maximum and
792 SCOPE PREFIX-LENGTH is longer than SOURCE PREFIX-LENGTH, store SOURCE
793 PREFIX-LENGTH bits of ADDRESS, and then mark the response as valid
794 only to answer client queries that specify exactly the same SOURCE
795 PREFIX-LENGTH in their own ECS option.
796
797 The handling of DNSSEC-related records in the Answer section was
798 unspecified in the original draft version of this document and is
799 inconsistently handled in existing implementations. A Resource
800 Record Signature (RRSIG) must obviously be tied to the RRset that it
801 signs, but it is RECOMMENDED that all other DNSSEC records be scoped
802 at /0. See Section 9 for more information.
803
804 Note that the Additional and Authority sections from a DNS response
805 message are specifically excluded here. Any records from these
806 sections MUST NOT be tied to a network. See Section 7.4 for more
807 information.
808
809 Records that are cached as /0 because of a query's SOURCE PREFIX-
810 LENGTH of 0 MUST be distinguished from those that are cached as /0
811 because of a response's SCOPE PREFIX-LENGTH of 0. The former should
812 only be used for other /0 queries that the Intermediate Resolver
813 receives, but the latter is suitable as a response for all networks.
814
815
816
817
818
819
820
821
822 Contavalli, et al. Informational [Page 15]
823 RFC 7871 Client Subnet in DNS Queries May 2016
824
825
826 Although omitting network-specific caching will significantly
827 simplify an implementation, the resulting drop in cache hits is very
828 likely to defeat most latency benefits provided by ECS. Therefore,
829 implementing full caching support as described in this section is
830 strongly RECOMMENDED.
831
832 Enabling support for ECS in an Intermediate Nameserver will
833 significantly increase the size of the cache, reduce the number of
834 results that can be served from cache, and increase the load on the
835 server. Implementing the mitigation techniques described in
836 Section 11 is strongly recommended. For cache size issues,
837 implementers should consider data storage formats that allow the same
838 answer data to be shared among multiple prefixes.
839
840 7.3.2. Answering from Cache
841
842 Cache lookups are first done as usual for a DNS query, using the
843 query tuple of <name, type, class>. Then, the appropriate RRset MUST
844 be chosen based on the longest prefix matching. The client address
845 to use for comparison will depend on whether the Intermediate
846 Nameserver received an ECS option in its client query.
847
848 o If no ECS option was provided, the client's address is used.
849
850 o If there was an ECS option specifying SOURCE PREFIX-LENGTH and
851 ADDRESS covering the client's address, the client address is used
852 but SOURCE PREFIX-LENGTH is initially ignored. If no covering
853 entry is found and SOURCE PREFIX-LENGTH is shorter than the
854 configured maximum length allowed for the cache, repeat the cache
855 lookup for an entry that exactly matches SOURCE PREFIX-LENGTH.
856 These special entries, which do not cover longer prefix lengths,
857 occur as described in the previous section.
858
859 o If there was an ECS option with an ADDRESS, the ADDRESS from it
860 MAY be used if the local policy allows. The policy can vary
861 depending on the agreements the operator of the Intermediate
862 Nameserver has with Authoritative Nameserver operators; see
863 Section 12.2. If the policy does not allow it, a REFUSED response
864 SHOULD be sent. See Section 7.5 for more information.
865
866 If a matching network is found and the relevant data is unexpired,
867 the response is generated as per Section 7.2.
868
869 If no matching network is found, the Intermediate Nameserver MUST
870 perform resolution as usual. This is necessary to avoid Tailored
871 Responses in the cache from being returned to the wrong clients, and
872
873
874
875
876
877 Contavalli, et al. Informational [Page 16]
878 RFC 7871 Client Subnet in DNS Queries May 2016
879
880
881 to avoid a single query coming from a client on a different network
882 from polluting the cache with a Tailored Response for all the users
883 of that resolver.
884
885 7.4. Delegations and Negative Answers
886
887 The prohibition against tying ECS data to records from the Authority
888 and Additional sections left an unfortunate ambiguity in the original
889 specification, primarily with regard to negative answers. The
890 expectation of the original authors was that ECS would only really be
891 used for address requests and the positive result in the response's
892 Answer section, which was the use case that was driving the
893 definition of the protocol.
894
895 For negative answers, some independent implementations of both
896 resolvers and authorities did not see the section restriction as
897 necessarily meaning that a given name and type must only have either
898 positive ECS-tagged answers or a negative answer. They support being
899 able to tell one part of the network that the data does not exist,
900 while telling another part of the network that it does.
901
902 Several other implementations, however, do not support being able to
903 mix positive and negative answers; thus, interoperability is a
904 problem. It is RECOMMENDED that no specific behavior regarding
905 negative answers be relied upon, but that Authoritative Nameservers
906 should conservatively expect that Intermediate Nameservers will treat
907 all negative answers as /0; therefore, they SHOULD set SCOPE PREFIX-
908 LENGTH accordingly.
909
910 This issue is expected to be revisited in a future revision of the
911 protocol, possibly blessing the mixing of positive and negative
912 answers. There are implications for cache data structures that
913 developers should consider when writing new ECS code.
914
915 The delegations case is a bit easier to tease out. In operational
916 practice, if an authoritative server is using address information to
917 provide customized delegations, it is the resolver that will be using
918 the answer for its next iterative query. Addresses in the Additional
919 section SHOULD therefore ignore ECS data, and the Authoritative
920 Nameserver SHOULD return a zero SCOPE PREFIX-LENGTH on delegations.
921 A Recursive Resolver SHOULD treat a non-zero SCOPE PREFIX LENGTH in a
922 delegation as though it were zero.
923
924
925
926
927
928
929
930
931
932 Contavalli, et al. Informational [Page 17]
933 RFC 7871 Client Subnet in DNS Queries May 2016
934
935
936 7.5. Transitivity
937
938 Generally, ECS options will only be present in DNS messages between a
939 Recursive Resolver and an Authoritative Nameserver, i.e., one hop.
940 However, in certain configurations, for example, multi-tier
941 nameserver setups, it may be necessary to implement transitive
942 behavior on Intermediate Nameservers.
943
944 Any Intermediate Nameserver that forwards ECS options received from
945 its clients MUST fully implement the caching behavior described in
946 Section 7.3.
947
948 An Intermediate Nameserver MAY forward ECS options with address
949 information. This information MAY match the source IP address of the
950 incoming query, and MAY have more or fewer address bits than the
951 nameserver would normally include in a locally originated ECS option.
952 If an Intermediate Nameserver receives a query with SOURCE PREFIX-
953 LENGTH set to 0, it MUST NOT include client address information in
954 queries made to resolve that client's request (see Section 7.1.2).
955
956 If, for any reason, the Intermediate Nameserver does not want to use
957 the information in an ECS option it receives (too little address
958 information, network address from a range not authorized to use the
959 server, private/unroutable address space, etc.), it SHOULD drop the
960 query and return a REFUSED response. Note again that a query MUST
961 NOT be refused solely because it provides 0 address bits.
962
963 Be aware that at least one major existing implementation does not
964 return REFUSED and instead just processes the query as though the
965 problematic information were not present. This can lead to anomalous
966 situations, such as a response from the Intermediate Nameserver that
967 indicates it is tailored for one network (the one passed in the
968 original query, since the ADDRESS must match) when actually it is for
969 another network (the one which contains the address that the
970 Intermediate Nameserver saw as making the query).
971
972 8. IANA Considerations
973
974 IANA has assigned option code 8 in the "DNS EDNS0 Option Codes (OPT)"
975 registry to edns-client-subnet.
976
977 IANA has updated the reference to refer to this RFC.
978
979
980
981
982
983
984
985
986
987 Contavalli, et al. Informational [Page 18]
988 RFC 7871 Client Subnet in DNS Queries May 2016
989
990
991 9. DNSSEC Considerations
992
993 The presence or absence of an EDNS0 OPT resource record ([RFC6891])
994 containing an ECS option in a DNS query does not change the usage of
995 the resource records and mechanisms used to provide data origin
996 authentication and data integrity to the DNS, as described in
997 [RFC4033], [RFC4034], and [RFC4035]. OPT records are not signed.
998
999 Use of this option, however, does imply increased DNS traffic between
1000 any given Recursive Resolver and Authoritative Nameserver, which
1001 could be another barrier to further DNSSEC adoption in this area.
1002
1003 The initial version of this protocol, against which several
1004 Authoritative and Recursive Nameserver implementations were written,
1005 did not discuss the handling of DNSSEC RRs; thus, it is expected that
1006 there are operational inconsistencies in handling them.
1007
1008 Given the intention of this document to describe how ECS is currently
1009 deployed, specifying new requirements for DNSSEC handling is out of
1010 scope. However, some recommendations can be made as to what is most
1011 likely to result in successful interoperation for a DNSSEC-signed ECS
1012 zone, mainly from the point of view of Authoritative Nameservers.
1013
1014 Most DNSSEC records SHOULD be scoped at /0, except for the RRSIG
1015 records, which MUST be tied to the RRset that they sign in a Tailored
1016 Response. While it is possible to conceive of a way to get other
1017 DNSSEC records working in a network-specific way, it has little
1018 apparent benefit or likelihood of working with deployed validating
1019 resolvers.
1020
1021 One further implication here is that, despite the discussion about
1022 negative answers in Section 7.4, scoping NextSECure (NSEC) or NSEC3
1023 records at /0 per the previous paragraph necessarily implies that
1024 DNSSEC-signed negative answers must also be network-invariant.
1025
1026 10. NAT Considerations
1027
1028 Special awareness of ECS in devices that perform Network Address
1029 Translation (NAT) as described in [RFC2663] is not required; queries
1030 can be passed through as is. The client's network address SHOULD NOT
1031 be added, and existing ECS options, if present, SHOULD NOT be
1032 modified by NAT devices.
1033
1034 In large-scale global networks behind a NAT device (but, for example
1035 with Centralized Resolver infrastructure), an internal Intermediate
1036 Nameserver might have detailed network layout information, and may
1037
1038
1039
1040
1041
1042 Contavalli, et al. Informational [Page 19]
1043 RFC 7871 Client Subnet in DNS Queries May 2016
1044
1045
1046 know which external subnets are used for egress traffic by each
1047 internal network. In such cases, the Intermediate Nameserver MAY use
1048 that information when originating ECS options.
1049
1050 In other cases, if a Recursive Resolver knows that it is situated
1051 behind a NAT device, it SHOULD NOT originate ECS options with their
1052 external IP address and instead rely on downstream Intermediate
1053 Nameservers to do so. It MAY, however, choose to include the option
1054 with their internal address for the purposes of signaling its own
1055 limit for SOURCE PREFIX-LENGTH.
1056
1057 Full treatment of special network addresses is beyond the scope of
1058 this document; handling them will likely differ according to the
1059 operational environments of each service provider. As a general
1060 guideline, if an Authoritative Nameserver on the publicly routed
1061 Internet receives a query that specifies an ADDRESS in [RFC1918] or
1062 [RFC4193] private address space, it SHOULD ignore ADDRESS and look up
1063 its answer based on the address of the Recursive Resolver. In the
1064 response, it SHOULD set SCOPE PREFIX-LENGTH to cover all of the
1065 relevant private space. For example, a query for ADDRESS 10.1.2.0
1066 with a SOURCE PREFIX-LENGTH of 24 would get a returned SCOPE PREFIX-
1067 LENGTH of 8. The Intermediate Nameserver MAY elect to cache the
1068 answer under one entry for special-purpose addresses [RFC6890]; see
1069 Section 11.3 of this document.
1070
1071 11. Security Considerations
1072
1073 11.1. Privacy
1074
1075 With the ECS option, the network address of the client that initiated
1076 the resolution becomes visible to all servers involved in the
1077 resolution process. Additionally, it will be visible from any
1078 network traversed by the DNS packets.
1079
1080 To protect users' privacy, Recursive Resolvers are strongly
1081 encouraged to conceal part of the user's IP address by truncating
1082 IPv4 addresses to 24 bits. 56 bits are recommended for IPv6, based on
1083 [RFC6177].
1084
1085 ISPs should have more detailed knowledge of their own networks. That
1086 is, they might know that all 24-bit prefixes in a /20 are in the same
1087 area. In those cases, for optimal cache utilization and improved
1088 privacy, the ISP's Recursive Resolver SHOULD truncate IP addresses in
1089 this /20 to just 20 bits, instead of 24 as recommended above.
1090
1091 Users who wish their full IP address to be hidden need to configure
1092 their client software, if possible, to include an ECS option
1093 specifying the wildcard address (i.e., a SOURCE PREFIX-LENGTH of 0).
1094
1095
1096
1097 Contavalli, et al. Informational [Page 20]
1098 RFC 7871 Client Subnet in DNS Queries May 2016
1099
1100
1101 As described in previous sections, this option will be forwarded
1102 across all the Recursive Resolvers supporting ECS, which MUST NOT
1103 modify it to include the network address of the client.
1104
1105 Note that even without an ECS option, any server queried directly by
1106 the user will be able to see the full client IP address. Recursive
1107 Resolvers or Authoritative Nameservers MAY use the source IP address
1108 of queries to return a cached entry or to generate a Tailored
1109 Response that best matches the query.
1110
1111 11.2. Birthday Attacks
1112
1113 ECS adds information to the DNS query tuple (q-tuple). This allows
1114 an attacker to send a caching Intermediate Nameserver multiple
1115 queries with spoofed IP addresses either in the ECS option or as the
1116 source IP. These queries will trigger multiple outgoing queries with
1117 the same name, type, and class, just with different address
1118 information in the ECS option.
1119
1120 With multiple queries for the same name in flight, the attacker has a
1121 higher chance of success to send a matching response with SCOPE
1122 PREFIX-LENGTH set to 0 to get it cached for all hosts.
1123
1124 To counter this, the ECS option in a response packet MUST contain the
1125 full FAMILY, ADDRESS, and SOURCE PREFIX-LENGTH fields from the
1126 corresponding query. Intermediate Nameservers processing a response
1127 MUST verify that these match, and they SHOULD discard the entire
1128 response if they do not.
1129
1130 The requirement to discard is categorized as "SHOULD" instead of
1131 "MUST" because it stands in opposition to the instruction in
1132 Section 7.3, which states that a response lacking an ECS option
1133 should be treated as though it had one of SCOPE PREFIX-LENGTH of 0.
1134 If that is always true, then an attacker does not need to worry about
1135 matching the original ECS option data and just needs to flood back
1136 responses that have no ECS option at all.
1137
1138 This type of attack could be detected in ongoing operations by
1139 marking whether the responding nameserver had previously been sending
1140 ECS options and/or by taking note of an incoming flood of bogus
1141 responses and flagging the relevant query for re-resolution. This
1142 type of detection is more complex than existing nameserver responses
1143 to spoof floods, and it would also need to be sensitive to a
1144 nameserver legitimately stopping ECS replies even though it had
1145 previously given them.
1146
1147
1148
1149
1150
1151
1152 Contavalli, et al. Informational [Page 21]
1153 RFC 7871 Client Subnet in DNS Queries May 2016
1154
1155
1156 11.3. Cache Pollution
1157
1158 It is simple for an arbitrary resolver or client to provide false
1159 information in the ECS option, or to send UDP packets with forged
1160 source IP addresses.
1161
1162 This could be used to:
1163
1164 o pollute the cache of Intermediate Resolvers by filling it with
1165 results that will rarely (if ever) be used.
1166
1167 o reverse-engineer the algorithms (or data) used by the
1168 Authoritative Nameserver to calculate Tailored Responses.
1169
1170 o mount a denial-of-service attack against an Intermediate
1171 Nameserver by forcing it to perform many more recursive queries
1172 than it would normally do, due to how caching is handled for
1173 queries containing the ECS option.
1174
1175 Even without malicious intent, Centralized Resolvers providing
1176 answers to clients in multiple networks will need to cache different
1177 responses for different networks, putting more memory pressure on the
1178 cache.
1179
1180 To mitigate those problems:
1181
1182 o Recursive Resolvers implementing ECS should only enable it in
1183 deployments where it is expected to bring clear advantages to the
1184 end users, such as when expecting clients from a variety of
1185 networks or from a wide geographical area. Due to the high cache
1186 pressure introduced by ECS, the feature SHOULD be disabled in all
1187 default configurations.
1188
1189 o Recursive Resolvers SHOULD limit the number of networks and
1190 answers they keep in the cache for any given query.
1191
1192 o Recursive Resolvers SHOULD limit the total number of different
1193 networks that they keep in cache.
1194
1195 o Recursive Resolvers MUST NOT send an ECS option with SOURCE
1196 PREFIX-LENGTH providing more bits in ADDRESS than they are willing
1197 to cache responses for.
1198
1199 o Recursive Resolvers should implement algorithms to improve the
1200 cache hit rate, given the size constraints indicated above.
1201 Recursive Resolvers MAY, for example, decide to discard more-
1202 specific cache entries first.
1203
1204
1205
1206
1207 Contavalli, et al. Informational [Page 22]
1208 RFC 7871 Client Subnet in DNS Queries May 2016
1209
1210
1211 o Authoritative Nameservers and Recursive Resolvers should discard
1212 ECS options that are either obviously forged or otherwise known to
1213 be wrong. They SHOULD at least treat unroutable addresses, such
1214 as some of the address blocks defined in [RFC6890], as equivalent
1215 to the Recursive Resolver's own identity. They SHOULD ignore and
1216 never forward ECS options specifying other routable addresses that
1217 are known not to be served by the query source.
1218
1219 o The ECS option is just a hint to Authoritative Nameservers for
1220 customizing results. They can decide to ignore the content of the
1221 ECS option based on blacklists or whitelists, rate-limiting
1222 mechanisms, or any other logic implemented in the software.
1223
1224 12. Sending the Option
1225
1226 When implementing a Recursive Resolver, there are two strategies on
1227 deciding when to include an ECS option in a query. At this stage,
1228 it's not clear which strategy is best.
1229
1230 12.1. Probing
1231
1232 A Recursive Resolver can send the ECS option with every outgoing
1233 query. However, it is RECOMMENDED that resolvers remember which
1234 Authoritative Nameservers did not return the option with their
1235 response and omit client address information from subsequent queries
1236 to those nameservers.
1237
1238 Additionally, Recursive Resolvers SHOULD be configured never to send
1239 the option when querying root, top-level, and effective top-level
1240 (i.e., "public suffix" [Public_Suffix_List]) domain servers. These
1241 domains are delegation-centric and are very unlikely to generate
1242 different responses based on the address of the client.
1243
1244 When probing, it is important that several things are probed: support
1245 for ECS, support for EDNS0, support for EDNS0 options, or possibly an
1246 unreachable nameserver. Various implementations are known to drop
1247 DNS packets with OPT RRs (with or without options), thus several
1248 probes are required to discover what is supported.
1249
1250 Probing, if implemented, MUST be repeated periodically, e.g., daily.
1251 If an Authoritative Nameserver indicates ECS support for one zone, it
1252 is to be expected that the nameserver supports ECS for all of its
1253 zones. Likewise, an Authoritative Nameserver that uses ECS
1254 information for one of its zones MUST indicate support for the option
1255 in all of its responses to ECS queries. If the option is supported
1256 but not actually used for generating a response, its SCOPE PREFIX-
1257 LENGTH MUST be set to 0.
1258
1259
1260
1261
1262 Contavalli, et al. Informational [Page 23]
1263 RFC 7871 Client Subnet in DNS Queries May 2016
1264
1265
1266 12.2. Whitelist
1267
1268 As described previously, it is expected that only a few Recursive
1269 Resolvers will need to use ECS, and that it will generally be enabled
1270 only if it offers a clear benefit to the users.
1271
1272 To avoid the complexity of implementing a probing and detection
1273 mechanism (and the possible query loss/delay that may come with it),
1274 an implementation could use a whitelist of Authoritative Nameservers
1275 to send the option to, likely specified by their domain name.
1276 Implementations MAY also allow additional configuring of this based
1277 on other criteria, such as zone or query type. As of the time of
1278 this writing, at least one implementation makes use of a whitelist.
1279
1280 An advantage of using a whitelist is that partial client address
1281 information is only disclosed to nameservers that are known to use
1282 the information, improving privacy.
1283
1284 A drawback is scalability. The operator needs to track which
1285 Authoritative Nameservers support ECS, making it harder for new
1286 Authoritative Nameservers to start using the option.
1287
1288 Similarly, Authoritative Nameservers can also use whitelists to limit
1289 the feature to only certain clients. For example, a CDN that does
1290 not want all of their mapping trivially walked might require a legal
1291 agreement with the Recursive Resolver operator, to clearly describe
1292 the acceptable use of the feature.
1293
1294 The maintenance of access control mechanisms is out of scope for this
1295 protocol definition.
1296
1297 13. Example
1298
1299 1. A Stub Resolver, SR, with the IP address
1300 2001:0db8:fd13:4231:2112:8a2e:c37b:7334 tries to resolve
1301 www.example.com by forwarding the query to the Recursive
1302 Resolver, RNS, asking for recursion.
1303
1304 2. RNS, supporting ECS, looks up www.example.com in its cache. An
1305 entry is found neither for www.example.com nor for example.com.
1306
1307 3. RNS builds a query to send to the root and .com servers. The
1308 implementation of RNS provides facilities so that an
1309 administrator can configure it not to forward ECS in certain
1310 cases. In particular, RNS is configured not to include an ECS
1311 option when talking to Top-Level-Domain or root nameservers, as
1312 described in Section 7.1. Thus, no ECS option is added, and
1313 resolution is performed as usual.
1314
1315
1316
1317 Contavalli, et al. Informational [Page 24]
1318 RFC 7871 Client Subnet in DNS Queries May 2016
1319
1320
1321 4. RNS now knows the next server to query: the Authoritative
1322 Nameserver, ANS, responsible for example.com.
1323
1324 5. RNS prepares a new query for www.example.com, including an ECS
1325 option with:
1326
1327 * OPTION-CODE set to 8.
1328
1329 * OPTION-LENGTH set to 0x00 0x0b for the following fixed 4
1330 octets plus the 7 octets that will be used for ADDRESS.
1331
1332 * FAMILY set to 0x00 0x02, as IP is an IPv6 address.
1333
1334 * SOURCE PREFIX-LENGTH set to 0x38, as RNS is configured to
1335 conceal the last 72 bits of every IPv6 address.
1336
1337 * SCOPE PREFIX-LENGTH set to 0x00, as specified by this
1338 document for all queries.
1339
1340 * ADDRESS set to 0x20 0x01 0x0d 0xb8 0xfd 0x13 0x42, providing
1341 only the first 56 bits of the IPv6 address.
1342
1343 6. The query is sent. ANS understands and uses ECS. It parses the
1344 ECS option, and generates a Tailored Response.
1345
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
the Internet Software Consortium
Internet Systems Consortium
ISC (no "the") was originally founded as Internet Software Consortium, Inc. in 1994 but it has been known as Internet Systems Consortium, Inc. since 2004. --VERIFIER NOTES-- Internet Software Consortium occurs only in the acknowledgements and while incorrect now it is generally the perogative of the authors to include in this section what they see fit. were a future version to be updated it's acknowledgements would probably include the then current contributors not the previous ones.
1346 7. Due its internal implementation, ANS finds a response that is
1347 tailored for the whole /16 of the client that performed the
1348 query.
1349
1350 8. ANS adds an ECS option in the response, containing:
1351
1352 * OPTION-CODE set to 8.
1353
1354 * OPTION-LENGTH set to 0x00 0x07.
1355
1356 * FAMILY set to 0x00 0x02.
1357
1358 * SOURCE PREFIX-LENGTH set to 0x38, copied from the query.
1359
1360 * SCOPE PREFIX-LENGTH set to 0x30, indicating a /48 network.
1361
1362 * ADDRESS set to 0x20 0x01 0x0d 0xb8 0xfd 0x13 0x42, copied
1363 from the query.
1364
1365 9. RNS receives the response containing an ECS option. It verifies
1366 that FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS match the query.
1367 If not, the message is discarded.
1368
1369
1370
1371
1372 Contavalli, et al. Informational [Page 25]
1373 RFC 7871 Client Subnet in DNS Queries May 2016
1374
1375
1376 10. The response is interpreted as usual. Since the response
1377 contains an ECS option, ADDRESS, SCOPE PREFIX-LENGTH, and FAMILY
1378 in the response are used to cache the entry.
1379
1380 11. RNS sends a response to Stub Resolver, SR, without including an
1381 ECS option.
1382
1383 12. RNS receives another query to resolve www.example.com. This
1384 time, a response is cached. The response, however, is tied to a
1385 particular network. If the client's address matches any network
1386 in the cache, then the response is returned from the cache.
1387 Otherwise, another query is performed. If multiple results
1388 match, the one with the longest SCOPE PREFIX-LENGTH is chosen,
1389 as per common best-network-match algorithms.
1390
1391 14. References
1392
1393 14.1. Normative References
1394
1395 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
1396 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
1397 <http://www.rfc-editor.org/info/rfc1034>.
1398
1399 [RFC1035] Mockapetris, P., "Domain Names - Implementation and
1400 Specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
1401 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
1402
1403 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
1404 DOI 10.17487/RFC1700, October 1994,
1405 <http://www.rfc-editor.org/info/rfc1700>.
1406
1407 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
1408 and E. Lear, "Address Allocation for Private Internets",
1409 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
1410 <http://www.rfc-editor.org/info/rfc1918>.
1411
1412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1413 Requirement Levels", BCP 14, RFC 2119,
1414 DOI 10.17487/RFC2119, March 1997,
1415 <http://www.rfc-editor.org/info/rfc2119>.
1416
1417 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1418 Rose, "DNS Security Introduction and Requirements",
1419 RFC 4033, DOI 10.17487/RFC4033, March 2005,
1420 <http://www.rfc-editor.org/info/rfc4033>.
1421
1422
1423
1424
1425
1426
1427 Contavalli, et al. Informational [Page 26]
1428 RFC 7871 Client Subnet in DNS Queries May 2016
1429
1430
1431 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1432 Rose, "Resource Records for the DNS Security Extensions",
1433 RFC 4034, DOI 10.17487/RFC4034, March 2005,
1434 <http://www.rfc-editor.org/info/rfc4034>.
1435
1436 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1437 Rose, "Protocol Modifications for the DNS Security
1438 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
1439 <http://www.rfc-editor.org/info/rfc4035>.
1440
1441 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
1442 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
1443 <http://www.rfc-editor.org/info/rfc4193>.
1444
1445 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
1446 Assignment to End Sites", BCP 157, RFC 6177,
1447 DOI 10.17487/RFC6177, March 2011,
1448 <http://www.rfc-editor.org/info/rfc6177>.
1449
1450 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
1451 "Special-Purpose IP Address Registries", BCP 153,
1452 RFC 6890, DOI 10.17487/RFC6890, April 2013,
1453 <http://www.rfc-editor.org/info/rfc6890>.
1454
1455 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
1456 for DNS (EDNS(0))", STD 75, RFC 6891,
1457 DOI 10.17487/RFC6891, April 2013,
1458 <http://www.rfc-editor.org/info/rfc6891>.
1459
1460 14.2. Informative References
1461
1462 [Address_Family_Numbers]
1463 IANA, "Address Family Numbers",
1464 <http://www.iana.org/assignments/address-family-numbers>.
1465
1466 [DPRIVE_Working_Group]
1467 IETF, "PNS PRIVate Exchange (dprive) DPRIVE Working
1468 Group", 2015,
1469 <https://datatracker.ietf.org/wg/dprive/charter/>.
1470
1471 [METADATA]
1472 Hardie, T., Ed., "Design considerations for Metadata
1473 Insertion", Work in Progress, draft-hardie-privsec-
1474 metadata-insertion-02, March 2016.
1475
1476 [Public_Suffix_List]
1477 "Public Suffix List", <https://publicsuffix.org/>.
1478
1479
1480
1481
1482 Contavalli, et al. Informational [Page 27]
1483 RFC 7871 Client Subnet in DNS Queries May 2016
1484
1485
1486 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
1487 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
1488 <http://www.rfc-editor.org/info/rfc2308>.
1489
1490 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
1491 Translator (NAT) Terminology and Considerations",
1492 RFC 2663, DOI 10.17487/RFC2663, August 1999,
1493 <http://www.rfc-editor.org/info/rfc2663>.
1494
1495 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
1496 Terminology", RFC 7719, DOI 10.17487/RFC7719, December
1497 2015, <http://www.rfc-editor.org/info/rfc7719>.
1498
1499 [VANDERGAAST]
1500 Contavalli, C., Gaast, W., Leach, S., and E. Lewis,
1501 "Client Subnet in DNS Requests", Work in Progress,
1502 draft-vandergaast-edns-client-subnet-02, July 2013.
1503
1504 Acknowledgements
1505
1506 The authors wish to thank Darryl Rodden for his work as a co-author,
1507 and the following people for reviewing this document and for
1508 providing useful feedback: Paul S. R. Chisholm, B. Narendran,
1509 Leonidas Kontothanassis, David Presotto, Philip Rowlands, Chris
1510 Morrow, Kara Moscoe, Alex Nizhner, Warren Kumari, and Richard Rabbat
1511 from Google; Terry Farmer, Mark Teodoro, Edward Lewis, and Eric
1512 Burger from Neustar; David Ulevitch and Matthew Dempsky from OpenDNS;
1513 Patrick W. Gilmore and Steve Hill from Akamai; Colm MacCarthaigh and
1514 Richard Sheehan from Amazon; Tatuya Jinmei from Infoblox; Andrew
1515 Sullivan from Dyn; John Dickinson from Sinodun; Mark Delany from
1516 Apple; Yuri Schaeffer from NLnet Labs; Duane Wessels Verisign;
1517 Antonio Querubin; Daniel Kahn Gillmor from the ACLU; Evan Hunt and
1518 Mukund Sivaraman from the Internet Software Consortium; Russ Housley
1519 from Vigilsec; Stephen Farrell from Trinity College Dublin; Alissa
1520 Cooper from Cisco; Suzanne Woolf; and all of the other people that
1521 replied to our emails on various mailing lists.
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537 Contavalli, et al. Informational [Page 28]
1538 RFC 7871 Client Subnet in DNS Queries May 2016
1539
1540
1541 Contributors
1542
1543 The individuals below contributed significantly to this document.
1544
1545 Edward Lewis
1546 ICANN
1547 12025 Waterfront Drive, Suite 300
1548 Los Angeles, CA 90094-2536
1549 United States
1550
1551 Email: edward.lewis@icann.org
1552
1553
1554 Sean Leach
1555 Fastly
1556 P.O. Box 78266
1557 San Francisco, CA 94107
1558 United States
1559
1560
1561 Jason Moreau
1562 Akamai Technologies
1563 150 Broadway
1564 Cambridge, MA 02142-1413
1565 United States
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592 Contavalli, et al. Informational [Page 29]
1593 RFC 7871 Client Subnet in DNS Queries May 2016
1594
1595
1596 Authors' Addresses
1597
1598 Carlo Contavalli
1599 Google
1600 1600 Amphitheater Parkway
1601 Mountain View, CA 94043
1602 United States
1603
1604 Email: ccontavalli@google.com
1605
1606
1607 Wilmer van der Gaast
1608 Google
1609 Belgrave House, 76 Buckingham Palace Road
1610 London SW1W 9TQ
1611 United Kingdom
1612
1613 Email: wilmer@google.com
1614
1615
1616 David C Lawrence
1617 Akamai Technologies
1618 150 Broadway
1619 Cambridge, MA 02142-1054
1620 United States
1621
1622 Email: tale@akamai.com
1623
1624
1625 Warren Kumari
1626 Google
1627 1600 Amphitheatre Parkway
1628 Mountain View, CA 94043
1629 United States
1630
1631 Email: warren@kumari.net
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647 Contavalli, et al. Informational [Page 30]
1648
7. Due its internal implementation, ANS finds a response that is
tailored for the whole /16 of the client that performed the
query.
8. ANS adds an ECS option in the response, containing:
[...]
* SCOPE PREFIX-LENGTH set to 0x30, indicating a /48 network.
7. Due its internal implementation, ANS finds a response that is
tailored for the whole /1648 of the client that performed the
query.
8. ANS adds an ECS option in the response, containing:
[...]
* SCOPE PREFIX-LENGTH set to 0x30, indicating a /48 network.