Subject: Re: [dispatch] Working Group Proposal: DNS Over HTTPS

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Sep 2017 10:28:35 +1000

On Fri, Aug 11, 2017 at 5:40 AM, Stephen Farrell
<[email-masked]> wrote:
>> CORS?
>
> Yes. The mention of that in the draft we're discussing is
> a bit of a puzzle to me. Hopefully you didn't read some
> other draft:-)

Let me try to clarify, though I might easily do the opposite.

tl;dr: I think that the draft doesn't need to concern itself with CORS.

CORS *is* relevant in the space of things that this is touching.  One
specific (and useful) outcome of this work is that it allows web
applications to make DNS queries.  That naturally raises the CORS
question.  However, the answer is not any different to any other thing
that we might put on HTTP(S).  The server needs to adopt a policy that
ensures that the data that it provides is not made available to those
that shouldn't have it, and that any actions it takes are properly
safeguarded.  This is still not extraordinary in any way.

The draft in question uses GET.  That means that web content will be
able to make queries without any special controls, but it won't be
able to read the response.  The DNS server can block the request from
certain network locations, but it has to specifically look for an
Origin header field.  Again, this isn't particularly special, though
there are some denial of service considerations we might add to a
draft for this case.

The draft also uses POST, which triggers CORS preflights.  These
requests check that the server is OK with receiving the POST before
sending the actual data.  Here, the default is to deny these requests.
A positive signal from the server is needed before the real request is
made.  So only servers that explicitly enable CORS will receive POST
requests from browsers.

Why is this important?  Well, the identity of your private DNS server
is not usually that private (at least not in a real cryptographic
sense).  But the content of certain responses might be.  The server
might provide responses that differ from the responses you get from
other DNS servers.  Operators of DNS servers do not necessarily want
that information out there on the web.  This might include information
about what services are active on the network, network topology and so
forth.

We might get into a whole lot more trouble if we were to - say -
provide an API that allowed web sites to make DNS queries using the
system resolver.  I keep hearing that suggested and I think that this
draft offers a much better alternative - it allows us to lean on a lot
of pre-existing work around cross-origin authentication and ensures
that DNS servers are given at least a semblance of control over who
can ask them for stuff.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 12 Sep 2017 11:03:34 -0400

> that DNS servers are given at least a semblance of control over who

yes, just to underline this it is a goal of this work to make resolution
available to the usual origin web security model (which martin nicely
describes).. we shouldn't have to say much about it as the point is to use
it unmodified (and without surprises).