[SURBL-Discuss] RFC: SURBL software implemetation guidelines

Simon Byrnand simon at igrin.co.nz
Wed Apr 21 14:03:39 CEST 2004


> On Tuesday, April 20, 2004, 8:39:50 AM, Jose Cruz wrote:
>> Jeff Chan wrote:
>>> On Sunday, April 18, 2004, 7:53:46 PM, Eric Kolve wrote:
>>>
>>>>Currently SpamCopURI checks both the 2nd and 3rd level domain
>>>> regardless
>>>>of the TLD.  I believe SA 3.0 does a little better job of this.
>
>>> Sounds good.  That should catch everything with few false
>>> positives, since we're filtering out most ccTLDs on the data
>>> side and not too many get reported in the first place.
>
>> Why not declare wildcards records at DNS to solve randomness and doing a
>> single DNS query ?
>
>> Instead of declaring
>
>> spammer.com   A  127.0.0.1
>
>> you could declare :
>
>> spammer.com      A   127.0.0.2
>> *.spammer.com    A   127.0.0.2
>
>> Does this work ?
>
> We're taking the opposite approach and removing the wildcards on
> the client side before comparing them to the SURBL.  That way the
> SURBL only gets the base domains.  The net results should be
> similar; the difference is where the randomness is resolved.  We
> also considered doing wildcard DNS but like the former approach
> better.

I'm not 100% sure on the behaviour of wildcard records, but if a client
looks up a record that is actually a wildcard on the server, can the local
nameserver cache it as a wildcard, or does it just cache the specific
match ?

In other words, if SA looked up abc.spammer.com.sc.surbl.org and the abc
part was actually a wildcard, would the local caching nameserver cache
abc.spammer.com.sc.surbl.org or *.spammer.com.sc.surbl.org ?

If a second query came along for xyz.spammer.com.sc.surbl.org and abc was
specifically cached, it couldn't be returned from the local cache.

With the current system of stripping the domains before making the query,
the local caching nameserver should be able to do a better job of caching
requests in that case...

So which way does it actually work in practice ? :)

Regards,
Simon




More information about the Discuss mailing list