dnsop                                                      C. Contavalli
Internet-Draft                                          W. van der Gaast
Intended status: Informational                                    Google
Expires: May 19, November 27, 2015                                   D. Lawrence
                                                     Akamai Technologies
                                                               W. Kumari
                                                                  Google
                                                       November 15, 2014
                                                            May 26, 2015

                      Client Subnet in DNS Requests
                 draft-ietf-dnsop-edns-client-subnet-00 Querys
                 draft-ietf-dnsop-edns-client-subnet-01

Abstract

   This draft defines an EDNS0 extension to carry information about the
   network that originated a DNS query, and the network for which the
   subsequent reply response can be cached.

IESG Note

   [RFC Editor: Please remove this note prior to publication ]

   This informational document describes an existing, implemented and
   deployed system.  A subset of the operators using this is at
   http://www.afasterinternet.com/participants.htm . The authors believe
   that it is better to document this system (even if not everyone
   agrees with the concept) than leave it undocumented and proprietary.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 19, November 27, 2015.

Copyright Notice

   Copyright (c) 2014 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4   5
   5.  Option Format . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Protocol Description  . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Originating the Option  . . . . . . . . . . . . . . . . .   7
       6.1.1.  Recursive Resolvers . . . . . . . . . . . . . . . . .   7
       6.1.2.  Stub Resolvers  . . . . . . . . . . . . . . . . . . .   8
       6.1.3.  Forwarders  . . . . . . . . . . . . . . . . . . . . .   9
     6.2.  Generating a Response . . . . . . . . . . . . . . . . . .   8   9
       6.2.1.  Authoritative Nameserver  . . . . . . . . . . . . . .   9
       6.2.2.  Intermediate Nameserver . . . . . . . . . . . . . . .  10
     6.3.  Handling edns-client-subnet Replies ECS Responses and Caching  . . . . .   9 . . . . . .  11
       6.3.1.  Caching the Response  . . . . . . . . . . . . . . . .  11
       6.3.2.  Answering from Cache  . . . . . . . . . . . . . . . .  12
     6.4.  Delegations and Negative Answers  . . . . . . . . . . . .  13
     6.5.  Transitivity  . . . . . . . . . . . . . . . . . . . . . .  11  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12  14
   8.  DNSSEC Considerations . . . . . . . . . . . . . . . . . . . .  12  14
   9.  NAT Considerations  . . . . . . . . . . . . . . . . . . . . .  12  15
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  13  15
     10.1.  Privacy  . . . . . . . . . . . . . . . . . . . . . . . .  13  15
     10.2.  Birthday Attacks . . . . . . . . . . . . . . . . . . . .  14  16
     10.3.  Cache Pollution  . . . . . . . . . . . . . . . . . . . .  14  17
   11. Sending the Option  . . . . . . . . . . . . . . . . . . . . .  16  18
     11.1.  Probing  . . . . . . . . . . . . . . . . . . . . . . . .  16  18
     11.2.  Whitelist  . . . . . . . . . . . . . . . . . . . . . . .  16  19
   12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . .  17  19
   13. Contributing Authors  . . . . . . . . . . . . . . . . . . . .  19  21
   14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19  21
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19  22
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  19  22
     15.2.  Informative References . . . . . . . . . . . . . . . . .  20  23
     15.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  20  23
   Appendix A.  Document History . . . . . . . . . . . . . . . . . .  20  23
     A.1.  -00 . . . . . . . . . . . . . . . . . . . . . . . . . . .  20  24
     A.2.  -01 . . . . . . . . . . . . . . . . . . . . . . . . . . .  21  25
     A.3.  -02 . . . . . . . . . . . . . . . . . . . . . . . . . . .  22
     A.4.  -03*  . . . . . . . . . . . . . . . . . . . . . . . . . .  22  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22  26

1.  Introduction

   Many Authoritative Nameservers today return different replies responses based
   on the perceived topological location of the user.  These servers use
   the IP address of the incoming query to identify that location.
   Since most queries come from intermediate Recursive Resolvers, the
   source address is that of the Recursive Resolver rather than of the
   query originator.

   Traditionally, and probably still in the majority of instances,
   Recursive Resolvers are reasonably close in the network topology topological sense to
   the Stub Resolvers or Forwarders that are the source of queries.  For
   these resolvers, using their own IP address is sufficient for
   authority servers that tailor responses based upon location of the
   querier.

   Increasingly, though, a class of Recursive Resolvers has arisen that
   handle query sources that are often not topologically close.  The
   motivation for a user to configure such a Centralized Resolver varies
   but is usually because of some enhanced experience, such as greater
   cache security or applying policies regarding where users may
   connect.  (Although political censorship usually comes to mind here,
   the same actions may be used by a parent when setting controls on
   where a minor may connect.)  Similarly, many ISPs and other
   organizations use a Centralized Resolver infrastructure that can be
   distant from the clients the resolvers serve.  The  These cases all lead
   to less than optimal replies desirable responses from topology-sensitive
   Authoritative Nameservers.

   This draft defines an EDNS0 [RFC6891] option to convey network
   information that is relevant to the DNS message.  It will carry
   sufficient network information about the originator for the
   Authoritative Nameserver to tailor responses.  It will also provide
   for the Authoritative Nameserver to indicate the scope of network
   addresses for which the tailored answer is intended.  This EDNS0
   option is intended for those recursive and authority servers that
   would benefit from the extension and not for general purpose
   deployment.  It is completely optional and can safely be ignored by
   servers that choose not to implement it or enable it.

   This draft also includes guidelines on how to best cache those
   results and provides recommendations on when this protocol extension
   should be used.

2.  Requirements Notation

   The key words "MUST", "MUST

   At least a dozen different client and server implementations had been
   written based on the original specification, first known as draft-
   vandergaast-edns-client-subnet.  While they interoperate for the
   primary goal, they have varying behaviour around poorly specified
   edge cases.  Known incompatibilities will be described.

2.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Terminology

   ECS  EDNS Client Subnet.

   Client  A Stub Resolver, Forwarder or Recursive Resolver.  A client
      to a Recursive Resolver or a Forwarder.

   Server  A Forwarder, Recursive Resolver or Authoritative Nameserver.

   Stub Resolver:  A simple DNS protocol implementation on the client
      side as described in [RFC1034] section 5.3.1.  A client to a
      Recursive Resolver or a Forwarder.

   Authoritative Nameserver:  A nameserver that has authority over one
      or more DNS zones.  These are normally not contacted by Stub
      Resolver or end user clients directly but by Recursive Resolvers.
      Described in [RFC1035]
      chapter Section 6.

   Recursive Resolver:  A nameserver that is responsible for resolving
      domain names for clients by following the domain's delegation
      chain.  Recursive Resolvers frequently use caches to be able to
      respond to client queries quickly.  Described in [RFC1035] chapter
      Section 7.

   Intermediate Nameserver:  Any nameserver (possibly a Recursive
      Resolver) in between the Stub Resolver and the Authoritative
      Nameserver.

   Centralized Resolvers:  Recursive Resolvers that serve a
      topologically diverse network address space.

   Optimized Reply:

   Tailored Response:  A reply response from a nameserver that is optimized customized
      for the node that sent the request, normally query, often based on performance (i.e.
      lowest latency, least number of hops, topological distance, ...).

   Topologically Close:  Refers to two hosts being close in terms of
      number of hops or time it takes for a packet to travel from one
      host to the other.  The concept of topological distance is only
      loosely related to the concept of geographical distance: two
      geographically close hosts can still be very distant from a
      topological perspective, and two geographically distant hosts can
      be quite close on the network.

