IETF Logo Mail Archive

Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt

Stephane Bortzmeyer <bortzmeyer@nic.fr> Wed, 19 July 2017 13:47 UTC

Return-Path: <bortzmeyer@nic.fr>
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 C958B131D31 for <dnsop@ietfa.amsl.com>; Wed, 19 Jul 2017 06:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 iYfW3AqP3UrZ for <dnsop@ietfa.amsl.com>; Wed, 19 Jul 2017 06:47:13 -0700 (PDT)
Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (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 E67FB131D22 for <dnsop@ietf.org>; Wed, 19 Jul 2017 06:47:12 -0700 (PDT)
Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 7571731C83; Wed, 19 Jul 2017 15:47:09 +0200 (CEST)
Received: by godin (Postfix, from userid 1000) id A9316EC0B1C; Wed, 19 Jul 2017 15:44:04 +0200 (CEST)
Date: Wed, 19 Jul 2017 15:44:04 +0200
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Tony Finch <dot@dotat.at>
Cc: Willem Toorop <willem@nlnetlabs.nl>, dnsop@ietf.org
Message-ID: <20170719134404.GA18669@laperouse.bortzmeyer.org>
References: <149592096439.3966.11385984990945858242@ietfa.amsl.com> <0edbf3f2-e575-3b34-d3f2-f1424f29f6e4@nlnetlabs.nl> <alpine.DEB.2.11.1707181622300.27210@grey.csi.cam.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.11.1707181622300.27210@grey.csi.cam.ac.uk>
X-Transport: UUCP rules
X-Operating-System: Ubuntu 16.04 (xenial)
X-Charlie: Je suis Charlie
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NLulxsNYz2sRAtn-mlv4BWl3ec0>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 19 Jul 2017 13:47:15 -0000

On Tue, Jul 18, 2017 at 05:09:00PM +0100,
 Tony Finch <dot@dotat.at> wrote 
 a message of 80 lines which said:

> A client queries its resolver for dotat.at A, but chiark has
> renumbered, so the client gets a response from the ANAME-aware
> resolver like below. A validating ANAME-aware client can see it
> should use the additional address 212.13.197.231 in preference to
> the address in the answer.

Cute trick. I love it. But it modifies the rules for response
credibility (the most credible response is in the additionnal section,
not in the answer section). Should we update RFC 2181, section 5.4.1?
I tend to think that the A record, in that example, should be treated
exactly like glue, by a ANAME-aware client.

v2.23.0 | Report a Bug | By Email