> -----Original Message-----
> From: ram [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 21, 2008 2:36 PM
> 
> ...omissis...
> > Again, no registrar check, sorry. You could eventually use the:
> "uri_whois
> > nsname" or the "uri_whois nsaddr" tests to attempt catch these.
> 
> I think I am missing something here. The NS address is different from
> the registrar.

Right, it is.

The URIWhois does not detect the registrar. It detects the name and the
address of the DNS- and whois-defined NSes for that domain.


> How can we score based on NS address? Can a spammer not put innocent
> servers as his Nameserver , as long as they allow DNS queries to his
> host

I guess there is a "not" in excess in your question. If you are asking "can
a spammer put an innocent etc, etc", then the answer is: yes, he/she can,
but this wouldn't help with the URIWhois plugin.

What I meant in my scarce previous reply was that the URIWhois plugin builds
a list of the nameservers' names and addresses related to the uris SA finds
in the message. These names and addresses are built merging the ones
discovered through DNS queries with the ones discovered through whois
queries. Then, your rules may attempt to match DNS server names or addresses
from this list. You of course would attempt matching the list with names and
addresses which are well-known to be bad, not with any "innocent" one.

There are many "usage cases" for the URIWhois plugin. However, basically
spammers as well as everybody else often like to have full control over the
authoritative NSes of their domains. Thereby, you may easily protected
yourself even from future spam by creating a URIWhois rule matching the
bunch of addresses in which the whois-published nameservers are: it is often
assigned to a single entity which I bet is less than innocent.

In example, whois says beekeeni<dot>com is handled by 210.14.128.172 and
210.14.128.112. These NSes are the 210.14.128.0/13 address space which is
assigned to a Chinese company. When I attempt to access its site I even get
a warning from my antivirus. Ok, I decide they are basically spammers. Then
I put this rule in my URIWhois.cf:

        uri_whois SPAMDNSADDR nsaddr in 210.14.128.172/13
        score SCAMDNSADDR {TheScoreILike}

and that's it: sites whose DNS authoritative servers are in these addresses
get a score, regardless of the NS name and any attempt to DNS redirection by
them...

Of course, I can also group together more bunch of addresses:

        uri_whois SPAMDNSADDR nsaddr in 210.14.128.172/13 1.1.1.0/24
2.2.2.0/24 etc, etc

Thereby, I don't need a SA rule for every and each bunch as long as I want
to score them the same.

Anyway, apart from matching the DNS names and addresses published through
whois records, I recently discovered that most spam domains don't respond to
SOA and NS request!!! This is quite easy to detect with very-low cpu
consumption (i.e., asynchronously), at the cost that the spam has to wait
for at least a couple of DNS request timeouts before asserting that SOA
and/or NS replies are missing. By the way, RFC 1035 states that SOA and NS
requests MUST be replied by an authoritative nameserver.

Try this:

        dig soa beekeeni<dot>com

...

Unfortunately this detection is not yet implemented in the URIWhois
RFC1035IGN rule.


> The format of the registrar in whois information is not standardized. I
> wonder why.  If I could do something like
> dig domain.tld REG ( just like dig domain.tld MX )
> then life would have been so simple.

The main problem here is that, when ICANN delegates control about gTLD
zones, there is not even a word in its agreements regarding "public access
to registration records". gTLDs' Network Information Centers are basically
free to do whatever they like with their gTLD, provided they implement
something to let ICANN inspect their records. ICANN, not you or me...


> Thanks
> Ram

You welcome,

Giampaolo

Reply via email to