4.  Overview

   The general idea of this document is to provide an EDNS0 option to
   allow Recursive Resolvers, if they are willing, to forward details
   about the origin network from which a query is coming when talking to
   Authoritative
   other Nameservers.

   The format of this option is described in Section 5, and is meant to
   be added in queries sent by Intermediate Nameservers in a way
   transparent to Stub Resolvers and end users, as described in
   Section 6.1.  ECS is only defined for the Internet (IN) DNS class.

   As described in Section 6.2, an Authoritative Nameserver could use
   this EDNS0 option as a hint to better locate the network of the end
   user and provide a better answer.

   Its reply response would also contain an edns-client-subnet (ECS) option,
   clearly indicating that the server made use of this information, and
   that the answer is tied to the network of the client.

   As described in Section 6.3, Intermediate Nameservers would use this
   information to cache the reply. response.

   Some Intermediate Nameservers may also have to be able to forward
   edns-client-subnet ECS
   queries they receive.  This is described in Section 6.4. 6.5.

   The mechanisms provided by edns-client-subnet ECS raise various security related
   concerns, related to cache growth, the ability to spoof EDNS0
   options, and privacy.  Section 10 explores various mitigation
   techniques.

   The expectation, however, is that this option will only be used by
   Recursive Resolvers and Authoritative Nameservers that incur
   geolocation issues.

   Most Recursive Resolvers, Authoritative Nameservers and Stub
   Resolvers will never know about this option, and will continue
   working as they had been.

   Failure to support this option or its improper handling will, at
   worst, cause suboptimal identification of client location, which is a
   common occurrence in current content delivery network (CDN) setups
   and not a cause of concern. setups.

   Section 6.1 also provides a mechanism for Stub Resolvers to signal
   Recursive Resolvers that they do not want edns-client-subnet ECS treatment for specific requests.
   queries.

   Additionally, operators of Intermediate Nameservers with edns-client-
   subnet ECS enabled
   are allowed to choose how many bits of the address of received
   queries to forward, or to reduce the number of bits forwarded for
   queries already including an edns-client-subnet ECS option.

5.  Option Format

   This draft uses an EDNS0 [RFC6891]) option to include client address
   information in DNS messages.  The option is structured as follows:

                +0 (MSB)                            +1 (LSB)
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   0: |                          OPTION-CODE                          |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   2: |                         OPTION-LENGTH                         |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   4: |                            FAMILY                             |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   6: |     SOURCE NETMASK PREFIX-LENGTH      |     SCOPE NETMASK PREFIX-LENGTH       |
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   7: |                           ADDRESS...                          /
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   o  (Defined in [RFC6891]) OPTION-CODE, 2 octets, for edns-client-
      subnet ECS is 8 (0x00
      0x08).

   o  (Defined in [RFC6891]) OPTION-LENGTH, 2 octets, contains the
      length of the payload (everything after OPTION-LENGTH) in octets.

   o  FAMILY, 2 octets, indicates the family of the address contained in
      the option, using address family codes as assigned by IANA in
      IANA-AFI [2].

   The format of the address part depends on the value of FAMILY.  This
   document only defines the format for FAMILY 1 (IP version 4) and 2
   (IP version 6), which are as follows:

   o  SOURCE NETMASK, PREFIX-LENGTH, an unsigned octet representing the length leftmost
      significant bits of the
      netmask pertaining ADDRESS to be used for the query. lookup.  In replies,
      responses, it mirrors the same value as in the requests.  It can be set to 0 to disable client-
      based lookups, in which case the ADDRESS field MUST be absent. queries.

   o  SCOPE NETMASK, PREFIX-LENGTH, an unsigned octet representing the length leftmost
      significant bits of ADDRESS that the
      netmask pertaining to the reply. response covers.  In requests, it SHOULD be set to
      the longest cacheable length supported by the Intermediate
      Nameserver.  For backwards compatibiilty with draft versions of
      this specification, in requests queries,
      it MAY MUST be set to 0 to have the
      Authoritative Nameserver treat the longest cacheable length as the
      SOURCE NETMASK length.  In responses, this field is set by the
      Authoritative Nameserver to indicate the coverage of the response.
      It might or might not match SOURCE NETMASK; it could be shorter or
      longer. 0.

   o  ADDRESS, variable number of octets, contains either an IPv4 or
      IPv6 address, depending on FAMILY, truncated in the request to the number of bits
      indicated by the SOURCE NETMASK PREFIX-LENGTH field, with bits set to 0 to
      pad up to the end of the last octet used.  (This need
      not be as many needed.  Trailing all-zero octets as a complete address would take.)  In the
      reply, if the SCOPE NETMASK of the request was 0 then ADDRESS must
      contain the same octets as in the request.  Otherwise, the bits
      for ADDRESS will be significant through the maximum of the SOURCE
      NETMASK or SCOPE NETMASK, and 0 filled to the end of an octet.

   All fields are
      SHOULD be omitted.

   All fields are in network byte order ("big-endian", per [RFC1700],
   Data Notation).

6.  Protocol Description

6.1.  Originating the Option

   The edns-client-subnet ECS option should generally be added by Recursive Resolvers when
   querying other servers, Authoritative Nameservers, as described in Section 11.

   In this option, the server should include the IP address of the
   client that caused the query to  The
   option can also be generated, truncated to the number
   of bits specified in the SOURCE NETMASK field.

   A initialized by a Stub Resolver MAY generate DNS queries with an edns-client-subnet
   option with SOURCE NETMASK set to 0 (i.e. 0.0.0.0/0) to indicate that
   the or Forwarder.

6.1.1.  Recursive Resolver MUST NOT add address information Resolvers

   The setup of the client
   to its queries.  The subsequent ECS option in a Recursive Resolver depends on the
   client query to that triggered the
   Authoritative Nameserver will then either not include an edns-client-
   subnet resolution process.

   In the usual case, where no ECS option or MAY optionally include its own address information,
   which is what was present in the Authoritative Nameserver will use anyway to
   generate client
   query, the reply in lieu of no option.  This allows Recursive Resolver initializes the answer to
   be handled option by setting the same caching mechanism as other requests, with an
   explicit indicator
   FAMILY of the applicable scope.  Subsequent Stub Resolver
   requests for /0 can client's address.  It then be answered from this cached response.

   The Stub Resolver may also add non-empty edns-client-subnet options
   to uses the value of its queries, but Recursive Resolvers are not required
   maximum cacheable prefix length to use this
   information. set SOURCE PREFIX-LENGTH.  For
   privacy reasons, and because the whole IP address is rarely required
   to determine an optimized reply, the ADDRESS field in the
   option a tailored response, this length SHOULD be truncated to a certain number of bits, chosen by the
   administrators of shorter than
   the Intermediate Nameserver, full address, as described in Section 10.

   If the Stub Resolver requests additional privacy via a SOURCE NETMASK
   that is shorter than the maximum cacheable SCOPE NETMASK that the
   Recursive Resolver allows, the Recursive Resolver SHOULD issue the
   query with its longer SCOPE NETMASK.

