Subject: Skipping DNS resolutions with ORIGIN frame

From: Ryan Hamilton <[email-masked]>
Date: Fri, 14 Jul 2017 06:18:36 -0700

Howdy Folks,

I've been talking with Chrome security folks about the issue of skipping
DNS resolutions when using an existing HTTP/2 connection for a new origin
announced via an ORIGIN frame. It is crystal clear that saving DNS
resolutions represents a real performance win, especially for long-tail
users.

However, we are not comfortable with the increased ability of an off-path
attacker to exploit a mis-issued certificate. A DNS resolution is not the
strongest security assertion in the world, but it's definitely something.

Before trusting a certificate for a connection, we'd like an assertion from
some other trusted source. This could be:
* On-path presence, for example DNS resolution, or proxy configuration
* A previous assertion from the origin itself (Alt-Svc)
* CT logs, etc.
Without such an assertion, we're not comfortable trusting the connection
and plan to continue consulting DNS when making use of the ORIGIN frame in
Chrome.

Cheers,

Ryan

---

From: Watson Ladd <[email-masked]>
Date: Fri, 14 Jul 2017 09:32:21 -0700

On Fri, Jul 14, 2017 at 6:18 AM, Ryan Hamilton <[email-masked]> wrote:

> Before trusting a certificate for a connection, we'd like an assertion
> from some other trusted source. This could be:

I'm a little confused by what this means: Is this for ORIGIN frame or
ORIGIN+CERTIFICATE? In the case of ORIGIN alone would this mean that a
multi-SAN cert logged in CT will be trusted, but not one not logged?

Sincerely,
Watson

---

From: Martin Thomson <[email-masked]>
Date: Sat, 15 Jul 2017 03:32:26 +1000

On 14 July 2017 at 23:18, Ryan Hamilton <[email-masked]> wrote:
> Without such an assertion, we're not comfortable trusting the connection and
> plan to continue consulting DNS when making use of the ORIGIN frame in
> Chrome.

Hi Ryan,

It's good that you are sharing this, but I did want to clarify a few
of these points.

I get that you believe that DNS resolution is valuable here, but I
don't understand your point about "proxy configuration".  If you have
a proxy configured, you generally don't do the DNS lookup directly, so
are you saying that you would allow the coalescing for a CONNECT
tunnel?

Can you verify that I understand your point about Alt-Svc: if the
origin had been previously contacted and Alt-Svc identified an IP
address that matches the current IP, then that could be a sufficient
signal.  Usually Alt-Svc is a name though, so that wouldn't help.

Similarly, are you saying that CT could assert something that would
cause you to skip the DNS lookup for a name?

Or is this list just to make a more general point about raising the
bar for gaining the ability to use a name, and not something that is
specific to this particular example of DNS lookups?

Cheers,
Martin

---

From: Mike Bishop <[email-masked]>
Date: Fri, 14 Jul 2017 22:27:50 +0000

The Alt-Svc is a name, but it's quite possible that it's a name you've already done DNS resolution for.  Or, worst case, you resolve the target hostname and the Alt-Svc name in parallel and check whether the currently-connected host is in either set.  You don't save the DNS resolution, but you get some evidence of shared control.  That's more important, in my book.

