IETF Logo Mail Archive

Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

Chris Thompson <cet1@cam.ac.uk> Wed, 20 August 2014 16:50 UTC

Return-Path: <cet1@hermes.cam.ac.uk>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA2B1A03F9 for <dnsop@ietfa.amsl.com>; Wed, 20 Aug 2014 09:50:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.868
X-Spam-Level:
X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham
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 eryzWIzPTgl2 for <dnsop@ietfa.amsl.com>; Wed, 20 Aug 2014 09:50:05 -0700 (PDT)
Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) (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 F0BF61A0455 for <dnsop@ietf.org>; Wed, 20 Aug 2014 09:50:04 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:33153) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:cet1) id 1XK95G-00009o-EO (Exim 4.82_3-c0e5623) (return-path <cet1@hermes.cam.ac.uk>); Wed, 20 Aug 2014 17:50:02 +0100
Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1XK95G-0000lA-DE (Exim 4.72) (return-path <cet1@hermes.cam.ac.uk>); Wed, 20 Aug 2014 17:50:02 +0100
Received: from [131.111.56.28] by old-webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 20 Aug 2014 17:50:02 +0100
Date: Wed, 20 Aug 2014 17:50:02 +0100
From: Chris Thompson <cet1@cam.ac.uk>
To: dnsop@ietf.org
Message-ID: <Prayer.1.3.5.1408201750020.12368@hermes-1.csi.cam.ac.uk>
In-Reply-To: <7EA38D42-3915-403E-AFE3-C0A8E4A391BF@hopcount.ca>
References: <20140814001610.3124D1CC688D@rock.dv.isc.org> <86AC48C0-4DFF-4286-A9B1-2A6BE3D14BDC@hopcount.ca> <20140814160453.1C7931CCE03D@rock.dv.isc.org> <7EA38D42-3915-403E-AFE3-C0A8E4A391BF@hopcount.ca>
X-Mailer: Prayer v1.3.5
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="ISO-8859-1"
Sender: Chris Thompson <cet1@hermes.cam.ac.uk>
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/ICvBQZRicxLQNyF1HuoDiVTXQtA
Cc: Joe Abley <jabley@hopcount.ca>
Subject: Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: cet1@cam.ac.uk
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: <http://www.ietf.org/mail-archive/web/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: Wed, 20 Aug 2014 16:50:07 -0000

On Aug 14 2014, Joe Abley wrote:

[...]
>It seems to me that no delegation is a perfectly reasonable steady state,

It fails to break the chain of trust. Because a validator can "prove" that
the names in the putative subzone do not exist, it will consider locally
defined content "bogus". The only way around this is either to have all
local nameservers be authoritative for the subzone (e.g. by slaving it)
or to sign it and have them all configured with a trust anchor. (Negative
trust anchors would make this a bit easier, but as we know a certain
common nameserver implementation does not support them...)

Depending on how large "local" is this can be difficult to achieve, and
in the particular use case of 100.64.0.0/10 it is liable to be big.

>so long as ARIN doesn't mind the NXDOMAIN load from leaked queries. An
>alternative to a delegation (if they do care) would be a DNAME redirection
>to EMPTY.AS112.ARPA once that is available.

Would this last actually work to break the chain of trust (provided that
EMPTY.AS112.NET was itself unsigned)? I am having difficulty working out
exactly what a validator would do in this situation.

-- 
Chris Thompson               University of Cambridge Information Services,
Email: cet1@uis.cam.ac.uk    Roger Needham Building, 7 JJ Thomson Avenue,
Phone: +44 1223 334715       Cambridge CB3 0RB, United Kingdom.

v2.30.2 | Report a Bug | By Email | System Status