Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Lanlan Pan <abbypan@gmail.com> Thu, 27 February 2020 03:52 UTC

Return-Path: <abbypan@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 33AB53A1046 for <dnsop@ietfa.amsl.com>; Wed, 26 Feb 2020 19:52:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHra37cCm1SZ for <dnsop@ietfa.amsl.com>; Wed, 26 Feb 2020 19:52:00 -0800 (PST)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CBC3A1044 for <dnsop@ietf.org>; Wed, 26 Feb 2020 19:52:00 -0800 (PST)
Received: by mail-qt1-x82a.google.com with SMTP id v25so1291136qto.7 for <dnsop@ietf.org>; Wed, 26 Feb 2020 19:52:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FR5ybhzrUZHDzACXajFsONQ2zxo86+uxTqETXRqrEGI=; b=XwY7GSK3L8qJasKvnhpxzd8AcyKIe0sKK56LdpmAFlpkvo2gwd2PcfPjOjtVJF+UWW 0Ow0pg4x/bvF75TVkebdVcD8QH1FHh/d3VHTUApLfKaE4yojRx3L/G1szKp6GReNFwz6 Fn7nHfFcjspRyeTa6ftORUbIaBslPydH5i8IKJyNDwNSZciLC8AHj2yMTQzgFnzLcsBn G05g/kxprYj1bvJfoI77Rb8QmOgpTtybyeWdioLNEUeUJDT2Hj0e0ZcqP3WvYfBtoPfG pooN1kUoskzYcgF01lCkju/IByT0l/BSpPeyB4JtsCfLSCkqtvDGtn1ErPEbrQwZSZg5 rp+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FR5ybhzrUZHDzACXajFsONQ2zxo86+uxTqETXRqrEGI=; b=o1CLPH+gzwkZUHIfRnvdWBDZKLWKeuU6CgOL9//P4N4pyZUy+YoNare1K7v+S6fnF+ 4atHujpQMRibnwNTLNC4vOy7GnPHrO+UN8+1W1L4PBPDeMbVlnJA8bfXpP09JEIGmSyl mQx4VjK4pRUrQfC39FzLWx2+eEg7zF4RJucugWyunMec43gHOsxaRkitLf3guNRn+JW2 NYYWohxv3RXYMdSI0ERpxhrEuL61ghBolNyb5g2/I0jUD5Q2Wg5Ne8C8MlK98kL0GE/F 54PRVmewej4GOGTYkrWC9Ru4+zK8KqWOk+cOsO08yeoBS2yY7WVQH252czyM5zMdyLZu gQTw==
X-Gm-Message-State: APjAAAWEHTko/DgbiTA8NPcJKWqfH1eo1EqZVQM6qM+E4o9wrb2Te4N4 bKTWObX8Hu1hsrIW3XuKjJcgV3yNdfTABraMIImCoksJ
X-Google-Smtp-Source: APXvYqx7B7PMCFYkB6VkLw0X/bRFzaiIYP/G4BpRPHx0bhqrQb1WFYGf2jiKSwC3xBnVKfKjZjkYXykLJTyt67fSWpY=
X-Received: by 2002:aed:2ce4:: with SMTP id g91mr2442250qtd.352.1582775519102; Wed, 26 Feb 2020 19:51:59 -0800 (PST)
MIME-Version: 1.0
References: <b34f1b0d-fa65-23d4-1b2b-761b965a2aae@knipp.de> <CAG8jCEzO7zrfL5G5CzdJ=c5wipJgqqHfyeA-a3-QjquoyPYgvg@mail.gmail.com> <3ead518d-f166-1c36-c3e9-18aeb355d160@pletterpet.nl> <20200220221517.GA16177@isc.org> <alpine.DEB.2.20.2002222349530.27562@grey.csi.cam.ac.uk> <CAH1iCiq+rOxs9c8zoJhAWbB6-0SP_WC5onF-DrbekwX=8iR49Q@mail.gmail.com> <CA+nkc8Coe8D1ECfrRwRUnzJ3azyJfXXUq3HMy63AL-4SOvmaaw@mail.gmail.com> <OF4062C1E9.B42128F1-ON86258519.006893C9-86258519.00690F29@prominic.net> <f5f17c26-e673-119e-e7aa-bc88f8ef46a3@nic.cz> <alpine.DEB.2.20.2002261657540.27562@grey.csi.cam.ac.uk> <CANLjSvWsy1Eeh+eBqe9x6LDaLnwZBvdTuQH-LKJNT88uO0p7Cw@mail.gmail.com> <CAKC-DJg46RraMuhXpPDXwM6WD65bAO7PFTA0wai1XdSEB6ZR-A@mail.gmail.com>
In-Reply-To: <CAKC-DJg46RraMuhXpPDXwM6WD65bAO7PFTA0wai1XdSEB6ZR-A@mail.gmail.com>
From: Lanlan Pan <abbypan@gmail.com>
Date: Thu, 27 Feb 2020 11:51:47 +0800
Message-ID: <CANLjSvWOSx4G-1cKcc1aNMhNoC67byZQxzzgDLckvFisCU6rFw@mail.gmail.com>
To: Erik Nygren <erik+ietf@nygren.org>
Cc: Tony Finch <dot@dotat.at>, "Andrew M. Hettinger" <AHettinger@prominic.net>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000934d9c059f86a4e3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QiuPE0FfGzqNy0irSrhzVjqB11c>
Subject: Re: [DNSOP] status of the aname and svcb/httpsvc drafts
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2020 03:52:03 -0000

Erik Nygren <erik+ietf@nygren.org> 于2020年2月27日周四 上午5:38写道:

> On Wed, Feb 26, 2020 at 2:34 PM Lanlan Pan <abbypan@gmail.com> wrote:
>
>> My option:
>> 1) ANAME just configured in zonefile, and anlayzed by authoritative
>> server.
>> 2) Authoritative server response to recursive (or resolver) on its policy
>> as before,  such as geo-ip, GSLB, ...
>> 3) No upgrade on recursive and resolver.
>>
>
> I don't follow how this works for the non-trivial static case.
> You have two authoritative parties, one for the authoritative zone
> and one authoritative for the ANAME target.
> Both are operated by different entities.
>

> The logic and policy for the ANAME target (involving geo-ip, GSLB, etc)
> is often highly dynamic and proprietary.  How does this get conveyed
> from the authorities for the ANAME target to the authorities for the zone
> containing the ANAME?  This is where we seem to get stuck.
>
Agree,  CDN target is high dynamic.

>
>
> CNAMEs provide an abstraction here given that they're implemented
> and followed by recursives so policies can be implemented based
> on the recursive IP and/or the ECS sent by the recursive IP.
>

> With an authority-only ANAME, the geo-ip/GSLB/etc policy can't
> be implemented by the authority for the zone containing the ANAME
> and any requests the authority makes won't be fine-grained enough
> to be useful.
>
Just configure ANAME in the zonefile,  authortitative return response is
CNAME, no ANAME.
If enable DNSSEC, this will cause some dynamic signature calculation(ECDSA
will be better).

>
> If the customer problem is "I want to be able to CNAME example.com to
> example.com.some-example-cdn.net" then ANAME won't solve if
> it users don't get directed to the right place or if the service provider
> for the target of the ANAME makes it clear that this configuration
> voids any performance+availability SLAs.
>
Yes, the common problem is no more clear information to select the best IP.

I think ANAME is not a "must" upgrade for recursive. Public recursive has
designed many policies to deal with multiple CNAME RRs response (from ECS
queries, or different resolve servers receive different CNAME from
authoritative).


>        Erik
>
>
>