> -----Original Message-----
> From: Matt Kettler [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 25, 2008 3:07 PM
>
> Jeff Chan wrote:
> > Quoting Matt Kettler <[EMAIL PROTECTED]>:
> >
> >> Matt Kettler wrote:
> >>> Giampaolo Tomassoni wrote:
> >>>>
> >>>> It doesn't use whois *instead of* dns. It uses both and attempts
> >>>> even to
> >>>> detect any discrepancy between their responses.
> >
> > Both types of queries can cause problems.
> >
> >>> How are these going to be different?? The information published to
> >>> whois has to match the information published to the authoritative
> >>> DNS servers for the TLD the domain falls under.
> >
> > That's a false assumption. Legitimate domains can have mismatched
> > whois and nameserver information during the time when they're being
> > changed.
>
> Ok, I guess I meant "how are these going to be usefully different".
> There's a time spread between TLD NS updates and whois updates, but you
> can't configure the two to be different and have it stay that way. So,
> any difference between the two sources of data is a function of timing,
> and probably not useful as a spam detection criteria.
>
> But this isn't the approach Giampaolo has taken. He's comparing whois
> to
> SOA records, so he's essentially detecting misconfigured SOA's that
> don't match the whois DNS servers.
No, SOA is used for another couple of tests in URIWhois: the
RFC1035-ignorant and ttl ones.
The kind of test you guys are referring is the nsmismatch one, which doesn't
involve a SOA query.
Ok, let me explain this thing better.
URIWhois supports a set of test. Not all these tests involve whois queries,
not all tests involve DNS queries. Tests may be selectively chosen/disabled.
The tests are:
WHOIS SOA NS A* TestName
n y n n ttl
n y y n rfc1035-ignorant
y n n n created
y n y n nsname
y n y y nsaddr
y n y n nsmismatch
A*: an A query to discover the address of a NS name, not the A of
the uri's host.
Mono-spaced font required to correctly view the table.
If you guys had enough patience to read the perldoc of the URIWhois plugin,
you had already got this.
The nsmismatch test compares the set of NSes discovered via whois with the
one gathered via DNS. It evaluates a mismatch factor (0 = no mismatch, 1 =
complete mismatch), then SA rules referring to this test may decide what to
do. My example config shows two rules using it: PARTNSMIS scores 0.75 when
the mismatch is >= 0.5 (i.e., at least half of the NS names defined on one
set differ from the ones defined on the other), while FULLNSMIS scores 3 and
triggers when the mismatch factor is close to 1 (basically, when NS names in
the two sets are completely different). I see very few FPs from PARTNSMIS,
no one from FULLNSMIS. But please note FULLNSMIS do work. Have a look at NS
names defined for goodivibe<dot>net<dot>cn, in example.
> He'd still be better off looking up the NS record at the TLD and
> comparing that to the SOA. Both are DNS queries and would show the same
> thing, except during moves.
>
> If detecting moves is your desire, you should be comparing the whois to
> the TLD NS record, not the SOA.
Please note that one generally can't issue a DNS request to a specific
server from SA, since its resolver engine only uses the globally-defined DNS
server(s). Thereby, in the common case I should get the NSes published by
root servers, which should be exactly the ones published in whois. But they
not always are! This is not because of a "change" in progress, but because
of the normal follow-up of the authoritative chain in domain names
resolution: if a root server says that NSa and NSb are authoritative for
domain D, but NSa says that instead NSc and NSd are, the resolver (which of
course must apply "recursion", since you're not using a non-recursive DNS
server for your standard queries, right?) yields two NS RR with NSc and NSd
names in them, not with the ones defined by the root server. Example:
~ # dig +norecurse ns goodivibe<dot>net<dot>cn @A.DNS.cn.
; <<>> DiG 9.4.1-P1 <<>> +norecurse ns goodivibe<dot>net<dot>cn @A.DNS.cn.
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61011
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;goodivibe<dot>net<dot>cn. IN NS
;; AUTHORITY SECTION:
goodivibe<dot>net<dot>cn. 21600 IN NS
ns2<dot>betotallyclear<dot>com.
goodivibe<dot>net<dot>cn. 21600 IN NS
ns1<dot>betotallyclear<dot>com.
;; Query time: 492 msec
;; SERVER: 203.119.25.1#53(203.119.25.1)
;; WHEN: Fri Jan 25 16:44:39 2008
;; MSG SIZE rcvd: 88
which are the NS names defined in whois.
~ # dig +recurse ns goodivibe<dot>net<dot>cn
; <<>> DiG 9.4.1-P1 <<>> +recurse ns goodivibe<dot>net<dot>cn
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49165
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;goodivibe<dot>net<dot>cn. IN NS
;; ANSWER SECTION:
goodivibe<dot>net<dot>cn. 60 IN NS
ns2<dot>goodivibe<dot>net<dot>cn.
goodivibe<dot>net<dot>cn. 60 IN NS
ns1<dot>goodivibe<dot>net<dot>cn.
;; Query time: 1835 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Fri Jan 25 16:47:04 2008
;; MSG SIZE rcvd: 70
Which aren't the NS names defined in whois.
This means that the nsname and nsaddr tests could avoid doing a whois lookup
if the URIWhois code could issue a DNS request to an arbitrary nameserver
(see first dig: @A.DNS.cn.). But they can't.
Since anyway I'm using the whois reply for the "created" test, I don't
bother with this and use the whois reply to obtain the nameservers defined
in the registrar records.
> However, I'm still stuck on how this information is useful, or has any
> high correlation to spam activity.
Some test work better than others. In example, rfc-1035-ignorant was good
some months ago, but now behaves poorly. ttl never worked really well since
it leads to too many FPs. Good tests are the "created" one (of course) and
the nsaddr one. Try punishing mail with uris which refer to a nameserver in
the 210.14.128.0/13 address bunch...
Giampaolo
