Forgery resilience idea - wildcard cooperative defense

[Brian Dickson <[e-mail]>]

While doing some free-associating around the Kaminsky presentation, I 
began pondering wildcards.

Specifically, what could we do, using wildcards, to nip the 
$RANDOM.example.com problem in the bud?

Here's the beginnings of a meme on this concept...

If:
Authority server for example.com has a wildcard which means to 
communicate that anything matching the wildcard should get NXDOMAIN answers;
And:
A recursive resolver, upon getting an NXDOMAIN for a *specific* 
subdomain query, such as foo000001.example.com, do a query for the "*" 
literal;
Then:
The recursive resolver could cache the wildcard NXDOMAIN for $TTL, and 
immediately answer queries for all such garbage subdomains.

Then, anyone wanting to protect their domain would be able to add in the 
wildcard NXDOMAIN.

Or, plan B (which does not require any work on the part of domain 
administrators, only modified code on resolvers and authority servers):

If:
An authority server, upon receiving a query for wildcard literal "*", if 
it does not find a match, returns in the Additional section, an 
enumerated list of delegated subdomains.
And:
(same as "And" clause above)
Then:
Additional responses get cached for positive enumerated answers, and an 
additional wildcard literal "*" gets synthesized for NXDOMAIN on all 
other subdomains.

Both of these appear, at first blush, to remove the non-TTL basis for 
triggering new windows for birthday attacks, and thus can significantly 
improve the resilience to forgery attacks of the new Kaminsky vector 
variants.

Thoughts?

Brian Dickson

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>