> On 9 Sep 2020, at 15:35, Ben Schwartz <[email protected]>
> wrote:
>
> Caching at the CPE reduces upstream resolver load by quite a lot more than
> you might imagine not actually a big problem but it’s nice to avoid adding
> compute if there is a cheaper solution trivially available.
> It sounds like the key goal here is caching at the CPE; the other goals could
> be served by client-specific logic at the central resolver. Do ISP-provided
> CPEs normally operate a DNS cache? My understanding was that they are
> usually mostly-stateless forwarders.
>
Yes lots of ISP-provided CPEs do caching. There is a draft in the ADD WG that
describes this for at least 3 large ISPs in Europe.
There are other reasons for wanting to do DoH in the CPE, such as performing
DNS filtering on the CPE.
BTW I’d interested in how “client-specific logic at the central resolver”
solves the connection count issue?
> * How does the server know which CPE to redirect the client to?
>
>
>
> I’m are assuming here that this is an ISP running both elements so knowing
> how to map the incoming IP to the name its currently using / was told to use
> is relatively trivial.
>
>
> Trivial, perhaps, but not necessarily secure. An adversary in the network
> could alter the IP headers to change the apparent client location, causing
> the client to be redirected to an attacker-controlled CPE, thus defeating the
> integrity assurances of DoH.
Possible, but I’m not sure this is a practical attack. The attacker would need
to be able to also change all the IP headers in the return packets to their
original values (that’s hard enough to do for legit purposes). 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.
Neil
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
