-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Larry,
> This creates an issue where you have a user coming in with ecs > 1.2.3.0/24 gets the correct answer, then user coming without ecs > get the default answer and finally user with ecs 1.2.4.0/24 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 1.2.4.0/24 would get an answer from the ecs cache. In case it was not in cache an upstream lookup would be done with ecs 1.2.4.0/24. 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 answer. 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, Yuri -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlNorSsACgkQI3PTR4mhavhdeACfUpkA6wiZMnzgTbgN/ZKcYL65 JdkAniIjFO1w00N3rnPU+Yy55C16Mx/X =lk90 -----END PGP SIGNATURE----- _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
