<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 6, 2015 at 10:07 PM, Miek Gieben <span dir="ltr"><<a href="mailto:miek@miek.nl" target="_blank">miek@miek.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[ Quoting <<a href="mailto:yuri@nlnetlabs.nl" target="_blank">yuri@nlnetlabs.nl</a>> in "Re: [Unbound-users] How to config w..." ]<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Larry,<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
I think the best way to avoid getting non ecs answers when ecs is present would be to always pass the query to the ecs module.  Yes<br>
this would slow down non ecs queries, but would avoid the issue of<br></span>
returning a non ecs answer to an ecs query.  acceptable to anyone who chooses to enable ECS.<br>
</blockquote><span class="">
<br>
I'm afraid this would not work sufficiently. Unbound does not know<br>
which source addresses get handled incorrectly by the authority. Thus,<br>
if no match is found in the subnet-cache has no choice than to ask the<br>
authority. Effectively Unbound won't be able to cache at all for the<br>
CDN queries.<br>
</span></blockquote>
<br>
this is effectively the text in the draft:<br>
<br>
   If the address of the client does not match any network in the cache,<br>
   then the Recursive Resolver MUST behave as if no match was found and<br>
   perform resolution as usual.  This is necessary to avoid suboptimal<br>
   replies in the cache from being returned to the wrong clients, and to<br>
   avoid a single request coming from a client on a different network<br>
   from polluting the cache with a suboptimal reply for all the users of<br>
   that resolver.<span class=""><br><br></span></blockquote><div>This is why I believe compiling a list of DNS servers who support client subnet is not enough. There should be another option to config a list of domains which supports client subnet. Any records in these domains should be cached in secondary cache instead of the primary one.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are two ways to look at this IMHO:<br>
1) The setup is broken, you can't have authorities answer differently<br>
and always expect to have an optimal answer.<br>
</blockquote>
<br></span>
? Isn't this exactly what a CND dns server does?<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
2) The draft is broken because it can not deal with this setup.<br>
<br>
I fail to see a way to fix this problem AND adhere to the draft AND<br>
not cause unexpected failures for anyone else. I'm open for fresh<br>
ideas though.<br>
<br>
Regards,<br>
Yuri<br></span><span class="">
______________________________<u></u>_________________<br>
Unbound-users mailing list<br>
<a href="mailto:Unbound-users@unbound.net" target="_blank">Unbound-users@unbound.net</a><br>
<a href="http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users" target="_blank">http://unbound.nlnetlabs.nl/<u></u>mailman/listinfo/unbound-users</a><br>
</span></blockquote>
<br>
/Miek<br>
<br>
--<br>
Miek Gieben<div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
Unbound-users mailing list<br>
<a href="mailto:Unbound-users@unbound.net" target="_blank">Unbound-users@unbound.net</a><br>
<a href="http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users" target="_blank">http://unbound.nlnetlabs.nl/<u></u>mailman/listinfo/unbound-users</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><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：+86 13466535220</span><br><font color="#888888"><br></font></div></div></div>
</div></div>