[DNSOP] Re: Disclosure of Negative Trust Anchors in DNS Resp onses (draft-farrokhi-dnsop-ede-nta-00)

Mukund Sivaraman <[email protected]> Tue, 14 Jul 2026 02:48:08 +0800

Newsgroups	gmane.ietf.dnsop
Message-ID	<alUy6INH5HtgD95_@p5>

Hi Joe

On Mon, Jul 13, 2026 at 04:38:36PM +0200, Joe Abley wrote:
> On 13 Jul 2026, at 16:21, Petr Špaček <[email protected]> wrote:
> 
> >> For example, a DNS response sent by an authoritative-only DNS server, which does not perform validation and hence has no obvious use for an NTA, SHOULD NOT include this EDE.
> > 
> > Why not MUST NOT?
> 
> I think MUST NOT is fine. And I agree with you that a SHOULD should ideally be accompanied with some discussion that helps an implementer make decisions. 
> 
> I would normally couple a MUST NOT send with advice about what to do if you receive on anyway, but so long as these are human-targeted, informational debugging messages perhaps that doesn't matter much. But see below.
> 
> > Personally I think machine parseable EXTRA-TEXT would be a good idea. Something like
> > {"d": "example.com", "e": "2026-07-30T00:00:00Z"}
> > or so.
> 
> RFC 8914 says that EXTRA-TEXT "is intended for human consumption (not automated parsing)" so I am not sure personally what I think about structuring the field to deliberately make it easier to parse. We put something in there about structured dns errors but I had some mild remorse about that after we published. 
> 
> If there was a really good use case for machine-parsing the information in the EXTRA-TEXT perhaps that would be convincing, but I can't really think of one. The idea of communicating an end date seems superficially attractive, but NTAs are usually a reaction to an unplanned event, and the thing about unplanned events is that their timing is difficult to know ahead of time (end times as well as start times).

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.

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),
what domain it was installed for, and how long it is expected to be in
use.

		Mukund

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

signature.asc (application/pgp-signature, 1.5 KB)