Re: [DNSOP] Minimum viable ANAME

Tony Finch <dot@dotat.at> Thu, 20 September 2018 13: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 6783D129C6B for <dnsop@ietfa.amsl.com>; Thu, 20 Sep 2018 06:08:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 pCGyjTxyjm64 for <dnsop@ietfa.amsl.com>; Thu, 20 Sep 2018 06:08:22 -0700 (PDT)
Received: from ppsw-31.csi.cam.ac.uk (ppsw-31.csi.cam.ac.uk [131.111.8.131]) (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 D3874130EA2 for <dnsop@ietf.org>; Thu, 20 Sep 2018 06:08:21 -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]:48900) by ppsw-31.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1g2ygt-000i4s-Ld (Exim 4.91) (return-path <dot@dotat.at>); Thu, 20 Sep 2018 14:08:19 +0100
Date: Thu, 20 Sep 2018 14:08:19 +0100
From: Tony Finch <dot@dotat.at>
To: Paul Wouters <paul@nohats.ca>
cc: dnsop <dnsop@ietf.org>
In-Reply-To: <alpine.LRH.2.21.1809191921500.16965@bofh.nohats.ca>
Message-ID: <alpine.DEB.2.20.1809201354470.3596@grey.csi.cam.ac.uk>
References: <20180919201401.8E0C220051382A@ary.qy> <08C8A740-D09B-4577-AF2A-79225EDB526B@dotat.at> <alpine.LRH.2.21.1809191921500.16965@bofh.nohats.ca>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/YSrzcXJmrNG7WhLSFwoDAw2Mi5I>
Subject: Re: [DNSOP] Minimum viable ANAME
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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 Sep 2018 13:08:23 -0000

Paul Wouters <paul@nohats.ca> wrote:
>
> > With this model, signing only happens where it currently happens.
>
> Good. Although if you want to return bar's IP if it is different from
> foo's IP and for resolvers that don't understand ANAME, you have to
> synthesize these, but at least then it is nor worse then DNS64 with
> respect to DNSSEC.

Who is "you" in this sentence?

If you are a secondary authoritative server, then you're almost certainly
oblivious to the target address records, but even if you do know them, you
aren't able to substitute them because the ANAME's zone is probably signed
and you don't have the keys.

If you are a recursive server, you can substitute if DO=0 or if the
ANAME's zone is unsigned. It would be nice if clients that make DO=1
queries also know about ANAME so they can substitute if required, but that
isn't necessary for correctness.

ANAME is much less bad than DNS64 because DNS64 requires knowledge about
the prefix used for tunneling, whereas ANAME substition doesn't need any
information beyond the additional section of the response you just got.
And ANAME substitution isn't necessary for in the way DNS64 is, i.e.
connectivity works if you don't substitute ANAME sibling address records,
but it doesn't if you lose DNS64 substitution.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
no one shall be enslaved by poverty, ignorance, or conformity