Re: [DNSOP] Meeting feedbacks/summary on draft-bretelle-dnsop-recursive-iprange-location

[Brian Dickson <[e-mail]>]

On Thu, Nov 19, 2020 at 9:35 AM Ben Schwartz <bemasc=
[e-mail]> wrote:

>
> I do not support the geolocation function.  I think the right solution
> here is ECS.  Even bad IP-geolocation from ECS will be better than using
> the recursive resolver's country-code; at least it will be estimating the
> location of the right entity.
>
> If ECS is not widely deployed enough for your purposes, I would focus on
> ways to increase support for ECS.  For example, we could work on ways
> to use shorter prefixes for improved privacy where appropriate, or provide
> guidance on how to use ECS for geo-based responses.
>

I agree with the sentiment against providing differentiated answers based
on the geo of the resolver (mostly).

However, geo has other valuable uses.
Thus, I'd like to retain geo as part of the standard.
I think recommending against using it as a proxy for ECS should be included
(with explanation, obviously).

One reason to have explicit geolocation is that the geoip of the resolver's
IP may not be accurate or timely, and for these use cases, explicit geo
info is always better.

One use case I raised at the meeting at the mic was grouping providers'
regional resolvers for various purposes on the authority servers' side.
Those things would include treating a regional group the same as a single
resolver, for purposes of white-listing, or rate-limiting, or other
operational activity.

There are other kinds of things that authority operators would be able to
do, some of which cannot be done today.
Those include:

   - Alerting on changes in affinity between resolver groups and authority
   instances (which might indicate a routing problem or outage)
   - Visibility on new deployments of resolver groups by a particular
   resolver operator (which might benefit from resource allocation work on the
   authority operator)
   - Ability to detect or prevent spoofing of resolver IP addresses
   - Ability to do cooperative work around ADoT
   - Ability to correlate oddities (e.g. unexpected DNS cookies, set by
   auth location A but seen by auth location B, associated with IP and
   resolver Geo info)

On the other hand, I could see a potential longer-term replacement of ECS
with ECG (EDNS client geo) once the geo stuff is standardized.

But let's not get distracted by that in the short term, where direct use of
resolver geo has real value.

Brian