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.orgAnd, 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
System Administrator Asarian-host.org
--- "If you were supposed to understand it, we wouldn't call it code." - FedEx