Re: [DNSOP] Fundamental ANAME problems
Matthijs Mekking <matthijs@pletterpet.nl> Fri, 02 November 2018 08:36 UTC
Return-Path: <matthijs@pletterpet.nl>
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 A375D1277CC for <dnsop@ietfa.amsl.com>; Fri, 2 Nov 2018 01:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 AAnzl6hzCizr for <dnsop@ietfa.amsl.com>; Fri, 2 Nov 2018 01:36:45 -0700 (PDT)
Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39CC312008A for <dnsop@ietf.org>; Fri, 2 Nov 2018 01:36:45 -0700 (PDT)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wA28ZMgS121157 for <dnsop@ietf.org>; Fri, 2 Nov 2018 08:36:42 GMT
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2ncfyqd5he-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <dnsop@ietf.org>; Fri, 02 Nov 2018 08:36:42 +0000
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wA28aYCx010517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <dnsop@ietf.org>; Fri, 2 Nov 2018 08:36:36 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wA28aYkK018184 for <dnsop@ietf.org>; Fri, 2 Nov 2018 08:36:34 GMT
Received: from [172.19.129.214] (/216.146.45.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Nov 2018 01:36:33 -0700
To: dnsop@ietf.org
References: <CAH1iCirXYsYB3sAo8f1Jy-q4meLmQAPSFO-7x5idDufdT_unXQ@mail.gmail.com>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <da7deee9-990b-6028-d8e0-c7602e86073e@pletterpet.nl>
Date: Fri, 02 Nov 2018 09:36:30 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <CAH1iCirXYsYB3sAo8f1Jy-q4meLmQAPSFO-7x5idDufdT_unXQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9064 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811020081
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ykkvqLRPoYbvR4oEb-hD9gHBU7w>
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 08:36:48 -0000
Hi Brian, Thanks for your feedback on ANAME. Comments inline. On 01-11-18 23:34, Brian Dickson wrote: > Greetings, DNSOP folks. [...] > First, there is the issue of imposed update frequency. > > The requirement on update rate, is imposed externally by whichever > entity operates the ANAME target. In other words, this is not under the > direct control of the zone operator, and is potentially a potentially > (and very likely) UNBOUNDED operational impact/cost. As John already pointed out: You are in control of the update rate. It may be that the target address records are changing frequently, but it is up to the one that processes the ANAME to set an appropriate update rate. So I don't see this as a particular worry. The draft uses DNS UPDATE as an example and that may be a useful scenario for one, but a red flag for another. However I will use ANAME and no DNS UPDATE and I think my implementation of ANAME is still compatible with the specification. What I would like to see be changed in the draft is that were ANAME processing occurs is more relaxed: Currently it focuses on this happening at zone provisioning time (before the zone is loaded by the primary), and mentions an optimization algorithm for resolvers that is optional. However, there is some text in section 5.2 Alternatives that the ANAME processing can occur on secondary servers which I think may fit your DNS infrastructure better. The point is that this draft should standardize the way ANAME is processed, while giving flexibility on where processing can occur. > Second, this issue is compounded by scale. > > The issue here is, that the larger the entity is that operates zones > with ANAMEs is, the larger the resulting impact. This is a new, > unanticipated, asymmetric cost. It has the definite potential to make > operating authority servers prohibitively costly. I don't see any difference with existing proprietary implementations: This statement is true for any CNAME-at-the-apex solution. > 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. [...] As I said above: I agree that the draft should relax where ANAME processing can occur. I don't see any reason why this processing can be done at the entity that does the stupid DNS trick. [...] > 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.) If you are going to do stupid tricks (aka tailored responses), you will have to do on-the-fly DNSSEC signing anyway. > Side-note: we, as a community, have been pushing for wide-scale adoption > of DNSSEC; this definitely places a significant hurdle to adoption, > precisely in a wide-scale manner, i.e. to the vast majority of DNS > registrants. It is a big roadblock to DNSSEC adoption, and a move in the > wrong direction. I disagree, I think it works pretty well with DNSSEC given the requirement that ANAME processing should happen before DNSSEC signing. This requirement is reasonable since ANAME processing is in the business of tailoring RRsets and any changes made to the zone contents must happen before signing. > What are the alternatives? > > Fundamentally, the behavior that is desired that we are collectively > trying to preserve, is that of resolver-based *NAME chain resolution, > just with the ability to do so at the apex of a zone. > > This points to the only logical places that MUST be part of any > apex-based chaining of resolution: resolvers, or clients. John is right: It is very hard to rely on a solution that depends on recursive name servers to be updated. Hence we look at a solution that can be implemented at authorities. Kind regards, Matthijs
- [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