Subject: Re: [DNSOP] comments on draft-ietf-dnsop-edns-client-subnet-00

From: John Dickinson <[email-masked]>
Date: Wed, 7 Jan 2015 14:27:23 +0000

Hi,

I have been reading this draft with a view to designing an implementation.
In an attempt to understand section 6 I tried to pull it apart in to 
more sections. I have attempted to describe the behaviour of each possible 
type of name server (e.g., auth, recursive, caching, forwarding, stub, etc.)
in separate sections even if that requires repeating text. My re-write can
be found below (with questions inline and a summary of changes at the end).
I hope the authors find it useful. If I have mis-understood anything please 
let me know.

In addition:

1. I also strongly agree with the comments made by JINMEI, Tatuya. Especially 
those about changing NETMASK to PREFIX_LENGTH.

2. For clarity, I think edns-client-subnet should be changed to ECS and
consistent use made of the terms query and response and not terms like
question, request or reply.

3. I think that there might be places where Intermediate Nameserver and
Recursive Nameserver have been used interchangeably/inconsistently.
I am not sure I have it correct in the suggested text below.

4. There is no mention of DNS CLASS. Somewhere it should state this is only
for IN and that IN is assumed throughout. Especially when matching queries 
with responses.

5. Several more examples would be useful as well. (I did send one to the
authors off list.)

My attempt at text:
3.  Terminology

      ECS: Edns Client Subnet.

      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.

      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
      7.

      Forwarder: A nameserver that receives queries from a Stub Resolver
      and forwards them on to a Recursive Resolver.  A client to a
      Recursive Resolver.  It is possible to have a chain of Forwarders.
      Forwarders frequently use caches to be able to respond to client
      queries quickly.

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

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

      Client: A Stub Resolver, Forwarder or Recursive Resolver.

      Server: A Forwarder, Recursive Resolver or Authoritative
      Nameserver.

   ...The rest of section 3 as is...

5.  Option Format

   ...as is...

   Question: Clarify the meaning of significant in the last bullet
   point: "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" so that it cannot be misinterpreted as "set
   additional significant bits to 1".

6.  Protocol Description

6.1.  Adding the ECS Option

   The ECS option should generally be added by Recursive Resolvers when
   querying other servers, as described in Section 11, but can be added
   by a Stub Resolver.

6.1.1.  Stub Resolvers

   A Stub Resolver MAY generate DNS queries with an ECS option with
   SOURCE NETMASK set to 0 (i.e. 0.0.0.0/0) to indicate that the
   Recursive Resolvers MUST NOT add address information of the client to
   its queries.

   The Stub Resolver may add non-zero ECS options to its queries.

   Question: Would be useful to clarify what should be used in the SCOPE
   NETMASK here - since there is no discussion on this in section 5?

6.1.2.  Recursive Resolver Receiving Queries

   A Recursive Resolver supporting ECS MAY use client address
   information in order to generate an optimized response.  The
   Recursive Resolver will look in its cache (see section 6.3.2) or send
   queries to Authoritative Servers to get a response.  The queries MAY
   contain an ECS option.

   Recursive Resolvers that have not implemented or enabled support for
   the ECS option may 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 support for the option.

   Queries with wrongly formatted options (e.g., wrong size) MUST be
   rejected and a FORMERR response MUST be returned to the sender, as
   described by [RFC6891], Transport Considerations.

   If no ECS option is present in a query received by a Recursive
   Resolver which supports ECS then it SHOULD add an ECS option to its
   queries including the IP address of the client that caused the query
   to be generated.

   For privacy reasons, and because the whole IP address is rarely
   required to determine an optimized response, the ADDRESS field in the
   option SHOULD be truncated to a certain number of bits, chosen by the
   administrators of the Recursive Nameserver, as described in
   Section 10

   If the client query contains an ECS option with SOURCE NETMASK set to
   0 then the Recursive Resolver MAY either not include an ECS option or
   MAY optionally include its own address information, which is what an
   ECS aware Authoritative Nameserver will use anyway to generate the
   response in lieu of no option.  This allows the answer to be handled
   by the same caching mechanism as other queries, with an explicit
   indicator of the applicable scope.  Subsequent Stub Resolver queries
   for /0 can then be answered from this cached response.

   If the client query contains an ECS option with a non-zero SOURCE
   NETMASK then the Recursive Resolver is not required to use this
   information.  The Recursive Resolver MAY act as if no ECS option was
   specified (see above), or it may respect the ECS option in the query
   and use this information to obtain an optimised response.  In the
   second case,

   o  the ECS information should be used when searching the cache for an
      answer instead of the client address (see section 6.3.2.1)

   o  if recursion is required and if the client query contains a SOURCE
      NETMASK that is shorter than the maximum cacheable SCOPE NETMASK
      that the Recursive Resolver allows, the Recursive Resolver SHOULD
      issue the upstream query with its longer SCOPE NETMASK

