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

Michael Richardson <[email protected]> Sun, 28 Jun 2026 14:09:01 -0400
Newsgroups gmane.ietf.dnsop
Message-ID <[email protected]>
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

...
    > I also think that the document should provide a bit more guidance on what
    > the server might want to set the TTL value to.

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.

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?

I'd appreciate knowing if public nameserver operators are able to quantify
the impact of this proposal from logs/simulations/?   {Warren, not
specifically directed at you, but maybe something you would be able to think
about}

about:
} "This also prevents introduction of new protocol elements where authoritative
}   servers intenionally return a SERVFAIL for certain queries."

I'm intringued as to what you have in mind.

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.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email protected]  http://www.sandelman.ca/        |   ruby on rails    [
]       My working hours and your working hours may be different.            [
]  Please do not feel obligated to reply outside your normal working hours   [

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 487 B)
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmpBYz0ACgkQgItw+93Q
3WV7aQf8DNyp6gvyZiS8Q7gkdT03j4/3hxQ7yM508mhl3RPlpktNXTzkEhlLvvJi
RNnC9qrCusnX9M3CxotL1oQIn/eqR39c0xE6gH/pdJ6137RIhyZf4X7u4LrDK/xU
UZZ6nCFVAiwaWdClICbBr/pzflcQEsGdyb65OWbyZwDZHZMF5mbmMjJHxSRzjy6e
/UCRmNjR/M3vgvdU6D8ZTecTY458THAntIT8xIrpet1AN8vqCP8synT9+oaWJ4MY
fXIpvRtkpFTa60i5PF72DybT52QQWZGRjXL7g0xvA51HbwAEQInI/msOdSMMkGM4
qg/34cKOXxoEXoki0hoftgVqRkzGPA==
=lv1F
-----END PGP SIGNATURE-----