Re: [DNSOP] Fundamental ANAME problems

Erik Nygren <erik+ietf@nygren.org> Fri, 02 November 2018 19:16 UTC

Return-Path: <nygren@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 EBB92129619 for <dnsop@ietfa.amsl.com>; Fri, 2 Nov 2018 12:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 GyKOU4YSeY-3 for <dnsop@ietfa.amsl.com>; Fri, 2 Nov 2018 12:16:39 -0700 (PDT)
Received: from mail-it1-f182.google.com (mail-it1-f182.google.com [209.85.166.182]) (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 EEB371277BB for <dnsop@ietf.org>; Fri, 2 Nov 2018 12:16:38 -0700 (PDT)
Received: by mail-it1-f182.google.com with SMTP id e74-v6so4608371ita.2 for <dnsop@ietf.org>; Fri, 02 Nov 2018 12:16:38 -0700 (PDT)
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=329qvU7wKB3Bzfv9AaajAIqF7k9TPYTgAkRb1x6piJE=; b=MISgiKi4JBEley/OXRIMIp+M9DdgurT7APdFaXlUjYEeGyKejAIrlO1qxMpA9J1/Kw pUzeBgwwd5EbFUviKK1CYhqEeAMLVXDnclOE535nDPzXhQaWUtpfV6yPZkfXzWXuvOk/ xxns7zNOaM6Mrz4juEscwvy/XpEPM7+wtkvqeDdWsnSC92qlsTuFNHO/8asUwabJTEFV jgVxSJFaC8GxeYLoV7/vAaapsJfZL1FUC3lvTgidqTyfV1LqFUuRzbH67hJMtknkgE3D 32kbv6YavbymzQnjpe1/A8rawpvfb1VSNkSV2i9XTQbfGnmAIcrsZt1tt8nakdgchJao KTRw==
X-Gm-Message-State: AGRZ1gJfpInMUJ7yV548njoPDWWTassebt/HLgYM8Q+fEed6UdCYz5uv hsIxUF+ZD8M3saL01XbHikVJHPBYy9nM1ZbhzW8=
X-Google-Smtp-Source: AJdET5c3EILMSrYo4ff0iMxb3AJQWjnNQcvxT0USBTRz2ckj6MsI3G2mFBC6pD/Ebq8S4QEkcA6PYm/PYUYonTviN8I=
X-Received: by 2002:a02:7811:: with SMTP id p17-v6mr6924377jac.120.1541186197844; Fri, 02 Nov 2018 12:16:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAH1iCirXYsYB3sAo8f1Jy-q4meLmQAPSFO-7x5idDufdT_unXQ@mail.gmail.com>
In-Reply-To: <CAH1iCirXYsYB3sAo8f1Jy-q4meLmQAPSFO-7x5idDufdT_unXQ@mail.gmail.com>
From: Erik Nygren <erik+ietf@nygren.org>
Date: Fri, 2 Nov 2018 15:16:25 -0400
Message-ID: <CAKC-DJi544+nwRCCChcWziiyQDb5N-a6UwFrwtVBjGRcKmd3sQ@mail.gmail.com>
To: brian.peter.dickson@gmail.com
Cc: dnsop WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000daf85c0579b35f4c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/La8XuKNTgaxwas6HgE3I_Xtg-6k>
Subject: Re: [DNSOP] Fundamental ANAME problems
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: Fri, 02 Nov 2018 19:16:41 -0000

On Thu, Nov 1, 2018 at 6:34 PM Brian Dickson <brian.peter.dickson@gmail.com>;
wrote:

> ...
>
> Third, there is an issue with the impact to anycast operation of zones
> with ANAMEs, with respect to differentiated answers, based on topological
> locations of anycast instances.
>
> There is currently an expectation on resolving a given name, that where
> the name is ultimately served (at the end of a *NAME chain) by an entity
> doing "stupid DNS tricks" (e.g. CDNs), that the answer provided is
> topologically appropriate, i.e. gives the "best" answer based on resolver
> (or in the case of client-subnet, client) location.
> When done using CNAMEs, the resolver is the entity following the chain,
> and does so in a topologically consistent manner. Each resolver instance
> querying a sequence of anycast authorities which return respective CNAMEs,
> gets its unique, topologically-appropriate answers, and there is no
> requirement or expectation that resolvers in topologically distinct
> locations have any mutual consistency.
> ANAME places the authority servers in an anycast cloud, in a "Hobsons
> choice" scenario. Either a single, globally identical sibling value is
> replicated to the anycast instances (which violates the expectation of
> resolvers regarding "best" answer), or each anycast instance needs to do
> its own sibling maintenance (with all that implies, including on-the-fly
> DNSSEC signing), or the anycast cloud now has to maintain its own set of
> divergent, signed answers at the master, and add all the complexity of
> distributing and answering based on resolver topological placement. (The
> last two have significant risk and operational complexity, multiplied by
> the volume of zones served, and impacted by the size of the anycast cloud.)
>

I share your concerns on how useful ANAME will be or whether it will
actually solve problems.
To make matters worse, for an authority to use ANAME in conjunction with a
CDN that returns
dynamic responses for mapping and load balancing, it's likely that the
*authority* would also need
to use ECS with client subnet information for the A/AAAA lookups (as is
done by some of the largest
anycast open resolver services) but then dynamically resign the results.
This means online
ECS lookups with caching (often of names/records with very short TTLs)
and online signing which open up quite a few perf, scaling, and security
challenges
such as DDoS-attack-resilience.

One of the reason that at least some CDNs have built integrated-stack
solutions
to DNS authorities that can do CNAME collapsing internally is that this
allows them
to do proprietary optimizations to resolve some of the issues described
here.

If a stated goal of ANAME is to allow authorities distinct from a CDN to
follow
a CNAME chain to a given CDN and then incorporate the results in their
answer
for the zone apex (to improve vendor agnosticism), it may also be worth
really validating whether the design will scale and be performant and
interoperate
with such CDNs.  Since this is being configured by the owner of a zone,
they are likely incentivized to make sure that whatever is configured
actually
works well and provides good end-user overall performance (not just DNS
lookup
performance).  Not incorporating client information (eg, via ECS) into
responses
and/or substantially increasing TTLs are likely to cause significant
overall problems.
The result may then be "who will actually use ANAME as described here and
for what?".

Exploring some of the alternatives as you suggest may result in
slower-to-deploy
but overall more widely adoptable approaches.

        Erik