Re: [Doh] Associating a DoH server with a resolver

Kenji,

I have a longterm desire to develop a protocol for recursive service
discovery that works through a hierarchy of nested gateways. Primarily,
this is so applications can be more considerate of user's internet costs,
allowing the querying for information about the ISP service contract
boundaries and usage status; but I also foresee other uses as well. I am
planning to start incubating the idea in the research-working-group nmrg.

While it won't satisfy your needs today (and isn't guaranteed to become a
standard), perhaps you might find this worth your support? I won't go into
detail here and now, but you can find my message here
https://www.ietf.org/mail-archive/web/nmrg/current/msg01989.html.

Regards,

Todd Hubers

Software Engineer

On Mon, 29 Oct 2018 at 20:30, Kenji Baheux <kenjibaheux=
40google.com@dmarc.ietf.org> wrote:

> *Apologies for starting a new thread (maybe), I couldn't find a
> straightforward way of replying to a thread that pre-existed my
> subscription.*
>
> *tl;dr:* I'm involved with Chrome's DNS over HTTPS effort. While I
> haven't yet read the proposal and I could be missing some important
> context, I support the use case (i.e. facilitating the discovery of DoH
> support from an existing resolver).
>
>
> Paul Hoffman said:
> "I would want to hear that [*no browser vendor is interested in ways to
> find the DoH version of a resolver* (paraphrasing)] directly from the
> browser vendors before abandoning this work, particularly because we are
> hearing a lot of interest from organizations who want it."
>
> I'm involved with Chrome's DNS over HTTPS effort. We are considering a
> behavior where Chrome would identify if the user's existing DNS server
> supports DoH, and if so, then perform an automatic upgrade (TBD: silent or
> with an opt in/out prompt).
>
> Our short term approach is to have a list of known resolvers that support
> DoH and do the mapping internally. But, in the long run, this doesn't seems
> ideal. Also, for custom resolvers, it seems preferable to have an easy
> configuration path instead of the potentially cumbersome URL scheme +
> POST/GET choice?
>
> So, while I haven't read the proposal, and it's possible that I'm missing
> important context, I support the use case.
>
> --
> Kenji BAHEUX
> Product Manager - Chrome
> Google Japan
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>

-- 
--
Todd Hubers