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

[Ben Schwartz <[e-mail]>]

On Fri, Nov 20, 2020 at 12:49 PM Brian Dickson <
[e-mail]> wrote:

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

I think it's worth focusing on the use case.  If the use case is traffic
optimization, then we want something more like ECG, even if the resolver
decides to label all queries with its own country code.


> 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)
>
> I don't think any of these use cases motivates an exit-IP-geolocation
design.  Instead, they motivate a hierarchical affinity or labeling design,
allowing the resolver operator to indicate which IP prefixes are managed
together as a group.  There's nothing necessarily geographical about this.
Cloud services often have several reliability "regions" that are within a
few kilometers of each other.  Some resolver operators deliberately use a
mix of nodes running different software stacks, spread out across their
deployments.

In many deployments, geolocation of the exit IP is meaningless: the stub,
caching forwarders, recursive logic, and exit peering point can all be in
different countries!  This is green-field design, so we should take the
time to express the right semantics.

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
>