On Thu, 11 Jul 2019, Paul Hoffman wrote:
Comment> If the stub resolver is already using DoH with the recursive resolver,
why does it have to determine the URI template of the DoH server?
One example is that the stub or browser may want to change DoH servers, such as
if it has discovered one that has a better security policy.
I find the term "security policy", a bit unnerving here. A DNS server
is either secure (and tells the truth), or it is not secure (and tells
lies). There is no "better". Some people say lying is more "secure for the
user", but that can really only come from a pre-existing configuration,
not a random DNS server offered by your random local network.
I think the better term here is "privacy policy". We kind of assume
all DoH severs are "secure" (at least for their transport, see above)
but we feel we can trust some DoH servers more than others for privacy.
2) DHCP clients typically have no secure and trusted relationships to DHCP
servers, how will the client know it is communicating with the recursive
resolver hosted in the attached network ?
It will not. This has always been the problem with DHCP, and efforts to make
DHCP authenticated have not borne fruti.
And since the prime advantage of DoH is privacy, and you cannot
have privacy without an authenticated encrypted channel, using a
randomly announced third party DoH server gains you little (and surely
unmeasurable) privacy. Unless you already trust the DoH server announced,
but than you hardly need the DHCP announcement. Just setting up the
connection to the DoH servers you trust (and have certs/CA for) until
one works. If those fail, you might as well use UDP 53 to whatever DHCP
gave you.
In the future, DHCP and/or DCHPv6 and/or RA may have options that
allow the configuration to contain the domain name of a resolver. If
so, this can be used for matching the domain name in the TLS
certificate.
As stated above, I see only very little use in this.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
