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

From: Marcus Grando <[email-masked]>
Date: Wed, 18 Feb 2015 15:19:00 -0200

I've read this draft again and my comments are below.

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

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

This paragraph isn't clear to me, I read and re read several times and
can’t figure out if there are any case where it will be possible to create
one request that will never be cached. Like stub create one request with
source netmask and some combination of resolver configuration and authority
answer, where in the end, resolver can’t cache the answer.

6.4. Transitivity:

In my point of view, this is like Stub/Resolver behaviour when Stub
generate edns-client-subnet packet. If it's, I think it can be removed to
keep it simpler.

10.1. Privacy:

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

I'd love to see an IPv6 recommendation here too, even 64 bits for example.
I vote to recommendation for End Sites in RFC 6177 of 56 bits.

10.3. Cache Pollution:

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

I'm worried about this, because if the implementators limit to lower limit,
this can be a problem. What will happen if reach this limit? I can't find
anything if the limit was reach, an non edns-client-subnet was sent and
answer without edns-client-subnet. For example, in CDNs, will be a lot of
answers with a lot of network subnets and a lower TTL. This behaviour can
reach easly those limits if are low. How you guys are seeing this problem?

11.1. Probing:

>> Additionally, Recursive Resolvers MAY 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 based on the address of the client.

I think we can change MAY to SHOULD, because there's no reason to send
edns-client-subnet to ROOT and TLD servers.

>> ... it is to be expected that the Nameserver supports edns-client-subnet
for all its zones.

This might be wrong, not all zones will be able to answer
edns-client-subnet. Like I describe below, If a domain announcing their
support will be better choice and there's no reason to send
edns-client-subnet for all hosted zones.

11.2. Whitelist:

About the manually whitelist, I really think it will be a huge problem and
I'm not a big fan, since the main problem is in the resolver side and not
the authoritative side. The authoritative side know if it support or not
for any hosted domain. It's impossible to know all resolvers around the
world and contact/appy to all those resolvers.

If the resolver side enable edns-client-subnet support, they intend to
enable all domains around the world to improve their user experience,
because that, does not make sense whitelist edns-client-subnet on the
resolver side. I vote to remove the Whitelist.

Another comments:

* Probing:

I think that Probing can be improved to support detection if domain has or
not support to edns-client-subnet. Implement something like sending
edns-client-subnet query to an TXT or SOA domain, with that result, enable
or disable domain's support. TTL of this response can be used to revalidate
edns-client-subnet support. With that, domain owner will be able to
enable/disable anytime.

* Handling edns-client-subnet Replies and Caching:

I'm trying to figure out how can support two answers like 10.10.0.0/16 and
10.10.10.0/24 active in resolver side. This can be usual to testing
purpose, like send a bunch of users to another place and the rest of users
keep going to old place. This not gonna work today because if resolver
first query was 10.10.0.0/16, another query will not gonna happen. If the
/24 query goes first, then another query /16 will gone later and this will
works fine.

What you guys thinking about all comments?

Best regards
--
Marcus Grando
marcus (at) sbh.eng.br
mnag (at) FreeBSD.org
@marcusgrando

---

From: Yuri Schaeffer <[email-masked]>
Date: Wed, 18 Feb 2015 21:21:17 +0100

Hi,

On 18-02-15 18:19, Marcus Grando wrote:
>>> 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..
> 
> This paragraph isn't clear to me, I read and re read several times
> and can’t figure out if there are any case where it will be
> possible to create one request that will never be cached. Like stub
> create one request with source netmask and some combination of
> resolver configuration and authority answer, where in the end,
> resolver can’t cache the answer.

I don't think this is about if an answer should be cached or not, but
rather if we we are allowed to serve it from the cache or not for a
particular query.

Thus having this in cache:
10.10.0.0/16/24

you are allowed to use that cache entry for the query:
10.10.0.0/16/0

but not for:
10.10.0.0/17/0

You'd have to requery or keep looking in your cache for a more
specific answer.

> (cut)

> * Probing:
> 
> I think that Probing can be improved to support detection if domain
> has or not support to edns-client-subnet. Implement something like
> sending edns-client-subnet query to an TXT or SOA domain, with that
> result, enable or disable domain's support. TTL of this response
> can be used to revalidate edns-client-subnet support. With that,
> domain owner will be able to enable/disable anytime.

I see no benefit in doing so.

However, there is an issue when one of the authoritative servers
signals no support for ECS, A situation congruent with answering with
SCOPE 0. If you cache this you effectively disable ECS for that name
for its TTL. I'm not really concerned about serving a suboptimal (not
wrong!) answer for some time but I've been told by operators this is a
deal breaker. The only way around this IMHO is not to cache answers
when you would have expected the option but did not get it. For which
I can't imagine anyone would argue is a good idea.

I'm bringing this up because I hoped your proposal would solve this
issue but it does not as far as I can see.

> I'm trying to figure out how can support two answers like
> 10.10.0.0/16 <http://10.10.0.0/16> and 10.10.10.0/24
> <http://10.10.10.0/24> active in resolver side. This can be usual
> to testing purpose, like send a bunch of users to another place and
> the rest of users keep going to old place. This not gonna work
> today because if resolver first query was 10.10.0.0/16
> <http://10.10.0.0/16>, another query will not gonna happen. If the
> /24 query goes first, then another query /16 will gone later and 
> this will works fine.

There are no issues supporting this. You need to remember though that
you have both SOURCE and SCOPE in your cache. If you correct your
example to include both values I can show you how it would work for a
resolver.

//Yuri