6.2.  Authoritative Server

   ...as is until paragraph 7...

   Question: Would it be better to convert P7 and P8 to be definitions
   of optimal and suboptimal?

      SUBOPTIMAL RESPONSES: A SCOPE NETMASK value longer than the SOURCE
      NETMASK indicates that the address and netmask provided in the
      query was not specific enough to select a single, best response,
      and it means that the response might be suboptimal.  The ADDRESS
      in the response ECS option MUST be extended to SCOPE NETMASK
      significant bits to indicate the network for which it is optimal.

      Question: Refer to Question in section 5?

      OPTIMAL RESPONSES: Conversely if the SCOPE NETMASK in the response
      is shorter than or equal to the SOURCE NETMASK this indicates that
      more bits than necessary were provided, and the answer is suitable
      for a broader range of addresses.  The response is optimal for the
      network described by the SCOPE NETMASK.

   ...Rest of section 6.2 from paragraph 9 as is...

6.3.  Intermediate Nameservers handling responses and caching

   When an Intermediate Nameserver receives a response containing an ECS
   option, it will return a response to its client and SHOULD cache the
   result.

   If the FAMILY, SOURCE NETMASK, and SOURCE NETMASK bits of ADDRESS in
   the response don't match the fields in the corresponding query, the
   full response MUST be dropped, as described in Section 10.

   If the Authoritative Nameserver extended the ADDRESS in the response
   to SCOPE NETMASK significant bits to indicate the network for which
   it is optimal, The Recursive Resolver SHOULD still provide the
   result as the answer to the triggering query even if the client is in
   a different address range.

   Any response containing an ECS option considered invalid should be
   treated as if no ECS option was specified at all.

   Responses coming from servers not supporting ECS or otherwise not
   containing an ECS option SHOULD be considered as containing a SCOPE
   NETMASK of 0 (e.g., cache the result for 0.0.0.0/0 or ::/0) for all
   the supported families.

6.3.1.  Caching responses

   In the cache, any resource record in the answer section will be tied
   to the network specified by the FAMILY, ADDRESS and SCOPE NETMASK
   fields in the response, as detailed below, even if the address has
   been extended.  This includes negative responses.  Note that the
   additional and authority sections from a DNS response message are
   specifically excluded here.  Any information cached from these
   sections MUST NOT be tied to a network.

   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 ECS.  Therefore,
   when implementing this option for latency purposes, implementing full
   caching support as described in this section is STRONGLY RECOMMENDED.

   Enabling support for ECS in an Intermediate Nameserver will
   significantly increase the size of the cache, reduce the number of
   results that can be 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 the cache

6.3.2.1.  No ECS option in client query

   If a query is received matching the name and type of an entry in the
   cache, the Intermediate Nameserver will check whether the IP version
   and source address of the client matches one of the networks in the
   cache for that entry.

6.3.2.2.  ECS option in client query

   If the original client query contained an ECS option the Intermediate
   Nameserver MAY use either the client source address or the
   information in the ECS option to perform the cache lookup.

   Question: What is the recommended behaviour here?

6.3.2.3.  Selecting the best response

   If the address of the client is within any of the networks in the
   cache, then the cached response MUST be returned as usual.  If the
   address of the client matches multiple networks in the cache, the
   entry with the longest SCOPE NETMASK value MUST be returned, as with
   most route-matching algorithms.

   If the address of the client does not match any network in the cache,
   then the Intermediate Nameserver MUST behave as if no match was found
   and perform forwarding/resolution as usual.  This is necessary to
   avoid suboptimal replies in the cache from being returned to the
   wrong clients, and to avoid a single query coming from a client on a
   different network from polluting the cache with a suboptimal response
   for all the users of that Intermediate Nameserver.

6.3.2.4.  Sub-optimal responses

   Suboptimal responses may be returned for several reasons e.g.,

   o  Every time a Recursive Resolver queries an Authoritative
      Nameserver by forwarding the ECS option that it
      received from another client, a short SOURCE NETMASK in the
      original request could cause a suboptimal reply to be returned by
      the Authoritative Nameserver.

   o  Question: This would be clearer if it specified what the SOURCE
      NETMASK was shorter than.

   o  When the request includes a longer SCOPE NETMASK, the reply
      returned may still be cached as optimal for the ADDRESS and SCOPE
      NETMASK of the reply.  This might still be suboptimal for the
      original client.

   o  Question: Again longer then what?

   To avoid a suboptimal response from being served from a cache for
   clients for which a better response would be available, the
   Intermediate Nameserver MUST check the SCOPE NETMASK that was
   returned in the response.

   o  If the SCOPE NETMASK in the response is longer than the SOURCE
      NETMASK, it means that the response might be suboptimal.  A
      Intermediate Nameserver 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 the network covered by
      the ADDRESS and SCOPE NETMASK.

   o  If the SCOPE NETMASK in the response is shorter than or equal to
      the SOURCE NETMASK, the response is optimal, and SHOULD be
      returned from cache to any client within the network indicated by
      ADDRESS and SCOPE NETMASK.

   Question: I find the above very hard to parse.  I think it needs
   rewriting and some examples.

   As another response is received, the response will be tied to a
   different network.  The Intermediate Nameserver SHOULD keep in cache
   both reponses, and return the most appropriate one depending on the
   address of the client.  Per standard DNS caching behavior, all
   records SHOULD be retained until their TTL expires.  Subsequent
   queries to refresh the data should always specify the longest SCOPE
   NETMASK that the Intermediate Nameserver is willing to cache, even if
   previous responses indicated that a shorter netmask was the optimal
   response.

