Please excuse my butting in rudely :-) It sounds like the problem to solve is primarily about preventing retry storms (e.g. "Problems with rapidly retrying clients "). At my place of work, we have run into retry storms in many of our systems (including DNS but also many other APIs) and have had to learn to adapt. I wonder if the approach that worked for us might also help here.
>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. 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. I'm pretty sure many of us have seen some pretty nasty events caused by resolver retry storms. If the RFCs were to recommend and common resolvers like Unbound, BIND and Knot were to implement this kind of retry mechanism, I think it might have the effect you want - without having to trust the server side. Of course, it would take time to bear fruit, but as it doesn't change the protocol, it might be less intrusive than adding SOA records in error responses. Marc, a colleague and leader on this effort, has written about this: https://brooker.co.za/blog/2022/02/28/retries.html https://builder.aws.com/content/3EumjoZascWd1oZiEgL8ORlv3qE/timeouts-retries-and-backoff-with-jitter Gavin On Mon, Jun 29, 2026 at 7:48 AM Philip Homburg <[email protected]> wrote: > >As I first read about this, I thought it was going to help with root > >nameserver load due to idiots, but idiots won't be implementing sane > things, > >so it's not about that. > >It seems late in the game to add this, unless it is supported by > significant > >operational savings/resilience. > > In my mind this is in the same category as EDE. Servers insert EDE options > without knowing whether the client can do anything with the EDE or not. > Inserting an EDE is relatively cheap. > > Likewise, inserting an extra record in an error reply is relatively cheap. > > >At first, I also thought that this was going to be between authoritative > and > >recursive resolvers, but reading fully tells me that this is between > >recursive and stub/local-cache resolver? > > It is intended for all paths where there is a client and a server and where > the server has to reply an error (other than NXDOMAIN). So stub to recursor > or stub to forwarder, forwarder to recursor (or another forwarder), > recursor to authoritative, etc. > > >about: > >} "This also prevents introduction of new protocol elements where > authoritativ > >e > >} servers intenionally return a SERVFAIL for certain queries." > > > >I'm intringued as to what you have in mind. > > This came from a DELEG discussion. A nameserver that serves a zone with a > DELEG-only delegation may get a query from a client that is not DELEG-ware. > It was proposed to return SERVFAIL in that case. However SERVFAIL was > considered a bad idea because it will not be cached long enough leading > to extra load on the server. > > >I also have come to understand that many things that historically were > added > >to additional section are now not added, and clients are expected to be > very > >suspicious of things there. I understand how we got to this, I'm sad > because > >DNSSEC ought to have made this safe, but lack of DNSSEC made this > practice > >into a problem. > > Maybe I can counter with EDNS(0) and TSIG which are part of the additional > section and are widely supported. I can see your point. But the risk is > mainly taking normal records from the additional section. For normal > records, > it is easy enough to send a separate query and get a better answer. > > Metadata like EDNS(0) and TSIG is both less risky and impossible to get > in another way. I think the error TTL also fall into this category. > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
