Re: [Resolverless-dns] Load-balancing concerns

Dave Lawrence <tale@dd.org> Thu, 08 November 2018 07:04 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 5CFB7130DC2 for <resolverless-dns@ietfa.amsl.com>; Wed, 7 Nov 2018 23:04:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MARKETING_PARTNERS=0.001, SPF_PASS=-0.001] autolearn=no 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 SQDrmjMJMMAe for <resolverless-dns@ietfa.amsl.com>; Wed, 7 Nov 2018 23:04:51 -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 6D8981294D7 for <resolverless-dns@ietf.org>; Wed, 7 Nov 2018 23:04:51 -0800 (PST)
Received: by gro.dd.org (Postfix, from userid 102) id EF8A6328A5; Thu, 8 Nov 2018 02:04:48 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <23523.57360.956625.553332@gro.dd.org>
Date: Thu, 8 Nov 2018 02:04:48 -0500
From: Dave Lawrence <tale@dd.org>
To: resolverless-dns@ietf.org
In-Reply-To: <CAArYzrLR52xtoCLs4S7wATXnERs_ea5CCz8ovC-8P5DSv7peng@mail.gmail.com>
References: <CAN-AkJt=Oe5oO19Zu-fKqzHvTD5P4PcrGq8t8Hg3rNkUQxC8WA@mail.gmail.com> <23523.55497.532269.465187@gro.dd.org> <CAArYzrLR52xtoCLs4S7wATXnERs_ea5CCz8ovC-8P5DSv7peng@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/lOB7sIiTw1IJxueNE93CbKXQp_k>
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 07:04:52 -0000

manu tman writes:
> Except that it will be based on the IP of the DoH server and not the
> 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