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.
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?
> and how long it is expected to be in
> use.
Joe
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
