<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

I'm aware of this and don't consider it an issue. It is doing best</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

effort for ECS queries to non whitelisted servers, but does not go the</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

extra mile to get an optimal answer. A quick explanation on what is</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

happening:</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

at 1) the query is not in the cache, a full recurse is started. Since</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

you don't have the particular authority whitelisted no ECS is passed</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

to it. The answer will end up in the regular cache. Subsequent queries</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

are looked up in that cache directly without going to the whole module</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

chain, making it cheap.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

at 2) ECS is passed in the query, this time the initial cache lookup</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

is skipped as ECS queries are in a secondary cache. Of course this</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

cache is empty and thus a full recurse is started. This recurse grabs</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

records from the cache as much as possible and indeed, the record is</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

in the cache and no packets need to go over the wire.</blockquote></blockquote><div><br></div><div>This creates an issue where you have a user coming in with ecs <a href="http://1.2.3.0/24">1.2.3.0/24</a> gets the correct answer, then user coming without ecs get the default answer and finally user with ecs <a href="http://1.2.4.0/24">1.2.4.0/24</a> get default instead of the correct answer.  To me and for my use this is a major show stopper.  Is there anyway the look up order could be reversed if ecs is enabled?  So that all queries first try ecs then goto normal cache?</div>

<div><br></div><div>Thanks,</div><div>Larry </div></div><div class="gmail_extra"><br clear="all"><div>-Larry</div>
<br><br><div class="gmail_quote">On Fri, May 2, 2014 at 4:55 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">

<div class="">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Hi Larry,<br>
<br>
</div>Thank you, this is very useful indeed!<br>
<div class=""><br>
> 1) The returned record does not update based on geoip when using<br>
> different subnets.  This happen only when the first request a given<br>
> name does not have a client subnet passed with it:<br>
><br>
</div>> 1) dig: answer x 2) dig +client: answer x (<a href="http://110.232.0.0/24/0" target="_blank">110.232.0.0/24/0</a>) 3)<br>
> flush cache 4) dig +client: answer y (<a href="http://110.232.0.0/24/19" target="_blank">110.232.0.0/24/19</a>)<br>
<br>
I'm aware of this and don't consider it an issue. It is doing best<br>
effort for ECS queries to non whitelisted servers, but does not go the<br>
extra mile to get an optimal answer. A quick explanation on what is<br>
happening:<br>
<br>
at 1) the query is not in the cache, a full recurse is started. Since<br>
you don't have the particular authority whitelisted no ECS is passed<br>
to it. The answer will end up in the regular cache. Subsequent queries<br>
are looked up in that cache directly without going to the whole module<br>
chain, making it cheap.<br>
<br>
at 2) ECS is passed in the query, this time the initial cache lookup<br>
is skipped as ECS queries are in a secondary cache. Of course this<br>
cache is empty and thus a full recurse is started. This recurse grabs<br>
records from the cache as much as possible and indeed, the record is<br>
in the cache and no packets need to go over the wire.<br>
<br>
Had the server been whitelisted, unbound would have sent ECS to it in<br>
step 1). And the answer would not end up in the regular cache.<br>
<div class=""><br>
> 2) The TTL returned when edns-subnet is passed does not change over<br>
</div>> time: 3) unbound-control marks all edns-subnet hits as misses:<br>
<br>
Indeed! I had not considered this before. I see what I can do after<br>
the weekend. Thanks for reporting your findings.<br>
<div class=""><br>
Regards,<br>
Yuri<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1<br>
Comment: Using GnuPG with Icedove - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
</div>iEYEARECAAYFAlNkMGIACgkQI3PTR4mhavhdhwCgwFqfYZUtbUJhNrZ2bljhOqJA<br>
9zoAnRnmH3FAA25iclZIQ0RdlyqbZYoy<br>
=HPAS<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br></div>