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

神明達哉 <> Fri, 26 April 2019 18:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D4383120174 for <>; Fri, 26 Apr 2019 11:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.669
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FZbTTZaPVGJB for <>; Fri, 26 Apr 2019 11:30:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D73EA120046 for <>; Fri, 26 Apr 2019 11:30:12 -0700 (PDT)
Received: by with SMTP id v16so3288801wrp.1 for <>; Fri, 26 Apr 2019 11:30:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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: <> <> <>
In-Reply-To: <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Fri, 26 Apr 2019 11:29:59 -0700
Message-ID: <>
To: Matthijs Mekking <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="000000000000fac6ec0587731f65"
Archived-At: <>
Subject: Re: [DNSOP] ANAME precedence [issue #58]
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: Fri, 26 Apr 2019 18:30:15 -0000

At Fri, 26 Apr 2019 09:16:58 +0200,
Matthijs Mekking <>; 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