6.2.  Generating a Response

   When a triggering query containing an edns-client-subnet option is received, an
   Authoritative Nameserver supporting edns-client-subnet MAY use the
   address information specified in the option in order to generate included an
   optimized reply.

   Authoritative Nameservers that have not implemented or enabled
   support for the edns-client-subnet ECS option may safely ignore itself, it within
   incoming queries.  Per [RFC6891] section 6.1.2, such a server MUST
   NOT include an edns-client-subnet option within replies, to indicate
   lack of support for the option.

   Requests with wrongly formatted options (e.g., wrong size) MUST be
   rejected and a FORMERR response
   examined for its SOURCE PREFIX-LENGTH.  The Recursive Resolver's
   outgoing query MUST be returned then set SOURCE PREFIX-LENGTH to the sender, as
   described by [RFC6891], Transport Considerations.

   If shorter of
   the Authoritative Nameserver decides to use information from incoming query's SOURCE PREFIX-LENGTH or the
   edns-client-subnet option server's maximum
   cacheable prefix length.

   Finally, in both cases, SCOPE PREFIX-LENGTH is set to calculate a response, it MUST include 0 and the option in
   ADDRESS is then added up to the response SOURCE PREFIX-LENGTH number of bits,
   with trailing 0 bits added, if needed, to indicate that fill the information was final octet.  The
   total number of octets used
   and SHOULD should only be cached accordingly.  If enough to cover SOURCE
   PREFIX-LENGTH bits, rather than the option was not included in
   a query, it MUST NOT full width that would normally be included
   used by addresses in the response.

   The FAMILY.

   FAMILY and SOURCE NETMASK in ADDRESS information MAY be used from the response MUST match those in ECS option
   incoming query.  Passing the
   request.  The first SOURCE NETMASK bits existing address data is supportive of
   the ADDRESS in Recursive Resolver being used as the
   response MUST match those in the request, even if fewer bits were
   used target of a Forwarder, but
   could possibly run into policy problems with regard to form the response.  Echoing back usage
   agreements between the address Recursive Resolver and netmask
   helps to mitigate certain attack vectors, as described in Authoritative
   Namserver.  See Section 10.

   The SCOPE NETMASK in the reply indicates the netmask of the network 11.2 for which the answer is intended.

   A SCOPE NETMASK value longer than more discussion on this point.  If
   the SOURCE NETMASK indicates that Recursive Resolver will not forward the address FAMILY and netmask provided in ADDRESS data
   from the query was not specific enough
   to select incoming ECS option, it SHOULD return a single, best REFUSED response.  The ADDRESS MUST be extended to
   SCOPE NETMASK significant bits
   [*dcl* -- discussion of existing implementations]

   Subsequent queries to indicate refresh the network for which it
   is optimal, but data MUST, if unrestricted by an
   incoming SOURCE PREFIX-LENGTH, specify the longest SOURCE PREFIX-
   LENGTH that the Recursive Resolver SHOULD still provide the
   result as the answer is willing to the triggering client request cache, even if the
   client is in a different address range.

   Conversely,
   previous response indicated that a shorter SCOPE NETMASK indicates prefix length was
   sufficient.

6.1.2.  Stub Resolvers

   A Stub Resolver MAY generate DNS queries with an ECS option set to
   indicate its own level of privacy via SOURCE PREFIX-LENGTH.  An
   Intermediate Nameserver that receives such a query MUST NOT make
   queries that include more bits than
   necessary were provided, and the answer is suitable for a broader
   range of addresses.

   If a non-zero SCOPE NETMASK was supplied client address than in the request, the SCOPE
   NETMASK
   originating query.

   A SOURCE PREFIX-LENGTH of 0 means the response Recursive Resolver MUST be no longer than the SCOPE NETMASK NOT add
   address information of the request.

   As not all netblocks are client to its queries.  The subsequent
   Recursive Resolver query to the same size, an Authoritative Nameserver
   may return different values of SCOPE NETMASK for different networks.

   In both cases, will then
   either not include an ECS option or MAY optionally include its own
   address information, which is what the value Authoritative Nameserver will
   almost certainly use to generate any Tailored Response in lieu of an
   option.  This allows the SCOPE NETMASK in answer to be handled by the reply has strong
   implications same caching
   mechanism as other queries, with regard to how an explicit indicator of the reply will
   applicable scope.  Subsequent Stub Resolver queries for /0 can then
   be answered from this cached by response.

   A Stub Resolver MUST set SCOPE PREFIX-LENGTH to 0.  It MAY include
   FAMILY and ADDRESS data, but should be prepared to handle a REFUSED
   response if the Intermediate Nameservers, as described in Section 6.3. Nameserver that it queries has a policy
   that denies forwarding of the ADDRESS.  If there is no ADDRESS set,
   FAMILY MUST be set to 0.

6.1.3.  Forwarders

   Forwarders essentially appear to be Stub Resolvers to whatever
   Recursive Resolver is ultimately handling the edns-client-subnet query, but look like a
   Recursive Resolver to their client.  A Forwarder using this option
   MUST prepare it as described in the request is not used at all, Section 6.1.1 section above.  In
   particular, a
   server supporting edns-client-subnet MUST indicate Forwarder that no bits of
   the ADDRESS implements this protocol MUST honor
   SOURCE PREFIX-LENGTH restrictions indicated in the request have been used by specifying incoming query
   from its client.  See also Section 6.5.

   Since the Recursive Resolver it contacts will essentially treat it as
   a SCOPE
   NETMASK of 0, equivalent to Stub Resolver, the networks 0.0.0.0/0 or ::/0.  This
   could happen, Forwarder must be prepared for example, because the reply is invariant across a REFUSED
   response if the
   network space. Recursive Resolver does not permit incoming ADDRESS
   information.  The answer Forwarded MUST retry with FAMILY and ADDRESS set to
   0.

6.2.  Generating a Response

