On Thu, Nov 19, 2020 at 9:35 AM Ben Schwartz <bemasc= 40google....@dmarc.ietf.org> 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
