On Wed, Jun 14, 2023 at 12:09:23PM -0400, Peter Thomassen wrote:
> > But the focus changes. For example, if we consider that "spoofing by
> > recursive server" is a threat, then having the recursive set bits to
> > affirm that the response is verified is not much of a protection --
> > the emphasis should move to verification by the client. I would love
> > to see this discussed.
>
> I agree that client-side validation would be ideal. One important
> aspect here is to save on the latency caused by extra queries; my
> impression is that this extra cost is generally considered
> prohibitive.
Not sure what you mean by "generally" (is that the browser use case)?
In Postfix, a caching validating resolver is expected to be and is
typically local (127.0.0.1). The latency cost is minimal and SMTP
is not nearly as latency sensitive as HTTP (with all the ads and
javascript the browser has to fetch in addition to the main page
content).
> Experimental protocols for this have been published. Specifically, RFC
> 7901 and RFC 9102 come to mind.
These are not always needed. A local resolver is a good option anywhere
where last-mile middleboxes don't MiTM and break access to DNSSEC.
> I'm not aware of any implementations of these protocols -- I think
> having software support, perhaps experimental, in some of the common
> software packages would be REALLY cool.
Some folks at NLNetLabs had implementations in progress IIRC.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