6.2.1.  Authoritative Nameserver

   When a query containing an ECS option is suitable for all clients received, an Authoritative
   Nameserver supporting ECS MAY use the address information specified
   in the option in order to generate a tailored response.

   Authoritative Nameservers that have not implemented or enabled
   support for the
   duration ECS option ought to safely ignore it within incoming
   queries, per [RFC6891] section 6.1.2.  Such a server MUST NOT include
   an ECS option within replies, to indicate lack of its TTL.

   The specific logic support for it.
   Implementers of Intermediate Nameservers should be aware, however,
   that some nameservers incorrectly echo back unknown EDNS0 options.
   In this protocol that should be mostly harmless, as SCOPE PREFIX-
   LENGTH should come back as 0, thus marking the response as covering
   all networks.

   A query with a wrongly formatted option (e.g., an unknown FAMILY)
   MUST be rejected and a FORMERR response MUST be returned to the
   sender, as described by [RFC6891], Transport Considerations.

   An Authoritative Nameserver uses that implements this protocol and
   receives an ECS option MUST include an ECS option in its response to
   indicate that it SHOULD be cached accordingly, regardless of whether
   the client information was needed to choose formulate an
   optimized reply is not in answer.  (Note that
   the scope of this document.  Implementers
   are encouraged, however, [RFC6891] requirement to consider carefully their selection of
   SCOPE NETMASK reserve space for the reply in the event OPT record could
   mean that an optimal reply cannot the answer section of the response will be determined.

6.3.  Handling edns-client-subnet Replies truncated and Caching

   When
   fallback to TCP indicated accordingly.)  If an Intermediate Nameserver receives ECS option was not
   included in a reply containing an edns-
   client-subnet option, it will return query, one MUST NOT be included in the response even if
   the server is providing a reply to its client and SHOULD
   cache Tailored Response -- presumably based on
   the result.

   If address from which it received the query.

   The FAMILY, SOURCE NETMASK, PREFIX-LENGTH and SOURCE NETMASK bits of ADDRESS in the reply don't response MUST
   match the fields those in the corresponding request, the
   full reply MUST be dropped, query.  Echoing back these values helps to
   mitigate certain attack vectors, as described in Section 10.

   In the cache, any resource record

   The SCOPE PREFIX-LENGTH in the response indicates the network for
   which the answer section will be tied is intended.

   A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH
   indicates that the provided prefix length was not specific enough to
   select the most appropriate Tailored Response.  Future queries for
   the name within the network specified by network SHOULD use the FAMILY, ADDRESS and longer SCOPE NETMASK
   fields, as detailed below.  Note
   PREIX-LENGTH.

   Conversely, a shorter SCOPE PREFIX-LENGTH indicates that the additional more bits
   than necessary were provided, and authority
   sections from the answer is suitable for a DNS response message are specifically excluded here.
   Any information cached from these sections MUST NOT
   broader range of addresses.  This could be tied as short as 0, to indicate
   that the answer is suitable for all addresses in FAMILY.

   As the logical topology of any part of the network with regard to a
   network.

   If another query is received matching the name and type
   tailored response can vary, an Authoritative Nameserver may return
   different values of SCOPE PREFIX-LENGTH for different networks.

   The specific logic that an entry Authoritative Nameserver uses to choose a
   tailored response is not in the cache, the resolver will check whether the FAMILY and ADDRESS scope of the client matches one this document.  Implementers
   are encouraged, however, to consider carefully their selection of
   SCOPE PREFIX-LENGTH for the networks response in the cache for event that
   entry. the best
   tailored response cannot be determined.  [Open issue: This seems so
   very vague; More text here about possible strategy?]

   If the address Authoritative Nameserver operator configures a more specific
   (longer prefix length) Tailored Response within a configured less
   specific (shorter prefix length) Tailored Response, then
   implementations can either:

   1.  Deaggregate the shorter prefix response into multiple longer
       prefix responses, or,

   2.  Alert the operator that the order of queries will determine which
       answers get cached, and either warn and continue or treat this as
       an error and refuse to load the configuration.

   Implementations SHOULD document their chosen behavior.

6.2.2.  Intermediate Nameserver

   When an Intermediate Nameserver uses ECS, whether it passes an ECS
   option in its own response to its client is within any of predicated on whether the networks in
   client originally included the
   cache, then option.  Because a client that did not
   use an ECS option might not be able to understand it, the cached response server MUST be returned as usual.
   NOT provide one in its response.  If the
   address of the client matches multiple networks query did include the
   option, the server MUST include one in its response, especially as it
   could be talking to a Forwarder which would need the cache, information for
   its own caching.  [Open issue: if the
   entry Forwarder sent 0s for FAMILY
   and ADDRESS, how could it take back a response with non-zero FAMILY
   and ADDRESS when the longest SCOPE NETMASK value spec says this mismatch MUST be returned, as with
   most route-matching algorithms. dropped?]

   If an Intermediate Nameserver receives a response which has a longer
   SCOPE PREFIX-LENGTH than the address of the client does not match any network SOURCE PREFIX-LENGTH that it provided in
   its query, it SHOULD still provide the cache,
   then the Recursive Resolver MUST behave as if no match was found and
   perform resolution result as usual.  This is necessary to avoid suboptimal
   replies in the cache from being returned answer to the wrong clients, and to
   avoid a single
   triggering client request coming from a even if the client on is in a different network
   from polluting the cache with a suboptimal reply for all the users of
   that resolver.

   Note that every time a Recursive Resolver queries an Authoritative
   address range.  The Intermediate Nameserver by forwarding the edns-client-subnet option that it
   received from another client, MAY instead opt to retry
   with a short longer SOURCE NETMASK in the original
   request could cause PREFIX-LENGTH to get a suboptimal better reply before
   responding to be returned by the
   Authoritative Nameserver.

   When the request includes its client, as long as it does not exceed a longer SCOPE NETMASK, SOURCE
   PREFIX-LENGTH specified in the reply returned
   may still be cached as optimal query that triggered resolution, but
   this obviously has implications for the ADDRESS and SCOPE NETMASK latency of the reply.  This might still be suboptimal overall
   lookup.

   The logic for using the original client.

   To avoid this suboptimal reply from being served from cache for other
   clients for which to determine whether the Intermediate
   Nameserver already knows the response to provide to its client is
   covered in the next section.

6.3.  Handling ECS Responses and Caching

   When an Intermediate Nameserver receives a better reply would be available, response containing an ECS
   option and without the TC bit set, it SHOULD cache the result based
   on the Recursive
   Resolver MUST check data in the SCOPE NETMASK that option.  If the TC bit was returned by set, the
   Authoritative Nameserver:

   o Intermediate
   Resolver SHOULD retry the query over TCP to get the complete answer
   section for caching.

   If the SCOPE NETMASK FAMILY, SOURCE PREFIX-LENGTH, and SOURCE PREFIX-LENGTH bits of
   ADDRESS in the reply is longer than response don't match the SOURCE
      NETMASK, it means that fields in the reply might be suboptimal.  A Recursive
      Resolver corresponding
   query, the full response MUST return this entry from cache only to queries that do
      not contain or allow a longer SOURCE NETMASK to be forwarded, or
      to queries originating from dropped, as described in Section 10.

   If no ECS option is contained in the network covered by response, the ADDRESS and Intermediate
   Nameserver SHOULD treat this as being equivalent to having received a
   SCOPE NETMASK..

   o  If PREFIX-LENGTH of 0, which is an answer suitable for all client
   addresses.  See further discussion on the SCOPE NETMASK security implications of
   this in Section 10.

6.3.1.  Caching the reply is shorter than or equal to Response

   In the
      SOURCE NETMASK, cache, any resource record in the reply is optimal, and SHOULD answer section will be returned from
      cache tied
   to any client within the network indicated specified by the FAMILY, ADDRESS and SCOPE NETMASK.

   As another reply is received, PREFIX-
   LENGTH fields, as limited by the reply will Intermediate Nameserver's own
   configuration for maximum cacheable prefix length.  Note that the
   additional and authority sections from a DNS response message are
   specifically excluded here.  Any records from these sections MUST NOT
   be tied to a different
   network.  The server SHOULD keep in cache both replies, and return
   the most appropriate one depending on the address network.  [Open issue: this conflicts a bit with draft-
   kumari-dnsop-multiple-responses, which wants to put data in the
   additional section that an authoritative nameserver that does ECS
   would probably want to tailor.]  See more at Section 6.4.

   Records that are cached as /0 because of a query's SOURCE PREFIX-
   LENGTH of 0 MUST be distinguished from those that are cached as /0
   because of a response's SCOPE PREFIX-LENGTH of the client.  Per
   standard DNS caching behavior, all records SHOULD 0.  The former should
   only be retained until
   their TTL expires.  Subsequent used for other /0 queries to refresh the data should
   always specify the longest SCOPE NETMASK that the Recursive Intermediate Resolver
   receives, but the latter is willing to cache, even if previous responses indicated that suitable as a
   shorter netmask was the optimal response. response for all networks.

   Although omitting network-specific caching will significantly
   simplify an implementation, the resulting drop in cache hits is very
   likely to defeat most latency benefits provided by edns-client-
   subnet. ECS.  Therefore,
   when implementing this option for latency purposes, implementing full
   caching support as described in this section is STRONGLY RECOMMENDED.

   Any reply containing strongly recommended.

   Enabling support for ECS in an edns-client-subnet option considered invalid
   should Intermediate Nameserver will
   significantly increase the size of the cache, reduce the number of
   results that can be treated served from cache, and increase the load on the
   server.  Implementing the mitigation techniques described in
   Section 10 is strongly recommended.

