[SURBL-Discuss] Fwd: Re: Goofy domain names

Chris Santerre csanterre at merchantsoverseas.com
Mon Apr 26 12:14:37 CEST 2004



>-----Original Message-----
>From: Mark [mailto:admin at asarian-host.net]
>Sent: Saturday, April 24, 2004 12:11 AM
>To: David B Funk; SURBL Discussion list
>Cc: SpamAssassin Users
>Subject: Re: [SURBL-Discuss] Fwd: Re: Goofy domain names
>
>
>David B Funk wrote:
>
>> On Sat, 24 Apr 2004, Mark wrote:
>>
>>> Why use expand_regex.pl at all? Instead of taking "/\d00\dhosting/",
>>> and expand it into 100 potential domain names, why not simply accept
>>> a query like:
>>>
>>>     9001hosting.com.be.surbl.org
>>>
>>> And, internally, do the regex "/\d00\dhosting/" on it? (and all
>>> BigEvil regexes, for that matter). And return 127.0.0.2 on a match.
>>>
>>> Ultimately, using expand_regex.pl, imho, is utterly 
>self-defeating --
>>> without stretching the imagination too much, even. If only I change
>>> the above regex to:
>>>
>>>     /\d+00\d+hosting/
>>>
>>> We're already looking at trillions of permutations!
>>>
>>> It seems to me be.surbl.org should not do an internal database query
>>> on single domain names, but instead do a BigEvil regex (like SA
>>> does). At least, that is what I thought it would do; and how I had
>>> hoped it would have been.
>>
>> Because the DNS system is designed to work with static lists of data,
>> not regex patterns.
>>
>> Theoretically you could design a DNS server front-end on a regex
>> engine that would take fixed DNS queries and do regex matches.
>> However the DNS zone-transfer mechanism is designed to deal with
>> fixed data-sets, not regexes.
>
>DNS zone-transfers would not be affected. It would still be 
>the same, static
>data-set being pushed back and forth. In fact, the 
>be.surbl.org DNS server
>would not contain a regular DNS database at all (!), as it merely does
>regexes on incoming queries! If anything, you'd have to transer BigEvil
>regex rules, really.
>
>> Another detail, is that the DNS system is heavily based upon the
>> concept of cacheing. Currently there's no meaningful way to cache a
>> regex, only the results of every lookup permutation. That would
>> impose an unrealistic demand on the down-stream DNS servers (remember
>> those trillions of permutations!),
>
>Not at the client-side. When I were to query 
>"9001hosting.com.be.surbl.org",
>there would be no overhead whatsoever, cache-wise, for a front-end DNS
>system that does a behind-the-scenes regex on the query. It would still
>reply with a single response. It would, to the client, appear 
>no different
>then if the DNS server had retrieved the domain name from database.
>
>The caching DNS server at be.surbl.org itself might grow big, 
>though, as it
>potentially holds those trillions of those domain names. But 
>it would, as
>you say, really only cache the result of each looked-up 
>permutation. And no
>more. And, in this, it would be no different from a regular DNS server.
>
>> Another detail, you're adding to the CPU load on the "regex-ifed" DNS
>> servers. Doing a regex match is more CPU intensive than a database
>> lookup on a fixed data set. When you have the potential of thousands
>> or millions of clients beating upon a handfull of DNS servers, the
>> CPU load considerations become critical.
>
>This is true. And it may indeed be quite a problem.
>
>> Might as well stick with BigEvil.cf
>
>My point exactly; without using real regexes in be.surbl.org, dropping
>BigEvil.cf, for now, is ill-advised, really.
>
>Cheers!
>
>- Mark

 Wow that was a lot to read for a Monday Morning :)  Bigevil won't be
dropped. But it will change. You will have lots of options in the near
future. Lots of options ;)

--Chris 


More information about the Discuss mailing list