[DNSOP] Re: Add TTLs to DNS errors (draft-homburg-dnsop-de ttl-00.txt)

Jim Mozley <[email protected]> Fri, 26 Jun 2026 15:24:42 +0000
Newsgroups gmane.ietf.dnsop
Message-ID <[email protected]>

> 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]