On 13. 07. 26 16:20, Petr Špaček wrote:
On 17. 06. 26 12:47, Joe Abley wrote:
Babak, Sebastiaan and I put pen to paper and came up with the following:
https://datatracker.ietf.org/doc/draft-farrokhi-dnsop-ede-nta/
https://github.com/farrokhi/id-ede-nta (working copy)
Good idea!
In section 2:
This EDE is intended for use in DNS responses sent by a DNS resolver
with a configured NTA and SHOULD NOT be included in other responses.
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 an occurrence of SHOULD NOT should (see what I did there) have
an explanation under what conditions it can be violated, and I can't
think of any.
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.
Urgh, I hit Send button too soon.
Ad > 5. Security Considerations
Clients that require integrity protection of these signals should use an
authenticated and encrypted transport between client and resolver, such as DNS
over TLS [RFC7858] or DNS over HTTPS [RFC8484]. See Section 6 of [RFC8914] for
more discussion.
Could we drop the encryption part? TSIG or SIG(0) is a fine integrity
protection, too. No need to encrypt when it's not needed.
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]