IETF Logo Mail Archive

[DNSOP] Re: Side Meeting - DNS Load Balancing

Paul Vixie <paul@redbarn.org> Mon, 01 July 2024 04:17 UTC

Return-Path: <paul@redbarn.org>
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 74EBAC15155E for <dnsop@ietfa.amsl.com>; Sun, 30 Jun 2024 21:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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_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 (1024-bit key) header.d=redbarn.org
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 5lkJjnegnGfe for <dnsop@ietfa.amsl.com>; Sun, 30 Jun 2024 21:17:44 -0700 (PDT)
Received: from util.redbarn.org (util.redbarn.org [24.104.150.222]) (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 D8D61C151539 for <dnsop@ietf.org>; Sun, 30 Jun 2024 21:17:44 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.redbarn.org", Issuer "RapidSSL TLS RSA CA G1" (not verified)) by util.redbarn.org (Postfix) with ESMTPS id 51D451A2926 for <dnsop@ietf.org>; Mon, 1 Jul 2024 04:17:44 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1719807464; bh=XiRVUbZqYZayY5vPHHek0dnIRzV6cj9NixtJjOIbGp4=; h=From:To:Subject:Date:In-Reply-To:References; b=d8pd4SWDY216oRGkS4suViANoLmK8CgMT5Ykskll3HhOOj7lACr1zyArvhKC9Q4Uy VVmdsOAQxpipe36iH246TseFfNvonL1u/oYfFxUysB+oWKoE+Z7qwWsASoWHmpfDri 3/Y+Q3sfqR514v23HVc4SLPymG9nqzEEGxT4sB7w=
Received: from heater.srcl.tisf.net (dhcp-176.access.rits.tisf.net [24.104.150.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPS id 16F03C3F21 for <dnsop@ietf.org>; Mon, 1 Jul 2024 04:17:44 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: dnsop@ietf.org
Date: Sun, 30 Jun 2024 21:17:43 -0700
Message-ID: <5020268.31r3eYUQgx@heater.srcl.tisf.net>
In-Reply-To: <CAAObRXL84d-BQWrPEDpps-4ghKGTiruTFe1vXOQSKrvp3gnUOQ@mail.gmail.com>
References: <dda32a30-518d-40dd-b7da-a19e8e9b3d4d@bellis.me.uk> <8C1D853F-17D4-4E2B-B281-F7FCA50DA8B3@strandkip.nl> <CAAObRXL84d-BQWrPEDpps-4ghKGTiruTFe1vXOQSKrvp3gnUOQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Message-ID-Hash: MRGOB5CC2FE4TCB4JOO6P2MITNCGMKCP
X-Message-ID-Hash: MRGOB5CC2FE4TCB4JOO6P2MITNCGMKCP
X-MailFrom: paul@redbarn.org
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/P2QDhnzaz2rIdQNg2ilOY0b41Dk>
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>

somebody asked me a few months ago why "it's always dns"? meaning, why are so 
many mysteries and outages ultimately traced down to something broken in dns? 
i answered that dns as conceived worked very well, and the first round of 
changes (ixfr, update, notify, edns) helped it work well even at scale, but 
after the commercial web industry started turning dns into whatever their 
marketing departments needed it to be, it got very complex, and flaky.

hear: https://changelog.com/person/paul-vixie

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".

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

see: https://queue.acm.org/detail.cfm?id=1242499

vixie

v2.26.15 | Report a Bug | By Email | System Status