IETF Logo Mail Archive

[DNSOP] Re: Side Meeting - DNS Load Balancing

Jim Reid <jim@rfc1035.com> Sat, 29 June 2024 17:35 UTC

Return-Path: <jim@rfc1035.com>
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 7B470C14F6A6 for <dnsop@ietfa.amsl.com>; Sat, 29 Jun 2024 10:35:45 -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 xuI8QyGEtkPU for <dnsop@ietfa.amsl.com>; Sat, 29 Jun 2024 10:35:44 -0700 (PDT)
Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37442C14F6A0 for <dnsop@ietf.org>; Sat, 29 Jun 2024 10:35:44 -0700 (PDT)
Received: from smtpclient.apple (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 9A7412420E4A; Sat, 29 Jun 2024 17:35:41 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <dda32a30-518d-40dd-b7da-a19e8e9b3d4d@bellis.me.uk>
Date: Sat, 29 Jun 2024 18:35:41 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <ACFFD3D5-0524-4EC5-9F0E-83B5D32A8925@rfc1035.com>
References: <SA1PR15MB4370B67BA1571F9246FD00CDB3D02@SA1PR15MB4370.namprd15.prod.outlook.com> <dda32a30-518d-40dd-b7da-a19e8e9b3d4d@bellis.me.uk>
To: Ray Bellis <ray@bellis.me.uk>
X-Mailer: Apple Mail (2.3774.600.62)
Message-ID-Hash: VLETSOFVFNCQMQRDVZMN5GZIYEWMD2EO
X-Message-ID-Hash: VLETSOFVFNCQMQRDVZMN5GZIYEWMD2EO
X-MailFrom: jim@rfc1035.com
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/afEjj4Qa5NoCy2P1I7yZTTv_EiM>
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 18:10, Ray Bellis <ray@bellis.me.uk> wrote:
> 
> The DNS was never designed intended to deliver different answers to different users.  DNSSEC solidified that and the practise IMNSHO should be discouraged, not standardised.

While this is undoubtedly true Ray, that ship sailed a *long* time ago*. 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.

* IIUC BIND provides a few options to enable this bad idea: RPZ for instance.

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