Re: Forgery resilience idea - wildcard cooperative defense
Brian Dickson <briand@ca.afilias.info> Thu, 07 August 2008 17:56 UTC
Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68473A6ABC; Thu, 7 Aug 2008 10:56:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLIhZ0zfqw6Y; Thu, 7 Aug 2008 10:56:34 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D0AA3A6B16; Thu, 7 Aug 2008 10:56:33 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KR9cc-000Iwu-Kb for namedroppers-data@psg.com; Thu, 07 Aug 2008 17:49:58 +0000
Received: from [207.219.45.62] (helo=vgateway.libertyrms.info) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <briand@ca.afilias.info>) id 1KR9cX-000Iw9-Og for namedroppers@ops.ietf.org; Thu, 07 Aug 2008 17:49:56 +0000
Received: from briand-vpn.int.libertyrms.com ([10.1.7.90] helo=[192.168.2.87]) by vgateway.libertyrms.info with esmtp (Exim 4.22) id 1KR9cS-0001V0-5V; Thu, 07 Aug 2008 13:49:48 -0400
Message-ID: <489B35BB.9010105@ca.afilias.info>
Date: Thu, 07 Aug 2008 13:49:47 -0400
From: Brian Dickson <briand@ca.afilias.info>
User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707)
MIME-Version: 1.0
To: bert hubert <bert.hubert@netherlabs.nl>, Paul Vixie <vixie@isc.org>, Wouter Wijngaards <wouter@NLnetLabs.nl>, Namedroppers <namedroppers@ops.ietf.org>, dns-operations@lists.oarci.net
Subject: Re: Forgery resilience idea - wildcard cooperative defense
References: <489AD5E3.20708@nlnetlabs.nl> <45759.1218122552@nsa.vix.com> <489B295C.3020002@ca.afilias.info> <59360.1218129508@nsa.vix.com> <20080807173819.GA25195@outpost.ds9a.nl>
In-Reply-To: <20080807173819.GA25195@outpost.ds9a.nl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-SA-Exim-Mail-From: briand@ca.afilias.info
X-SA-Exim-Scanned: No; SAEximRunCond expanded to false
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
bert hubert wrote: > On Thu, Aug 07, 2008 at 05:18:28PM +0000, Paul Vixie wrote: > >> any solution requiring cooperative action/change by both the RDNS and ADNS >> has a cost that's equivilent to "deploy DNSSEC". the thing that's good >> > > That's simply not true - DNSSEC does not function automatically even if both > ADNS and RDNS support it. > > DNSSEC needs a change to: > ADNS, > RDNS, > the zone, > the registry, > the registrar, > and even the operational procedures of domain owner. > (the stub, the application - if you want to give the end-user a > choice) > > Paul's point was that there are orders (many) of magnitude more systems enumerated in the sets { ADNS } and { RDNS } than in all the rest of the items. And, if you are talking about touching them, you may as well touch them in a way that facilitates DNSSEC - possibly in addition to other things. Furthermore: "the zone" and "the registry" are often under the same administrative control, and in the case of TLDs, (a) there are very few currently, and (b) there are choices of TLD once there exists one TLD that does DNSSEC. And, technically, it only requires a change to ONE registrar, to enable DNSSEC, since it is possible to change registrars, if one wants DNSSEC. So, the bare minimum for DNSSEC deployment is: ADNS, RDNS, *one* zone + registry, *one* registrar, and the ops procedures and tools for the domain owner - which may be further facilitated by the outsourcing of some aspects of domain maintenance to a DNS hosting provider that "does" DNSSEC. Brian > EDNS PING or other entropy enhancing solutions provide benefit to anybody > deploying them, without further work, and require only ADNS and RDNS work. > > DNSSEC provides lots of other things beyond entropy of course. > > Bert > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>
- Re: Additional filtering of responses Tony Finch
- Additional filtering of responses Wouter Wijngaards
- OFFTOPIC: DNSSEC groupthink versus improving DNS bert hubert
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: Additional filtering of responses Paul Vixie
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Paul Vixie
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Paul Vixie
- RE: OFFTOPIC: DNSSEC groupthink versus improving … Jesper G. Høy
- Re: Additional filtering of responses Roy Arends
- Re: Additional filtering of responses Paul Vixie
- Forgery resilience idea - wildcard cooperative de… Brian Dickson
- Re: Forgery resilience idea - wildcard cooperativ… Paul Vixie
- Re: Additional filtering of responses Roy Arends
- Re: Forgery resilience idea - wildcard cooperativ… bert hubert
- Re: Forgery resilience idea - wildcard cooperativ… Brian Dickson
- Re: Additional filtering of responses Edward Lewis
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Olaf Kolkman
- Re: Additional filtering of responses Tony Finch
- Re: OFFTOPIC: DNSSEC groupthink versus improving … David Conrad
- Re: OFFTOPIC: DNSSEC groupthink versus improving … bert hubert
- Re: Additional filtering of responses Edward Lewis
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Federico Lucifredi
- Re: Additional filtering of responses Paul Vixie
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Mark Andrews
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Paul Vixie
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Paul Vixie
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Mark Andrews
- Re: Additional filtering of responses Mark Andrews
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Mark Andrews
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Mark Andrews
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Mark Andrews
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Mark Andrews
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Brian Dickson
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Mark Andrews
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Brian Dickson
- Re: Additional filtering of responses Masataka Ohta
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane
- Re: Additional filtering of responses Masataka Ohta
- Re: Additional filtering of responses Roy Arends
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Ralf Weber
- Re: Additional filtering of responses Masataka Ohta
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane at e164 dot org
- Re: Additional filtering of responses Duane at e164 dot org
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Ralf Weber
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Alex Bligh
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane at e164 dot org
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane at e164 dot org
- Re: OFFTOPIC: DNSSEC groupthink versus improving … sthaug
- Re: OFFTOPIC: DNSSEC groupthink versus improving … bert hubert
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane at e164 dot org
- Re: Additional filtering of responses Peter Koch
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Duane at e164 dot org
- Please stop this thread (was: OFFTOPIC: DNSSEC gr… Andrew Sullivan
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Otmar Lendl
- Re: Please stop this thread (was: OFFTOPIC: DNSSE… Matt Larson
- Re: Please stop this thread (was: OFFTOPIC: DNSSE… David Conrad
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Ben Laurie
- how many angels can dance on the head of a pin? bmanning
- Re: how many angels can dance on the head of a pi… Duane at e164 dot org
- Re: how many angels can dance on the head of a pi… Alex Bligh
- Re: how many angels can dance on the head of a pi… Duane at e164 dot org
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Florian Weimer
- Re: how many angels can dance on the head of a pi… Alex Bligh
- Re: how many angels can dance on the head of a pi… Alex Bligh
- Re: how many angels can dance on the head of a pi… sthaug
- Re: how many angels can dance on the head of a pi… Ben Laurie
- Re: how many angels can dance on the head of a pi… Alex Bligh
- Re: how many angels can dance on the head of a pi… Ben Laurie
- Re: how many angels can dance on the head of a pi… Paul Vixie
- Re: how many angels can dance on the head of a pi… Paul Hoffman
- Re: how many angels can dance on the head of a pi… bmanning
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Havard Eidnes
- Re: OFFTOPIC: DNSSEC groupthink versus improving … Mark Andrews
- DNSSEC on autopilot (was: OFFTOPIC: DNSSEC groupt… Otmar Lendl
- Re: DNSSEC on autopilot (was: OFFTOPIC: DNSSEC gr… Andrew Sullivan
- Re: DNSSEC on autopilot (was: OFFTOPIC: DNSSEC gr… Otmar Lendl
- Re: DNSSEC on autopilot (was: OFFTOPIC: DNSSEC gr… Mark Andrews
- Re: DNSSEC on autopilot (was: OFFTOPIC: DNSSEC gr… Andrew Sullivan