Re: [DNSOP] ANAME precedence [issue #58]

Matthijs Mekking <matthijs@pletterpet.nl> Tue, 30 April 2019 13:21 UTC

Return-Path: <matthijs@pletterpet.nl>
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 909D512007A for <dnsop@ietfa.amsl.com>; Tue, 30 Apr 2019 06:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 ScvT8fsZuho4 for <dnsop@ietfa.amsl.com>; Tue, 30 Apr 2019 06:21:23 -0700 (PDT)
Received: from lb2-smtp-cloud8.xs4all.net (lb2-smtp-cloud8.xs4all.net [194.109.24.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A43120006 for <dnsop@ietf.org>; Tue, 30 Apr 2019 06:21:22 -0700 (PDT)
Received: from [IPv6:2001:980:4eb1:1:1dbb:566d:e94e:6d63] ([IPv6:2001:980:4eb1:1:1dbb:566d:e94e:6d63]) by smtp-cloud8.xs4all.net with ESMTPSA id LShChazkab8gSLShDhHVtZ; Tue, 30 Apr 2019 15:21:20 +0200
To: dnsop <dnsop@ietf.org>
References: <87d7d127-20cc-8044-277a-d31b1a546219@pletterpet.nl> <CAJE_bqdFQOqg50mVNYMosqqpqpbF0DZR5YeFPs50zM3earOb=A@mail.gmail.com> <0dafbeaa-acc0-c5fc-d917-b3f8cd88e0a5@pletterpet.nl> <CAJE_bqf47T=EkDLgLviZFYmcrKCgbCB7WZkg=-TwfgDyZir1_g@mail.gmail.com> <CAM1xaJ-97cHDoqM6589JsgbcH6XVy4X1txGvhtsgvVHQ1D5b3Q@mail.gmail.com>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <b9f42f5c-7776-a69a-5475-ca3430b06ad1@pletterpet.nl>
Date: Tue, 30 Apr 2019 15:21:18 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CAM1xaJ-97cHDoqM6589JsgbcH6XVy4X1txGvhtsgvVHQ1D5b3Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfKORTCghU2kYSaCLR8qui0mY0i5HxHqn1E3WWALNqXX234u8LduE8l2H5YjAtAfuk0Rz6YCsNW68pGDXNpK9SM5X595f9/vVMOsBHq0NjRYcFmr+7C+U zknuor05LJ7lsWEdIR6g7x7l7j5qm4LOGuIe+C1qNuz1EJlcW5EZdLVzqf5P8U3CEma5P0fYayO/h18IqmPgqKHw+ip9TD/EPYW91gWgJpKzqDqWljGHbET5 0qmG91gSPDx4BglZI0vWdg5BMHL3sbeWK8v5KG8eu58=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Xvtixk1ABorMdeQXBQbsHhUZs7U>
Subject: Re: [DNSOP] ANAME precedence [issue #58]
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 30 Apr 2019 13:21:26 -0000

Hi,

Jan and everyone else, thanks for your feedback. It feels indeed like we
should continue with the behavior that ANAME will take precedence over A
and AAAA when on the same name. I shall go over the draft and see if the
text is correct in that sense.

Best regards,

Matthijs


On 4/30/19 11:56 AM, Jan Včelák wrote:
> On Fri, Apr 26, 2019 at 8:30 PM 神明達哉 wrote:
>>> Jan Včelák mentioned that at least NS1 uses a different order of
>>> priority: If an sibling address record exists next to the ANAME it takes
>>> precedence and no target lookup is done for that address record type.
>>
>> if there's a specific use case where this behavior is important,
>> either the developer or user of this implementation should be able to
>> clarify that.  At least until we know that I don't see the point of
>> considering this choice.
> 
> The reason for different processing order in our implementation is
> merely historical: ALIAS was intended to solve the problem with CNAME
> in zone apex, our customers were familiar with CNAME processing, and
> therefore we wanted ALIAS to resemble CNAME closely. CNAME is
> practically a fallback record as well. I'm not aware of any specific
> use case where such behavior would be required although it's possible
> that our customers have developed some use case over the years.
> 
> It looks like there is an agreement that ANAME should take precedence
> over A/AAAA. That's fine with me. We will figure it out for our
> customers.
> 
> Jan
>