Maintained by: NLnet Labs

[Unbound-users] How to config whitelist for EDNS client subnetin unbound

余坤
Fri Jan 9 06:37:13 CET 2015


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.


On Thu, Jan 8, 2015 at 7:01 PM, Yuri Schaeffer <yuri at nlnetlabs.nl> wrote:

> -----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-----
>



-- 
Kun YU
Ph.D. Candidate, Department of Electronic Engineering, Tsinghua University,
Beijing, 100084, China.
Mobile Phone:+86 13466535220
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20150109/4e78172e/attachment.html>