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

Tony Finch <dot@dotat.at> Tue, 18 July 2017 16:09 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 367B6128DE5 for <dnsop@ietfa.amsl.com>; Tue, 18 Jul 2017 09:09:04 -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 CaG6hOKEB-Vj for <dnsop@ietfa.amsl.com>; Tue, 18 Jul 2017 09:09:02 -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 675F41287A0 for <dnsop@ietf.org>; Tue, 18 Jul 2017 09:09:02 -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]:42547) 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 1dXV3U-000fT6-eT (Exim 4.89) (return-path <dot@dotat.at>); Tue, 18 Jul 2017 17:09:00 +0100
Date: Tue, 18 Jul 2017 17:09:00 +0100
From: Tony Finch <dot@dotat.at>
To: Willem Toorop <willem@nlnetlabs.nl>
cc: dnsop@ietf.org
In-Reply-To: <0edbf3f2-e575-3b34-d3f2-f1424f29f6e4@nlnetlabs.nl>
Message-ID: <alpine.DEB.2.11.1707181622300.27210@grey.csi.cam.ac.uk>
References: <149592096439.3966.11385984990945858242@ietfa.amsl.com> <0edbf3f2-e575-3b34-d3f2-f1424f29f6e4@nlnetlabs.nl>
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/Zh7viwmrR7QcJSFQvqMsb7YSRU8>
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 16:09:04 -0000

Willem Toorop <willem@nlnetlabs.nl> wrote:
>
> The dependency on online signing is a little more then just a technical
> issue.

I need to review the draft properly, but I do not think ANAME should
require any online signing.

In my view an authoritative server which does online signing and on-demand
record synthesis is a master server. You can make all your public
authoritative servers into masters if you like, but it must not be
required.

If (like me) you have a more traditional setup then ANAME is an
instruction to the master server about zone maintenance, saying that it
needs to periodically update the sibling A and AAAA records, similar to
periodic re-signing, or as if some script were periodically `nsupdate`ing
the records. The secondary servers can continue to work the same as they
do now, but they'll work better if they know about some helpful additional
section rules for ANAME.

(That is basically how my bodged-up ANAME implementation works, in my
zone provisioning scripts.)

The other kind of DNS server that might be able to do something useful
with ANAME is a recursive server, so it could co-operate nicely with
authoritative servers that are playing clever tricks. But the rDNS will
have to be careful about not breaking downstream validators.

Say (for example) my zone has:

dotat.at.	ANAME	www.chiark.greenend.org.uk.
dotat.at.	RRSIG	ANAME
dotat.at.	A	212.13.197.229
dotat.at.	RRSIG	A
dotat.at.	AAAA	2001:ba8:1e3::
dotat.at.	RRSIG	AAAA

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.

; ANSWER
dotat.at.       A       212.13.197.229
dotat.at.	RRSIG	A

; ADDITIONAL
dotat.at.       AAAA    2001:ba8:1e3::
dotat.at.	RRSIG	AAAA
dotat.at.       ANAME   www.chiark.greenend.org.uk.
dotat.at.	RRSIG	ANAME
www.chiark.greenend.org.uk.	A	212.13.197.231
www.chiark.greenend.org.uk.	RRSIG	A
www.chiark.greenend.org.uk.	AAAA    2001:ba8:1e3::
www.chiark.greenend.org.uk.	RRSIG	AAAA

Note that neither the resolver nor the client needs any algorithm updates
to avoid being confused by this additional information; they just need a
code update so that they are able to make good use of it.

If the resolver knows the client is DNSSEC-oblivious then it can do the
substitution itself and return a simple answer like this:

dotat.at.	A	212.13.197.231

Validating but ANAME-oblivious resolvers won't get to enjoy clever
latency minimization tricks.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
East Sole, Lundy, Fastnet, Irish Sea: Easterly becoming cyclonic 4 or 5,
increasing 6 or 7 at times. Slight or moderate. Fair then thundery showers,
fog patches later. Moderate or good, occasionally very poor later.