6.3.3.  Responses to clients

   The response from the Intermediate Nameserver to the client MUST NOT
   contain the ECS option if none was present in the client's original
   query.

   If the original client query contained a valid ECS option that was
   respected and the information used during recursion, the Recursive
   Resolver MUST include the ECS option from the Authoritative
   Nameserver response in the response to the client.

   Question: What about the case of a valid ECS option that is received
   but not used, and the Recursive Resolver uses its own ECS option
   instead?  How about adding this text "In the case of a valid ECS
   option that is received but not used, and when the Recursive Resolver
   uses its own ECS option instead, the Recursive Resolver SHOULD
   include the ECS option it received from the Authoritative Nameserver
   in the response to the client".

6.4.  Transitivity

   Question: would this section be better earlier in the text?

   .. as is until paragraph 3...

   Options received with a SOURCE_NETMASK set to 0 (completely
   anonymized) MUST be forwarded unchanged by all Intermediate
   Nameservers supporting ECS, including Recursive Resolvers.  Such an
   option MUST NOT be replaced with an option with more accurate address
   information.

   ...rest of section 6.4 as is...

Summary of changes...
New sections:

      Added new section 6.1.1 Stub Resolvers

      Added new section 6.1.2 Recursive Resolver Receiving Queries

      Added new section 6.3.1 Caching responses

      Added new section 6.3.2 Answering from the cache
      
      Added new section 6.3.2.1 no ECS option in client query

      Added new section 6.3.2.2 ECS option in client query

      Added new section 6.3.2.3 Selecting the best response

      Added new section 6.3.2.4 Sub-optimal responses

      Added new section 6.3.3 Responses to clients

Changes:

      section 3 Modified and added additional terminology      
      
      section 5 Question about last bullet point

      section 6.1 Section title changed and question added to text

      section 6.1.P1 Modified

      section 6.1.P2 Modified and moved to section 6.1.2

      section 6.1.P3 Modified and split between sections 6.1.1 and 6.1.2

      section 6.1.P4 Modified and split between sections 6.1.1 and 6.1.2

      section 6.1.P5 Modified and moved to section 6.1.2

      section 6.1.P6 Modified and moved to section 6.1.2

      section 6.2 Section title changed

      section 6.2.P7 Modified and questions

      section 6.2.P8 Modified and questions

      section 6.3 Section title changed

      section 6.3.P1 Modified

      section 6.3.P2 Modified

      section 6.3.P3 Modified and moved to section 6.3.1

      section 6.3.P4 Modified and moved to section 6.3.2.1

      section 6.3.P5 Moved to section 6.3.2.3

      section 6.3.P6 Modified and moved to section 6.3.2.3

      section 6.3.P7 Now bullet points in section 6.3.2.4

      section 6.3.P8 Now bullet points in section 6.3.2.4

      section 6.3.P9 (and bullet points) Modified, questions and
      moved to section 6.3.2.4

      section 6.3.P10 Moved to 6.3.2.4

      section 6.3.P11 Moved to 6.3.1

      section 6.3.P14 Modified and moved to section 6.3.3

      section 6.3.P15 Modified and moved to section 6.3.1

      section 6.4.P3 Modified

regards,
John

---
[email-masked]

http://sinodun.com

Sinodun Internet Technologies
Magdalen Centre
The Oxford Science Park
Oxford
OX4 4GA
U.K.

---

From: Yuri Schaeffer <[email-masked]>
Date: Thu, 08 Jan 2015 15:52:12 +0100

On 12/31/2014 08:31 PM, 神明達哉 wrote:
> - Section 6.3
> entry with the longest SCOPE NETMASK value MUST be returned, as
> with most route-matching algorithms.
> 
> If I understand this (and Section 6.3 in general), the following 
> "suboptimal" scenario could happen: - The Authoritative Server is
> configured with two prefixes for optimized responses: 2001:db8::/32
> and 2001:db8:2::/48 - The Recursive Server sends a query with
> SOURCE of 2001:db8:1::/48 - The Authoritative Server finds the best
> matching prefix for the SOURCE is 2001:db8::/32 and returns a
> response corresponding to it, setting SCOPE NETMASK to 32

No, I thing the authority should have responded with a scope of 47.
That's the number of bits it needs (for this address) to make sure
there isn't a more specific answer.

Q:  2001:db8:1::/48/0
A:  2001:db8:1::/48/47

> - The Recursive Server receives the response and caches it - The
> Recursive Server receives a query from 2001:db8:2::1, and finds it
> has a matching cache (with prefix being 2001:db8::/32)

It will have in its cache:
  2001:db8:1::/48/47
Likely, (we assume the recursive server wants to expose only the 48
first bits) 2001:db8:2::/48 will be looked up in the cache and will
not match. So then the following exchange happens:

