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