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

"Peter van Dijk" <> Fri, 31 March 2017 14:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E6AD0129446 for <>; Fri, 31 Mar 2017 07:04:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dbUTxTzwe1Se for <>; Fri, 31 Mar 2017 07:04:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 42F61120326 for <>; Fri, 31 Mar 2017 07:04:04 -0700 (PDT)
Received: from [] (unknown [IPv6:2001:610:666:0:4835:5d5f:ecfb:87d3]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by (Postfix) with ESMTPSA id 9D4C0C1B96; Fri, 31 Mar 2017 16:04:02 +0200 (CEST)
From: Peter van Dijk <>
Date: Fri, 31 Mar 2017 16:04:01 +0200
Message-ID: <>
In-Reply-To: <20170330230806.6273.qmail@ary.lan>
References: <20170330230806.6273.qmail@ary.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <>
Subject: Re: [DNSOP] New draft for ALIAS/ANAME type
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 Mar 2017 14:04:07 -0000

On 31 Mar 2017, at 1:08, John Levine wrote:

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

There are PowerDNS ALIAS deployments that signs offline (for some 
stretch of the definition of offline) - every minute. For small zones 
the NOTIFY+XFR overhead is very tolerable, and the public auths do not 
need the private key data.

Obviously, whatever way you sign, you would make sure the signer sees 
the A/AAAA RRsets, otherwise you have nothing.

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

You could point your ANAME-aware auth at a specific resolver that has 
stub zones configured for those domains, and then this would work with 
ANAME as well.

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

Recursive clients are easy - your libc/libresolv comes with one. Live 
signing is not mandated if you can tolerate frequent XFRs. And, of 
course, any auth implementer is free to not implement ANAME if he does 
not like the requirements.

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

Yet the operational reality is that several big DNS hosters have it 
today, and I am aware of a few private PowerDNS ALIAS deployments as 
well. It’s obvious the need is real, and people today rely on ALIAS 
being transferred in AXFR without in line expansion. Anthony’s draft 
documents existing widespread practice. The upcoming replacement draft 
by Evan, Anthony and me adds some improvements to it, including details 
that may, if resolver operators cooperate, reduce the need for 
online/live signing in the future.

Kind regards,
Peter van Dijk