> One possibility to counter that a new ENDS option: - 16 bit value > as number of milliseconds the client is willing to wait.
I recognize the problem, but I doubt that this solution will solve it. This option may work with a very simple client that sends a query and then waits for a fixed amount of time before doing anything else. But what about more advanced forwarders or stub resolvers. What if a query is sent to upstream A, then X milliseconds later to upstream B, and Y milliseconds later to upstream C. If a reply comes in, the request is effectively terminated but the other upstreams don't know and continue with the query. Or what if a forwarder has downstream clients that use this option and the clients have different timeout values. A first client sends a query with a short timeout. The request fails, does that get cached? Then another client send the same query with a longer timeout. Does a cached answer get returned even when the timeouts are different? Finally, DNS works because of caching. An occasional expensive query is expected and tolerated when most queries can be answered from the cache. So with these issues, maybe there is an underlying caching issue that should be resolved. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
