Subject: [Doh] Servers offering responses for domaines they are not responsible for

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 05 Nov 2017 07:47:48 -0800

On 5 Nov 2017, at 0:30, Eliot Lear wrote:

>   * When an HTTP server offers this service for domains it is not
>     responsible for, it has the potential to impact DNS-based load
>     balancing by masking the IP address of the sender and substituting
>     its own.  The remedy here is that any service offering DoH should
>     sufficiently distributed as to minimize such an impact.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 6 Nov 2017 11:15:56 +1100

I'd think the remedy here would be RFC7871 (EDNS client subnet) support.

Cheers,

> On 6 Nov 2017, at 2:47 am, Paul Hoffman <[email-masked]> wrote:
> 
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh

--
Mark Nottingham   https://www.mnot.net/

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Nov 2017 00:21:51 +0000

>>>   sufficiently distributed as to minimize such an impact.

Client Subnet is fairly controversial in the DNS world due to privacy reasons.

In fact, I don't understand Eliot's concern here. DNS recursive resolvers (which is what a DOH server would be fronting for) are not "responsible for domains". Authoritative servers are responsible for domains.

Eliot: can you say more about your concern here?

--Paul Hoffman

---

From: Eliot Lear <[email-masked]>
Date: Mon, 6 Nov 2017 05:57:34 +0100

Hi Paul,

> Eliot: can you say more about your concern here?

Sure.  DNS-based load balancing mechanisms assume that the source of a
query is going to be proximate to the originator.  Use of DoH may upset
that assumption.  In the extreme case, imagine having just one DoH
caching resolver out there, and all queries flowing to it, from anywhere
in the world.  Especially if it is caching, any number of queries would
end up returning addresses that are local to that one DoH server and not
to the originator.

I mentioned authority here only in as much as I don't care what a DoH
server does for services that are related to it, but if they are not,
and if it really is just acting as a caching resolver, then this issue
comes into play.

Eliot

---

From: Martin Thomson <[email-masked]>
Date: Mon, 6 Nov 2017 16:18:45 +1100

Eliot, are you assuming that the DNS client will be looking at
responses from origins other than the one it has configured as a DOH
server?

That is, say that https://example.net is configured (or just
example.net), but if I talk to https://somesite.example and it
provides what is an otherwise valid DOH response, are you assuming
that this response is used?

Generally speaking, even if the DNS client shared a cache with a web
browser, this wouldn't happen without the DNS client taking special
steps to enable it, so I'm not sure why you would be specially
concerned about this.

Of course, I would still be supportive of text that made it clear that
this particular model is not in scope.

I don't want to categorically rule this possibility out forever.  For
instance, we might be able to convince ourselves that
https://somesite.example can be trusted to speak for itself.  But I
agree that anything that differs from the accepted model would be
difficult to get right for more than just this reason.

FWIW, I think that the notion that we use HTTP caching ultimately
enables better operational stories here, not worse.  Tighter control
over caching might avoid certain performance problems.  See for
example the stale-while-revalidate option previously mentioned .

---

From: Eliot Lear <[email-masked]>
Date: Mon, 6 Nov 2017 07:27:30 +0100

Good evening(?) Martin,

> responses from origins other than the one it has configured as a DOH

No, although I have a good joke about that re certain all-encompassing
apps and 4-engine aircraft.  Find me next week ;-)

My presumption is simply that the common case will be that HTTP will be
used as a substrate for DNS queries, separate from any other subsystem,
at least initially.  I think this is Paul's view as well, if I
understand him correctly.

What I am getting at is that introducing a new operating model entails
certain operational aspects, most of which can be addressed.  But let's
not kid ourselves: in the case of global load balancers, if this
mechanism isn't going to disturb them, then at least for the moment, one
should expect to have an infrastructure similar to that used by Google
for 8.8.8.8, whereas Eliot's home system would be an exceedingly poor
choice for general use ;-)

Sorry for not sticking to example.com examples- I am trying to convey
some notion of scope and scale.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 6 Nov 2017 08:25:17 +0100

Hi Mark,

> I'd think the remedy here would be RFC7871 (EDNS client subnet) support.

It is a *a* remedy, and could certainly be mentioned.  However,
precisely because of the warnings in that document, it probably
shouldn't be listed on its own as the sole recommended approach.

Eliot

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 6 Nov 2017 07:07:14 -0500

> shouldn't be listed on its own as the sole recommended approach.

It's the only thing we have that solves this problem today, however.
If you want geo- or even (and more accurately) network-topologically
sensitive answers to work, you need to know where the query originator
was.  For years we used the network address of the resolver as a proxy
for the location of the query originator, but in a world where
resolvers may be quite distant from the query originator that doesn't
work, and it doesn't matter whether the query travels via UDP port 53
or some other mechanism.

And indeed, given the DOH use case (which as we're currently
discussing it is really just last hop), I'm not sure what the problem
is.  This is directly analagous to a stub contacting a full service
resolver, and that's exactly the problem the large authoritative DNS
tricks have and that edns-client-subnet addresses.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Thu, 9 Nov 2017 16:16:37 +0530

Hi Andrew,

> tricks have and that edns-client-subnet addresses.

Having thought about this a bit, what got me was this:

1.  I get the impression through my own experience that it doesn't seem
to be used (I see odd localizations that could have been avoided were it
so); and
2.  Given that, DOH can exacerbate the problem if the service is not
deployed as a CDN itself.

So I think Mark's right to out the remediation.  I just am wary that
it's enough.

Eliot