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

David B Funk dbfunk at engineering.uiowa.edu
Fri Apr 23 23:36:48 CEST 2004

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. Again you could take the standard DNS TXT record and overload
them with special 'magic' tags to indicate that their data are regex
patterns and then design a special DNS server front-end that would take
those special zones and convert them into food for the regex engine
back-end, but that would take special coding...
Anyway you cut it, you've already blown out the possibility of using the
standard DNS packages and moved into the custom coding land.

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!), or demand a query all the way back to the authoritative
servers on every lookup (IE do not permit any caching) which would be
a killer for them in bandwidth and CPU load.

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.

Might as well stick with BigEvil.cf and the rsync distribution scripts
that have been developed by various people in SA land.
(IE use already tried and tested means for those that want this kind of

Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{

More information about the Discuss mailing list