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

Brian Dickson briand at ca.afilias.info
Thu Aug 7 16:57:00 UTC 2008


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



More information about the dns-operations mailing list