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

神明達哉 <jinmei@wide.ad.jp> Fri, 26 April 2019 18:30 UTC

Return-Path: <jinmei.tatuya@gmail.com>
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 D4383120174 for <dnsop@ietfa.amsl.com>; Fri, 26 Apr 2019 11:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.669
X-Spam-Level:
X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 FZbTTZaPVGJB for <dnsop@ietfa.amsl.com>; Fri, 26 Apr 2019 11:30:13 -0700 (PDT)
Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73EA120046 for <dnsop@ietf.org>; Fri, 26 Apr 2019 11:30:12 -0700 (PDT)
Received: by mail-wr1-f44.google.com with SMTP id v16so3288801wrp.1 for <dnsop@ietf.org>; Fri, 26 Apr 2019 11:30:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NFRLIs9EhBft7SW0xt9L/XXfeyaev/icw+Atf2RKaoA=; b=Db6cGPAcj8G1ZZyZKw0d9MY/dRKeRoXexCgJMdPGaIVXs19mP+uRPEOKKmA0C0gTLX m+ho+PTiC7skVwQNPbDCXnF2xrXixvCgNZHU5HsxDZvkldrAlecSLRBk9ggqHAN0koS3 jYjxAZ4EWDMEt+3hEFARp3hsOf87jhLCN1o8K3mU+2i7Uh230sF82nbA35PQ0y8fy8iz za/fP2dvguI2EKSfufd7kNTaIrv0XFWPsdDC3YJc3kZEljWL71KSi4x4gpFQ01gi1F7X YW+MzV5CVqbG3Oz7jlIhHNJAh0WX6FkeWDaCuaFJJ2IBvzyTPLF33qxZLZ/+NLrGIAML rRMQ==
X-Gm-Message-State: APjAAAUxALbfcdPEKm7kVuqo3EX4/QIMK5Lha/QwKiYn4FlKNevGUcW1 wdWt6ag2EGWFPbtErb1c+/W/wjgu9TRA28mBfNYfMgO4
X-Google-Smtp-Source: APXvYqzW9ZYbHDU1b2F2Zfs7k0vdRKsjSKEBq5XGkZOf8b3KKaZH6BBaeVrmgWOxzEpqBun7zkNxxVxBtTxOtnsrfP4=
X-Received: by 2002:adf:b68d:: with SMTP id j13mr33793263wre.50.1556303411069; Fri, 26 Apr 2019 11:30:11 -0700 (PDT)
MIME-Version: 1.0
References: <87d7d127-20cc-8044-277a-d31b1a546219@pletterpet.nl> <CAJE_bqdFQOqg50mVNYMosqqpqpbF0DZR5YeFPs50zM3earOb=A@mail.gmail.com> <0dafbeaa-acc0-c5fc-d917-b3f8cd88e0a5@pletterpet.nl>
In-Reply-To: <0dafbeaa-acc0-c5fc-d917-b3f8cd88e0a5@pletterpet.nl>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Fri, 26 Apr 2019 11:29:59 -0700
Message-ID: <CAJE_bqf47T=EkDLgLviZFYmcrKCgbCB7WZkg=-TwfgDyZir1_g@mail.gmail.com>
To: Matthijs Mekking <matthijs@pletterpet.nl>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fac6ec0587731f65"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/crxYwpePMikFjjU8IVJNLPg_mVE>
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: Fri, 26 Apr 2019 18:30:15 -0000

At Fri, 26 Apr 2019 09:16:58 +0200,
Matthijs Mekking <matthijs@pletterpet.nl>; wrote:

> > Also, especially if both AAAA and A sibling records are available,
> > what's the purpose of ANAME in the first place if it's (effectively)
> > not used?
> >
> > I'm sure I'm just confused and don't understand the expected usage,
> > but I can't figure it out from the available descriptions.  Could you
> > clarify it?
>
> Personally I agree that the purpose of ANAME becomes less useful with
> choice #2.  The difference is that you can set up ANAME for example for
> AAAA only, or for A only. I don't know what the expected usage of that
> is, and that is why I am asking on the list. If it turns out there is no
> useful case, I think we should put text in the draft that says ANAME
> takes precedence over sibling A and AAAA records.

Okay.  In that case I agree we should go for choice #1 (ANAME should
be preferred) unless the expected usage for choice #2 is clarified and
convinces us (the wg).  Choice #2 looks awkward to me especially if we
consider the case where both AAAA and A siblings exist.

According to your original message choice #2 was derived from the
behavior of a particular implementation:

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

--
JINMEI, Tatuya