6.3.2.  Answering from Cache

   Cache lookups are first done as if usual for a DNS query, using the
   query tuple of <name, type, class>.  Then the appropriate RRset MUST
   be chosen based on longest prefix matching.  The client address to
   use for comparison will depend on whether the Intermediate Nameserver
   received an ECS option in its client query.

   o  If no edns-client-subnet ECS option was specified at
   all.

   Replies provided, the client's address is used.

   o  If there was an ECS option, the ADDRESS from it MAY be used if
      local policy allows.  Policy can vary depending on the agreements
      the operator of the Intermediate Nameserver has with Authoritative
      Nameserver operators; see Section 11.2.  If policy does not allow,
      a REFUSED response must be sent.

   If a matching network is found and the relevant data is unexpired,
   the response is generated as per Section 6.2.

   If no matching network is found, the Intermediate Nameserver MUST
   perform resolution as usual.  This is necessary to avoid Tailored
   Responses in the cache from being returned to the wrong clients, and
   to avoid a single query coming from servers not supporting edns-client-subnet or
   otherwise not containing an edns-client-subnet option SHOULD be
   considered as containing a SCOPE NETMASK of 0 (e.g., cache client on a different network
   from polluting the result
   for 0.0.0.0/0 or ::/0) cache with a Tailored Response for all the supported families.

   In any case, the response from the resolver users
   of that resolver.

6.4.  Delegations and Negative Answers

   The prohibition against tying ECS data to records from the client MUST NOT
   contain the edns-client-subnet option if none was present Authority
   and Additional section left an unfortunate ambiguity in the
   client's original request.  If
   specification, primarily with regard to negative answers.  The
   expectation of the original client request contained
   a valid edns-client-subnet option that authors was that ECS would only really be
   used during recursion, the
   Recursive Resolver MUST include for address records, the edns-client-subnet option from use case that was driving the Authoritative Nameserver response in
   definition of the response protocol.

   The delegations case is a bit easier to tease out.  In operational
   practice, if an authoritative server is using address information to
   provide customized delegations, it is the client.

   Enabling support resolver that will be using
   the answer for edns-client-subnet its next iterative query.  Addresses in the Additional
   section SHOULD therefore ignore ECS data, and the authority SHOULD
   return a zero SCOPE PREFIX-LENGTH on delegations.  A recursive
   resolver will
   significantly increase SHOULD treat a non-zero SCOPE PREFIX LENGTH in a delegation
   as though it were zero.

   For negative answers, some independent implementations of both
   resolvers and authorities did not see the size section restriction as
   necessarily meaning that a given name and type must only have either
   positive ECS-tagged answers or a negative answer.  They support being
   able to tell one part of the cache, reduce network that the number data does not exist,
   while telling another part of
   results the network that can be served from cache, it does.

   Several other implementations, however, do not support being able to
   mix positive and increase the load on negative answers, and thus interoperability is a
   problem.

   This issue is expected to be revisited in a future revision of the
   server.  Implementing
   protocol, possibly blessing the mitigation techniques described in
   Section 10 is strongly recommended.

6.4. mixing of positive and negative
   answers.  There are implications for cache data structures that
   developers should consider when writing new ECS code.

