On 20 Aug 2018, at 17:47, Tom Pusateri wrote:
On Aug 20, 2018, at 12:42 PM, Tony Finch <d...@dotat.at> wrote:
Marek Vavruša <mvavrusa=40cloudflare....@dmarc.ietf.org> wrote:
https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive.txt
This is interesting to me because I want to support DoTH on my campus
resolvers.
Regarding DoH, the DHCP option ought to include a URI template (there
isn't a .well-known for DoH). I plan to set up my servers so that
misdirected attempts to get web pages from the DoH server are
redirected
to the relevant documentation; that's much easier if the DoH endpoint
isn't at the server root.
Our variant of this same idea that Willem Toorop and I presented at
the DRIU BOF in Montréal has a URI for the DoH case:
https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00
<https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00>
But let me remind everyone that there was a lot of people agreeing
with Ted in Montréal and so far, Ted appears to be standing all by
himself.
Where are all the other folks that shot down this idea earlier? :)
Judging what was said at an excited mic line is always challenging. :-)
Two issues are being conflated here:
1) a DHCP option to include a URI template
2) how the DHCP client in an OS would use that option
DHCP options are easy and cheap. However #2 was vexing. The proposal
that an OS say "oh look, there is a DoH server, I'll use that because it
is more secure than Do53" was what was controversial because of the
utter lack of DHCP security. Some of the folks on the mic line disagreed
with the assumption that, given two pieces of insecurely-acquired
information (a Do53 address and a DoH template) that the latter would
result with a more secure connection. A network admin can see the port
53 traffic and see if there's crap in there; they can't see the inner
DoH traffic.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
