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

Evan Hunt <each@isc.org> Thu, 20 April 2017 21:52 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 8FAEF1316ED for <dnsop@ietfa.amsl.com>; Thu, 20 Apr 2017 14:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 S5MBBnAGZ82Z for <dnsop@ietfa.amsl.com>; Thu, 20 Apr 2017 14:52:18 -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 869CB1316E2 for <dnsop@ietf.org>; Thu, 20 Apr 2017 14:51:58 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 152B83493A5; Thu, 20 Apr 2017 21:51:56 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id 03F96216C1E; Thu, 20 Apr 2017 21:51:56 +0000 (UTC)
Date: Thu, 20 Apr 2017 21:51:56 +0000
From: Evan Hunt <each@isc.org>
To: Paul Wouters <paul@nohats.ca>
Cc: dnsop <dnsop@ietf.org>
Message-ID: <20170420215155.GB96219@isc.org>
References: <20170414200316.86192.qmail@ary.lan> <CA3AE8E2-A54F-4F9D-A6F3-D754A6829B75@powerdns.com> <alpine.LRH.2.20.999.1704191436580.15622@bofh.nohats.ca> <20170420063648.GA73884@isc.org> <alpine.LRH.2.20.999.1704201650180.14463@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.LRH.2.20.999.1704201650180.14463@bofh.nohats.ca>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8cw8x3NIw11s9OBaGttNk5LtuBc>
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: Thu, 20 Apr 2017 21:52:20 -0000

On Thu, Apr 20, 2017 at 04:54:55PM -0400, Paul Wouters wrote:
> If that is your use case, I also see no point in ANAME being used by
> resolvers, and you should just create the new XFR type for this, so that
> AUTH servers can update their A/AAAA records without needing any
> recursive DNS protocol changes. Because what you seem to want is a
> method for updating some information between two AUTH servers.

What I want is for queries for addresses at a zone apex to be redirectable,
so that (for example) "www.example.com" and "example.com" have the same
degree of flexibility.

I'd love it if an authoritative server, configured with an ANAME, returned
only the ANAME and let the resolver populate it. However, legacy resolvers
won't know what to do with an ANAME answer, so the authority will need to
provide addresses too. Several vendors are already doing that part of it.

> Maybe if A and SRV could be returned in the same query they would, so
> that leads back to generic support for multi-type queries (with I guess
> _location support) being a better generic solution to the problem
> compared to this ANAME draft that builds a validating recursive resolver
> into any authoritative server.

Once again, the recursive resolver needn't be built in. It only has to be
accessible -- via resolv.conf, for example.

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