[DNSOP] Re: Side Meeting - DNS Load Balancing

Bill Woodcock <woody@pch.net> Sun, 30 June 2024 03:22 UTC

Return-Path: <woody@pch.net>
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 24BE2C15109A for <dnsop@ietfa.amsl.com>; Sat, 29 Jun 2024 20:22:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.706
X-Spam-Level:
X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=pch.net
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 OFEdZ02_Ns5z for <dnsop@ietfa.amsl.com>; Sat, 29 Jun 2024 20:22:21 -0700 (PDT)
Received: from secmail.pch.net (secmail.pch.net [206.220.231.87]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C6CDC14F5F9 for <dnsop@ietf.org>; Sat, 29 Jun 2024 20:22:21 -0700 (PDT)
Received: from secmail.pch.net (localhost [127.0.0.1]) by secmail.pch.net (Postfix) with ESMTP id 4WBZH10rF2z4y5MR for <dnsop@ietf.org>; Sat, 29 Jun 2024 20:22:21 -0700 (PDT)
Authentication-Results: secmail.pch.net (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=pch.net
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pch.net; h= x-mailer:message-id:in-reply-to:to:references:date:subject :mime-version:content-type:from; s=secmail_dkim; t=1719717740; x=1722309741; bh=jq9JIckttflsqJnjGCe7EWQz+QygjEMSYl4TtN/i1a0=; b= awkH7anr9P3gy/yRseqjLA1WSnCmZqOHBrtZ3JXYXmrPNhJzrOKZQz3dfj1Mnlo3 uqae1VEjx9caTuimu8uYMn/l1GzlEzMwfnXPv7mpZqWuAo8wbg0mKntsDW/cxt81 APv2Ce/p7TIioMAfLbUmU/hNv4CG1lC5mKrsSrBCvfA/Ua/6Xar4KeYDqqfLZUDQ oz27feW2bAhlKv2bF1NwkEIPPVvwaj8mR4I73loVf8LI+JwSOo5i9oAaQHTZrMDH d16HynR7rgsHdOFpapc/bYZIJw0UsJvCO+QaOeU3/4pb0SXeH7B536LT9zD8r4Wg cZlpaEI+myFw83XGrl5INg==
X-Virus-Scanned: amavisd-new at secmail.pch.net
Received: from secmail.pch.net ([127.0.0.1]) by secmail.pch.net (secmail.pch.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KCE8lVmt9PSf for <dnsop@ietf.org>; Sat, 29 Jun 2024 20:22:20 -0700 (PDT)
Received: from smtpclient.apple (unknown [66.185.123.190]) by secmail.pch.net (Postfix) with ESMTPSA id 4WBZGz6McGz4y5M3 for <dnsop@ietf.org>; Sat, 29 Jun 2024 20:22:19 -0700 (PDT)
From: Bill Woodcock <woody@pch.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_4FCB540E-2E2B-4B7D-96A2-DB0CC15AB999"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.11\))
Date: Sun, 30 Jun 2024 05:22:17 +0200
References: <SA1PR15MB4370B67BA1571F9246FD00CDB3D02@SA1PR15MB4370.namprd15.prod.outlook.com> <dda32a30-518d-40dd-b7da-a19e8e9b3d4d@bellis.me.uk> <ACFFD3D5-0524-4EC5-9F0E-83B5D32A8925@rfc1035.com> <509f0d65-0e43-4ad6-ad33-e4345c1a35aa@redbarn.org>
To: dnsop@ietf.org
In-Reply-To: <509f0d65-0e43-4ad6-ad33-e4345c1a35aa@redbarn.org>
Message-Id: <60FA3B2C-6A32-4211-8331-6C4768712B2D@pch.net>
X-Mailer: Apple Mail (2.3776.700.11)
Message-ID-Hash: N54HUVU5TSJFQSAXMGDQKT7ARE44SYZU
X-Message-ID-Hash: N54HUVU5TSJFQSAXMGDQKT7ARE44SYZU
X-MailFrom: woody@pch.net
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
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/2CtqiET7SuZEjQlY2oOGu9wedjc>
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 Jun 29, 2024, at 19:59, Paul Vixie <paul=40redbarn.org@dmarc.ietf.org> wrote:
> It's my hope that CDN support can be added to DNS in a way that allows all answers to be identical. Modern clients even mobile ones are powerful enough to make application layer routing decisions locally. But we have to move away from CNAME especially at the apex. The great bogie man of CDN seems to be additional round trips. 

Agreed.  I would suggest that another goal should be to move away from proprietary systems which attempt to lock content publishers into specific CDNs to the exclusion of others.  That is, essentially, single-homing on the content side, and is just as bad an idea as monopoly-enforced single-homing on the eyeball side.  Multi-signer DNSSEC was a step in the right direction, I think.  Anything which entrenches DNS inside CNS because the CDN is too stupid to function without even-stupider DNS tricks that break, for instance, zone transfer, is really bad.  And we’re at that point.  There are people who have data in CDNs, where the CDN tells them that they can only use that CDN’s associated DNS, and are either anti-competitively unwilling to support standards-based redundant DNS, or have broken things so badly that they’re technologically incapable of it.  Either is bad.

> On Jun 29, 2024 10:36, Jim Reid <jim@rfc1035.com> wrote:
> I agree this shouldn’t (doesn’t?) need to be standardised. 
> However if the side meeting is able a make valid case for work on the topic, it deserves to be heard. And if it doesn’t, the proponents can get to be heard and then dismissed. 

I agree with both of these as well.

                                -Bill