> On 25 Jun 2026, at 20:49, Warren Kumari <[email protected]> wrote: > > > On Fri, Jun 19, 2026 at 6:23 AM, Philip Homburg <[email protected]> > wrote: > Something that came up a couple of times, in the context of DELEG and the NS > . proposal, is that there is no way for a server to indicate how long DNS > errors (other than NXDOMAIN) can be cached. > I created a small draft to add a SOA record to the addional section. In the > current version, all processing is entirely optional. Please let me know if > this would be useful. > > > I think that the base idea is great, but I'm not so sure about the " the > server should add a SOA record to the additional section of the reply. [...] > The SOA record MUST have "_error_ttl." as owner name, and as TTL the time to > live of the error. MNAME and RNAME SHOULD be set to ".". SERIAL, REFRESH, > RETRY, and EXPIRE SHOULD be set to 0. For compatibility with existing SOA > processing for NXDOMAIN and NODATA, The MINIMUM field SHOULD be set to the > TTL of the SOA record." > > This feels a little clunky / hacky, and I think something more along the > lines of: > "The server should add the ERROR_TTL resource record (code TBD) to the > additional section of the reply. The server SHOULD keep the Answer and > Authority sections empty and the ERROR_TTL record SHOULD be the first record > of the Additional section." instead. New RR types are (still) cheap, and not > overloading an existing RR type seems to keep the intent clear.
Would an SVCB record (or more likely a derivative, like HTTPS is a “subclass”) be appropriate for this use case with something like a service parameter key of error_ttl? This might allow for the (inevitable?) scope creep when some one says we have an error TTL but now also want parameter X. Just a thought. Cheers, Jim _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