We share the same reservations about not doing the DNS lookups, FWIW.  I've also been looking at Alt-Svc as a middle ground here.  A collection of origins that have disjoint IPs but share a certificate and want to coalesce simply have to issue Alt-Svc records pointing to the same place.  Whether that's one of the hostnames being considered primary, or a "special" hostname that returns the union of the IP addresses (so whatever you're connected to already will be in that set), or simply a dedicated hostname that's used for Alt-Svc doesn't matter so much.  That means you'll have to connect to each origin once to get the Alt-Svc record, but thereafter you get the best of both worlds.  While that seems daunting for certificates that contain 70+ names including wildcards, the typical client doesn't actually connect to that full set of hostnames.

(A way to get the Alt-Svc records without having to make HTTP requests first might also help here, but doing so securely requires infrastructure that isn't practically available yet.)

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Friday, July 14, 2017 10:32 AM
To: Ryan Hamilton <[email-masked]>
Cc: [email-masked]; Piotr Sikora <[email-masked]>
Subject: Re: Skipping DNS resolutions with ORIGIN frame

On 14 July 2017 at 23:18, Ryan Hamilton <[email-masked]> wrote:
> Without such an assertion, we're not comfortable trusting the 
> connection and plan to continue consulting DNS when making use of the 
> ORIGIN frame in Chrome.

Hi Ryan,

It's good that you are sharing this, but I did want to clarify a few of these points.

I get that you believe that DNS resolution is valuable here, but I don't understand your point about "proxy configuration".  If you have a proxy configured, you generally don't do the DNS lookup directly, so are you saying that you would allow the coalescing for a CONNECT tunnel?

Can you verify that I understand your point about Alt-Svc: if the origin had been previously contacted and Alt-Svc identified an IP address that matches the current IP, then that could be a sufficient signal.  Usually Alt-Svc is a name though, so that wouldn't help.

Similarly, are you saying that CT could assert something that would cause you to skip the DNS lookup for a name?

Or is this list just to make a more general point about raising the bar for gaining the ability to use a name, and not something that is specific to this particular example of DNS lookups?

Cheers,
Martin

---

From: Patrick McManus <[email-masked]>
Date: Sat, 15 Jul 2017 06:30:59 +0000 (UTC)

Hey Ryan, thanks for the comments.

On Fri, Jul 14, 2017 at 3:18 PM, Ryan Hamilton <[email-masked]> wrote:

> . It is crystal clear that saving DNS resolutions represents a real
> performance win, especially for long-tail users.
>
>
I want to re-emphasize here that I believe a perhaps larger win here is the
privacy implication of a lookup never made - especially when combined with
secondary certificates and exported authentiactors (still to come to h2).
This achieves much of what encrypted SNI could do.

My first question is would you be ok with just loosening the draft language
a little bit.. i.e. instead of saying must not consult DNS, define this in
a way that it is the client's decision.

As I've said before, I don't think the DNS is providing any real value here
now that ORIGIN is playing the role of traffic routing. Indeed it is
creating a privacy cost - so I'm eager to get it out of the loop.

If we can't get consensus on that I'd prefer some kind of stapled assertion
that kept the perf and privacy properties of the current draft. I guess
that could be dnssec though that would certainly limit use for imo limited
value.. I'm not sure I fully understand what you're thinking of wrt
expect-ct -does it fit that model?

-Patrick

---

From: Patrick McManus <[email-masked]>
Date: Sat, 15 Jul 2017 07:10:54 +0000 (UTC)

> that kept the perf and privacy properties of the current draft.
>

one other thought while I'm here. If the driving concern is amplifying a
key compromise perhaps making the ORIGIN-as-DNS property contingent on a
strong revocation check would be a workable path.. i.e. use as dns when
ocsp has been stapled or checked (hopefully stapled!).

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 15 Jul 2017 10:23:32 +0300

> expect-ct -does it fit that model?

My understanding of the "CT" idea was to require secondary certificates
to be CT qualified to be used without DNS.

Exported authenticators are capable of both OCSP and SCT stapling (all
three modes for SCTs).

-Ilari

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 18 Jul 2017 11:30:54 -0700

My apologies for starting this thread on Friday and then going on vacation!
I'm catching up now.

> are you saying that you would allow the coalescing for a CONNECT

Yes, I think so.

> signal.  Usually Alt-Svc is a name though, so that wouldn't help.

​Sorry, I wasn't very clear. What I means is that if I connection to
www.example.org which presents an *.example.org certificate, I need some
second piece of information before using it for mail.example.com. In the
alt-svc case, if an earlier connection to mail.example.org advertised
alt-svc for www.example.org, then I would be comfortable coalescing the
connection​ and would not need to do any resolution of mail.example.org.

> cause you to skip the DNS lookup for a name?

​This was more of a straw-man than a concrete proposal, but yes. Folk in
Chrome security thought that this was plausible, though probably required
more thought.​

> specific to this particular example of DNS lookups?

Specific to the issue of skipping DNS lookups when deciding to trust a
certificate.​

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 18 Jul 2017 11:38:24 -0700

On Fri, Jul 14, 2017 at 11:30 PM, Patrick McManus <[email-masked]>
wrote:

> I want to re-emphasize here that I believe a perhaps larger win here is
> the privacy implication of a lookup never made - especially when combined
> with secondary certificates and exported authentiactors (still to come to
> h2). This achieves much of what encrypted SNI could do.
>

​Interesting point. It's a bit of a tradeoff between privacy and security
then, I suppose.
​

> My first question is would you be ok with just loosening the draft
> language a little bit.. i.e. instead of saying must not consult DNS, define
> this in a way that it is the client's decision.
>

​I think that'd definitely a step in the right direction, but I heard some
real security concerns about "blindly"​ skipping resolution in this case,
so I'm interested to hear what the group things about the advisability of
doing this.

> If we can't get consensus on that I'd prefer some kind of stapled
> assertion that kept the perf and privacy properties of the current draft. I
> guess that could be dnssec though that would certainly limit use for imo
> limited value..
>

​It does seem like a stapled DNSSEC response is a plausible option here!

> I'm not sure I fully understand what you're thinking of wrt expect-ct
> -does it fit that model?
>

​I don't think I was thinking about expect-ct per-se. Instead, folks were
thinking that we could consider skipping DNS resolutions when the
certificate is valid according to the CT logs that the client has access
too. This is a different sort of assertion from a second source that helps
mitigate the impact of a mis-issued certificate, which is the main fear of
skipping DNS.​

---

From: Watson Ladd <[email-masked]>
Date: Tue, 18 Jul 2017 11:43:51 -0700

On Tue, Jul 18, 2017 at 11:30 AM, Ryan Hamilton <[email-masked]> wrote:

> My apologies for starting this thread on Friday and then going on
> vacation! I'm catching up now.
>
> On Fri, Jul 14, 2017 at 10:32 AM, Martin Thomson <[email-masked]
> > wrote:
>

This doesn't work for our major usecase, which is using an existing
connection to one of our customers to send the content of
cdnjs.cloudflare.com. If logging a certificate in CT is enough to enable
ORIGIN that is fine.

---

From: Mike Bishop <[email-masked]>
Date: Tue, 18 Jul 2017 21:23:23 +0000

Unless the cdnjs.cloudflare.com is in the same cert, you’d also need the Secondary Certificates extension to support that.  Once it’s there, though, I think the discussion is the same whether we have multiple certificates or one – we have a single factor (the certificate) that claims authority for some other name.  How do we reach a sufficient level of trust?  DNS is a weak second factor; are there other second factors we would be willing to consider as equivalent?

From: Watson Ladd [mailto:[email-masked]]
Sent: Tuesday, July 18, 2017 11:44 AM
To: Ryan Hamilton <[email-masked]>
Cc: Martin Thomson <[email-masked]>; [email-masked]; Piotr Sikora <[email-masked]>
Subject: Re: Skipping DNS resolutions with ORIGIN frame

On Tue, Jul 18, 2017 at 11:30 AM, Ryan Hamilton <[email-masked]<mailto:[email-masked]>> wrote:
My apologies for starting this thread on Friday and then going on vacation! I'm catching up now.

On Fri, Jul 14, 2017 at 10:32 AM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

Yes, I think so.

​Sorry, I wasn't very clear. What I means is that if I connection to www.example.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.org&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C0a535a7fb83f4a3187c008d4ce0d6576%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636360004315030763&sdata=A11yjgd7M%2BFAWckA%2B4yXLreK7egSTp0o7fHOxTmro1Y%3D&reserved=0> which presents an *.example.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.org&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C0a535a7fb83f4a3187c008d4ce0d6576%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636360004315030763&sdata=z7e0gWv6d9qNO3LlzWYdAdJF%2Fdz1fl6ePrL4wXc%2Fo5w%3D&reserved=0> certificate, I need some second piece of information before using it for mail.example.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.example.com&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C0a535a7fb83f4a3187c008d4ce0d6576%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636360004315030763&sdata=m0%2FQIhc5PZ7qOzojoiCQcvrpWLL4fEbXrzCjH27AmeA%3D&reserved=0>. In the alt-svc case, if an earlier connection to mail.example.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.example.org&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C0a535a7fb83f4a3187c008d4ce0d6576%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636360004315030763&sdata=dzpNY0d8AF2kRFXdgSMNqZebFcyj8CTepsxlWxwNKFg%3D&reserved=0> advertised alt-svc for www.example.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.org&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C0a535a7fb83f4a3187c008d4ce0d6576%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636360004315030763&sdata=A11yjgd7M%2BFAWckA%2B4yXLreK7egSTp0o7fHOxTmro1Y%3D&reserved=0>, then I would be comfortable coalescing the connection​ and would not need to do any resolution of mail.example.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.example.org&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C0a535a7fb83f4a3187c008d4ce0d6576%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636360004315030763&sdata=dzpNY0d8AF2kRFXdgSMNqZebFcyj8CTepsxlWxwNKFg%3D&reserved=0>.

This doesn't work for our major usecase, which is using an existing connection to one of our customers to send the content of cdnjs.cloudflare.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcdnjs.cloudflare.com&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C0a535a7fb83f4a3187c008d4ce0d6576%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636360004315030763&sdata=9yE4PkHTxyyqml%2BhutprXtHJO9nbwEtfi9ptaijYZb0%3D&reserved=0>. If logging a certificate in CT is enough to enable ORIGIN that is fine.

​This was more of a straw-man than a concrete proposal, but yes. Folk in Chrome security thought that this was plausible, though probably required more thought.​

Specific to the issue of skipping DNS lookups when deciding to trust a certificate.​

---

From: Watson Ladd <[email-masked]>
Date: Tue, 18 Jul 2017 16:29:13 -0700

On Tue, Jul 18, 2017 at 2:23 PM, Mike Bishop <[email-masked]>
wrote:

> Unless the cdnjs.cloudflare.com is in the same cert, you’d also need the
> Secondary Certificates extension to support that.  Once it’s there, though,
> I think the discussion is the same whether we have multiple certificates or
> one – we have a single factor (the certificate) that claims authority for
> some other name.  How do we reach a sufficient level of trust?  DNS is a
> weak second factor; are there other second factors we would be willing to
> consider as equivalent?
>

We can put it in the same cert for a lot of our customers and Secondary
Certificates is also on the roadmap for this.

It depends on what we want to guard against. If it is just mississuance,
presence of the certificate in CT logs is fine. If we're concerned about an
attacker with the private key of the certificate, then presence of the
certificate in the CT logs isn't enough and DNS provides an extra fig-leaf.

A lot of the proposals being discussed aren't detailed enough for me to say
if they would work or not for us. Would it be enough to have every site
Alt-Svc cloudflare.com (easy), or would the Alt-Svc proposals end up N^2
scaling (nonstarter)? Our IPs aren't shared between sites in any sort of
regular pattern and which one is used by customer.example.com can change
for various reasons.

We can't have cdnjs.cloudflare.com advertise every single customer as an
Alt-Svc.

Sincerely,
Watson

>
> *From:* Watson Ladd [mailto:[email-masked]]
> *Sent:* Tuesday, July 18, 2017 11:44 AM
> *To:* Ryan Hamilton <[email-masked]>
> *Cc:* Martin Thomson <[email-masked]>; [email-masked];
> Piotr Sikora <[email-masked]>
> *Subject:* Re: Skipping DNS resolutions with ORIGIN frame
>
>
>
>
>
>
>
> www.example.org
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.org&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C0a535a7fb83f4a3187c008d4ce0d6576%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636360004315030763&sdata=A11yjgd7M%2BFAWckA%2B4yXLreK7egSTp0o7fHOxTmro1Y%3D&reserved=0>
> which presents an *.example.org
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.org&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C0a535a7fb83f4a3187c008d4ce0d6576%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636360004315030763&sdata=z7e0gWv6d9qNO3LlzWYdAdJF%2Fdz1fl6ePrL4wXc%2Fo5w%3D&reserved=0>
> certificate, I need some second piece of information before using it for
> mail.example.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.example.com&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C0a535a7fb83f4a3187c008d4ce0d6576%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636360004315030763&sdata=m0%2FQIhc5PZ7qOzojoiCQcvrpWLL4fEbXrzCjH27AmeA%3D&reserved=0>.
> In the alt-svc case, if an earlier connection to mail.example.org
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.example.org&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C0a535a7fb83f4a3187c008d4ce0d6576%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636360004315030763&sdata=dzpNY0d8AF2kRFXdgSMNqZebFcyj8CTepsxlWxwNKFg%3D&reserved=0>
> advertised alt-svc for www.example.org
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.org&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C0a535a7fb83f4a3187c008d4ce0d6576%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636360004315030763&sdata=A11yjgd7M%2BFAWckA%2B4yXLreK7egSTp0o7fHOxTmro1Y%3D&reserved=0>,
> then I would be comfortable coalescing the connection​ and would not need
> to do any resolution of mail.example.org
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.example.org&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C0a535a7fb83f4a3187c008d4ce0d6576%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636360004315030763&sdata=dzpNY0d8AF2kRFXdgSMNqZebFcyj8CTepsxlWxwNKFg%3D&reserved=0>
> .
>
>
>
> cdnjs.cloudflare.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcdnjs.cloudflare.com&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C0a535a7fb83f4a3187c008d4ce0d6576%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636360004315030763&sdata=9yE4PkHTxyyqml%2BhutprXtHJO9nbwEtfi9ptaijYZb0%3D&reserved=0>.
> If logging a certificate in CT is enough to enable ORIGIN that is fine.
>
>
>

---

From: Erik Nygren <[email-masked]>
Date: Tue, 18 Jul 2017 21:26:36 -0400

On Tue, Jul 18, 2017 at 7:29 PM, Watson Ladd <[email-masked]> wrote:

> On Tue, Jul 18, 2017 at 2:23 PM, Mike Bishop <[email-masked]
> > wrote:
>
> A lot of the proposals being discussed aren't detailed enough for me to
> say if they would work or not for us. Would it be enough to have every site
Strawperson:  if every one of a CDN's sites (including cdnjs.example.com)
did an:

                  Alt-Svc: h2="cdn.example.net:443"; ma=7200; coalesce=1

then one might argue that there is a positive indication from a strongly
authenticated origin (where DNS was followed initially to receive the
Alt-Svc)
saying that connections to cdn.example.net can safely coalesce as long as
there is cert coverage.
ie, if the cert presented when connecting to cdn.example.net and sending
SNI="www.example.com" covers "www.example.com", or if such a cert
is pushed via Secondary Certificates down the road.

It may be that to make this really useful, clients may want to be able to
probe
for a Secondary Cert + ORIGIN to be sent to them.

The risk exposures in this case seem to be from the Alt-Svc MA TTL
extending too long
(ie, long past a typical DNS TTL, so perhaps there should be a cap on the
MA allowed
before re-authenticating with the origin), or if the Alt-Svc is learned
from an Origin
using a MitM CA cert (which we may want to explictly prohibit being used
in combination here as otherwise this could be used to shove everything
through a MitM appliance that can construct certs, unless
that is a desired behavior which I doubt is the case in most places).

          Erik

---

From: Patrick McManus <[email-masked]>
Date: Wed, 19 Jul 2017 06:32:56 +0000 (UTC)

On Wed, Jul 19, 2017 at 3:26 AM, Erik Nygren <[email-masked]> wrote:

> is pushed via Secondary Certificates down the road.
following DNS and SNI even once removes the pro-privacy attributes of
ORIGIN; or do I misunderstand the proposal? If we were going to go in that
direction it might be easier to define some kind of "h2='originframe'"
attestation from alt-svc, but again - bootstrapping alt-svc has the name
leak so I don't think its a great idea.

---

From: Piotr Sikora <[email-masked]>
Date: Wed, 19 Jul 2017 10:00:40 +0200

Yes, DNSSEC staple in ORIGIN frame is definitely a good option.

It doesn't solve _all_ problems, e.g. GeoDNS, since we don't know that
the same DNS response would be sent for a query issued by this
particular client, but none of the suggested alternatives solve this
anyway (other than the SkipDNS X509 extension, which doesn't have many
fans here), so we shouldn't dismiss DNSSEC staple because of that.

Best regards,
Piotr Sikora

On Tue, Jul 18, 2017 at 8:38 PM, Ryan Hamilton <[email-masked]> wrote:
> Interesting point. It's a bit of a tradeoff between privacy and security
> then, I suppose.
>>
> I think that'd definitely a step in the right direction, but I heard some
> real security concerns about "blindly" skipping resolution in this case, so
> I'm interested to hear what the group things about the advisability of doing
> this.
>
>> As I've said before, I don't think the DNS is providing any real value
>> here now that ORIGIN is playing the role of traffic routing. Indeed it is
> It does seem like a stapled DNSSEC response is a plausible option here!
>
>>
> I don't think I was thinking about expect-ct per-se. Instead, folks were
> skipping DNS.

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 19 Jul 2017 07:38:45 -0700

I wonder if it could serve up CNAME result instead of a A or AAAA record
instead to avoid the problem of the server not actually knowing what IP the
client *thinks* it's talking to?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Jul 2017 16:41:47 +0200

I would not modify the protocol in that way.  I would prefer to leave
ORIGIN alone.  DOH is a much a better way to get that information to
the client, for example.

---

From: Piotr Sikora <[email-masked]>
Date: Wed, 19 Jul 2017 17:33:28 +0200

DNS-over-HTTPS would require _clients_ to make the DNS query (most
likely to a different server), instead of receiving cached DNS
response from the server that can send it to many clients, so you'd be
losing some of the properties that you care about.

Best regards,
Piotr Sikora

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Jul 2017 17:38:16 +0200

If this uses DNSSEC, then there is a possibility that it is sufficient
for this purpose (though perhaps not generally useful).