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

Mark admin at asarian-host.net
Sat Apr 24 07:10:50 CEST 2004

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


- Mark

        System Administrator Asarian-host.org

"If you were supposed to understand it,
we wouldn't call it code." - FedEx

More information about the Discuss mailing list