On 22. 07. 25 19:32, Mark Nottingham wrote:
Hi all,
After the discussion on Monday, I had a look through structured-dns-error-15 to
see if anything would clash with what we're thinking of in
draft-nottingham-public-resolver-errors.
In short, it appears that updates by the authors address many of the issues I
found previously; there are only a couple left that would raise concerns for me
if the two drafts were kept separate. See below for those, along with some
comments and questions I had along the way (that don't affect that decision).
## Issues
- 5.2 prohibits using sub-error codes in 'Censored' responses. That seems
excessive; conceivably, they might conceivably be needed down the road.
- Section 5.3 step 2 requires the use of encrypted DNS, otherwise the extra
information is thrown away. Conceivably, some clients may have enough
information available to trust non-encrypted DNS at some future time. I agree
with the notion that the client should evaluate the context of the DNS resolver
and make decisions based upon that regarding how to use the information -- and
that definitely involves whether the connection is encrypted -- but baking it
into the algorithm like this precludes them from any future flexibility, no
matter what the use case.
If WG consensus on this is firm and fully informed, so be it, but I thought I
heard an indication that there was a subtle shift away from such draconian
measures in the discussion on Monday.
- Similarly, 5.3 step 6 puts constraints on the information available to
clients who have enabled a DoT opportunistic privacy profile. This likewise
seems to take any discretion out of the client's hands and bakes it into the
algorithm.
- Same question for step 7 regarding opportunistic discovery.
I agree with the angle 'do not mandate DoT/this single encryption method'.
There's plethora of technologies to secure DNS data in transit: TSIG,
SIG(0) / TKEY, IPsec or any VPN in general, DoT, DoH, DoQ, resolver on a
local socket, to name a couple.
I don't see why specification should pick one or two out of many.
(Implementations will, of course, but IMHO spec should not.)
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
