Re: [Doh] Seeking input on draft-03

[Erik Kline <[e-mail]>]

Sounds like you might want a (TXT) record at the zone cut level?

On 8 February 2018 at 10:55, Justin Henck <[e-mail]> 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.  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 <[e-mail]> wrote:
>>
>> On Thu, Feb 8, 2018 at 1:11 PM, Mike Bishop <[e-mail]> 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:[e-mail]] On Behalf Of Ben Schwartz
>>> Sent: Thursday, February 8, 2018 10:05 AM
>>> To: [e-mail]
>>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/doh
>
>
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>