<div dir="ltr">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.<div>The discussion helps me understand this issue much further than I expected. Thank you guys.</div><div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 8, 2015 at 7:01 PM, Yuri Schaeffer <span dir="ltr"><<a href="mailto:yuri@nlnetlabs.nl" target="_blank">yuri@nlnetlabs.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</span><span>> If <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> is not a good idea, how about setting the prefix<br>
> length as max-client-subnet-ipv4 option?<br>
<br>
</span>We've performed some thought experiments with this idea as well.<br>
However this would create some new problems.<br>
<br>
My objections:<br>
- - This goes against the specifications.<br>
- - We'd be making up authoritative data.<br>
<br>
I believe that the setup you are describing is not compatible with the<br>
draft and the only way for Unbound to deal with it is also to go<br>
against the specs. The problem is that your server -depending on query<br>
content!- signals support or no support for ECS. It is explicitly the<br>
job of the resolver to cache this information.<br>
<br>
What should happen is that the answers of the queries relayed to the<br>
CDN should get a /24 (or whatever you choose) ECS option returned.<br>
<br>
Additionally, we may be able to 'punish' less harsh when we get a<br>
stray non-ECS answer while we know /some/ ECS data is available in the<br>
cache. But that comes with its own set of problems (like loss of<br>
caching for certain blocks when some authority server misbehaves), at<br>
this time I'm unsure we should do this.<br>
<span><br>
//Yuri<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1<br>
<br>
</span>iEYEARECAAYFAlSuY5QACgkQI3PTR4mhavh3GgCdHyj9OdpiJFbc6qTS4XrTW+19<br>
eicAniEDm5AE2PZmS2VBQw6x+exIl4dt<br>
=6DK5<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr">Kun YU<div>Ph.D. Candidate, Department of Electronic Engineering, Tsinghua University, Beijing, 100084, China.</div><div><span style="color:rgb(0,0,0);font-family:arial;font-size:14px;line-height:23.799999237060547px">Mobile Phone：<a href="tel:%2B86%2013466535220" value="+8613466535220" target="_blank">+86 13466535220</a></span><br><font color="#888888"><br></font></div></div></div>
</div></div></div>