[SURBL-Discuss] Fwd: Re: Goofy domain names
csanterre at merchantsoverseas.com
Mon Apr 26 12:14:37 CEST 2004
>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:
>>> 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
>>> without stretching the imagination too much, even. If only I change
>>> the above regex to:
>>> 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
>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
>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.
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 ;)
More information about the Discuss