Q:  2001:db8:2::/48/0
A:  2001:db8:2::/48/48

Now, if the recursive server would have asked for 2001:db8:8002::/48
the authority would have responded with a small scope.

Q:  2001:db8:8002::/48/0
A:  2001:db8:8002::/48/33

> and uses the cached response to answer the query, even if it could 
> get the specifically optimized response for 2001:db8:2::/48 from 
> the Authoritative Server.
> 
> Is my understanding correct?  If so, is this a problem to resolve
> or something we need to accept?

Think of scope like:
 "I would have used N bits to come to this answer if N or more have
been available. (for this particular block)"
Rather than:
 "Only the first N bits of the address are relevant"

//Yuri

---

From: 神明達哉 <[email-masked]>
Date: Thu, 8 Jan 2015 10:58:00 -0800

At Thu, 08 Jan 2015 15:52:12 +0100,

> there isn't a more specific answer.

Hmm, okay, if the definition of SCOPE is what you described, I see it
will prevent the "suboptimal" case I described above.

I hope I'm not the only person, but I suspect it's very difficult to
reach this understanding just from the current description of the
draft:

   o  SCOPE NETMASK, unsigned octet representing the length of the
      netmask pertaining to the reply.  [...
      ...] In responses, this field is set by the
      Authoritative Nameserver to indicate the coverage of the response.
[...]
   The SCOPE NETMASK in the reply indicates the netmask of the network
   for which the answer is intended.
[...]
   Conversely, a shorter SCOPE NETMASK indicates that more bits than
   necessary were provided, and the answer is suitable for a broader
   range of addresses.

[...]

>  "Only the first N bits of the address are relevant"

I'm also not sure if the "would have used N bits" definition is clear
enough to get the idea.  To me, "the number of bits it needs (for this
address) to make sure there isn't a more specific answer" looks
better, and, even with this definition, I guess I'd need some specific
examples to understand it correctly.  (So I'd suggest revising the
draft with some "better" definition with helper examples)

   In the cache, any resource record in the answer section will be tied
   to the network specified by the FAMILY, ADDRESS and SCOPE NETMASK
   fields, as detailed below.

Now, if this is the intended definition of SCOPE, I have a couple of
concerns:

- The authoritative server's implementation will be very complicated.
  Maybe this is not something we have to worry about, maybe
  existing utility libraries used for longest prefix matching are good
  and capable enough to implement the concept, and maybe
  the quality/maturity of implementations will become better over time
  anyway.  But I think it's still worth discussing whether the
  resulting behavior is worth the complexity.
- Using my server side configuration example of 2001:db8::/32 and
  2001:db8:2::/48 again.  With this definition of SCOPE and caching
  behavior at the Recursive Server, the Recursive Server would have to
  cache separate responses for all of the 64K prefixes that match
  2001:db8::/48.  Wouldn't it be too costly, even though a Recursive
  Server that supports this option is already expected to be memory
  (or cache storage in general) hog and it would manage the amount of
  total cache storage properly by, e.g., purging least used ones
  regularly?  Do we have any analysis and/or measurement results on
  the cost against the perceived benefits?

--
JINMEI, Tatuya

---

From: Wilmer van der Gaast <[email-masked]>
Date: Thu, 8 Jan 2015 19:36:00 +0000

Hello everyone,

Only just spotted this thread after a coworker pointed me at it. I
won't be able to follow up to everything, but will try to address some
of the questions.

Re NETMASK: Yeah, sorry, poor choice of terminology early on in the
doc. Prefix length is the right term to use, it just felt like the
point was clear and it was too late to change it. But feel free, of
course, it's definitely more correct.

