>From the thread, I understand the proposed approach is for the server to >effectively tell the client how long to wait between retries (aka how long >to cache the failure). At least one downside some have pointed out is that >you can't really trust the error response is authentic.
As I pointed out in an earlier mail, if an attacker can somehow spoof this error TTL then the attacker can do very similar damage in the current DNS protocol. So the fact that this is subject to the same limitations as the existing DNS protocol doesn't strike me as a good reason to find a different solution. >I think there are >probably other challenges like figuring out, in practice, what to set that >TTL value to - I suspect it may depend on the circumstances. > >An approach that has worked out well for us has been what we call an >"adaptive" or "token-bucket based" retry mechanism, implemented purely by >the client. The idea is that the client will retry readily in response to >occasional errors, but if errors persist, and retrying is not helping, >quickly exhaust the retry token bucket and retries slow down. Typically the problem with client side solution is that the server has no control what so ever. This leads to a complex discussion about what are reasonable parameters for the client. We have such an RFC: RFC 9520 (Negative Caching of DNS Resolution Failures). The problem is that limits specified in this RFC do not apply to all situations. Note that this draft does not require specific client behavior. A client could (within the limits set by RFC 9520) implement the retry mechanisms you propose. The only difference is that with error TTLs the client can use longer intervals between retries than allowed by RFC 9520. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
