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.
- 10.2 puts specific requirements on browsers (as opposed to clients) -- is
that intentional?
## Comments
- Section 3 ("DNS Filtering Techniques and Their Limitations") should be moved
to an appendix; it has a very different character as compared to the rest of
the specification.
- Because this specification requires use of I-JSON, it should be clarified
whether non-conforming messages are required to be rejected. See RFC7493
Section 3. I'd suggest this NOT be required (but we still need to be explicit
about that).
- Making 'j' mandatory seems excessive; most of these responses will never be
seen by "IT staff" and the justification may be self-evident from other fields.
- Requiring contact details for reporting seems... optimistic, and will likely
lead to 'do-not-reply' style addresses being used. I'd suggest making this a
SHOULD.
- 10.2 "The value consists solely of an organization name and does not contain
any additional free-form content such as instructions, URLs, or messaging
intended to influence the end-user behavior." Is this implementable? The
context seems to imply it can be done in an automated fashion.
- 11.1 Has a registry column for 'mandatory'. It should be noted that new
mandatory extensions can't be introduced in a backwards-compatible way, and so
this should always be 'no' for extensions registered after the initial RFC
publication.
- 11.2 Probably needs to say that contact URI schemes must be registered URI
schemes.
Cheers,
--
Mark Nottingham https://www.mnot.net/
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
