Subject: Re: [Resolverless-dns] Load-balancing concerns

From: Justin Henck <[email-masked]>
Date: Thu, 8 Nov 2018 15:19:21 +0700

>
>
> 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.
>

You'll have to forgive my ignorance - I definitely don't pretend to be an
expert in any of these areas.  My understanding (please correct me!) was
that generally an authoritative will return a single A or AAAA record based
on a particular query, but with DNSSEC it will return an entire relevant
RRSET.  So although there might be multiple such RRSETs you will at least
have (perhaps) more than one IP.

I was imagining a worst-case scenario (heavily simplified):
-----Definitions-----
Primary Server  - In country "A"
Referred Service - Global. Has different sets of servers for different
locations/networks
Many Users - In country "B"

------Scenario:------
1. Many Users load page from Primary Server in a short time.
2. Primary Server queries for a record for Referred Service.
3. Primary Server caches a single IP in country "A" for Referred Service
4. Many Users hit single IP for Referred Service which experiences Bad
Things

The partial alleviation I was hypothesizing about was:
------Scenario:-------
1. Many Users load page from Primary Server in a short time.
2. Primary Server queries for a complete RRSET for Referred Service
3. Primary Server caches country "A" RRSET for Referred Service
4. Many Users' clients pick different IPs for Referred Service and connect
to them
5. Many Users' clients receive AltSvc records telling them to use an IP in
country "B" for their next connection

Pure point of ignorance: To your point about different clients getting
different IPs - does that extend beyond the resolver+ECS level? E.g. if
10,000 customers using a mobile carrier in a single city hit their ECS-less
resolver for a particular domain, will they get different IPs?

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

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

---

From: Jim Reid <[email-masked]>
Date: Thu, 8 Nov 2018 08:47:50 +0000

> On 8 Nov 2018, at 08:19, Justin Henck <henck=[email-masked]> wrote:
> 
> You'll have to forgive my ignorance - I definitely don't pretend to be an expert in any of these areas.  My understanding (please correct me!) was that generally an authoritative will return a single A or AAAA record based on a particular query, but with DNSSEC it will return an entire relevant RRSET.

Not quite. If an authoritative server is queried for the A or AAAA records for some name, it will return all the matching A (or AAAA) records. [Modulo truncated responses and TCP retries.] It won't return a single A or AAAA record unless of course there's only one of them.

When DNSSEC is used, authoritative servers return RRsets.* That's because the signature covers the RRset and the validator has to have all of the original data -- the RRset -- so that it can validate the signed response.

*That's pretty much the same as the unsigned response with the addition of some extra RRtypes for the DNSSEC special sauce.

---

From: Justin Henck <[email-masked]>
Date: Thu, 8 Nov 2018 16:16:04 +0700

Got it, I made a mistake and inferred behavior from recursives :-/

How is a "resolverless" (unrequested resolution?) solution here any
different from sharing a recursive, if we use ECS or if the primary service
is widely deployed?

E.g. it seems to me that there are three scenarios:
1) really large globally distributed services implementing will act like
geographicaply distributed resolvers, which some of them also are
2) small single-datacenter services won't produce enough traffic to matter
3) large single-datacenter services might cause a problem

Are there other negative scenarios? I suppose 1 but not very well
distributed?

On Thu, Nov 8, 2018, 3:47 PM Jim Reid <[email-masked] wrote:

> > You'll have to forgive my ignorance - I definitely don't pretend to be
> an expert in any of these areas.  My understanding (please correct me!) was
> RRSET.
> Not quite. If an authoritative server is queried for the A or AAAA records
> for some name, it will return all the matching A (or AAAA) records. [Modulo
> truncated responses and TCP retries.] It won't return a single A or AAAA
> record unless of course there's only one of them.
>
> When DNSSEC is used, authoritative servers return RRsets.* That's because
> the signature covers the RRset and the validator has to have all of the
> original data -- the RRset -- so that it can validate the signed response.
>
> *That's pretty much the same as the unsigned response with the addition of
> some extra RRtypes for the DNSSEC special sauce.
>
>

---

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

Justin Henck writes:
> You'll have to forgive my ignorance - I definitely don't pretend to
> be an expert in any of these areas.  My understanding (please
> correct me!) was that generally an authoritative will return a
> single A or AAAA record based on a particular query, but with DNSSEC
> it will return an entire relevant RRSET.

It depends.

Non-mapping authorities, the pre-CDN norm and still very common, will
return every record matching the qname/qclass/qtype tuple.  That's the
RRSet.  Most names (hand-wavingly most--I confess no data) only
had one address for A or AAAA though so your sense that they would
generally return a single record is probably apt.  The presence or
absence of DNSSEC doesn't really change any of the preceding.

Then CDNs with their mapping authorities came along and muddied things
a bit.  Akamai would, for example, generally provide two IP addresses
in an answers to any given query, but from a much larger pool.
Because the number of permutations was large that also meant CDNs were
late to the party on DNSSEC implementation, and didn't offer it at all
for a very long time so asking for it wouldn't have changed their
behaviour.  Now those that offer DNSSEC tend to do so with some form
of online signing -- it's way too much to sign all the permutations
individually and or to hand out all thousands of addresses in one
RRset, so they sign just the one their answering with when they need
to, and still only hand out a couple (or few) at a time.  So the
presence or absence of DNSSEC here also ultimately doesn't make a
difference as far as how many addresses a client is seeing in a
response.

> Pure point of ignorance: To your point about different clients
> getting different IPs - does that extend beyond the resolver+ECS
> level? E.g. if 10,000 customers using a mobile carrier in a single
> city hit their ECS-less resolver for a particular domain, will they
> get different IPs? 

It depends again, but mostly they get the same IPs because caching.
It depends a little on what time scale you're looking and other things
happening at the time. CDNs can keep mappings pretty stable for long
periods of time, so all those clients would tend to get the same
addresses over multiple TTL cycles.  If a flash mob comes along they
might quickly remap the load so that successive refreshes of the cache
end up with different addresses.

---

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

Justin Henck writes:
> different from sharing a recursive, if we use ECS or if the primary
> service is widely deployed?

The landscape is complicated.  In many cases it will offer the same
results.  In some cases it will be demonstrably more bad.  In some
cases it might even be a bit better.    There are a lot of variables
to suss out here.

> geographicaply distributed resolvers, which some of them also are

Right this one probably ends up looking largely like a regular
recursive resolver now, so is basically fine.

> 2) small single-datacenter services won't produce enough traffic to matter

I think maybe we shouldn't be cavalier with "to matter", because
it could very well matter quite a lot to the clients here.

> 3) large single-datacenter services might cause a problem

Yep.

> Are there other negative scenarios? I suppose 1 but not very well

Yep,

---

From: Justin Henck <[email-masked]>
Date: Thu, 8 Nov 2018 16:59:31 +0700

> it could very well matter quite a lot to the clients here.

Point well taken. I think my definition of small was a bit
self-referential.  (E.g. small defined as won't produce a heavy load.) But
I realize now that there are other reasons beyond load-balancing for
wanting to have traffic sent to a particular geographic location.  That
brings me back to the idea of opt-out or constraints.

Are there any minimum use cases that haven't been proposed?
What about if the DNSSEC-signed records have to include the ip serving the
push? That would suggest that the RRSET might be appropriate for the
client. (An obvious exception: an anycast IP signed with a bunch of unicast
ones.)

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

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

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