Request for an ECS option to explicitly define the subnet and scope to be placed in recursive queries
Description
Resolver Operators are having a love-hate relationship with ECS. On one hand, it can be useful to be able to provide and to cache client-specific query responses from some domains, and on the other hand, the overhead of maintaining ECS cache (additional content etcetera) can be undesirable for some.
So why bother - especially if your resolver is servicing clients who are all from the same geographical location?
A new problem then arises - that some providers are using different geoip databases for queries that offer ECS, as opposed to those that are based solely on the resolver's own IP address (no ECS provided). And it turns out that some of these are just plain wrong. So as well as submitting requests to the database providers to correct errors, one operator has asked if it could be possible to just hard-configure an ECS option to send on behalf of all clients (whose queries are eligible per other configuration options) to have ECS added.
===
I would then like to add a new use case of my own - adding the requirement that the hard-coded ECS option be configurable per view, not just globally.
Consider the case where a global operator has region-specific resolvers, and additionally matches their clients to views that are country-specific (because of the necessity of adding response policies that are specific to the legal requirements imposed on resolver operators on a per-country basis). Most of the time, the local resolver will be fielding its region's client queries. But in order to provide diversity and fallback, it's possible that one regional resolver may be handling queries from another region from time to time. These will still be matched to the appropriate view.
Then think on further - geo-specific responses from authoritative servers do have different levels of specificity but in this instance, we're just trying to obtain a 'good' answer for all clients from a region, no more than that. If I, the resolver operator, can produce an ECS subnet and mask that achieves that goal, on behalf of all of my clients, then I don't need to cache any more than that one answer and use that on behalf of all my clients from this region.
Request
The original request was for an option to send a hard-coded ECS option on behalf of all clients - this to cause the authoritative servers receiving it to respond with the right geo-specific answer.
Second-guessing the requester (Support ticket #21784) I'm going to surmise that they do not expect this answer to be placed in ECS cache.
But actually I think that it does need to be placed in ECS cache, because of the second use case I proposed, where a view-specific hard-configured ECS option might be required, and also where a multi-viewed resolver is sharing cache between views.
Therefore.. there also need to be 'smarts' for cache look-ups in this case, where not only is the ECS option added to cache-miss queries on behalf clients instead of the 'naturally' occurring ECS subnet per the requesting client's own IP address, but also this hard-configured ECS option is used for cache lookups too.
This could go a long way towards making ECS more usable in some operating environments.
See also cache bloat considerations that this might help with in SF1412
Links / references
See also the issues/complaints/solution (albeit commercial) proposed in https://indico.dns-oarc.net/event/47/contributions/1022/. This for sure is presenting a commercial solution, but (as you will see when the DNS-OARC 41 videos are eventually available), it does raise several concerns about ECS implementations on the authoritative side, including unnecessary specificity, plus points out that IP subnet is, in many cases, far too granular, but we're obliged to use it to identify geo-location because we don't have a better way of handling this.
In reality, a far better predictor of geo-location than its subnet is the ASN of the originating client request. Alas, from a protocol design perspective, that a tough nut to crack because resolvers have no access to client ASN and authoritative servers have no access to geo-ASN databases to use instead of geo-IP. But in the meantime, allowing resolver operators to manually say 'oh, I'm representing clients from "here"' via a hard-configured ECS option might be a reasonable fudge.