6.5.  Transitivity

   Generally, edns-client-subnet ECS options will only be present in DNS messages between a
   Recursive Resolver and an Authoritative Nameserver, i.e., one hop.
   In certain configurations however, for example multi-tier nameserver
   setups, it may be necessary to implement transitive behaviour on
   Intermediate Nameservers.

   It is important that any Intermediate Nameserver that forwards edns-
   client-subnet ECS
   options received from their clients MUST fully implement the caching
   behaviour described in Section 6.3.

   Intermediate Nameservers, including Recursive Resolvers, Nameservers supporting
   edns-client-subnet ECS MUST forward options with
   SOURCE NETMASK PREFIX-LENGTH set to 0
   (i.e., (that is, completely anonymized), such an option MUST
   forward the query with SOURCE PREFIX-LENGTH set to 0 and MUST NOT be
   replaced with an option with more accurate address information.

   An Intermediate Nameserver MAY also forward edns-client-subnet ECS options with actual
   address information.  This information MAY match the source IP
   address of the incoming query, and MAY have more or
   less fewer address
   bits than the Nameserver would normally include in a locally
   originated edns-client-subnet ECS option.

   If for any reason the Intermediate Nameserver does not want to use
   the information in an edns-client-subnet ECS option it receives (too little address
   information, network address from a range not authorized to use the
   server, private/unroutable address space, etc), it SHOULD drop the
   query and return a REFUSED response.  Note again that an edns-client-subnet ECS option
   with 0 address bits MUST NOT be refused.

   Be aware that at least one major existing implementation does not
   return REFUSED and instead just process the query as though the
   problematic information were not present.  This can lead to anomalous
   situations, such as a response from the Intermediate Nameserver that
   indicates it is tailored for one network (the one passed in the
   original query, since ADDRESS must match) when actually it is for
   another network (the one which contains the address that the
   Intermediate Nameserver saw as making the query).

7.  IANA Considerations

   IANA has already assigned option code 8 in the "DNS EDNS0 Option
   Codes (OPT)" registry to edns-client-subnet. ECS.

   The IANA is requested to update the reference ("draft-vandergaast-
   edns-client-subnet") to refer to this RFC when published.

8.  DNSSEC Considerations

   The presence or absence of an [RFC6891] EDNS0 OPT resource record
   containing an edns-client-subnet ECS option in a DNS query does not change the usage of
   the resource records and mechanisms used to provide data origin
   authentication and data integrity to the DNS, as described in
   [RFC4033], [RFC4034] and [RFC4035].  OPT records are not signed.

   Use of this option, however, does imply increased DNS traffic between
   any given Recursive Resolver and Authoritative Nameserver, which
   could be another barrier to further DNSSEC adoption in this area.

9.  NAT Considerations

   Special awareness of edns-client-subnet ECS in devices that perform Network Address
   Translation (NAT) as described in [RFC2663] is not required; queries
   can be passed through as-is.  The client's network address SHOULD NOT
   be added, and existing edns-client-subnet ECS options, if present, SHOULD NOT be
   modified by NAT devices.

   In large-scale global networks behind a NAT (but, device (but for example, example
   with a Centralized Resolver infrastructure), an internal Intermediate
   Nameserver might have detailed network layout information, and might may
   know which external subnets are used for egress traffic by each
   internal network.  In such cases, the Intermediate Nameserver MAY use
   that information when originating edns-client-subnet ECS options.

   In other cases, Recursive Resolvers sited behind a NAT device SHOULD
   NOT originate edns-client-subnet ECS options with their external IP address, and instead
   rely on downstream Intermediate Nameservers doing so.  They MAY,
   however, choose to include the option with their internal address for
   the purposes of signaling a shorter, more anonymous SOURCE NETMASK. PREFIX-
   LENGTH.

   If an Authoritative Nameserver on the publicly routed Internet
   receives a request query that specifies an ADDRESS in [RFC1918] or [RFC4193]
   private address space, it SHOULD ignore ADDRESS and look up its
   answer based on the address of the Recursive Resolver.  In the
   reply
   response it SHOULD set SCOPE NETMASK PREFIX-LENGTH to cover all of the
   relevant private space.  For example, a request query for ADDRESS 10.1.2.0
   with a SOURCE NETMASK PREFIX-LENGTH of 24 would get a returned SCOPE NETMASK PREFIX-
   LENGTH of 8.  The Intermediate Nameserver MAY elect to cache the
   answer under one entry for special-purpose addresses [RFC6890]; see
   Section 10.3.

10.  Security Considerations

10.1.  Privacy

   With the edns-client-subnet ECS option, the network address of the client that initiated
   the resolution becomes visible to all servers involved in the
   resolution process.  Additionally, it will be visible from any
   network traversed by the DNS packets.

   To protect users' privacy, Recursive Resolvers are strongly
   encouraged to conceal part of the IP address of the user by
   truncating IPv4 addresses to 24 bits.  No recommendation is provided
   for IPv6 at this time, but IPv6 addresses should be similarly
   truncated in order to not allow unique identification of the client.

   When a non-zero SCOPE NETMASK is provided by the Recursive Resolver
   that is longer than SOURCE NETMASK, users can often obtain more
   optimal mapping if the resolver is well-used.  Replies will have
   answers optimized up to SCOPE NETMASK bits for a subset strongly
   encouraged to conceal part of the SOURCE
   NETMASK.  Subsequent requests within the TTL from clients within the
   cached range will be served the optimal answer, while still
   preserving privacy IP address of the user. user by
   truncating IPv4 addresses to 24 bits. 56 bits are recommended for
   IPv6, based on [RFC6177].

   ISPs will often should have more detailed knowledge of their own networks.  That
   is, they will might know if that all 24-bit prefixes in a /20 are in the same
   area.  In those cases, for optimal cache utilization and improved
   privacy, the ISP's Recursive Resolver SHOULD truncate IP addresses in
   this /20 to just 20 bits, instead of 24 as recommended above.

   Users who wish their full IP address to be hidden can include an
   edns-client-subnet ECS
   option specifying the wildcard address 0.0.0.0/0 (i.e.  FAMILY set to 1 (IPv4),  SOURCE NETMASK to 0 and no ADDRESS). PREFIX-LENGTH of
   0).  As described in previous sections, this option will be forwarded
   across all the Recursive Resolvers supporting edns-client-subnet, ECS, which MUST NOT
   modify it to include the network address of the client.

   Note that even without an edns-client-subnet ECS option, any server queried directly by
   the user will be able to see the full client IP address.  Recursive
   Resolvers or Authoritative Nameservers MAY use the source IP address
   of requests queries to return a cached entry or to generate an optimized reply a Tailored
   Response that best matches the request. query.

10.2.  Birthday Attacks

   edns-client-subnet

   ECS adds information to the DNS question tuple query tupe (q-tuple).  This allows an
   attacker to send a caching Intermediate Nameserver multiple queries
   with spoofed IP addresses either in the
   edns-client-subnet ECS option or as the source
   IP.  These queries will trigger multiple outgoing queries with the
   same name, type and class, just different address information in the edns-client-subnet
   ECS option.

   With multiple queries for the same name in flight, the attacker has a
   higher chance of success in sending to send a matching response (with with the
   address 0.0.0.0/0 SCOPE
   PREFIX-LENGTH set to 0 to get it cached for many hosts). all hosts.

   To counter this, every edns-client-subnet ECS option in a response packet MUST contain
   the FAMILY full FAMILY, ADDRESS and SOURCE NETMASK PREFIX-LENGTH fields from the
   corresponding request, along with identical ADDRESS bits for SOURCE
   NETMASK length. query.  Intermediate Nameservers processing a response
   MUST verify that these match, and MUST SHOULD discard the entire reply response
   if they do not.

   That requirement to discard is "SHOULD" instead of "MUST" because it
   stands in opposition to the instruction in Section 6.3 which states
   that a response lacking an ECS option should be treated as though it
   had one of SCOPE PREFIX-LENGTH of 0.  If that is always true, then an
   attacker does not need to worry about matching the original ECS
   option data and just needs to flood back responses that have no ECS
   option at all.

   This type of attack could be detected in ongoing operations by
   marking whether the responding nameserver had previously been sending
   ECS option, and/or by taking note of an incoming flood of bogus
   responses and flagging the relevant query for re-resolution.  This is
   more complex than existing nameserver responses to spoof floods, and
   would also need to be sensitive to a nameserver legitimately stopping
   ECS replies even though it had previously given them.

10.3.  Cache Pollution

   It is simple for an arbitrary resolver or client to provide false
   information in the edns-client-subnet ECS option, or to send UDP packets with forged
   source IP addresses.

   This could be used to:

   o  pollute the cache of intermediate resolvers, by filling it with
      results that will rarely (if ever) be used.

   o  reverse engineer the algorithms (or data) used by the
      Authoritative Nameserver to calculate the optimized answer. Tailored Responses.

   o  mount a denial-of-service attack against an Intermediate
      Nameserver, by forcing it to perform many more recursive queries
      than it would normally do, due to how caching is handled for
      queries containing the edns-client-subnet ECS option.

   Even without malicious intent, Centralized Resolvers providing
   answers to clients in multiple networks will need to cache different
   replies
   responses for different networks, putting more memory pressure on the
   cache.

   To mitigate those problems:

   o  Recursive Resolvers implementing edns-client-subnet ECS should only enable it in
      deployments where it is expected to bring clear advantages to the
      end users.  For example, when expecting clients from a variety of
      networks or from a wide geographical area.  Due to the high cache
      pressure introduced by edns-client-subnet, ECS, the feature SHOULD be disabled in all
      default configurations.

   o  Recursive Resolvers SHOULD limit the number of networks and
      answers they keep in the cache for a given query.

   o  Recursive Resolvers SHOULD limit the number of total different
      networks that they keep in cache.

   o  Recursive Resolvers should never send edns-client-subnet options
      with a SCOPE NETMASK that is longer than they are willing to
      cache.  Similarly, if using the backwards-compatible SCOPE NETMASK
      of 0, the request should not set that they keep in cache.

   o  Recursive Resolvers MUST never send an ECS option with a SOURCE NETMASK of
      PREFIX-LENGTH providing more bits in the ADDRESS than they are
      willing to cache. cache responses for.

   o  Recursive Resolvers should implement algorithms to improve the
      cache hit rate, given the size constraints indicated above.
      Recursive Resolvers MAY, for example, decide to discard more
      specific cache entries first.

   o  Authoritative Nameservers and Recursive Resolvers should discard
      edns-client-subnet
      ECS options that are either obviously forged or otherwise known to
      be wrong.  They SHOULD at least treat unroutable addresses, such
      as some of the address blocks defined in [RFC6890], as equivalent
      to the Recursive Resolver's own identity.  They SHOULD ignore and
      never forward edns-client-subnet ECS options specifying other routable addresses that
      are known not to be served by the query source.

   o  Authoritative Nameservers consider the edns-client-subnet ECS option just as a hint
      to provide better results.  They can decide to ignore the content
      of the edns-client-subnet ECS option based on black or white lists, rate limiting
      mechanisms, or any other logic implemented in the software.

11.  Sending the Option

   When implementing a Recursive Resolver, there are two strategies on
   deciding when to include an edns-client-subnet ECS option in a query.  At this stage,
   it's not clear which strategy is best.

11.1.  Probing

   A Recursive Resolver can send the edns-client-subnet ECS option with every outgoing
   query.  However, it is RECOMMENDED that Resolvers remember which
   Authoritative Nameservers did not return the option with their
   response, and omit client address information from subsequent queries
   to those Nameservers.

   Additionally, Recursive Resolvers MAY SHOULD be configured to never send
   the option when querying root, top-level, and effective top-level
   domain servers.  These domains are delegation-centric and are very
   unlikely to generate different replies responses based on the address of the
   client.

   When probing, it is important that several things are probed: support
   for edns-client-subnet, ECS, support for EDNS0, support for EDNS0 options, or possibly an
   unreachable Nameserver.  Various implementations are known to drop
   DNS packets with OPT RRs (with or without options), thus several
   probes are required to discover what is supported.

   Probing, if implemented, MUST be repeated periodically (i.e.  daily). periodically, e.g., daily.
   If an Authoritative Nameserver indicates edns-client-subnet ECS support for one zone, it
   is to be expected that the Nameserver supports edns-
   client-subnet ECS for all of its
   zones.  Likewise, an Authoritative Nameserver that uses edns-client-subnet ECS
   information for one of its zones, MUST indicate support for the
   option in all of its responses. responses to ECS queries.  If the option is
   supported but not actually used for generating a response, its SCOPE NETMASK value
   PREFIX-LENGTH SHOULD be set to 0.

11.2.  Whitelist

   As described previously, it is expected that only a few Recursive
   Resolvers will need to use edns-client-subnet, ECS, and that it will generally be enabled
   only if it offers a clear benefit to the users.

   To avoid the complexity of implementing a probing and detection
   mechanism (and the possible query loss/delay that may come with it),
   an implementation could decide to use a statically configured whitelist of Authoritative Namesevers
   to send the option to. to, likely specified by their domain name.
   Implementations MAY also allow additionally configuring this based on
   other criteria, such as zone or query type.

   An additional advantage of using a whitelist is that partial client
   address information is only disclosed to Nameservers that are known
   to use the information, improving privacy.

   A major drawback is scalability.  The operator needs to track which
   Authoritative Nameservers support edns-client-subnet, ECS, making it harder for new
   Authoritative Nameservers to start using the option.

   Similarly, Authoritative Nameservers can also use whitelists to limit
   the feature to only certain clients.  For example, a CDN that does
   not want all of their mapping trivially walked might require a legal
   agreement with the Recursive Resolver operator, to clearly describe
   the acceptable use of the feature.

   The maintenance of access control mechanisms is out of scope for this
   protocol definition.

12.  Example

   1.   A stub resolver SR resolver, SR, with IP address 192.0.2.37 tries to resolve
        www.example.com, by forwarding the query to the Recursive
        Resolver R
        Resolver, RNS, from IP address IP, asking for recursion.

   2.   RNS, supporting edns-client-subnet, ECS, looks up www.example.com in its cache.  An
        entry is found neither for www.example.com, nor for example.com.

   3.   RNS builds a query to send to the root and .com servers.  The
        implementation of R RNS provides facilities so an administrator
        can configure RNS it not to forward edns-client-subnet ECS in certain cases.  In
        particular, RNS is configured to not include an edns-
        client-subnet ECS option when
        talking to delegation-centric TLD or root nameservers, as described in Section 6.1.
        Thus, no edns-client-
        subnet ECS option is added, and resolution is performed as
        usual.

   4.   RNS now knows the next server to query, query: the Authoritative Nameserver
        Nameserver, ANS, responsible for example.com.

   5.   RNS prepares a new query for www.example.com, including an edns-
        client-subnet ECS
        option with:

        *  OPTION-CODE, set to 0x00 0x08. 8.

        *  OPTION-LENGTH, set to 0x00 0x07 for the following fixed 4
           octets plus the 3 octets that will be used for ADDRESS.

        *  FAMILY, set to 0x00 0x01 as IP is an IPv4 address.

        *  SOURCE NETMASK, PREFIX-LENGTH, set to 0x18, as RNS is configured to
           conceal the last 8 bits of every IPv4 address.

        *  SCOPE NETMASK, PREFIX-LENGTH, set to 0x1B, 0x00, as RNS is willing to cache
           answers up to a /27. specified by this
           document for all queries.

        *  ADDRESS, set to 0xC0 0x00 0x02, providing only the first 24
           bits of the IPv4 address.

   6.   The query is sent.  Server  ANS understands and uses edns-client-
        subnet. ECS.  It parses the edns-client-subnet
        ECS option, and generates
        an optimized reply. a Tailored Response.

   7.   Due to the its internal implementation of ANS, it implementation, ANS finds an answer a response that is optimal
        tailored for several /27 ranges within the ADDRESS/SOURCE
        NETMASK whole /16 of the request.  It chooses one randomly.  (Note well,
        this is just one example of how ANS could pick a suitable
        answer.  Other selection methods are possible.) client that performed the
        query.

   8.   The Authoritative Nameserver   ANS adds an edns-client-subnet ECS option in the reply, response, containing:

        *  OPTION-CODE, set to 0x00 0x08. 8.

        *  OPTION-LENGTH, set to 0x00 0x08 for the following fixed 4
           octets plus the 4 octets that will be used for ADDRESS . 0x07.

        *  FAMILY, set to 0x00 0x01, the same as the request. 0x01.

        *  SOURCE NETMASK, PREFIX-LENGTH, set to 0x18, copied from the request. query.

        *  SCOPE NETMASK, PREFIX-LENGTH, set to 0x1B, 0x10, indicating a /27 /16 network.

        *  ADDRESS, set to 0xC0 0x00 0x02 0xE0, 0x02, copied from the request. query.

   9.   RNS receives the reply response containing an edns-client-subnet ECS option.
        The resolver  It verifies
        that FAMILY, SOURCE NETMASK, PREFIX-LENGTH, and the
        SOURCE NETMASK bits of ADDRESS match the request. query.
        If not, the message is discarded.

   10.  The reply response is interpreted as usual.  Since the reply response
        contains an
        edns-client-subnet ECS option, the ADDRESS, SCOPE NETMASK, PREFIX-LENGTH, and
        FAMILY in the response are used to cache the entry.

   11.  RNS sends a response to stub resolver SR, without including an
        edns-client-subnet
        ECS option.

   12.  RNS receives another request query to resolve www.example.com.  This
        time, a reply response is cached.  The reply, response, however, is tied to a
        particular network.  If the address of the client matches any
        network in the cache, then the reply response is returned from the
        cache.  Otherwise, another query is performed.  If multiple
        results match, the one with the longest SCOPE NETMASK PREFIX-LENGTH is
        chosen, as per common best-network match algorithms.

13.  Contributing Authors

   The below individuals contributed significantly to the draft.  The
   RFC Editor prefers a maximum of 5 names on the front page, and so we
   have listed additional authors in this section

   Edward Lewis
   ICANN
   12025 Waterfront Drive, Suite 300
   Los Angeles, Angeles CA 90094-2536
   USA
   Email: edward.lewis@icann.org

   Sean Leach
   Fastly
   POBox 78266
   San Francisco, Francisco CA 94107

   Jason Moreau
   Akamai Technologies
   8 Cambridge Ctr
   Cambridge MA 02142-1413
   USA

14.  Acknowledgements

   The authors wish to thank Darryl Rodden for his work as a co-author
   on previous versions, and the following people for reviewing early
   drafts of this document and for providing useful feedback: Paul S.

   R.  Chisholm, B.  Narendran, Leonidas Kontothanassis, David Presotto,
   Philip Rowlands, Chris Morrow, Kara Moscoe, Alex Nizhner, Warren
   Kumari, and Richard Rabbat from Google, Google; Terry Farmer, Mark Teodoro,
   Edward Lewis, and Eric Burger from Neustar, Neustar; David Ulevitch, Ulevitch and
   Matthew Dempsky from OpenDNS, OpenDNS; Patrick W.  Gilmore and Jason Moreau Steve Hill from
   Akamai; Colm MacCarthaigh and Richard Sheehan from Amazon; Tatuya
   Jinmei from Internet Software Consortium; Andrew Sullivan from Dyn;
   John Dickinson from Sinodun; Mark Delany from
   Akamai, Colm MacCarthaigh, Richard Sheehan Apple; Yuri Schaeffer
   from NLnet Labs; Antonio Querubin; and all of the other people that
   replied to our emails on various mailing lists.

15.  References

15.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              October 1994.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets", BCP
              5, RFC 1918, February 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC6177]  Narten, T., Huston, G., and L. Roberts, "IPv6 Address
              Assignment to End Sites", BCP 157, RFC 6177, March 2011.

   [RFC6890]  Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
              "Special-Purpose IP Address Registries", BCP 153, RFC
              6890, April 2013.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.

15.2.  Informative References

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations", RFC
              2663, August 1999.

15.3.  URIs

   [1] http://www.iana.org/assignments/address-family-numbers/

Appendix A.  Document History

   [RFC Editor: Please delete this section before publication.]

   -00 to -01 (IETF)

   o  <David> Made the document describe how things are actually
      implmented now.  This makes the document be more of a "this is how
      we are doing things, this provides information on that".  There
      may be a future document that describes additional funcationality.

   o  NETMASK was not a good desription, changed to PREFIX-LENGTH
      (Jinmei, others).  Stole most of the definition for prefix length
      from RFC4291.

   o  Fixed the "SOURCE PREFIX-LENGTH set to 0" definition to include
      IPv6 (Tatuya Jinmei)

   o  Comment that ECS cannot be used to hand NXDOMAIN to some clients
      and not others, primarily because of interoperability issues.
      (Tatuya Jinmei)

   o  Added text explaining that implmentations need to document thier
      behavior with overlapping networks.

   o  Soften "optimized reply" language.  (Andrew Sullivan).

   o  Fixed some of legacy IPv4 cruft (things like 0.0.0.0/0)

   o  Some more grammar / working cleanups.

   o  Replaced a whole heap of occurances of "edns-client-subnet" with
      "ECS" for readability.  (John Dickinson)

   o  More clearly describe the process from the point of view of each
      type of nameserver.  (John Dickinson)

   o  Birthday attack still possible if attacker floods with ECS-less
      responses.  (Yuri Schaeffer)

   o  Added some open issues directly to the text.

A.1.  -00

   o  Document moved to experimental track, added experiment description
      in header with details in a new section.

   o  Specifically note that edns-client-subnet ECS applies to the answer section only.

   o  Warn that caching based on edns-client-subnet ECS is optional but very important for
      performance reasons.

   o  Updated NAT section.

   o  Added recommendation to not use the default /24 recommendation for
      the source netmask prefix-length field if more detailed information about
      the network is available.

   o  Rewritten problem statement to be more clear about the goal of
      edns-client-subnet ECS
      and the fact that it's entirely optional.

   o  Wire format changed to include the original address and netmask prefix
      length in responses in defence against birthday attacks.

   o  Security considerations now includes a section about birthday
      attacks.

   o  Renamed edns-client-ip in edns-client-subnet, ECS, following suggestions on the
      mailing list.

   o  Clarified behavior of resolvers when presented with an invalid
      edns-client-subnet ECS
      option.

   o  Fully take multi-tier DNS setups in mind and be more clear about
      where the option should be originated.

   o  A note on Authoritative Nameservers receiving queries that specify
      private address space.

   o  A note to always ask for the longest acceptable SOURCE prefix
      length, even if a prior answer indicated that a shorter prefix
      length was suitable.

   o  Marked up a few more references.

   o  Added a few definitions in the Terminology section, and a few more
      aesthetic changes in the rest of the document.

A.2.  -01

   o  Document version number reset from -02 to -00 due to the rename to
      edns-client-subnet.
      ECS.

   o  Clarified example (dealing with TLDs, and various minor errors).

   o  Referencing RFC5035 instead of RFC1918.

   o  Added a section on probing (and how it should be done) vs.
      whitelisting.

   o  Moved description on how to forward edns-client-subnet ECS option in dedicated
      section.

   o  Queries with wrongly formatted edns-client-subnet ECS options should now be rejected
      with FORMERR.

   o  Added an "Overview" section, providing an introduction to the
      document.

   o  Intermediate Nameservers can now remove an edns-client-subnet ECS option, or reduce
      the SOURCE NETMASK PREFIX-LENGTH to increase privacy.

   o  Added a reference to DoS attacks in the Security section.

   o  Don't use "network range", as it seems to have different meaning
      in other contexts, and turned out to be confusing.

   o  Use shorter and longer netmasks, prefix lengths, rather than higher or
      lower.  Add a better explanation in the format section.

   o  Minor corrections in various other sections.

A.3.  -02

   o  Added IANA-assigned option code.

A.4.  -03*

   o  [*] There was no -03 version of the draft; these changes, however,
      were made after -02.

   o  Allow non-zero SCOPE NETMASK for Recursive Resolvers to indicate
      their maximum cacheable mask length, and updated the example
      accordingly.

   o  A note on Authoritative Nameservers receiving requests that
      specify private address space.

   o  A note to always ask for the longest acceptable SCOPE NETMASK,
      even if a prior answer indicated that a shorter netmask was
      optimal.

   o  Marked up a couple of references.

   o  Minor grammatical consistency edits.

Authors' Addresses

   Carlo Contavalli
   Google
   1600 Amphitheater Parkway
   Mountain View, CA  94043
   US

   Email: ccontavalli@google.com

   Wilmer van der Gaast
   Google
   Belgrave House, 76 Buckingham Palace Road
   London  SW1W 9TQ
   UK

   Email: wilmer@google.com

   David C Lawrence
   Akamai Technologies
   8 Cambridge Center
   Cambridge, MA  02142
   US

   Email: tale@akamai.com

   Warren Kumari
   Google
   1600 Amphitheatre Parkway
   Mountain View, CA  94043
   US

   Email: warren@kumari.net