Re: [Resolverless-dns] Load-balancing concerns

Dave Lawrence <tale@dd.org> Thu, 08 November 2018 09:27 UTC

Return-Path: <tale@dd.org>
X-Original-To: resolverless-dns@ietfa.amsl.com
Delivered-To: resolverless-dns@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D4E130E83 for <resolverless-dns@ietfa.amsl.com>; Thu, 8 Nov 2018 01:27:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkBbLpQobPlG for <resolverless-dns@ietfa.amsl.com>; Thu, 8 Nov 2018 01:27:07 -0800 (PST)
Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89F7130E7A for <resolverless-dns@ietf.org>; Thu, 8 Nov 2018 01:27:05 -0800 (PST)
Received: by gro.dd.org (Postfix, from userid 102) id D699832AB0; Thu, 8 Nov 2018 04:27:04 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23524.360.861432.338830@gro.dd.org>
Date: Thu, 08 Nov 2018 04:27:04 -0500
From: Dave Lawrence <tale@dd.org>
To: resolverless-dns@ietf.org
In-Reply-To: <CAN-AkJtKbgy0RNf6c5TZd3j5SsjaYe4CwtkaQzYA=FhrrAvJAA@mail.gmail.com>
References: <CAN-AkJtKbgy0RNf6c5TZd3j5SsjaYe4CwtkaQzYA=FhrrAvJAA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/Z-weScHPkQxMvjBdC7HLKYlVKic>
Subject: Re: [Resolverless-dns] Load-balancing concerns
X-BeenThere: resolverless-dns@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Resolverless DNS <resolverless-dns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/resolverless-dns/>
List-Post: <mailto:resolverless-dns@ietf.org>
List-Help: <mailto:resolverless-dns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 09:27:09 -0000

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.