IETF Logo Mail Archive

Re: [DNSOP] ANAME in answer or additional section [issue #62]

Evan Hunt <each@isc.org> Wed, 12 June 2019 00:05 UTC

Return-Path: <each@isc.org>
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 E8D1C12002F for <dnsop@ietfa.amsl.com>; Tue, 11 Jun 2019 17:05:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 vAEc3W5-0o7M for <dnsop@ietfa.amsl.com>; Tue, 11 Jun 2019 17:05:01 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 5DBF712001E for <dnsop@ietf.org>; Tue, 11 Jun 2019 17:05:01 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed2.isc.org [IPv6:2001:4f8:1:f::88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id E02053AB001; Wed, 12 Jun 2019 00:04:59 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id 8D2CA3F569; Wed, 12 Jun 2019 00:04:59 +0000 (UTC)
Date: Wed, 12 Jun 2019 00:04:59 +0000
From: Evan Hunt <each@isc.org>
To: Matthijs Mekking <matthijs@pletterpet.nl>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Message-ID: <20190612000459.GA60387@isc.org>
References: <3b136e34-7ec0-e144-2c2a-0885185ec2b1@pletterpet.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3b136e34-7ec0-e144-2c2a-0885185ec2b1@pletterpet.nl>
User-Agent: Mutt/1.11.4 (2019-03-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PrsaRv-2j07JUdueq_53FYlGnps>
Subject: Re: [DNSOP] ANAME in answer or additional section [issue #62]
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: Wed, 12 Jun 2019 00:05:03 -0000

On Tue, Jun 11, 2019 at 10:31:55AM +0200, Matthijs Mekking wrote:
> The main argument for putting it in the answer section is that putting
> it in the additional section implies a lower trust level, and that the
> record is optional and can be removed when minimizing responses.

I'm inclined to favor this argument (probably unsurprisingly, since I'm the
one who argued it).

IMHO, the ANAME is the real answer we're sending; the A and AAAA records
are just friendly hand-holding for legacy servers.  It doesn't make sense
to me to demote the real answer into the additional section, any more than
it would have to move DNAME there. The protocol specificaions are clear on
this point - the more so considering we've already deployed DNAME - and my
sympathies for an implementation that got it wrong would be limited.

That said, if any resolver implementations are known to choke if they see
an unexpected extra RRset in the answer section, it would be good to find
out about it. I guess we should do some testing.

Hm, stub resolvers might be stupider than full resolvers. Perhaps it
would be useful to differentiate RD=0 and RD=1?

-- 
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.

v2.23.0 | Report a Bug | By Email