[DNSOP] Re: Side Meeting - DNS Load Balancing

Davey Song <songlinjian@gmail.com> Mon, 01 July 2024 03:49 UTC

Return-Path: <songlinjian@gmail.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 B6F3DC151061 for <dnsop@ietfa.amsl.com>; Sun, 30 Jun 2024 20:49:23 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 NKIqtU8urSEK for <dnsop@ietfa.amsl.com>; Sun, 30 Jun 2024 20:49:23 -0700 (PDT)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 5789DC14F704 for <dnsop@ietf.org>; Sun, 30 Jun 2024 20:49:23 -0700 (PDT)
Received: by mail-il1-x133.google.com with SMTP id e9e14a558f8ab-376517b9408so11025715ab.0 for <dnsop@ietf.org>; Sun, 30 Jun 2024 20:49:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719805762; x=1720410562; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rvZn76ADu7b2Pm/IhS+ieMr90lBlTajVhNIdWbDwmG0=; b=gi6fKOHSaWyPrw8TNEA9nfJKqp0cdkjdxFFgrVeuiZ1l1qCsnZKHv/lgHkawt2Asyg DEluqBEsr6V/Pmes41Y6534CxFANDBwUY64qEhPSd7Kk26rQufl+imoeV6/4uA1nTZkx wUhd1eZjjSyW+s+cHNgcVBzEL8YcjqYYsPL1Pc8jhePR6URuiXuxd87H1xAi93tBlXKp 3hwr7gNifxB3jE0Ujej9OYaG0tYj/xOd3bWND+f/xf4w0S1bKfSw2xcQ1dNrykzNJFCS O6YX6brID+fmLlu3JzlpwtvAb5/pW53azdci2YiCXSsKSWk0xxCB1NaJqSG5OXgtMExg f3IA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719805762; x=1720410562; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rvZn76ADu7b2Pm/IhS+ieMr90lBlTajVhNIdWbDwmG0=; b=L1zoDUHSI2mtL5+CcTEetiUx+nvAMJxCi7QDEZJIveLH/nvp4Ai/m/eDvm9zHeVkBn iPTeJJv49L5jzLo8P3duQ1u+zgbJy/lIi4bRGt9s5enOG2YpUGqEMZonYGaJNmnf3wIy RK0M+3FjMwT/At0HD5dsLM0hCTpw2m2gKDOVaFxZPyfH6JfGMDcTGfwvfeHLhvKZkEzC 0v/K4Siysf+yHxKi8OUHEEZhwct/gFEDcRUpdl3N4rENxeF+ZFvWUxJQ7co0Cy9Rs8V7 xlStzz45nlYV6Voi6JBdHpgSSgB1uXXQ/5NnbxoqwxdizXePm74vMLKsyXJfkykt4D7i MVQQ==
X-Forwarded-Encrypted: i=1; AJvYcCVTMpDNt4u5SZuDbiktQ6WsUbQ05dvPZcZsA9r+TTe8spTZMuNhXpv2E/d1ff0NK3PneYViGts9aiCEx5hruQ==
X-Gm-Message-State: AOJu0YyFrId+sN8v18QDkpTf3g1Nzpwu2tGDlEAwUjp3KyuJ1hvyKEuV j1gdWpPhVoZiMEmKyXUPFp+KYgJQdVYkEagAsspX7TPQDTuJVk4cqf4ZU35hKbo9Cno8Fp6tiS8 WbpcvxQ6+hYlpsCbu+kolAIesr2ZSfwbQUYA=
X-Google-Smtp-Source: AGHT+IFvXEQbpXxIGnGtQdxm/DM8JEw8gFrGDwR4Wh78LEAhZnmvaS16dXvkpKuIFYFE847z44S+JlzUMxD+aPDzrm8=
X-Received: by 2002:a05:6e02:170b:b0:375:9dc2:fbe3 with SMTP id e9e14a558f8ab-37cd349831fmr68825485ab.25.1719805762344; Sun, 30 Jun 2024 20:49:22 -0700 (PDT)
MIME-Version: 1.0
References: <dda32a30-518d-40dd-b7da-a19e8e9b3d4d@bellis.me.uk> <8C1D853F-17D4-4E2B-B281-F7FCA50DA8B3@strandkip.nl>
In-Reply-To: <8C1D853F-17D4-4E2B-B281-F7FCA50DA8B3@strandkip.nl>
From: Davey Song <songlinjian@gmail.com>
Date: Mon, 01 Jul 2024 11:49:10 +0800
Message-ID: <CAAObRXL84d-BQWrPEDpps-4ghKGTiruTFe1vXOQSKrvp3gnUOQ@mail.gmail.com>
To: Joe Abley <jabley@strandkip.nl>
Content-Type: multipart/alternative; boundary="0000000000008c2451061c277b29"
Message-ID-Hash: IIS6RMPTQZEMYCGKYKBASHN55FQPFBYX
X-Message-ID-Hash: IIS6RMPTQZEMYCGKYKBASHN55FQPFBYX
X-MailFrom: songlinjian@gmail.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: 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/2j2oxz-ZzdX8_uCnaK6IzKQyDb0>
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>

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