Thanks both, So, I seem to gather that the main problem is to put forward Geolocation as a way to return pseudo-targeted answers to end-users by using the resolver IP as a proxy for it. This was more meant to be a use-case as to how geo location has been used, but It is by no means my intent to push this as a recommended solution. I am happy to drop this or rephrase.
I do believe that Geo can have other useful properties as Brian has highlighted, even more so in an infrastructure that heavily relies on anycast. I suppose in most cases one could find other approaches to get that information whether the traffic coming from a given network is legitimate, but in many cases, this will involve having access/knowledge to the full stack (routing tables, peering links, AS paths...) which may not be readily available to the ones operating DNS. Likely geo is not a perfect proxy, but it does provide high enough signal that one can leverage. Manu On Fri, Nov 20, 2020 at 9:49 AM Brian Dickson <brian.peter.dick...@gmail.com> wrote: > > 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
