Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt

Tony Finch <> Tue, 18 July 2017 16:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 367B6128DE5 for <>; Tue, 18 Jul 2017 09:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CaG6hOKEB-Vj for <>; Tue, 18 Jul 2017 09:09:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 675F41287A0 for <>; Tue, 18 Jul 2017 09:09:02 -0700 (PDT)
X-Cam-AntiVirus: no malware found
Received: from ([]:42547) by ( []:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dXV3U-000fT6-eT (Exim 4.89) (return-path <>); Tue, 18 Jul 2017 17:09:00 +0100
Date: Tue, 18 Jul 2017 17:09:00 +0100
From: Tony Finch <>
To: Willem Toorop <>
In-Reply-To: <>
Message-ID: <>
References: <> <>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt
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: Tue, 18 Jul 2017 16:09:04 -0000

Willem Toorop <> wrote:
> The dependency on online signing is a little more then just a technical
> issue.

I need to review the draft properly, but I do not think ANAME should
require any online signing.

In my view an authoritative server which does online signing and on-demand
record synthesis is a master server. You can make all your public
authoritative servers into masters if you like, but it must not be

If (like me) you have a more traditional setup then ANAME is an
instruction to the master server about zone maintenance, saying that it
needs to periodically update the sibling A and AAAA records, similar to
periodic re-signing, or as if some script were periodically `nsupdate`ing
the records. The secondary servers can continue to work the same as they
do now, but they'll work better if they know about some helpful additional
section rules for ANAME.

(That is basically how my bodged-up ANAME implementation works, in my
zone provisioning scripts.)

The other kind of DNS server that might be able to do something useful
with ANAME is a recursive server, so it could co-operate nicely with
authoritative servers that are playing clever tricks. But the rDNS will
have to be careful about not breaking downstream validators.

Say (for example) my zone has:	ANAME	RRSIG	ANAME	A	RRSIG	A	AAAA	2001:ba8:1e3::	RRSIG	AAAA

A client queries its resolver for A, but chiark has renumbered,
so the client gets a response from the ANAME-aware resolver like below. A
validating ANAME-aware client can see it should use the additional address in preference to the address in the answer.


; ADDITIONAL       AAAA    2001:ba8:1e3::	RRSIG	AAAA       ANAME	RRSIG	ANAME	A	RRSIG	A	AAAA    2001:ba8:1e3::	RRSIG	AAAA

Note that neither the resolver nor the client needs any algorithm updates
to avoid being confused by this additional information; they just need a
code update so that they are able to make good use of it.

If the resolver knows the client is DNSSEC-oblivious then it can do the
substitution itself and return a simple answer like this:	A

Validating but ANAME-oblivious resolvers won't get to enjoy clever
latency minimization tricks.

f.anthony.n.finch  <>  -  I xn--zr8h punycode
East Sole, Lundy, Fastnet, Irish Sea: Easterly becoming cyclonic 4 or 5,
increasing 6 or 7 at times. Slight or moderate. Fair then thundery showers,
fog patches later. Moderate or good, occasionally very poor later.