Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

Florian Weimer <fweimer@redhat.com> Mon, 10 April 2017 09:29 UTC

Return-Path: <fweimer@redhat.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 B3A1F129451 for <dnsop@ietfa.amsl.com>; Mon, 10 Apr 2017 02:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.024
X-Spam-Level:
X-Spam-Status: No, score=-5.024 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 cHvycwqxvxKm for <dnsop@ietfa.amsl.com>; Mon, 10 Apr 2017 02:29:54 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99736129467 for <dnsop@ietf.org>; Mon, 10 Apr 2017 02:29:52 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1DE1A80461; Mon, 10 Apr 2017 09:29:52 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1DE1A80461
Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 1DE1A80461
Received: from oldenburg.str.redhat.com (dhcp-192-212.str.redhat.com [10.33.192.212]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 73BF386CF9; Mon, 10 Apr 2017 09:29:51 +0000 (UTC)
To: Evan Hunt <each@isc.org>, dnsop@ietf.org
References: <20170407181139.GB66383@isc.org>
From: Florian Weimer <fweimer@redhat.com>
Message-ID: <cc3bbc7a-3f48-2f7f-a3d9-3f752874fc00@redhat.com>
Date: Mon, 10 Apr 2017 11:29:50 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170407181139.GB66383@isc.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 10 Apr 2017 09:29:52 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vNWfiwnZhTRBa8SnOyfwUKfzoHI>
Subject: Re: [DNSOP] new ANAME draft: draft-hunt-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: Mon, 10 Apr 2017 09:29:56 -0000

On 04/07/2017 08:11 PM, Evan Hunt wrote:
> Title:		Address-specific DNS Name Redirection (ANAME)

I think the introduction should discuss why it is not possible to push 
the CNAME to the parent zone, replacing the entire zone with an alias.

Section 3 is currently written in such a way that a recursive DNS lookup 
must be performed at the authoritative server side.  I don't think it is 
necessary to require that.  A recursive DNS lookup of the target is just 
one way to implement this.

In particular, the suggested recursive DNS lookup needs some form of 
distributed loop detection.  Otherwise, a malicious customer could 
publish two zones with ANAME records and achieve significant traffic 
amplification, potentially taking down the DNS hoster.  A hop count in 
an EDNS option or an “ANAME lookup in progress” indicator would be one 
way to implement this.  Another approach would impose restrictions on 
the owner name of an ANAME record and its target, and restrict where 
CNAMEs can appear, so that a valid ANAME can never point to another 
valid ANAME.

Thanks,
Florian