Re: [DNSOP] New draft for ALIAS/ANAME type

"John Levine" <johnl@taugh.com> Thu, 30 March 2017 23:08 UTC

Return-Path: <johnl@taugh.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 8E9F512949E for <dnsop@ietfa.amsl.com>; Thu, 30 Mar 2017 16:08:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 oGj6llv43qkh for <dnsop@ietfa.amsl.com>; Thu, 30 Mar 2017 16:08:29 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E6B1129434 for <dnsop@ietf.org>; Thu, 30 Mar 2017 16:08:29 -0700 (PDT)
Received: (qmail 22364 invoked from network); 30 Mar 2017 23:08:28 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 30 Mar 2017 23:08:28 -0000
Date: 30 Mar 2017 23:08:06 -0000
Message-ID: <20170330230806.6273.qmail@ary.lan>
From: "John Levine" <johnl@taugh.com>
To: dnsop@ietf.org
Cc: rharolde@umich.edu
In-Reply-To: <CA+nkc8Bwc6eQz6YPAnMLNjvHm4POLTyvsTRQC5Pn+R4iTzaB-g@mail.gmail.com>
Organization:
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/sZrs-tajN1Lti_mrvG15KYZPlTc>
Subject: Re: [DNSOP] New draft for ALIAS/ANAME type
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 30 Mar 2017 23:08:31 -0000

>If you sign offline, what happens when the A records change?

You Lose(tm).  For that matter, you lose even when the A records don't
change since the signer only sees the ANAME, not the A or AAAA.

I did an ANAME like feature in my DNS system, entirely on the
provisioning side.  It does offline signing, zones are constructed by
the provisioning software, expanding the anames, then signed, then
given to the master server, NSD in my case.  It remembers which zones
have anames and rechecks them every hour, redoing the zone's expansion
and signing if they've changed.

This lets me do things that regular ANAME can't, in particular
shadowing data from a server that is not authoritative for the zone.
My users often host their web sites at hosting providers that insist
you use their name servers, except that they don't provide usable mail
so I have to do the mail and DNS.  On my server, the aname-like things
can specify what server to query as well as what name, so it
automatically follows the A and AAAA records that the web host
publishes in their DNS.

My objection to ANAME is more or less the same as it is to BULK, even
though ANAME is vastly less complex.  It requires that an
authoritative server include a recursive client and do online signing,
both of which would be rather large additions to the mandatory set of
server features.

I think it'd be fine to reserve ANAME as a pseudo-rrtype so that
people can do the name following magic consistently in their provisioning
software, but I wouldn't want to put it into DNS servers.

R's,
John