On 31 December 2014 at 19:31, 神明達哉 <[email-masked]> wrote:
>
> - Section 6.3
>
>    fields, as detailed below.  Note that the additional and authority
>    sections from a DNS response message are specifically excluded here.
>    Any information cached from these sections MUST NOT be tied to a
>    network.
>
>   What if the "optimized" reply is a negative one for some specific
>   client addresses (while it's positive for some other addresses)?

So, this opens an interesting separate debate: I always thought the
debate specifically disallows using ECS to generate negative
responses: A name must exist or not exist, ECS info is only for
helping out with picking a location closer to the user. However I've
never actually included such a claim into the draft.

>   Or are we simply excluding the support for negative optimized
>   replies?  (If so, I think it would be worth noting explicitly).
>
Definitely should have been noted, and now I've heard some voices of
support for negative responses based on ECS. I myself am still not in
favour.

>   "suboptimal" scenario could happen: [...]

I think this has been responded to already, but if not.. Let me first
start with some sort of intro:

ECS is mostly meant to be very simple. Some early versions did not
mention transitive use of the option. The user can pass a 0/0 option
for privacy, but otherwise none at all, and resolvers/INSes were not
expected to use any ECS info other than info they generated themselves
from the end user's IP address, including exactly as many bits as they
want to include themselves (and really for IPv4 this should be a /24
because more info is rarely useful and less info very quickly makes
ECS useless).

Many of the confusing parts of the ECS draft now are caused by support
for a transitive ECS option. :-/

To get to your scenario:

>   - The Authoritative Server is configured with two prefixes for
>     optimized responses: 2001:db8::/32 and 2001:db8:2::/48
>   - The Recursive Server sends a query with SOURCE of 2001:db8:1::/48
>   - The Authoritative Server finds the best matching prefix for the
>     SOURCE is 2001:db8::/32 and returns a response corresponding to
>     it, setting SCOPE NETMASK to 32
>   - The Recursive Server receives the response and caches it
>   - The Recursive Server receives a query from 2001:db8:2::1, and
>     finds it has a matching cache (with prefix being 2001:db8::/32)
This is not what the draft is meant to say and I do think this is
explained elsewhere. The response the authority sent here should mean:
"I have nothing for that very specific /48 you sent me, but something
for the /32 it is part of. You can use it for that /48 but if you get
a query for another /48 within it you should re-query me." I think
this is explained in the caching section.

I don't expect this problem to happen much with IPv4 unless someone
sends less specific info than a /24, which could happen if it's poorly
configured, or if it has a client that sends it short ECS options.

(IPv6 is a different story, and with IPv6 it's pretty hard to choose a
good recommended default prefix length...)

> - Section 6.3
>
>    Any reply containing an edns-client-subnet option considered invalid
>    should be treated as if no edns-client-subnet option was specified at
>    all.
>
>   What specifically does "considered invalid" mean?  And, depending on
>   that, shouldn't the reply rather be discarded in such a case?
>
Interesting question. We ourselves were mostly just trying to be
conservative, and not lose traffic/queries from buggy resolvers.
(Being liberal in what you accept, etc.) If the rest of the query is
perfectly valid, we can still send a response that will get the user
to a working endpoint, it *might* just not be as close to the user as
it could have been.

>   If these challenges make CDN-like operators unwilling to deploy
>   DNSSEC and this option makes the optimization even more attractive,
>   then this option could help hinder wider deployment of DNSSEC.

I don't think ECS contributes to this significantly though. A CDN
nameserver is really just an authority with a "few" more A/AAAA
records than your average nameserver, that would therefore need to
keep a "few" more signatures as well. The number is still finite, a
CDN nameserver doesn't dynamically generate random IPv6 addresses for
its responses, right?

Hrm, actually, NSEC might actually be a good reason why ECS can't be
used for negative responses?

>    Users who wish their full IP address to be hidden can include an
>    edns-client-subnet option specifying the wildcard address 0.0.0.0/0
>    (i.e.  FAMILY set to 1 (IPv4), SOURCE NETMASK to 0 and no ADDRESS).
>
>   What if the user (stub resolver)'s address is IPv6?  Should it still
>   set FAMILY to 1?
>
Doesn't really matter, the point the client is trying to get across is
that it doesn't want its query origin IP address to be in an ECS
option. Whther the client is querying over IPv4 or IPv6 might in fact
be a piece of information then so hardcoding to always using 0.0.0.0/0
might be preferable.

Whether it's an IPv4 or IPv6 address the end user is after should
already be clear from the qtype.

> - Section 10.2
>
>    With multiple queries for the same name in flight, the attacker has a
>    higher chance of success in sending a matching response (with the
>    address 0.0.0.0/0 to get it cached for many hosts).
>
>   Another IPv4-centric description.  This should probably be, e.g.
>   "with the SCOPE NETMASK being 0, meaning an empty prefix".
>
It's just an example, I went for an IP address to save on words. COuld
consider mixing ::/0 (less typing in fact!) and 0.0.0.0/0 in various
examples.

-- 
Wilmer van der Gaast, London Traffic/Edge SRE.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 8 Jan 2015 11:36:31 -0800

On Thu, Jan 8, 2015 at 10:58 AM, <[email-masked]> wrote:

>   behavior at the Recursive Server, the Recursive Server would have
>   to cache separate responses for all of the 64K prefixes that match
>   2001:db8::/48.

Correction: I realized I was wrong here...the Recursive Server would
*only* have to cache 17 prefixes:
2001:db8:8000::/33
2001:db8:4000::/34
...
2001:db8:0004::/46
2001:db8:0000::/47
2001:db8:0002::/48
2001:db8:0003::/48

This still seems to be costly compared to just caching the matched
prefix (at the cost of having suboptimal cases), but maybe it's
marginal based on the fact that the Recursive Server would require a
lot of cache anyway.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Fri, 9 Jan 2015 11:14:44 -0800

At Thu, 8 Jan 2015 19:36:00 +0000,

> course, it's definitely more correct.

I'm not necessarily pushing it especially if others don't see the need
for clarifying it, but I don't think it's too late; this doesn't
affect the wire format or the protocol behavior, it's just a
terminology clarification.  Some implementations may have to be
updated over time so they are more consistent with the latest
terminology, but this can be gradual updates without affecting the
actual behavior.  The draft itself is literally a draft yet, and it's
not uncommon for internet drafts to have this kind of naming changes.
If that provides more clarity and less confusion for many future
readers of the RFC that this draft will eventually become, I think
it's worth the cost of today a lot.

> On 31 December 2014 at 19:31 <[email-masked]> wrote:

> support for negative responses based on ECS. I myself am still not in

I don't have a strong opinion, but in either case I think this should
be clearly documented.

> this is explained in the caching section.

I'm afraid I couldn't find anything in the current draft that clearly
excludes the above "suboptimal" scenario.  Could you point at the
specific text?

Besides: in another message of this thread I was told that the server
would set SCOPE NETMASK to 47, and I see that will surely prevent the
suboptimal case I described.  But I'm not sure if you are talking
about the same thing by "I have nothing for that very specific
/48...", and, in any case, I suspect it's very difficult to reach this
interpretation just from the current text of the draft.

> good recommended default prefix length...)

