Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

"Peter van Dijk" <> Wed, 19 April 2017 18:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3D18128708 for <>; Wed, 19 Apr 2017 11:29:12 -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 NWKkKpjqofEX for <>; Wed, 19 Apr 2017 11:29:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F2A19129BC4 for <>; Wed, 19 Apr 2017 11:29:07 -0700 (PDT)
Received: from [] (unknown [IPv6:2001:610:666:0:a494:7c0f:1b4e:cca9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by (Postfix) with ESMTPSA id 525DFC1B96; Wed, 19 Apr 2017 20:29:04 +0200 (CEST)
From: "Peter van Dijk" <>
Date: Wed, 19 Apr 2017 20:29:07 +0200
Message-ID: <>
In-Reply-To: <20170414200316.86192.qmail@ary.lan>
References: <20170414200316.86192.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 ANAME draft: draft-hunt-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: Wed, 19 Apr 2017 18:29:13 -0000

On 14 Apr 2017, at 22:03, John Levine wrote:

> In article <> you 
> write:
>>> Wouldn't it be safer to put the ANAME in the additional section?
>> My thinking was that given that DNAME got away with being in ANSWER, 
>> so
>> could we.
> Seems to me that it belongs in the answer section, since for 
> aname-aware
> reasolvers the aname is the answer.
>>> Do we care about SSHFP?
>> I understand the question but I’m uncomfortable extending ANAME 
>> beyond
>> address types. I will put it on the list of things that need more 
>> thought.
> Type bitmaps like the ones in NSEC wouldn't be hard to implement.  Add
> some sanity rules saying that type bits for DNSSEC types and the like
> are ignored, and it's an error to include any types also present at
> the same name.

Type bitmaps would preclude simple implementations that use getaddrinfo 
to do their business. As much as I think the idea may have merit, I feel 
this draft should stay close to the long list of existing ALIAS/ANAME 
implementations if it wants any chance to succeed.

If after that (perhaps after some operational experience with ANAME!) 
you want to draft up a more generic forwarding mechanism, I will happily 
help you write it all down.

Kind regards,
Peter van Dijk