Re: [DNSOP] Minimum viable ANAME

Matthijs Mekking <> Tue, 26 March 2019 16:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC008120491 for <>; Tue, 26 Mar 2019 09:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id grhkcXBLZA4C for <>; Tue, 26 Mar 2019 09:27:10 -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 9B26B120457 for <>; Tue, 26 Mar 2019 09:27:09 -0700 (PDT)
Received: from [] ([]) by with ESMTPA id 8oumh68yzUjKf8ouphmFzk; Tue, 26 Mar 2019 17:27:07 +0100
References: <20180919201401.8E0C220051382A@ary.qy> <> <20180920061343.GA754@jurassic> <> <> <> <> <> <>
From: Matthijs Mekking <>
Message-ID: <>
Date: Tue, 26 Mar 2019 17:27:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfC6Z/spGT/bHm9uJohw8zpx30UMVln6dk/sMDGRR8ITWKpCjOI115kaPFpB+ZcEvn/tqDUbdDYcAgcfvJt3EArNTjYjXDgIOnRdGuGWFibTX1cxKCdKE X4hBaGCjZU02BCT7+dPJeNwMVcDXEvFHFasLcw7mzUx2t8oKYwx2fNOq
Archived-At: <>
Subject: Re: [DNSOP] Minimum viable ANAME
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Mar 2019 16:27:12 -0000

On 3/26/19 5:10 PM, Tony Finch wrote:
> Matthijs Mekking <> wrote:
>> I think that would be the wrong direction.  I believe there is a need to
>> standardize the ANAME resolution process and so my suggestion would be to
>> reduce the scope by focusing just on how to do that on the provisioning side
>> (and leave secondary servers and resolvers out of scope for now).
>>From past discussions, I didn't think there was any way we could get
> consensus on the provisioning side.
> Dynamic lookups on authoritative servers are out, because it has to be
> compatible with traditional secondaries.
> Updates on the primary are out, because that doesn't scale to large
> numbers of zones.
> Sometimes a system might have known fallback addresses, but often it won't
> (e.g. whether the DNS setup is or isn't coupled to a web provisioning
> system).

All these things are contentious which is the reason why removing it 
from the scope will hopefully aid progress.  These can be resolved in a 
follow up document.

> But I think it's reasonable to allow whatever provisioning mechanisms
> there might be, provided the meaning of answers from auth -> rec have a
> consistent meaning that resolvers can use. >
> It's also really imortant that ANAME can work in multi-provider setups, so
> there needs to be something approaching interoperable semantics for
> importing a zone file into a provisioning system. (Though I think the
> semantics will have to be very loose in this case, to allow for variations
> between existing systems.)
> I haven't seen any objections to support for ANAME in recursive servers
> so I'm surprised you think that is problematic enough to be removed. My
> understanding was that recursive support is seen as better than trying to
> do all the tricks on authoritative servers.

Except for the slow deployment issue.

> Tony.