[DNSOP] Re: Side Meeting - DNS Load Balancing
Dave Lawrence <tale@dd.org> Tue, 02 July 2024 22:15 UTC
Return-Path: <tale@dd.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 4DBE9C1CAF2D for <dnsop@ietfa.amsl.com>; Tue, 2 Jul 2024 15:15:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 4lJRUTpwu9fC for <dnsop@ietfa.amsl.com>; Tue, 2 Jul 2024 15:15:28 -0700 (PDT)
Received: from fluff.twonth.com (fluff.twonth.com [45.79.143.238]) (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 CF7D9C1CAF2A for <dnsop@ietf.org>; Tue, 2 Jul 2024 15:15:28 -0700 (PDT)
Received: from gro.dd.org (c-76-23-204-191.hsd1.vt.comcast.net [76.23.204.191]) by fluff.twonth.com (Postfix) with ESMTPS id CE7FD1FCC0 for <dnsop@ietf.org>; Tue, 2 Jul 2024 22:15:27 +0000 (UTC)
Received: by gro.dd.org (Postfix, from userid 102) id 241808D3D4; Tue, 02 Jul 2024 18:15:27 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <26244.31743.123459.569215@gro.dd.org>
Date: Tue, 02 Jul 2024 18:15:27 -0400
From: Dave Lawrence <tale@dd.org>
To: dnsop@ietf.org
In-Reply-To: <5020268.31r3eYUQgx@heater.srcl.tisf.net>
References: <dda32a30-518d-40dd-b7da-a19e8e9b3d4d@bellis.me.uk> <8C1D853F-17D4-4E2B-B281-F7FCA50DA8B3@strandkip.nl> <CAAObRXL84d-BQWrPEDpps-4ghKGTiruTFe1vXOQSKrvp3gnUOQ@mail.gmail.com> <5020268.31r3eYUQgx@heater.srcl.tisf.net>
Message-ID-Hash: 2JISOJF5EUOV6XI6I2ER2UFHE6VBJGGQ
X-Message-ID-Hash: 2JISOJF5EUOV6XI6I2ER2UFHE6VBJGGQ
X-MailFrom: tale@dd.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/kcvIerByLzdbwYHYnGQIzWcanXY>
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>
Paul Vixie writes: > 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? Personally, even despite having the relevant haiku as my desktop background, I push back on this when it rears its head. I mean, even ignoring the trouble with absolutes like "always", which can rapidly be disproven. The DNS is remarkably robust. Even when a problem can be "ultimately traced down to something broken in the dns", it is often not the DNS itself that was broken. It frequently did a wonderful job of providing the answers it was told to provide. Sometimes it even did so heroically while under assault. And, of course, many times the problematic answers had nothing whatsoever to do with Stupid DNS Tricks(tm). So why is it perceived to be "always dns"? Because the DNS stands at an incredibly important juncture between people and machines. That interface is a concentrator and bound to be where failures on one side or the other become visible. That should be the answer to a non-DNS person asking why it always seems to be the DNS, not harping on the particular sub-developments that we don't care for. It can be fun to joke about, but please let's not feed the narrative that the DNS as a whole is pitifully flawed. Even with (despite?) the features that you dislike, it still has done an amazing job as a fundamental piece of the amazing technological advancement that has been the Internet.
- [DNSOP] Re: Side Meeting - DNS Load Balancing Joe Abley
- [DNSOP] Side Meeting - DNS Load Balancing Ben Schwartz
- [DNSOP] Re: Side Meeting - DNS Load Balancing Ben Schwartz
- [DNSOP] Re: Side Meeting - DNS Load Balancing Ben Schwartz
- [DNSOP] Re: Side Meeting - DNS Load Balancing Ray Bellis
- [DNSOP] Re: Side Meeting - DNS Load Balancing John Levine
- [DNSOP] Re: Side Meeting - DNS Load Balancing Jim Reid
- [DNSOP] Re: Side Meeting - DNS Load Balancing Joe Abley
- [DNSOP] Re: Side Meeting - DNS Load Balancing Paul Vixie
- [DNSOP] Re: Side Meeting - DNS Load Balancing Bill Woodcock
- [DNSOP] Re: Side Meeting - DNS Load Balancing Paul Vixie
- [DNSOP] Re: Side Meeting - DNS Load Balancing George Michaelson
- [DNSOP] Re: Side Meeting - DNS Load Balancing Davey Song
- [DNSOP] Re: Side Meeting - DNS Load Balancing Paul Vixie
- [DNSOP] Re: Side Meeting - DNS Load Balancing Davey Song
- [DNSOP] Re: Side Meeting - DNS Load Balancing Paul Vixie
- [DNSOP] Re: Side Meeting - DNS Load Balancing Dave Lawrence
- [DNSOP] Re: Side Meeting - DNS Load Balancing Edward Lewis
- [DNSOP] Re: Side Meeting - DNS Load Balancing Jared Mauch
- [DNSOP] Re: Side Meeting - DNS Load Balancing Davey Song