-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlSuY5QACgkQI3PTR4mhavh3GgCdHyj9OdpiJFbc6qTS4XrTW+19 eicAniEDm5AE2PZmS2VBQw6x+exIl4dt =6DK5 -----END PGP SIGNATURE----- _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
