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