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

Libor Peltan <[email protected]> Fri, 26 Jun 2026 07:26:13 +0200
Newsgroups gmane.ietf.dnsop
Message-ID <[email protected]>
I welcome that this draft opens a really needed topic in DNS. Problems 
with rapidly retrying clients whose queries lead to errors are real and 
painful for many DNS operators.

However, I don't see how this solution can work. As the draft even 
acknowledges, the attacker can spoof the error+TTL response, since the 
crafted SOA (or whatever RR type) can't be DNSSEC-secured.

Even when the TTL would be (upper bounded to) several seconds, can't the 
attacker simply DoS anything easily by repeatedly poisoning the cache 
with error+TTL?

Libor

On 19. 06. 26 12:19, Philip Homburg 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.
>
> -------- Forwarded Message --------
> Subject: 	New Version Notification for draft-homburg-dnsop-dettl-00.txt
> Date: 	Fri, 19 Jun 2026 03:13:28 -0700
> From: 	[email protected]
> To: 	Philip Homburg <[email protected]>
>
>
>
> A new version of Internet-Draft draft-homburg-dnsop-dettl-00.txt has been
> successfully submitted by Philip Homburg and posted to the
> IETF repository.
>
> Name: draft-homburg-dnsop-dettl
> Revision: 00
> Title: Add TTLs to DNS errors
> Date: 2026-06-19
> Group: Individual Submission
> Pages: 4
> URL: https://www.ietf.org/archive/id/draft-homburg-dnsop-dettl-00.txt
> Status: https://datatracker.ietf.org/doc/draft-homburg-dnsop-dettl/
> HTML: https://www.ietf.org/archive/id/draft-homburg-dnsop-dettl-00.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-homburg-dnsop-dettl
>
>
> Abstract:
>
> When a DNS server replies an error other than NXDOMAIN, there is no
> mechanism to specify how long this error can be cached by the
> recepient. This document introduces a mechanism where a server can
> specify the time to live (TTL) of an error by adding a SOA record to
> the additional section of a reply. Clients can use this TTL at their
> discretion. In particular, clients can limit the TTL to a maximum
> value, impose a minimum value or just ignore the TTL value all
> together.
>
>
>
> The IETF Secretariat
>
> _______________________________________________
> 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]