[DNSOP] Re: Side Meeting - DNS Load Balancing

Joe Abley <jabley@strandkip.nl> Mon, 01 July 2024 06:25 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 978C4C180B4E for <dnsop@ietfa.amsl.com>; Sun, 30 Jun 2024 23:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.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_NONE=-0.0001, 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 Iuyd-zcs-Uyl for <dnsop@ietfa.amsl.com>; Sun, 30 Jun 2024 23:24:57 -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 C02DCC1516F8 for <dnsop@ietf.org>; Sun, 30 Jun 2024 23:24:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=strandkip.nl; s=sig1; t=1719815097; bh=8gabeQZMufuIu46GQPMzGZtCHK2PRLTvvEzK5R8CopM=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=hIHniX2wD7DnD0AkwnOYhMRkIEVvE4+GmiivvZRKWQsnJGYJLgHcHQfUPAe7Qj9cP 27ChRUU0bMfM4Fo0IRKuxoz0h466nVfA7cUWgKC0bGuHgY+8pZbkCf/4AjcMBxoOLe 6+4D/Lenu4cw0PipEdUAT2sBdJyVEAx31Cv+WrH51MQyPT62rU+mybi7GzmBubp936 x9STFNfrnwyrlZ6LuBUy79L+zn2UY3tkJa6kboYyK6Av0/gNVbouixYFhJF3tH2I7S VRwo/sz+A5VH8TqfGQs2ELOeZCPWwLPzPa7W1Nvo6gsHRPb5sKuYVGB/2LprDDqtOE DwjVPnCrO5giw==
Received: from smtpclient.apple (pv50p00im-dlb-asmtp-mailmevip.me.com [17.56.9.10]) by pv50p00im-zteg10011401.me.com (Postfix) with ESMTPSA id 4FF3BDC03AC; Mon, 1 Jul 2024 06:24:53 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
From: Joe Abley <jabley@strandkip.nl>
In-Reply-To: <5020268.31r3eYUQgx@heater.srcl.tisf.net>
Date: Mon, 01 Jul 2024 09:24:39 +0300
Message-Id: <32B33399-3B9D-402E-895E-0CF03690A34A@strandkip.nl>
References: <5020268.31r3eYUQgx@heater.srcl.tisf.net>
To: Paul Vixie <paul=40redbarn.org@dmarc.ietf.org>
X-Mailer: iPhone Mail (21F90)
X-Proofpoint-ORIG-GUID: Rgsdjt1RGaaPCxBTbPlB1k7nvMrR4_iP
X-Proofpoint-GUID: Rgsdjt1RGaaPCxBTbPlB1k7nvMrR4_iP
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-07-01_05,2024-06-28_01,2024-05-17_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxscore=0 mlxlogscore=315 adultscore=0 malwarescore=0 clxscore=1030 spamscore=0 suspectscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2407010047
Message-ID-Hash: IYNXVC3VM2RNY6BKKEO266SIZJPKYDWH
X-Message-ID-Hash: IYNXVC3VM2RNY6BKKEO266SIZJPKYDWH
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/3NUIQnJKCLAXp3qdA5yf0Jbpg7I>
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 1 Jul 2024, at 07:19, Paul Vixie <paul=40redbarn.org@dmarc.ietf.org> wrote:

> joe, let's figure out how to "rigidly constrain" again. expressing fixed policy
> which can operate inside the recursive system would be a whole lot easier to
> diagnose whenever it's unreliable, but avoid the additional round trips that
> the CDN world fears so strongly. we should want that outcome, which
> corresponds to "anti-complexity".

The BOF is about the practice of authority servers returning client-specific responses to clients in order to direct applications to particular destinations.

The IETF in the past has said "don't do that" about things it has felt were distasteful, or it has refused to say anything because the dirty business in question was somehow not worthy of recognition. NAT was one of those things, and as a result v4 NAT traversal is a pig's ear. To me this BOF is an attempt not to perpetuate the same mistake with "DNS load balancing".

Coming up with a replacement mechanism sounds lovely but I suspect is unlikely to change the core architectures of those CDNs and other providers who have deployed these existing mechanisms, and if that turns out to be true we will have an additional mechanism to manage in fine xkcd-927 style. 

Documenting the existing mechanisms and perhaps coming up with ways to make them more supportable seem like better bets if the goal is to move the needle on operational reliability.

> davey, "another indirection" means both more round trips and more complexity,
> and will find few friends.

Not in the sense I intended it.

Names are a layer of indirection for addresses. Any layer of indirection is an open door for a control plane.

I'm saying that it's unremarkable that people are using the DNS as part of the process of connecting applications to content in a dynamic, user-centric way. I am saying nothing about how many round trips might be involved in doing so. 


Joe