Subject: [Resolverless-dns] Load-balancing concerns

From: Justin Henck <[email-masked]>
Date: Thu, 8 Nov 2018 11:35:09 +0700

Hi all,

Some people mentioned load-balancing concerns during the meeting.  Ben
Schwartz pointed out to me that if a potential solution included DNSSEC,
then the server would have to push an entire RRSET.  If we combine that
with random IP selection by clients and AltSvc to solve geographical
misdirection, would that alleviate load balancing concerns?

Justin

Justin Henck
Product Manager
212-565-9811
google.com/jigsaw

PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 8 Nov 2018 01:33:45 -0500

Justin Henck writes:
> Some people mentioned load-balancing concerns during the meeting.
> Ben Schwartz pointed out to me that if a potential solution included
> DNSSEC, then the server would have to push an entire RRSET.  If we
> combine that with random IP selection by clients and AltSvc to solve
> geographical misdirection, would that alleviate load balancing concerns?

I'm afraid I don't understand the connection you're making.  What does
the setup, "would have to push an entire RRSET", have to do with the
rest of "If we combine that..."?  I'm not clear on how DNSSEC makes
any difference at all in this particular problem.

My guess is that you are imagining a situation where all possible
addresses that clients could receive are put into one A or AAAA
RRset.  This isn't the way most such systems work though.

For example, one CDN puts only the addresses it wants a particular
client to use into the answer, with the appropriate signature.  If you
then learned addresses for another client, with its own signature for
the RRSet, there's no way to combine those different answer sets into
one and still have it validate.  

Even if you could combine them, random selection would then largely
defeat the way the CDN is trying to direct traffic, but for the
occasions where the random guess was right.

Of course, a DoH server which has used EDNS Client Subnet (or some
other internal mechanism) to know appropriate client-based answers can
just use the appropriate RRset and signature and be as true to the
load-balancing and geo-redirection intents as if the client had just
asked through conventional DNS.  If the DoH server can't do ECS or
otherwise have mapping information from the authority, any customized
answers it gets will be resolver-mapped just like a client talking to
any traditional non-ECS resolver. It's really hard to imagine how it
could be otherwise without even more significant changes to the way
things are done now, far beyond random IP selection.

---

From: manu tman <[email-masked]>
Date: Thu, 8 Nov 2018 13:44:17 +0700

On Thu, Nov 8, 2018 at 1:33 PM Dave Lawrence <[email-masked]> wrote:

>  If the DoH server can't do ECS or
> any traditional non-ECS resolver.

> Except that it will be based on the IP of the DoH server and not the
resolver of the client, which in most cases will be more representative of
the actual network location (ISP or subnets of ISP) of the client.

The DoH server will most likely be mapped to the “best” location for the
majority of the clients using the service at the cost of totally bad
selection for the ones that don’t fall in the majority bucket and its
neighbors.

Manu

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 8 Nov 2018 02:04:48 -0500

manu tman writes:
> resolver of the client,

Right, as I said (or thought I said).

> which in most cases will be more representative of the actual
> network location (ISP or subnets of ISP) of the client.

I question the validity of this assertion.  It seems to be making a
huge assumptive leap about where the server providing the records is
and what its network relationship to any given client is, and
completely discounting typical resolver locality.  "in most cases"
will need some data to support it, and it's way too early in the brave
new DoH world to have good data on that.

Personally I expect DoH to be used in a variety of environments, not
just by the biggest providers with worldwide footprints.

> The DoH server will most likely be mapped to the best location for
> the majority of the clients using the service

Who said the DoH server is getting mapped at all, or has any locality
to the additional resources it is trying to provide access to?

Imagine a pretty reasonable set up where some website which only has a
handful of deployments, say a couple in North America and a couple in
Europe, wants to point records for one of its partners which actually
has a much broader footprint.  An Asian client connected to one of the
North American data centers and getting American-mapped answers when
the partner site would much rather have preferred you be using one of
their Asian installations if only you'd asked through normal DNS.

That's just the simple case of network-performance mapping anyway, and
completely ignores other mapping

---

From: manu tman <[email-masked]>
Date: Thu, 8 Nov 2018 14:35:33 +0700

> Right, as I said (or thought I said).

It was not clear to me, you mentioned it would be resolver-based but this
resolver is now unrelated to the original resolver. I may have missed the

> new DoH world to have good data on that.

I am referring to the recursive resolver of the original client, not the
DoH server that would now return records. Before resolverless, you would
return answers based on client recursive resolver IP (which I assume is
somewhat "close" to the end user, but don't have data to back this up
with), with resolverless dns, it would be based on the IP of the DoH server
(or the recursive resolver used by that one).

> their Asian installations if only you'd asked through normal DNS.

This is what I wanted to say and failed at apparently. I did not mean to
contradict your statement, but rather support it.
That being said, chances are that if the majority of the users that use the
first North American server are actually Asian users, chances are the
effect will be that North American users will end up being sent to the
Asian servers of the second site instead of the North American one. As you
said, this is network performance mapping, not geo locality.

> --
> Resolverless-dns mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/resolverless-dns
>