[DNSOP] Re: Side Meeting - DNS Load Balancing

Joe Abley <jabley@strandkip.nl> Sat, 29 June 2024 18:50 UTC

Return-Path: <jabley@strandkip.nl>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93C1C151980 for <dnsop@ietfa.amsl.com>; Sat, 29 Jun 2024 11:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strandkip.nl
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTKC_-nVadiN for <dnsop@ietfa.amsl.com>; Sat, 29 Jun 2024 11:50:27 -0700 (PDT)
Received: from pv50p00im-zteg10011401.me.com (pv50p00im-zteg10011401.me.com [17.58.6.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8FDEC151989 for <dnsop@ietf.org>; Sat, 29 Jun 2024 11:50:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=strandkip.nl; s=sig1; t=1719687027; bh=xTC4KaE30JB35GuwmViXIMrMA5eqVwPBmjH8te+br4Q=; h=Content-Type:From:Mime-Version:Subject:Date:Message-Id:To; b=oWsFoCh9gtNVH9+9Tave2c2yEr5OpCJ6kUg5T0BZF1u3TiEE4zalYoMNrEedEuA5s 13wvC60QqSPC4nceJe281OK9/AyHdbW9A5SiUzKZYsOFcp3iP4eOx4O3+p7z52t9BR I1Tcg8aKIXA6qzAL18XBw79E04cdSoYb0/9i/s6shb9FVoQYd+QGsissK0yG14obKs U4ax+jScOQoUKhyajHPjntQHoWY54GjYet8XH5M8emVBEJoxEwEM6cgQc5YQkKqqqi MBp7azgcAPAvPnZYTH+ZW1hSLfSXsqg9LFKpf51D/X/C42ezncCw2z7XA2v1mZ15zY oLz7nbtaQVQUw==
Received: from smtpclient.apple (pv50p00im-dlb-asmtp-mailmevip.me.com [17.56.9.10]) by pv50p00im-zteg10011401.me.com (Postfix) with ESMTPSA id C0177DC0227; Sat, 29 Jun 2024 18:50:25 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
From: Joe Abley <jabley@strandkip.nl>
Mime-Version: 1.0 (1.0)
Date: Sat, 29 Jun 2024 21:50:11 +0300
Message-Id: <8C1D853F-17D4-4E2B-B281-F7FCA50DA8B3@strandkip.nl>
References: <dda32a30-518d-40dd-b7da-a19e8e9b3d4d@bellis.me.uk>
In-Reply-To: <dda32a30-518d-40dd-b7da-a19e8e9b3d4d@bellis.me.uk>
To: Ray Bellis <ray@bellis.me.uk>
X-Mailer: iPhone Mail (21F90)
X-Proofpoint-ORIG-GUID: mx6gih5TqdPt1ePRGwDaggsZ4Bh8zx39
X-Proofpoint-GUID: mx6gih5TqdPt1ePRGwDaggsZ4Bh8zx39
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-06-29_08,2024-06-28_01,2024-05-17_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=727 phishscore=0 adultscore=0 bulkscore=0 suspectscore=0 mlxscore=0 spamscore=0 malwarescore=0 clxscore=1030 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2406290136
Message-ID-Hash: HDRCNZPIAKNAJNGWWD3RCDZ5RUXWYZLL
X-Message-ID-Hash: HDRCNZPIAKNAJNGWWD3RCDZ5RUXWYZLL
X-MailFrom: jabley@strandkip.nl
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: Side Meeting - DNS Load Balancing
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Cq05q4uorDSpDU_rnJ68OUsZQuI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

On 29 Jun 2024, at 20:13, Ray Bellis <ray@bellis.me.uk> wrote:

> Can you please ensure that there's time on the agenda for discussion on why it remains a bad idea to use the internet's name to resource mapping scheme to perform what should be achieved in the routing layer?

This seems like a bit of an inflammatory overreach, Ray :-)

Names as a layer of indirection between applications and addresses represent dynamic data by design, and the idea that the manner by which that data can be managed must be rigidly constrained seems unnecessary and a bit out of touch with reality.

> The DNS was never designed intended to deliver different answers to different users.

Strictly speaking, that statement is incompatible with the concept of loose coherence which certainly was part of the original design. I appreciate this is not what you meant. 

More broadly, the absence of something from the original design hardly means that it can never exist. See, for example, every DNS-related RFC since 1035.

The DNS hasn't operated within a single namespace for a long time. Different vantage points, different namespaces, different response data. I'm not sure I understand the benefit of pretending this is not true. 

>  DNSSEC solidified that and the practise IMNSHO should be discouraged, not standardised.

DNSSEC did nothing of the sort. 

The practice of off-line signing did not imagine dynamic response policy at query time, because it didn't fit that model very easily. But the fact that some implementations are built around that premise doesn't make other approaches wrong.


Joe