Wouldn’t that be simpler to use SRV, and require no new RRTYPE? If a
previously-granted resolver via DHCP was 192.168.1.1, then a lookup and
result of:
_doh._tcp.1.1.168.192.in-addr.arpa. 86400 IN SRV 10 60 443
dns-doh.example.com.
…would provide the client with a DOH resolver at
“dhs-doh.example.com” after a subsequent and hopefully final non-DOH
lookup on the name(s). Or multiple DOH resolvers could be returned, if
one wished to use SRV expansion to its full extent.
I know there are some leakage problems here in certain cases to
upstream resolvers, and there is a serious fundamental problem with the
first-query (bootstrap) trust chain in a practical sense, but the same
issue exists with a new RR type and I suspect will be far longer to
implement a new RR type than to use SRV which already exists. I see the
risks as close to identical.
“DOH” of course isn’t an official service name, but RFC2782
allows for service names that are local, so maybe there is a task to get
“doh” turned into an official service name but in the meantime it
can work without official nomenclature. It’s entirely possible
“doh” is already on track or listed as a service name and I’ve
missed it, despite the fact that it is really just HTTPS, even though
we’re overloading the service type, as seems to be the case for
[everything]-over-HTTPS. That seems thin as an objection.
I’m probably overlooking an obvious reason that this isn’t a use
case for SRV, but it’s been a long day in a different timezone than
I’m used to. Slings and arrows welcome.
JT
On 23 Aug 2018, at 17:01, Paul Hoffman wrote:
Greetings again. Some of the people in the recent thread about
"dynamic discovery of secure resolvers" have expressed an interest in
something that was mentioned at the DRIU BoF in Montréal: they want
their browser to use a DoH server that is related to the DNS resolver
that their OS is already using. I don't think DHCP can help with that
problem (I could be wrong), but I do think that resolver operators
should be able to tell browsers the DoH resolvers that they would want
their customers to be using.
Please see the draft below. If folks like it, I can continue to work
on it. Or, if you like the use case but have a better technical
solution, that would be great too. I wanted to bring it to this list
before taking it to the DOH WG because it really is an operational
issue, not all that related to the DoH protocol.
Thoughts?
--Paul Hoffman
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Associating a DoH Server with a Resolver
Author : Paul Hoffman
Filename : draft-hoffman-resolver-associated-doh-00.txt
Pages : 8
Date : 2018-08-23
Abstract:
Some clients will want to know if there are one or more DoH servers
associated with the DNS recursive resolver that the client is already
using. This document describes a protocol for a resolver to tell a
client what its associated DoH servers are.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hoffman-resolver-associated-doh/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-hoffman-resolver-associated-doh-00
https://datatracker.ietf.org/doc/html/draft-hoffman-resolver-associated-doh-00
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
