Re: [ietf-dkim] Domain Lists versus SSP wildcards

On May 31, 2007, at 7:03 AM, Jim Fenton wrote:
> william(at)elan.net wrote:
> > Dont do it. The issue is that you can not properly tell where zone  
> > delegation starts. I know resourceful programmers (including me)  
> > keep track of this data and know that for example ".com" is one  
> > delegation but ".uk" is not and there you have ".co.uk". But the  
> > list is actually rather large and for several ccTLDs you have both  
> > use ".com.??" and ".??" as proper delegation zones. So getting  
> > around this is just way too tricky and if you don't what you end  
> > up doing is sending multitude of extra queries to ccTLD name  
> > servers. This is not proper operational approach as extra load  
> > would not be spread but directed towards several single points on  
> > the net.
> The number of upward queries to TLDs and other "non-delegation  
> zones" would be limited by negative cacheing; each verifier should  
> only be making one such query per minimum TTL period.  I'm not sure  
> how to assess what would be an "acceptable" load, however, and in  
> any case the min TTL is sometimes rather short (15 minutes  
> for .com, I see) so that might not be enough help.
> As for Doug's subsequent suggestion of publishing a list of such  
> non-delegation zones somewhere, we would need to normatively refer  
> to such a list, which means that it would need to be maintained by  
> IANA or a similar authority.  I don't see that as a likely  
> possibility, especially since the usage of ccTLDs is outside IANA's  
> scope.
Jim,

Caching is more effective starting the search below the TLD.  Bad- 
actors often make use of random labels and wildcards to obfuscate  
their significant domain.  This rather common practice of random  
labels is flooding the DNS cache making it less effective.  A  
strategy starting high leads to fewer queries and less time per  
transaction.  However, this will cause second and third level domains  
to experience higher levels of undesired traffic.  An option these  
domains have is to terminate queries with a long lived record with a  
prefix and RR type used by the protocol causing the traffic.  As  
Phillip suggested, this would be a PITA and prohibit versioning.   
Forcing any publication of "dummy" records by second and third level  
domains would be demanding an inordinate amount of cooperation.
IANA could provide these second and third levels domains a much  
easier alternative.  With this alternative, they avoid a significant  
amount of traffic without publishing anything used directly by some  
protocol.
For just a _single_ IP address, our customers generate over 50  
queries per second for those items not cached and, at any point in  
time, more than 70 million IP addresses are active.  Think how bad  
this gets when there is no record to cache to quell the queries.
If IANA were to publish a list offering second and third level  
registries a simple solution to curtail this traffic, _no_ other  
enticement or legal obligation should be needed.  In this respect, we  
hold a different view about what might be possible and practical.   
This would be hundreds of times safer than wildcards, while also  
conserving a vast amount DNS cache which will otherwise contain  
mostly junk.  A list of this nature could assist many differ polices  
and protocols without resorting to wildcards of any sort.
-Doug

 
 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html