On 13. 07. 26 16:38, 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.
The way I interpret it is that it must be legible for humans. I.e. no
binary blobs in EXTRA-TEXT. That does not preclude making the human
readable text machine parseable at the same time. IMHO doing so costs
nothing and opens possibilities.
Right now I know of DNS research surveys which parse EDE EXTRA-TEXT with
vendor-specific rules because there's no other way.
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.
For this specific case, say a diagnostic tool tools might provide detail
than 'AD=0, some NTA somewhere in effect'.
Instead if might say something like ... Answer
wwww.example.com CNAME 1234.cdn.example
1234.cdn.example HTTPS ...
has AD=0 because NTA is activa at cdn.example.com.
And this can be in French because the tool could ingest the EDE + domain
name in structured form and provide localized output.
Or the research stats could actually be made more reliable than
hand-written regexes.
> 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).
Agreed. Let's remove the expiry timestamp and keep structured DNS name
in, then?
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