I admit the above specific scenario is a bit artificial and it's
probably less likely to be seen in practice.  But, we cannot be sure
how exactly this option will be used in general especially for IPv6
(as you said), and since this document is generic and IP-version
agnostic, I don't think we can just dismiss corner cases.  Ideally we
should make the protocol work for such cases, and we should at least
clearly describe any limitations.

> to a working endpoint, it *might* just not be as close to the user as

My main point is that "invalid" is too broad.  All of the following
could be considered "invalid":

A. OPTION-LENGTH is too large (e.g. 65535) for the entire message
B. OPTION-LENGTH is too sort (e.g. 2)
C. FAMILY is neither 1 nor 2
D. SOURCE/SCOPE NETMASK is 255
E. SCOPE NETMASK is not 0 in a request
F. SOURCE/SCOPE are 0, but ADDRESS is not empty (according to OPTION-LENGTH)
G. FAMILY=1, SOURCE NETMASK=32, but ADDRESS contains more than 4
   octets of data (according to OPTION-LENGTH)
H. ADDRESS indicates it's a multicast address (e.g. starting with 0xff
   for IPv6)

Some should be considered "too invalid" to continue handling the
message at all; at least I believe any sane implementation treats the
case A that way.  Others may be negligible, but I wouldn't be
surprised if an implementation drops the entire message in cases like
G (in fact, from a quick look the ISC BIND 9 seems to drop the entire
message in cases A, B, D, F, and G).

I don't know what's the best way to address this point (or whether to
do it in the first place).  Perhaps it might not matter much, as cases
like G are clearly bogus and the sender implementation should be
corrected (and will be so if reasonably maintained) over time.  But if
we want to do something about it in this document, some options are:

- describe message validation more specifically and precisely: e.g.,
  "if the OPTION-LENGTH is smaller than 4, the receiver MUST discard
  the entire DNS message...."  Many IETF protocol documents take this
  approach (but many others don't).
- describe the general guideline with some more leniency and details,
  e.g. "if any of the option field contains an unexpected value (e.g.
  SOURCE NETMASK larger than 128 when FAMILY is 2), the receiver SHOULD
  ignore the entire option but continue processing the message unless
  OPTION-LENGTH is too large to move to the next option (or the end of
  the OPT RR) safely.  An implementation MAY choose to discard the
  entire message according to its own validation policy except for
  cases that this document explicitly allows, if any."

> CDN nameserver doesn't dynamically generate random IPv6 addresses for

Possibly so, but if we think about implementation and deployment
details, it may not be that trivial.  For example, many
publicly-available signing tools that I know of work per zone.  So
you'd need to sign the entire zone for all versions corresponding to
all combinations of different answers.  Depending on the size of
deployment it's scalability limitation may not be acceptable.  Big
operators can certainly develop custom tools that work well in these
cases, but some operators will still prefer using generic tools or
simply don't have resource to develop custom ones.

I also know an implementation at the authoritative side that allows a
user to specify regular expressions for owner names, e.g.,
*.example.com, where '*' is not a DNS wildcard, and www.example.com,
ftp.example.com etc would be considered individual owner names in
terms of DNSSEC signature calculation.

Also, technically, if you change an answer that means you make a
change to the zone, which, again technically, would require an update
to its SOA, which would require resigning it.

Admittedly, though, I don't know whether these technical details are a
barrier for deploying DNSSEC in CDN-like operations.

> be a piece of information then so hardcoding to always using 0.0.0.0/0

In the case of a "real" end user (a stub resolver), the address family
is not a secret.  In case it's forwarded by a recursive server
obscuring it may make some sense.

Anyway, I knew it wouldn't really matter, but my point is that the
possible ambiguity of the text could be an interoperability issue.
For example, a stub resolver sets FAMILY to 1 with the actual source
address being IPv6.  A Resolver implementation notices the
inconsistency and might consider it a kind of malicious attempt and
drop it (btw this is probably also related to the "what's invalid"
discussion).

Perhaps the draft can be clearer and more explicit, e.g.:

- When setting SOURCE NETMASK to 0, the client (end client or
  forwarding resolver) SHOULD set FAMILY to 1, regardless of the
  corresponding address for (slightly) better privacy protection.
- The receiving node MUST ignore the ADDRESS and FAMILY if SOURCE
  NETMASK is set to 0.

BTW: while responding to this part I noticed one minor editorial
issue: in the definition of FAMILY in Section 2, s/[2]/[1]/:

   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].

