Re: [Doh] Seeking input on draft-03

[Justin Henck <[e-mail]>]

>
> What I understood from you original comment was to use this as an entry
> point to discover alternate locations, delegation... I think it is worth it
> but should be optional.


Got it.  I understand the desire for simplicity, and would also prefer to
avoid complex solutions.  My specific goal is to enable users to reliably
and easily configure a trusted DOH server of their choice without
bootstrapping.


On Thu, Feb 8, 2018 at 4:36 PM manu tman <[e-mail]> wrote:

>
>
> On Thu, Feb 8, 2018 at 11:23 AM, Justin Henck <[e-mail]> wrote:
>
>> 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.
>>
>>
>> I may be misunderstanding, but doesn't this imply either a fixed path, or
>> a discoverable path via another (e.g. .well-known/dns)?
>>
>
> Yes, I mean to have a fixed well-known path that provides DOH service (as
> in actual DNS queries) that can be used universally. So, any clients, given
> a domain, can use DOH without having to go through the steps of service
> discovery indirections.
> What I understood from you original comment was to use this as an entry
> point to discover alternate locations, delegation... I think it is worth it
> but should be optional.
>
> At the end of the day, either accessing a discovery endpoint or DOH
> service endpoint, the client will need to be told where to get it. Having a
> predefined entry point would make this easier.
>
>
>>
>>
>> On Thu, Feb 8, 2018 at 2:22 PM Hewitt, Rory <[e-mail]> wrote:
>>
>>> Additionally, using /.well-known/ would allow for URI Template
>>> discovery, if required - client retrieves URI Template from e.g.
>>> /.well-known/doh.template and then uses that to build DNS request URI.
>>>
>>>
>>>
>>> See https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/74
>>> for @mnot's suggestion.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Rory
>>>
>>>
>>>
>>> *Rory Hewitt*
>>>
>>> Senior Solutions Architect
>>>
>>> Global Services & Support
>>>
>>> Akamai Technologies
>>>
>>> Tel: [phone]
>>>
>>>
>>>
>>> *From:* Justin Henck [mailto:[e-mail]]
>>> *Sent:* Thursday, February 8, 2018 11:17 AM
>>> *To:* [e-mail]
>>> *Cc:* Ben Schwartz <[e-mail]>; [e-mail];
>>> [e-mail]
>>> *Subject:* Re: [Doh] Seeking input on draft-03
>>>
>>>
>>>
>>> That would work for the situation I specified, but I think that a
>>> .well-known pointer provides the additional benefit of serving more
>>> technical users with an advanced configuration. (It is also in-line with
>>> the intended use of .well-known as I understand RFC 5785.)
>>>
>>>
>>>
>>> Specifically, if an implementer creates an advanced setting whereby you
>>> can configure a DOH server with both a domain and an IP (to eliminate the
>>> need for bootstrapping) then you have made the user's life easier. And,
>>> although a URI is not supposed to change, a .well-known/dns pointer
>>> requirement would ensure that capricious servers don't break
>>> manually-configured clients.
>>>
>>>
>>>
>>>
>>> *Justin Henck*
>>> Product Manager
>>>
>>> 212-565-9811 <(212)%20565-9811>
>>>
>>> google.com/jigsaw
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__google.com_jigsaw&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=h4goE6gK_ZaRrvwi4Hglaq0NyaBCb3I3XALyazxKb6w&m=KrH6cYm-gcGpqevreKzpdpsMm-hErKTCNEthg2TBsTU&s=N-RLQbYhldj1naDovU3jQQtWdiNb5pbKuxXJJ3p663Y&e=>
>>>
>>>
>>>
>>> PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B
>>>
>>>
>>>
>>> On Thu, Feb 8, 2018 at 1:59 PM Erik Kline <[e-mail]> wrote:
>>>
>>> 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
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_doh&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=h4goE6gK_ZaRrvwi4Hglaq0NyaBCb3I3XALyazxKb6w&m=KrH6cYm-gcGpqevreKzpdpsMm-hErKTCNEthg2TBsTU&s=T69zw0O8NFcgM07c8aK0knaf9RoDeSYGFdN_MXSy4a4&e=>
>>> >
>>> >
>>> > _______________________________________________
>>> > Doh mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/doh
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_doh&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=h4goE6gK_ZaRrvwi4Hglaq0NyaBCb3I3XALyazxKb6w&m=KrH6cYm-gcGpqevreKzpdpsMm-hErKTCNEthg2TBsTU&s=T69zw0O8NFcgM07c8aK0knaf9RoDeSYGFdN_MXSy4a4&e=>
>>> >
>>>
>>>
>> _______________________________________________
>> Doh mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/doh
>>
>>
>