[dns-operations] Forgery resilience idea - wildcard cooperative defense

[Brian Dickson]

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