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, 02 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
- [DNSOP] Fundamental ANAME problems Brian Dickson
- Re: [DNSOP] Fundamental ANAME problems John Levine
- Re: [DNSOP] Fundamental ANAME problems Brian Dickson
- Re: [DNSOP] Fundamental ANAME problems John R Levine
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Matthijs Mekking
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Måns Nilsson
- Re: [DNSOP] Fundamental ANAME problems Erik Nygren
- Re: [DNSOP] Fundamental ANAME problems Bob Harold
- Re: [DNSOP] Fundamental ANAME problems Richard Gibson
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Christian Huitema
- Re: [DNSOP] Fundamental ANAME problems John R Levine
- Re: [DNSOP] Fundamental ANAME problems Lanlan Pan
- Re: [DNSOP] Fundamental ANAME problems Joe Abley
- Re: [DNSOP] Fundamental ANAME problems Måns Nilsson
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Brian Dickson
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Paul Ebersman
- Re: [DNSOP] Fundamental ANAME problems Paul Ebersman
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- [DNSOP] CNAME at apex - a website publisher persp… Dan York
- Re: [DNSOP] Fundamental ANAME problems Måns Nilsson
- Re: [DNSOP] Fundamental ANAME problems Joe Abley
- Re: [DNSOP] Fundamental ANAME problems manu tman
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Paul Ebersman
- Re: [DNSOP] Fundamental ANAME problems Jim Reid
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Paul Vixie
- Re: [DNSOP] Fundamental ANAME problems Mark Andrews
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Mark Andrews
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Fundamental ANAME problems Joe Abley
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Olli Vanhoja
- Re: [DNSOP] Fundamental ANAME problems Thomas Peterson
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Joe Abley
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Fundamental ANAME problems Dan York
- [DNSOP] Further ANAME minimization /\ Ray converg… Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Ray Bellis
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Ray Bellis
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Ray Bellis
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Patrik Fältström
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Matthijs Mekking
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Richard Gibson
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Tim Wicinski
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Ray Bellis
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Michael J. Sheldon
- Re: [DNSOP] Further ANAME minimization /\ Ray con… tjw ietf
- Re: [DNSOP] Further ANAME minimization /\ Ray con… Kevin Darcy
- Re: [DNSOP] Fundamental ANAME problems Richard Gibson
- Re: [DNSOP] Fundamental ANAME problems Matthijs Mekking
- Re: [DNSOP] Fundamental ANAME problems Tim Wicinski
- Re: [DNSOP] Fundamental ANAME problems Tony Finch
- Re: [DNSOP] Fundamental ANAME problems Bob Harold
- Re: [DNSOP] Fundamental ANAME problems Richard Gibson
- Re: [DNSOP] Fundamental ANAME problems Matthijs Mekking
- Re: [DNSOP] Fundamental ANAME problems Thomas Peterson
- Re: [DNSOP] Fundamental ANAME problems Tim Wicinski