Re: [Resolverless-dns] Load-balancing concerns

Dave Lawrence <tale@dd.org> Thu, 08 November 2018 06:33 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 0FD7A130DE2 for <resolverless-dns@ietfa.amsl.com>; Wed, 7 Nov 2018 22:33:49 -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 QoSpq07W6DlZ for <resolverless-dns@ietfa.amsl.com>; Wed, 7 Nov 2018 22:33:47 -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 337A012D4ED for <resolverless-dns@ietf.org>; Wed, 7 Nov 2018 22:33:47 -0800 (PST)
Received: by gro.dd.org (Postfix, from userid 102) id 87FB332894; Thu, 8 Nov 2018 01:33:45 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <23523.55497.532269.465187@gro.dd.org>
Date: Thu, 8 Nov 2018 01:33:45 -0500
From: Dave Lawrence <tale@dd.org>
To: resolverless-dns@ietf.org
In-Reply-To: <CAN-AkJt=Oe5oO19Zu-fKqzHvTD5P4PcrGq8t8Hg3rNkUQxC8WA@mail.gmail.com>
References: <CAN-AkJt=Oe5oO19Zu-fKqzHvTD5P4PcrGq8t8Hg3rNkUQxC8WA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/mK89xIdU_kqGSv3D_ZqkaSgUe2Q>
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 06:33:49 -0000

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.