Maintained by: NLnet Labs

[Unbound-users] edns client subnets

Yuri Schaeffer
Tue May 6 11:36:43 CEST 2014

Hash: SHA1

Hi Larry,

> This creates an issue where you have a user coming in with ecs 
> gets the correct answer, then user coming without ecs
> get the default answer and finally user with ecs get
> default instead of the correct answer.

Did you test this?

I believe this is not what would happen. The final user asking for ecs would get an answer from the ecs cache. In case it was not in
cache an upstream lookup would be done with ecs Yielding the
most accurate response.

Also, I'd like to stress that an answer from the 'regular' cache is not
wrong, merely suboptimal. It is what a non ECS aware resolver would

Please note there is no need for the clients to 'speak' ECS. When you
whitelist a server to do ECS Unbound will ask it for the most specific
answer for its client. Relaying ECS, specially to non-whitelisted
servers is a courtesy to the client and not mandated by the draft.

> To me and for my use this is a major show stopper.

I'm interested in your usecase and what functionality you are looking
for. What do you expect from a recursor? Do you not intent to use the
whitelist functionality?

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

While possible it would affect every single incoming query. It is
assumed ECS is only communicated with a fraction of authority servers.
It would mean a significant performance hit, especially since the ECS
cache is not a straight forward key:value lookup.

Best regards,
Version: GnuPG v1
Comment: Using GnuPG with Icedove -