Re: [DNSOP] call for adoption: draft-vandergaast-dnsop-edns-client-subnet

["Mark Delany" <[e-mail]>]

> The draft is available here: http://datatracker.ietf.org/doc/draft-vandergaast-dnsop-edns-client-subnet/

a) 6.2 - Intent of SCOPE NETMASK

  "In both cases, the value of the SCOPE NETMASK in the reply has strong
  implications with regard to how the reply will be cached"

I wonder whether SCOPE NETMASK should have a bigger impact beyond how
the reply is cached?

Specifically, if an auth returns a SCOPE NETMASK that is more
fine-grained than the SOURCE NETMASK, should that granularity
influence the SOURCE NETMASK of future queries from that cache to that
auth/domain?

If you think about it, SCOPE NETMASK is the auth communicating its
knowledge of the client network back to the cache. And, in the cases
where the client-subnet option is most useful (CDN-like applications),
it is commonly the case that auths do indeed have better knowledge
than the cache/resolver.

By way of example if a cache issues a query with a default SOURCE
NETMASK of /24 to a well-managed CDN auth, it is entirely possible
that the auth has greater knowledge of the SOURCE network and may
return a SCOPE NETMASK of, say, /25 because it knows that that /24 is
distributed topologically from the auth's perspective.

As it stands today, this cache will continue to issue queries to that
auth/domain with a /24 SOURCE NETMASK even though the replies coming
back indicate that the client network is divided on /25 basis as far
as the auth is concerned. In effect the auth has no way to correct the
erroneous assumptions of the cache.

I'm primarily concerned that client implementations of client-subnet
will hard-code a minimum or default SOURCE NETMASK which may not be
granular enough in the future. As we approach v4 exhaustion I can
easily imagine a corp network dividing a /24 up on a regional basis
and who knows what will happen to public routing as we really do get
close to v4 exhaustion?

If caches allow returned SCOPE NETMASKs to influence future SOURCE
NETMASKs (modulo privacy policy of course) then as networks get more
granular, auths - which have the greatest incentive to adapt - can
dynamically influence caches as the Internet changes.

(Admittedly this may not help if caches adopt a default privacy mask
that matches their default SOURCE NETMASK - which I expect many will).


b) 11.2 - Whitelist

   "Only a few Recursive Resolvers will need to use edns-client-subnet"

Does "few" refer to implementations or deployments? If the later, then
I wonder whether that estimate is accurate?

I would think that any enterprise or ISP with multiple ingress points
is a candidate user. Maybe that's still a "few" in the grand scheme of
things but the number of relevant operators goes well beyond the tiny
population of public caches and giant eyeball networks.

Has "few" been quantified? Are we talking about 1,000 deployments,
10,000? What is the threshold at which "few" no longer applies?

I'm also thinking of medium sized corporates which could easily run
regional networks with internal caches and auths. Maybe this isn't a
concern here because it's not the "Internet", but generally they will
want to use the same technology.

My ulterior motive is to revisit the whole notion of whitelisting. Why
have it at all? I worry that the desire to make a manageable
Internet-wide whitelist (if that's not an oxymoron) is driving some of
the assumptions and text in the spec.


Apologies if this is a rehash of earlier discussions, ignore anything
that has been previously settled.


Mark.