Interesting. This approach is similar to the lists curated by Frank and people from dnscrypt-proxy: https://dnscrypt.info/public-servers
Assuming that separating protocol change from trust model change is a no-go, then the trust would need to go both ways - the network operator would need to push the list of resolvers that she considers trusted, and the client would crosscheck that list to its provisioned configuration (or list downloaded from a public service such as this etc.). This is conceptually similar to NPN/ALPN. Marek On Sun, Aug 19, 2018 at 11:35 AM, Tom Pusateri <pusat...@bangj.com> wrote: > > > On Aug 19, 2018, at 9:29 AM, Livingood, Jason <jason_living...@comcast.com> > wrote: > > On 8/18/18, 7:03 PM, "DNSOP on behalf of bert hubert" > <dnsop-boun...@ietf.org on behalf of bert.hub...@powerdns.com> wrote: > Especially when such a move will incidentally kill intranets, VPNs, split > horizon, DNS monitoring & DNS malware detecion and blocking. > > It seems to me that the underlying protocol is separable from the > operational implementation, and the latter case is likely where most of the > concerns lie. Thus, the issue is likely less DoH itself but rather how it is > likely to be deployed. > > I am considering starting work on a draft along the lines of 'potential > impacts of DoH deployment' to try to document some of this, if for nothing > else than to organize my own thinking on the matter. This is because I also > share concern, given the apparent deployment model, around what may break in > enterprise networks, malware detection & remediation, walled garden portals > during service provisioning, parental controls, and the impacts of > eliminating other local policies. The CDN-to-CDN competition case is an > interesting one as well, with respect to passing EDNS client subnet or not. > > JL > > > In the DRIU BOF, I mentioned establishing a reputation service for public > DNS resolvers. With a JSON interface, this could lead to users conveying > some trust of a public service or more likely, the inverse of trust for > operating systems or stub resolvers to whitelist/blacklist public DNS > resolvers. > > I tried to summarize it here: > > https://dnsdisco.com/reputation-post.html > > Or you could go listen to the proceedings of the DRIU BOF. > > Thanks, > Tom > > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
