Hi Joe On Mon, Jul 13, 2026 at 10:02:54PM +0200, Joe Abley wrote: > Hey, > > On 13 Jul 2026, at 20:48, Mukund Sivaraman <[email protected]> wrote: > > > RFC 7646 requires a configured lifetime ("NTAs MUST expire automatically > > when their configured lifetime ends. The lifetime SHOULD NOT exceed a > > week."), so the lifetime of a specific NTA is expected to be known in > > advance. It could be extended, but the expiry time of the currently > > configured NTA can be communicated in responses. > > In practice, I don't know a good way of making an end date meaningful. > > NTAs are generally needed when third parties exhibit unpredictable behaviour. > If it was predictable nobody would need an NTA since the zone owner could > simply go unsigned in an orderly fashion. Given that it's unpredictable, > making future-looking statements seems hard. > > An end date that is an hour from now, and which continues to be extended by > an hour at a time until it is allowed to expire, is essentially the same as > not having an end date. An end date that is a week and which gets effectively > truncated when an NTA is removed in twelve hours doesn't seem very helpful > either.
It does not have to contradict what's in RFC 7646 about the configured
NTA expiry time limit. The objective of that RFC text was likely to not
let an NTA stay configured without a re-evaluation for too long.
Observing a change in expiry would communicate that the NTA was
re-evaluated recently. The other choice is being completely blind to how
long upstream has applied the NTA for.
I understand what you mean about not having an accurate estimate or even
that the NTA itself may be removed in advance of expiry, but the time of
the next re-evaluation can be communicated.
>
> This may be an area where operational experience has clarified the
> anticipated uses of NTAs.
>
> > Rather than machine parsing, a DNS support person analyzing traffic
> > would like to know if an NTA is in use (the objective of your draft),
>
> Yep
>
> > what domain it was installed for,
>
> This one also seems obvious, but I think it's worth digging into. Do we want
> the closest-enclosing NTA, do we want to know if there's more than one NTA
> covering the QNAME, do we need to dig into the complexities of CNAME
> processing? What information is the DNS support person looking for beyond
> simply (above) whether an NTA exists?
It could be the farthest (highest/outermost) NTA domain as it would
affect everything under. A DNS support person may want to know what NTA
caused the answer to have AD=0 and how long that condition was
configured to last. Other free-form text may not have any value.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
