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]
