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

Evan Hunt <each@isc.org> Mon, 10 April 2017 21:44 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 12E50128B38 for <dnsop@ietfa.amsl.com>; Mon, 10 Apr 2017 14:44:32 -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 Xg-78IkemNll for <dnsop@ietfa.amsl.com>; Mon, 10 Apr 2017 14:44:31 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 068E8128708 for <dnsop@ietf.org>; Mon, 10 Apr 2017 14:44:31 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::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 B882F3493BB; Mon, 10 Apr 2017 21:44:27 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id A5487216C1E; Mon, 10 Apr 2017 21:44:27 +0000 (UTC)
Date: Mon, 10 Apr 2017 21:44:27 +0000
From: Evan Hunt <each@isc.org>
To: Paul Wouters <paul@nohats.ca>
Cc: dnsop@ietf.org
Message-ID: <20170410214427.GA91544@isc.org>
References: <20170407181139.GB66383@isc.org> <alpine.LRH.2.20.999.1704071658030.20015@bofh.nohats.ca> <20170407224716.GB33435@isc.org> <alpine.LRH.2.20.999.1704081826570.9031@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.1704081826570.9031@bofh.nohats.ca>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/JGa7mxRSBsOpWjSMhvqy2oSSN6I>
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 21:44:32 -0000

On Sat, Apr 08, 2017 at 06:32:12PM -0400, Paul Wouters wrote:
> > Resolvers don't ask for ANAME. They ask for A/AAAA, and get an A/AAAA
> > answer, along with an ANAME record so they can go directly to the source
> > and get a better answer if they support that.
> 
> If these are the premises for ANAME, and its special handling, wouldn't
> it be better to generalise asking for multiple records (eg A + AAAA
> + ANAME) where ANAME has no special handling on its own? And then do the
> generealised multi-query-at-once using one of the previously suggested
> proposals?

I must have been unclear -- I meant the slash to mean "or". This isn't
about getting back multiple records. I did include a MAY in there saying
that if you query for an A you can get AAAA in the additional section, and
vice versa, but that's not the central point of ANAME at all.

This is a mechanism for redirecting address queries. Because it's limited
to address types, it can, unlike CNAME, be used at the zone apex.

So the initial query is going to be for type A or type AAAA. (If we ever
invent a third address family, that would count here as well.)  The
response is going to be an ANAME record plus the address you asked for.
That address has to be looked up by the auth in case the querying resolver
doesn't have ANAME support, but if the resolver *does* have ANAME support,
then it repeats the lookup on its own behalf, just as it would do if it got
back a CNAME.

> Then people who want to ask (A + AAAA + TLSA) or (A+AAAA+SSHFP) or
> (A+AAAA+IPSECKEY) could use the same mechanism. And ANAME would just be
> a regular DNS record without any abnormal processing.

Fine idea but not related.  ANAME == CNAME for addresses.

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