> already be clear from the qtype.

Yes, but I don't think it's relevant to this discussion...

> consider mixing ::/0 (less typing in fact!) and 0.0.0.0/0 in various

I know this is (most likely to be) intended to be just an example, but
IMO the text isn't clear enough about the intent.  Mixing cases may be
helpful, and/or just adding "e.g." etc may be enough (in this case it
would be: "(e.g., with the address 0.0.0.0/0 to get it cached for many
hosts).".

--
JINMEI, Tatuya

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 13 Jan 2015 18:45:17 +0000

Hello All,

Some time ago (when there was a Verisign coauthor on this draft) I was asked
to review it internally.  I'm not sure if all of my comments were passed
back, so I am sending them here.  Hopefully I have correctly accounted and
adjusted for changes between the current version and the one that I reviewed.
If not please forgive me.

As a general comment, I found it a little bit loose with the terminology
and vague at times.  As protocol to be implemented I think it should be
tightened up.

>       side as described in [RFC1034] section 5.3.1.
> 
>       or more DNS zones.  These are normally not contacted by clients
>       directly but by Recursive Resolvers.  Described in [RFC1035]
>       chapter 6.
> 
>    Intermediate Nameserver:  Any nameserver (possibly a Recursive
>       Resolver) in between the Stub Resolver and the Authoritative
>       Nameserver.

Another sort of general comment here: I have some trouble with the protocol
that says "if you are a Recursive Resolver, do this.  Or if you're an
Intermediate Resolver, do that" because I think servers don't usually or
always know if they are recursive, or intermediate, or authoritative.  (A
name server can be recursive for one zone and authoritative for another).
It is especially confusing to try to distinguish between recursive and
intermediate.  So I wish the behavior could be expressed in terms of the
protocol elements.  For example, rather than say "if you're a stub, do
this" you would say "if the outgoing query as the RD bit set, do this"
Maybe thats unrealistic though.

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

I question whether it is really necessary to define a Centralized Resolver as
something different a Recursive Resolver.  It seems to be used very few times in
the document, and nowhere in a way that would affect protocol implementation.

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

"The expectation" makes me cringe a little bit.  I strongly believe that
the new feature is going to be used and abused in ways that haven't been
envisioned.  I predict that a significant amount of name servers will
enable this either because they *think* it will give them more optimal
DNS responses and/or because it enables some other new feature.
Just look at how many people use 8.8.8.8 because somebody told them its
faster than their ISP.

slight diversion/rant/anecdote:
On the Squid project ("back in my day...") I was responsible for coming
up with the X-Forwarded-For HTTP header, which is very similar to
edns-client-subnet.  X-Forwarded-For happened because people wanted their
apache access log files to reflect the individual end users IP, not the
proxy IP.  Now there are numerous instances where you can use browser
plugins to insert a fake X-Forwarded-For header to bypass country-level
content restrictions, etc.

> 
>    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.

If its not a cause of concern then why is client-edns-subnet being proposed?

>    In this option, the server should include the IP address of the

"In this option" and "the server" is an example of how I think the language needs to 
be tightened.  Which server?  Are we still talking about Recursive Resolver
from the previous paragraph?  

>    The Stub Resolver may also add non-empty edns-client-subnet options
>    to its queries, but Recursive Resolvers are not required to use this
>    information.

Here is an example where I think there is a conflict because a server won't
necessarily know if it is "Recursive" or "Intermediate." In the text above
the Recursive can ignore the edns-client-subnet from the Stub.  In the
Transitivity section it says if an Intermediate doesn't want to use the
query's edns-client-subnet information, it should drop the query and return
REFUSED.

> 
>    The FAMILY and SOURCE NETMASK in the response MUST match those in the
>    request.  The first SOURCE NETMASK bits of the ADDRESS in the
>    response MUST match those in the request, even if fewer bits were
>    used to form the response.  Echoing back the address and netmask
>    helps to mitigate certain attack vectors, as described in Section 10.

So we can also use edns-client-subnet as an entropy source to fight Kaminsky?

>    sections from a DNS response message are specifically excluded here.

The different treatment for authority and additional data is interesting.
I wonder if it impacts the "ranking data" rules of RFC 2181 section 5.4.1?
An 'A' record could be in the cache because it came in via the additional
section, and it could also be in the cache with a different value because
someone queried for it directly with edns-client-subnet.  

The document doesn't say anything about applying or not applying to specific
record types, but should it?  Can NS/SOA/RRSIG/DNSKEY/etc rdata depend on
edns-client-subnet?

Late-breaking comment: A few days ago a coauthor of this very draft published
another draft document (draft-wkumari-dnsop-multiple-responses-00.txt)
which essentially says a server can put extra "answer" records in an
additional section (they must be signed) to preempt subsequent queries.
The two drafts would seem to be in conflict for how to handle additional
section records.

>    most route-matching algorithms.

