Re: [Doh] Seeking input on draft-03

On Thu, Feb 8, 2018 at 10:55 AM, Justin Henck <henck@google.com> wrote:

> I would like to see a way for clients to discover a DNS server hosted on a
> certain domain.  Perhaps a .well-known/dns path that contains a relative
> pointer and other metadata.
>

https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/75 touches on
discoverability.

I am more in favor of a set of simple requirements, so simple client and
server implementation can exist and provide the basics of DOH
functionality.
Optionally, discovery can be used to be more fancy and provide
extensibility, but at the core of it, I would expect that knowing a domain
and optionally an IP (to avoid the chicken and egg issue of being able to
resolve the DOH server IP ) should be enough to be able to access DNS over
HTTPS using GET at a well known endpoint.
Enforcing discovery will most likely slow and prevent new implementations.

Manu

> I'm imagining a use case whereby the user could choose to rely upon an
> organization that they find trustworthy which is offering DNS, without
> needing to do a significant amount of discovery (e.g. "maybe known.tld has
> a DNS server?").  You could of course also have an absolute pointer, but
> then you have to account for the situation whereby known.tld might delegate
> to unknown.tld.
>
> Justin Henck
> Google
>
>
> On Thu, Feb 8, 2018 at 1:21 PM Ben Schwartz <bemasc@google.com> wrote:
>
>> On Thu, Feb 8, 2018 at 1:11 PM, Mike Bishop <mbishop@evequefou.be> wrote:
>>
>>> I’m inclined to think this is a positive change.  We’re trying to do
>>> something better than the current world of “trust the local DNS server
>>> because unauthenticated DHCP says so”, and promiscuous trust just because a
>>> server claims it support DOH via a .well-known endpoint isn’t really any
>>> better.
>>>
>>
>> To be clear, the draft never proposed promiscuous trust, which would
>> indeed be highly problematic.  However, draft-03 does include additional
>> language clarifying this point.
>>
>>
>>> The client should know the hostname(s) of the DOH server(s) it wants to
>>> use
>>>
>>
>> In draft-03, "knowing the hostname" is not sufficient, because there is
>> no default path for DOH.  This is the change on which I am seeking input.
>>
>>
>>> , and it should authenticate the DOH server against that hostname.
>>>
>>
>> Yes, definitely.  (I believe the draft is clear on this point, but feel
>> free to suggest improvements.)
>>
>>
>>>   If a server hosts content and also wants to also serve DOH, there are
>>> ways to present a hostname that covers both names (or present two
>>> certificates) on an HTTP connection.
>>>
>>>
>>>
>>> *From:* Doh [mailto:doh-bounces@ietf.org] *On Behalf Of *Ben Schwartz
>>> *Sent:* Thursday, February 8, 2018 10:05 AM
>>> *To:* doh@ietf.org
>>> *Subject:* [Doh] Seeking input on draft-03
>>>
>>>
>>>
>>> Hi all,
>>>
>>>
>>>
>>> The authors of draft-ietf-doh-dns-over-https have been making good
>>> progress, and a draft-03 is now ready with several changes and
>>> clarifications.
>>>
>>>
>>>
>>> One important difference is that draft-03 no longer proposes a
>>> ".well-known" entry.  In draft-02 and prior, clients could check for the
>>> presence of a DOH service at the default path, given only the domain name
>>> of a server.  In draft-03, there is no default path, so clients must be
>>> configured with the full URL of the DOH endpoint.
>>>
>>>
>>>
>>> Is this change compatible with your use cases?  Would this alter the way
>>> users interact with your systems?  How do you think DOH client
>>> configuration should work?
>>>
>>>
>>>
>>> Please respond with your thoughts,
>>>
>>> Ben Schwartz
>>>
>>
>> _______________________________________________
>> Doh mailing list
>> Doh@ietf.org
>> https://www.ietf.org/mailman/listinfo/doh
>>
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
>