IETF Logo Mail Archive

[DNSOP] Re: Side Meeting - DNS Load Balancing

Paul Vixie <paul@redbarn.org> Sat, 29 June 2024 18:00 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 8CEE6C14F681 for <dnsop@ietfa.amsl.com>; Sat, 29 Jun 2024 11:00:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, HTML_MESSAGE=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=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 fiDm0M_p_zV8 for <dnsop@ietfa.amsl.com>; Sat, 29 Jun 2024 11:00:02 -0700 (PDT)
Received: from util.redbarn.org (util.redbarn.org [IPv6:2001:559:8000:cd::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 977FBC14F609 for <dnsop@ietf.org>; Sat, 29 Jun 2024 11:00:02 -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 91C661A2926; Sat, 29 Jun 2024 18:00:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1719684001; bh=03Qt+QUGg1ElRfl8AssswysEpm128q1kPv/AcQxHDSA=; h=Date:Subject:In-Reply-To:References:From:To:Cc; b=ILiRsLiMJmmZJ+6KmNzUak56lmbP+BlJtpIY46/Tlk8hOhppuR6hk7dlUrpxB9kg4 AGAoExlEbReeTECoUGsXv+3O2oJK8cOjbvJ6fIiVmiFZKyHj3lc2e/chJlwpdVRlQz nebyGZjBESy8RwBhPOmIGOMIZRespRT4KCaEI38k=
Received: from [24.104.150.143] (dhcp-143.access.rits.tisf.net [24.104.150.143]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 ESMTPSA id 58DADC3F21; Sat, 29 Jun 2024 18:00:01 +0000 (UTC)
Date: Sat, 29 Jun 2024 10:59:59 -0700
Message-ID: <509f0d65-0e43-4ad6-ad33-e4345c1a35aa@redbarn.org>
In-Reply-To: <ACFFD3D5-0524-4EC5-9F0E-83B5D32A8925@rfc1035.com>
References: <SA1PR15MB4370B67BA1571F9246FD00CDB3D02@SA1PR15MB4370.namprd15.prod.outlook.com> <dda32a30-518d-40dd-b7da-a19e8e9b3d4d@bellis.me.uk> <ACFFD3D5-0524-4EC5-9F0E-83B5D32A8925@rfc1035.com>
From: Paul Vixie <paul@redbarn.org>
To: Jim Reid <jim@rfc1035.com>, Ray Bellis <ray@bellis.me.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.boxer.email_3198368788191300"
Message-ID-Hash: PMSVNWBLB6F7DT42N6QW3NIZPDJ3RHXW
X-Message-ID-Hash: PMSVNWBLB6F7DT42N6QW3NIZPDJ3RHXW
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
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/TWD2op_jsDNbPoedNAxZ4P9VlyQ>
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>

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. That's workable. 


DNS RPZ, mentioned below, is intended as a security enhancer below the recursive and ought not be used above the recursive. So, off topic here. But to be clear, ECS has shown that the CDN industry is willing to involve recursive servers in their path selection activities, we might expect more technology of that kind to result from this side meeting. 


p vixie 


On Jun 29, 2024 10:36, Jim Reid <jim@rfc1035.com> wrote:



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

_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-leave@ietf.org

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