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/>