If 0.0.0.0/0 is not a good idea, how about setting the prefix length as max-client-subnet-ipv4 option?
According to unbound.conf manual,
max-client-subnet-ipv4:
Specifies the maximum prefix length of the client source address we are willing to expose to third parties for IPv4. Defaults to 24.
Since this is the default prefix length exposed to the DNS server that supports ECS, the records returned by the DNS server must be optimal for the prefix with a length set by max-client-subnet-ipv4/6.
If 0.0.0.0/0 is not a good idea, how about setting the prefix
length as max-client-subnet-ipv4 option?
We've performed some thought experiments with this idea as well.
However this would create some new problems.
My objections:
- - This goes against the specifications.
- - We'd be making up authoritative data.
I believe that the setup you are describing is not compatible with the
draft and the only way for Unbound to deal with it is also to go
against the specs. The problem is that your server -depending on query
content!- signals support or no support for ECS. It is explicitly the
job of the resolver to cache this information.
What should happen is that the answers of the queries relayed to the
CDN should get a /24 (or whatever you choose) ECS option returned.
Additionally, we may be able to 'punish' less harsh when we get a
stray non-ECS answer while we know /some/ ECS data is available in the
cache. But that comes with its own set of problems (like loss of
caching for certain blocks when some authority server misbehaves), at
this time I'm unsure we should do this.
//Yuri
Looks like it’s not easy to reach a rough consensus about this issue right now. I’ve decided to wait until the draft becomes rfc and to evaluate whether to add this functionality to our DNS server at that time.
The discussion helps me understand this issue much further than I expected. Thank you guys.