Is there potential problem because RRs are cached with associated
FAMILY/ADDRESS/SCOPE and you might have multiple RRs in the Answer section,
but you only have one edns-client-subnet in the response?  For example,
could you have a cached CNAME RR under 192.168.0.0/16 and an associated
cached A RR under 192.168.1.0/24?  What does the edns-client-subnet option
response (especially SCOPE NETMASK) look like in this case, 

>    then the Recursive Resolver MUST behave as if no match was found and

This section started out talking about an Intermediate Resolver but
here switched to Recursive Resolver.

>    When the request includes a longer SCOPE NETMASK, the reply returned

longer than what?

>    o  If the SCOPE NETMASK in the reply is longer than the SOURCE
>       NETMASK, it means that the reply might be suboptimal.  A Recursive
>       Resolver 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 the network covered by the ADDRESS and
>       SCOPE NETMASK..

I've tried to parse this about 10 times, and I still don't feel like
I've got it.

How does a "[query] ... not ... allow a longer SOURCE NETMASK to be forwarded"?
Only SOURCE NETMASK of 0 must be obeyed and anything else can be overridden, right?

How does the cache know whether or not a cached RR is sub-otpimal (because
the cache doesn't save the SOURCE NETMASK, right?)  Does it have to set
a this-response-is-sub-optimal bit when it goes into the cache?

Maybe you can walk me through this example:

First query:   www.google.com/A   ADDRESS=192.168 SOURCENM=16
Server response:   x.x.x.x        ADDRESS=192.168 SCOPENM=24

(so this is a possibly sub-optimal response because the server says
it has more specific info but the client wasn't willing to provide
more address bits)

Soon a second query comes in just like the first:

Second query:  www.google.com/A   ADDRESS=192.168 SOURCENM=16

Is this a cache hit?  The document doesn't really detail how networks are
matched.  It says "if the address of the client is within any of the
networks in the cache." Is 192.168/16 within 192.168.0/24?  I wouldn't
think so, but otherwise you get nothing but cache misses from this situation.

Anyway, one of my concerns with handling sub-optimal responses was that
you keep forwarding the query rather than use the cached data but you keep
getting back the same response.  The document doesn't say if the "same
response" should update the cache (extending its TTL) or be ignored.

> 
>    As another reply is received, the reply will be tied to a different
>    network.  The server SHOULD keep in cache both replies, and return
>    the most appropriate one depending on the address of the client.  Per
>    standard DNS caching behavior, all records SHOULD be retained until
>    their TTL expires.

being very pedantic here I guess, but that reply won't necessarily
be tied to a different network.  Perhaps the document should simply
state what to do when it gets a response for a network not already
in the cache, and for a network already in the cache (update or drop)?

>    If the original client request contained
>    a valid edns-client-subnet option that was used during recursion,

What does "used during recursion" mean?  used in cache lookups?  forwarded?
Can a "0.0.0.0/0" edns-client-option be "used?"

> 
>    Intermediate Nameservers, including Recursive Resolvers, supporting
>    edns-client-subnet MUST forward options with SOURCE NETMASK set to 0

"forward queries", perhaps?

>    An Intermediate Nameserver MAY also forward edns-client-subnet
>    options with actual address information.

Not exactly clear what the "actual address" is in this case.  I guess you
mean the edns-client-subnet data received in the query?

>  This information MAY match
>    the source IP address of the incoming query, and MAY have more or
>    less address bits than the Nameserver would normally include in a
>    locally originated edns-client-subnet option.

Is the Intermediate allowed to change SOURCE NETMASK?

The document doesn't really say if the Intermediate is allowed to 
overwrite the query-provided edns-client-subnet data with its own
choice of values, or did I miss that?

>  Note again
>    that an edns-client-subnet option with 0 address bits MUST NOT be
>    refused.

queries are refused, not options.  I suggest:

Note again that an Intermediate Nameserver MUST NOT refuse a query simply
because the edns-client-subnet SOURCE NETMASK is set to 0.

(i.e., it could refuse the query for other reasons).

> 
>    In other cases, Recursive Resolvers sited behind a NAT device SHOULD
>    NOT originate edns-client-subnet options with their IP address, and
>    instead rely on downstream Intermediate Nameservers doing so.

This is a configuration decision, right?  How would a Recursive know
whether or not it is behind NAT?

>    (i.e.  FAMILY set to 1 (IPv4), SOURCE NETMASK to 0 and no ADDRESS).

Its not really a User's choice, is it?  Guess it depends on your definition
of user.

>    To counter this, every edns-client-subnet option in a response packet

every?  There can be more than one?

>    o  Recursive Resolvers SHOULD limit the number of networks and
>       answers they keep in the cache for a given query.
 
I wouldn't say these things "cache queries".  I would say they "cache records" or
maybe even RRsets.  So maybe "... keep in the cache for a given RRset?"  

>   If
>    the option is supported but not actually used for generating a
>    response, its SCOPE NETMASK value SHOULD be set to 0.

I think this was a MUST before (section 6.2)

> 12.  Example

I would like to see many more examples, not only of the normal/expected cases, but
also of the abnormal and unexpected cases.  

Throughout the document there seems to be an assumption that all of the
authoritative name servers for a zone would support edns-client-subnet. 
What would happen if that is not the case?  

DW