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

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).


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