> On 9 Sep 2020, at 17:53, Ben Schwartz <[email protected]> wrote: > > > There are other reasons for wanting to do DoH in the CPE, such as performing > DNS filtering on the CPE. > > This could equally be by client-specific logic on the central resolver, as > demonstrated by NextDNS. >
Agreed, and it’s being done by many folks, not just NextDNS (all large UK ISPs have had the capability do this for over 5 years, and it’s used by millions of consumers). > BTW I’d interested in how “client-specific logic at the central resolver” > solves the connection count issue? > > It doesn't, but caching does, hence my conclusion that caching is the focus. I’m not sure I follow. The CPE could do no caching, and the central resolver would still benefit from the decreased connection count, just not a decreased query load. > > Also, the attacker has to have compromised an ISP-managed CPE, and that CPE > still needs to be running on an ISP-managed network connection. > > Maybe. As Alister noted, in some models the subscriber can acquire a DV cert > for the name without reaching inside the CPE. I think these are notional models - I’m not aware of any CPEs supporting a DoH forwarder currently. Certainly if it were to be done, securing the keying material would be extremely important. Neil
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
