[DNSOP] Re: Side Meeting - DNS Load Balancing

Jared Mauch <jared@puck.nether.net> Thu, 18 July 2024 18:39 UTC

Return-Path: <jared@puck.nether.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 392C2C14F60E for <dnsop@ietfa.amsl.com>; Thu, 18 Jul 2024 11:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.305
X-Spam-Level:
X-Spam-Status: No, score=-4.305 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 (2048-bit key) header.d=puck.nether.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 U3JC8Af9B8C4 for <dnsop@ietfa.amsl.com>; Thu, 18 Jul 2024 11:39:15 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (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 DA6C1C151078 for <dnsop@ietf.org>; Thu, 18 Jul 2024 11:39:15 -0700 (PDT)
Received: by puck.nether.net (Postfix, from userid 1001) id 7CCD15403E2; Thu, 18 Jul 2024 14:39:10 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 puck.nether.net 7CCD15403E2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=puck.nether.net; s=default; t=1721327950; bh=9T6ps48U2tt+6ejAVgRkBmNaaCQ0hSgX+uRakNoKnnI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JlhIvzg+X9rMmNlEagdzkh8vY2gHmrQhJsRXr6X7zRqaHIMu9JDLeFU/RXOqT3KAh WYiZHcJlWbbqxmuIiEcU/tJvavuZyCyZ6/6rVB0bGMzXFX9EDvmTLlfEDegk8I47KU NXXWzZHlsfWx16YI5OgpdyPW7WWkxQfVUJT0ot5GnXkbS9goiuidNRLs9+C53KoTyT KPZ2XxuS+MTql/KWq/vCGE7OkVVe7/uBWRfePVhN7iHZbncPlVR7FRzytZRIMSba4v Qg/KKMRSrKtxqmXkTk236qgisgz8IiVOfx5/+LCEsXpZyfejmb7D8KFpvECuNC0k3H /DPVN7rS0RZrQ==
Date: Thu, 18 Jul 2024 14:39:10 -0400
From: Jared Mauch <jared@puck.nether.net>
To: Davey Song <songlinjian@gmail.com>
Message-ID: <ZplhTnEEzoAm5dcX@puck.nether.net>
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-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAAObRXL84d-BQWrPEDpps-4ghKGTiruTFe1vXOQSKrvp3gnUOQ@mail.gmail.com>
Message-ID-Hash: X2COC5RMNAPN2L22FNSVNSUZ6CMPYUN4
X-Message-ID-Hash: X2COC5RMNAPN2L22FNSVNSUZ6CMPYUN4
X-MailFrom: jared@puck.nether.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
CC: Joe Abley <jabley@strandkip.nl>, Ray Bellis <ray@bellis.me.uk>, 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/loEOal6S7smCFuhykbQnB_1Bdqw>
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 Mon, Jul 01, 2024 at 11:49:10AM +0800, Davey Song wrote:
>    People add tricks to DNS when DNS does not fit their needs. However, my
>    customers complained about the difficulties of deploying their DNS on
>    multiple platforms with different DNS tricks (GeoDNS for example) or
>    switching from one another.
>    I agree with Joe. DNS is a layer of indirection. If one indirection can
>    not solve the problem in a good manner, another indirection is needed. If
>    we do it in resolver like Paul suggest, another indirection protocol
>    should be introduced.  You can name it anything other than "DNS"...
>     
> 
>      Names as a layer of indirection between applications and addresses
>      represent dynamic data by design, and the idea that the manner by which
>      that data can be managed must be rigidly constrained seems unnecessary
>      and a bit out of touch with reality.
> 
>     
>    Davey 

	I'm not sure which is worse, morphing DNS answers or TTL=0 that
i've seen in the past as well from different systems.

	As anyone that has done anycast knows, it works but also has
numerous corner cases to mitigiate.  So do other "stupid dns tricks".

	I understand why folks don't want to accept/pass ECS along, but
the interesting thing is that privacy tradeoff isn't necessarily what
they think it is, they may be missing out on a more localized answer
with less hops for MITM purposes of the actual transaction vs an
authority or someone MITM resolver <-> authority knowing more about the
query origin, and that's before one talks about all the extra state.

	I've seen a few stupid DNS and routing tricks and like most
situations, nobodys hands are quite clean :-)

	- jared

-- 
Jared Mauch  | pgp key available via finger from jared@puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.