Re: [DNSOP] Fundamental ANAME problems

"John Levine" <johnl@taugh.com> Fri, 02 November 2018 00:14 UTC

Return-Path: <johnl@iecc.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 E5BF8127B92 for <dnsop@ietfa.amsl.com>; Thu, 1 Nov 2018 17:14:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.752
X-Spam-Level:
X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=A0QZuw6/; dkim=pass (1536-bit key) header.d=taugh.com header.b=oWmt+jQl
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 EKpN5XtxKgXK for <dnsop@ietfa.amsl.com>; Thu, 1 Nov 2018 17:14:34 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 A4FF81271FF for <dnsop@ietf.org>; Thu, 1 Nov 2018 17:14:33 -0700 (PDT)
Received: (qmail 83953 invoked from network); 2 Nov 2018 00:14:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=147ef.5bdb96e8.k1811; bh=6WhPjSZtPfHRjyD49OHrtZbBymWKYbMnrTdbDxOTLnY=; b=A0QZuw6/zpxtfjGjIfesJ0O0hIDpbTMxiqyWOtIyBRvb34PPZsHRBkyb0UT8dHGQJ1Kfh17MiYdTbSojaMXgq/glbg8JaB51jwAVUmywr5rNadXWW8Upp8jY4RBNLHZEZY6ZFEu45+9+EIH12lO1FhgQ3yByI1RIUSey4YUWhdqSdxmYFTLgKQHfeQuIk9cUMU6MOEnAV+11AsXgvO2NXPA70q1oapNb+ukGJqLDEvLwccqnhZap52FsEIqd/TMi
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=147ef.5bdb96e8.k1811; bh=6WhPjSZtPfHRjyD49OHrtZbBymWKYbMnrTdbDxOTLnY=; b=oWmt+jQl+y9nLej64kt6GPs4iFOtDetgxQLt67mrzQ7/SNG3au/vA5AeM4K4Ef9TkFKmLDVaZ/qAvumwUqms8mWM490ErXsZ2GacTwfy1Tg8qO4layf3ZhxJYvJiBFrBYueHEEfV2bzjD44qv/xLdZbkhHxZZI4c9lcbw3bNl5w7jtkd2+UzPrySTDIs6BeSbl+3cJaRrm3pkbTmSnMYZJ2K/HVPpE6CRrvZJJOGPFwrJlkG+HZ4HfGkNt1Mec1D
Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 02 Nov 2018 00:14:31 -0000
Received: by ary.local (Postfix, from userid 501) id 129AC2007E00AF; Fri, 2 Nov 2018 08:14:30 +0800 (CST)
Date: 2 Nov 2018 08:14:30 +0800
Message-Id: <20181102001431.129AC2007E00AF@ary.local>
From: "John Levine" <johnl@taugh.com>
To: dnsop@ietf.org
Cc: brian.peter.dickson@gmail.com
In-Reply-To: <CAH1iCirXYsYB3sAo8f1Jy-q4meLmQAPSFO-7x5idDufdT_unXQ@mail.gmail.com>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZcJq7khHENCtmzRz2Gp2bRSdfo0>
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 00:14:35 -0000

I can't help but note that people all over the Internet do various
flavors of ANAME now, and the DNS hasn't fallen over.  Let us not make
the same mistake we did with NAT, and pretend that since we can't find
an elegant way to do it, we can put our fingers in our ears and it
will go away.

In article <CAH1iCirXYsYB3sAo8f1Jy-q4meLmQAPSFO-7x5idDufdT_unXQ@mail.gmail.com>; you write:
>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.

"Something very bad will happen if I do that."  "OK, so don't do
that."  My aname-ish code has a maximum update rate, and I expect
everyone else's does too.  Yeah, the ANAMEs won't be in sync with
the hostile remote server, but I can't get too upset about that.

>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.

How is this different from CNAMEs via to 8.8.8.8 and other anycast
caches?  The cache has no relation to the location of the client unless
you use one of the client location hint hacks.

I'm not wedded to the current ANAME spec but we have plenty of experience
showing that it's possible to implement without causing disasters?

R's,
John