Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

Paul Vixie <paul@redbarn.org> Sun, 21 September 2014 21:23 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0001A024C for <dnsop@ietfa.amsl.com>; Sun, 21 Sep 2014 14:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
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 PJUgJ3GhFtwt for <dnsop@ietfa.amsl.com>; Sun, 21 Sep 2014 14:23:08 -0700 (PDT)
Received: from ss.vix.su (ss.vix.su [24.104.150.2]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7F91A0294 for <dnsop@ietf.org>; Sun, 21 Sep 2014 14:23:08 -0700 (PDT)
Received: from [IPv6:2001:559:8000:cb:3cf2:7db0:1462:fe59] (unknown [IPv6:2001:559:8000:cb:3cf2:7db0:1462:fe59]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ss.vix.su (Postfix) with ESMTPSA id 66A79EBC47 for <dnsop@ietf.org>; Sun, 21 Sep 2014 21:23:08 +0000 (UTC) (envelope-from paul@redbarn.org)
Message-ID: <541F41B7.6070105@redbarn.org>
Date: Sun, 21 Sep 2014 14:23:03 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 3.0.11 (Windows/20140602)
MIME-Version: 1.0
To: dnsop <dnsop@ietf.org>
References: <20140921115222.GB16178@xs.powerdns.com> <541F1AE8.6010709@redbarn.org> <457731AF-E11F-4B1C-AC32-5E1AEE4EC5E5@gmail.com> <541F3D5A.7000205@dougbarton.us> <349FA254-AF50-457E-9504-A8707C5B57DB@virtualized.org>
In-Reply-To: <349FA254-AF50-457E-9504-A8707C5B57DB@virtualized.org>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/alternative; boundary="------------080307050808080308010902"
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/hPEEKhHaYG1VX9gpOcTmCefe8Rs
Subject: Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sun, 21 Sep 2014 21:23:10 -0000


> David Conrad <mailto:drc@virtualized.org>
> Sunday, September 21, 2014 2:10 PM
> ...
>
> There are at least three implementations of 'alias mechanism for zone apex' I'm aware of (DNS Made Easy's ANAME, PowerDNS's ANAME (same thing?), and CloudFlare's "CNAME Flattening"). Not sure if they interoperable (or even if there is a need for interoperability).

from the point of view of many operators and implementers (so, like dns
made easy, powerdns, and cloudflare from your example above) there is
almost certainly a disadvantage to interoperability and standardization
here, that being economic, in that as long as this feature remains
incompatible, a single vendor is likely to gain business via "lock in".
my reason for preferring a standardized way to do this is to make it
possible for a registrant to get primary name service from one vendor
and secondary name service from one or more others vendors.

i don't think it makes sense to question, inside the IETF, whether a
vendor-independent interoperable standard is desirable. we can ask
questions of the form "but is this good engineering?" or "is this the
best way to do it?" or even "what should the applicability statement
be?" but since the IETF's stated purpose is to promote interoperable
standards, if we want to argue about whether we need an interoperable
standard for this widely-used feature, we should move that thread to a
non-IETF forum where it would not be a nonsequitur.

-- 
Paul Vixie