Re: [Add] New Version Notification for draft-schinazi-httpbis-doh-preference-hints-02.txt

[David Schinazi <[e-mail]>]

Hi Tommy,

Thanks for your comments! Responses inline.

On Sun, Jul 26, 2020 at 1:43 PM Tommy Pauly <[e-mail]> wrote:

> Hi Nick,
>
> I definitely like the optimizations that this mechanism is looking
> for—specifically, binding resolutions to a DoH server that is hosted by the
> same CDN that provides the desired web content. This not only allows for
> faster resolution (based on being near the authoritative) and faster
> connections (based on tailoring DNS answers for the client’s subnet) as you
> describe, but has some privacy benefits in limiting the number of parties
> involved in subsequent resolutions.
>
> The specific mechanism does cause some concerns for me, however.
>
> I know this is just a hint, but the weak relationship between this hint
> and the DNS may cause issues. The DoH preference hint is one-way only,
> and determined only by the entity that is generating HTTP headers for a
> given URL. This means that neither the operator of the DNS zone for the
> origin, nor the target DoH resolver, have any way to influence or validate
> this hint. It is possible that these are all the same entity (Google
> content in a google.com zone pointing to 8.8.8.8), but that’s not
> guaranteed. Nothing stops any website from providing a hint to direct
> clients to whichever DoH server it wants, for as long as it wants. I have
> no problem with HTTPS content helping to confirm that the owner of the cert
> for a name agrees to using a specific DoH server (see
> https://www.ietf.org/id/draft-pauly-add-resolver-discovery-01.html#name-confirmation-of-designation)
> but the primary control over DNS routing should lie with the operator of
> the DNS zone in order to get the optimizations described in the document.
>

Your statement that "the primary control over DNS routing should lie with
the operator of the DNS zone" contradicts existing best practices. Today,
when my devices connect to a first hop network (Wi-Fi, cellular, etc.),
that network will almost always provide me with a list of DNS servers,
using mechanisms such as IPv6 RAs or DHCP. My device then proceeds to route
its DNS based on that information. This control over DNS routing does not
lie with the operator of the DNS zone, it lies with the first hop network
operator - or with the device administrator who can override DNS
configuration. Our proposal allows HTTP server operators to influence DNS
routing, and your proposal allows DNS zone operators to influence DNS
routing, but neither of those solutions is "more correct" based on how DNS
works today.


> It also seems like it would be more optimal for this indication of DoH
> server to be expressed for a set of names (names within a zone, or
> all subdomains, etc), rather than just a single host name. The text limits
> any hint to only apply to one name, which is good because the hint
> could otherwise cause problems for an entire zone, but means that the
> benefit is limited. If every YouTube video has a unique hostname that is
> only resolved once, wouldn’t it be better to learn that I should use
> 8.8.8.8 for all YouTube names?
>

Definitely agree. We could change the draft to allow these hints to
influence other hostnames that are covered by the same TLS certificate,
though we'd have to consider the security implications carefully.


> What would the client behavior for this header be if there is a redirect?
> For any content that uses redirects, I assume these hints must be ignored?
>

I don't think HTTP redirects should have any impact on the DoH-Preference
header. If https://foo.example.com/abc returns a 301 redirect to
https://bar.example.net/def it can still tell the client that subsequent
resolutions for foo.example.com can be made to a given DoH server. The key
distinction here is that the DoH-Preference operates at the scope of a
hostname, whereas an HTTP redirect operates at the scope of a given request
(i.e. it's specific to the full path, not just the hostname).

Cheers,
David


Best,
> Tommy
>
> On Jul 13, 2020, at 1:25 PM, Nick Sullivan <
> nick=[e-mail]> wrote:
>
> ADD Working Group,
>
> This is to inform you of a new submission of the doh-preference-hints
> document. This document was originally intended for the HTTPbis working
> group, but we were directed to the ADD group as a more appropriate venue to
> discuss it. Our intention is to put this document up for consideration to
> be adopted as a working group item.
>
> Nick, David, Jesse
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Mon, Jul 13, 2020 at 12:36 PM
> Subject: New Version Notification for
> draft-schinazi-httpbis-doh-preference-hints-02.txt
> To: Jesse Kipp <[e-mail]>, Nick Sullivan <[e-mail]>,
> David Schinazi <[e-mail]>
>
>
>
> A new version of I-D, draft-schinazi-httpbis-doh-preference-hints-02.txt
> has been successfully submitted by David Schinazi and posted to the
> IETF repository.
>
> Name:           draft-schinazi-httpbis-doh-preference-hints
> Revision:       02
> Title:          DoH Preference Hints for HTTP
> Document date:  2020-07-13
> Group:          Individual Submission
> Pages:          8
> URL:
> https://www.ietf.org/internet-drafts/draft-schinazi-httpbis-doh-preference-hints-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-schinazi-httpbis-doh-preference-hints/
> Htmlized:
> https://tools.ietf.org/html/draft-schinazi-httpbis-doh-preference-hints-02
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-schinazi-httpbis-doh-preference-hints
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-schinazi-httpbis-doh-preference-hints-02
>
> Abstract:
>    When using a publicly available DNS-over-HTTPS (DoH) server, some
>    clients may suffer poor performance when the authoritative DNS server
>    is located far from the DoH server.  For example, a publicly
>    available DoH server provided by a Content Delivery Network (CDN)
>    should be able to resolve names hosted by that CDN with good
>    performance but might take longer to resolve names provided by other
>    CDNs, or might provide suboptimal results if that CDN is using DNS-
>    based load balancing and returns different address records depending
>    or where the DNS query originated from.  This document attempts to
>    lessen these issues by allowing the web server to indicate to the
>    client which DoH server can best resolve its addresses.  This
>    document defines an HTTP header field that enables web host operators
>    to inform user agents of the preferred DoH servers to use for
>    subsequent DNS lookups for the host's domain.
>
>    Discussion of this work is encouraged to happen on the ADD IETF
>    mailing list [e-mail] or on the GitHub repository which contains
>    the draft: https://github.com/DavidSchinazi/draft-httpbis-doh-
>    preference-hints.
>
>
>
>
> 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.
>
> The IETF Secretariat
>
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>
>
>