On Mon, Mar 16, 2026 at 11:22:37AM +0100, Vittorio Bertola wrote: > Indeed, to become useful, this document would need a much broader > diversity in its authors and content in terms of geography, vendors > / backgrounds, and approaches, and include references to past work > on these topics (e.g. RFC 7754).
Besides the process issues (dnsop or another working group or even another SDO), there are other important problems with this draft: * the general tone is very much in support of these kind of resolvers (IETF terminology is "Policy-implementing resolver", see RFC 9499, section 6, do not say "protective"). But some people regard them as very questionable (using the infrastructure to implement policy, instead of doing it in the endpoints like, for instance, a blocklist in a Web browser). The document should be modified to look less than an advertisment. * because this kind of "policy-implementing" resolvers have an obvious use in censorship (and are actually used for that), people are, and rightly so, very sensitive about the entire concept. (The draft mentions censorship but washes it away too quickly.) * security analysis should be more detailed, for instance, sending a IP address (instead of REFUSED or NXDOMAIN), in the hope that clients will HTTP-connect to it raise a very big privacy issue (mentioned in the draft but it is way too short). _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
