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

Tony Finch <dot@dotat.at> Tue, 18 July 2017 21:08 UTC

Return-Path: <dot@dotat.at>
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 A06CA12EC23 for <dnsop@ietfa.amsl.com>; Tue, 18 Jul 2017 14:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_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 QhTIc9F_3fSz for <dnsop@ietfa.amsl.com>; Tue, 18 Jul 2017 14:08:17 -0700 (PDT)
Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 A029E12EB5F for <dnsop@ietf.org>; Tue, 18 Jul 2017 14:08:17 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:39584) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dXZj5-000e2J-eK (Exim 4.89) (return-path <dot@dotat.at>); Tue, 18 Jul 2017 22:08:15 +0100
Date: Tue, 18 Jul 2017 22:08:15 +0100
From: Tony Finch <dot@dotat.at>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
cc: dnsop@ietf.org
In-Reply-To: <20170718180128.omffg7ce5kbhoqjr@mx4.yitter.info>
Message-ID: <alpine.DEB.2.11.1707182153180.1305@grey.csi.cam.ac.uk>
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> <20170718180128.omffg7ce5kbhoqjr@mx4.yitter.info>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/YTKTaqyYjJByCJ2yL5vZZhwNbPI>
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: Tue, 18 Jul 2017 21:08:20 -0000

Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
>
> I think I (at least mostly) agree.  One possible way to sort out these
> bits of potential confusion is to break the problem up into conceptual
> parts, so that one can see the way that they work together.  One part
> is, "How do you give this instruction to the master server(s)?"  It
> covers representation in the master file format, what a master is
> supposed to do on input, how to refresh the data, and so on.

Yes.

> A second part is, "How do you give this instruction to a slave?".  This
> covers transferring zones, the trade-offs in handing the slaves the
> ANAME vs the "resolved" records, refresh timers and so on.

The only compatible option here is to transfer the signed resolved
records, and have the secondary behave the same as now, except for a small
amount of extra additional section processing. All dynamic behaviour has
to happen on a master.

If you think you have a secondary that's editing and/or resigning your
zone, what you actually have is a master which happens to use another DNS
server as its data source, rather than a zone file or database.

> A third part has to do with downstream resolvers and caches and so on.
> This is really a separate problem: how to handle ANAME-aware vs
> ANAME-unaware systems, the consequences of an ANAME-unaware cache
> ending up with an ANAME in the cache,

It should be just the same as any other new RR type.

> the effects of having an A and not AAAA in cache, &c &c.

It should be just the same as now.

> A fourth part, which might be yet a separate problem or might be the
> same document, is what this all looks like from a stub and what happens
> when there are chains of forwarders and caches and so on with a mix of
> ANAME-awareness and -obliviousness.

I think that if the transmission through the resolver forwarding chain is
done by putting extra records in the additional section, then it should be
self-healing. Downstream ANAME-aware resolvers can (if necessary) do extra
ANAME-related queries through an ANAME-oblivious upstream.

> I still think that in addition a clear description of why this is hard
> would be helpful.

I think it can be made reasonably simple :-)

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Fisher, Northeast German Bight: Northwest veering east 4 or 5, decreasing 3
for a time. Slight or moderate. Fair. Moderate or good.