SpamCop "Cannot resolve" a valid URL

[paul.hunt]

http://www.spamcop.net/sc?id=z1098619467z7...7cd9b7b6bddfc7z

Shows an IP address of a spoof website and discards it as fake because "Cannot resolve". But that IP and website exists. You can enter it as a URL and display it. So why can't SpamCop resolve and report it?

[agsteele]

Shows an IP address of a spoof website and discards it as fake because "Cannot resolve". But that IP and website exists. You can enter it as a URL and display it. So why can't SpamCop resolve and report it?

Well, I can't resolve this from here either so presumably you have data for systms.com in your DNS whereas other DNS servers do not have the information.

http://network-tools.com/default.asp?prog=...host=systms.com

Andrew

[Farelf]

http://www.spamcop.net/sc?id=z1098619467z7...7cd9b7b6bddfc7z Shows an IP address of a spoof website and discards it as fake because "Cannot resolve". But that IP and website exists. You can enter it as a URL and display it. So why can't SpamCop resolve and report it?

I'm confused - the only IP addresses I see are for email services including that of the supposed spamsource serv4.domainnameregistrar.com.au ([66.98.128.84] helo=dnra.com.au). Incidentally that is nowhere as dodgy-looking as the next target, which the parser declines, adsl-70-141-16-86.dsl.sgnwmi.sbcglobal.net (HELO User) (70.141.16.86) however, in the absence of any explanation for domainnameregistrar.com.au supposedly relaying for that address I suppose the parser only did what it can do. But that is a digression. This is not apparently related to the spamvertized site for which I cannot see that the parser has suggested any IP or hosting address because, as you say, it "Cannot resolve".

Are you asking why the parser does not resolve www.rightreasons.com when your browser can dig it out of the string in the spam - http://www.google.com/url?sa=u&start=4....com/index.html ? My browser cannot resolve that either, not at this time, and even if it could the parser does not attempt to follow M$ and others past the limits of compliance and even if it did that it cannot allow as much time in resolution of each case as can an ordinary user. There is much prior discussion about this in these pages.

But your observation that www.rightreasons.com exists and you can or could get to it from the link offered will be of interest to programmers.

[Jeff G.]

Interestingly enough, http://www.dnsstuff.com/tools/dnstime.ch?n....com&type=A currently says "Searching for systms.com A record at J.GTLD-SERVERS.NET. Reports no A records (NXDOMAIN). 208ms." and "Sorry, I could not continue.", my local tools cannot find domain systms.com in DNS, and http://www.spamcop.net/sc?id=z1098619467z7...7cd9b7b6bddfc7z is now showing "Host systms.com (checking ip) IP not found ; systms.com discarded as fake." and "Cannot resolve http://systms.com/online/www.rightreasons....ndex.html". Ask your ISP why you can resolve systms.com, possibly including results of a dig or nslookup command sent to your ISP's nameservers.

OTOH, consider that eNom still has systms.com registered, and eNom's nameservers like dns1.name-services.com are still returning results as follows when queried with dig:

; <<>> DiG 9.2.3 <<>> [at]dns1.name-services.com systms.com

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5

;; QUESTION SECTION:

;systms.com. IN A

;; ANSWER SECTION:

systms.com. 1800 IN A 65.98.52.135

;; AUTHORITY SECTION:

systms.com. 3600 IN NS dns1.name-services.com.

systms.com. 3600 IN NS dns2.name-services.com.

systms.com. 3600 IN NS dns3.name-services.com.

systms.com. 3600 IN NS dns4.name-services.com.

systms.com. 3600 IN NS dns5.name-services.com.

;; ADDITIONAL SECTION:

dns1.name-services.com. 3600 IN A 69.25.142.1

dns2.name-services.com. 3600 IN A 216.52.184.230

dns3.name-services.com. 3600 IN A 63.251.92.193

dns4.name-services.com. 3600 IN A 64.74.96.242

dns5.name-services.com. 3600 IN A 70.42.37.1

;; Query time: 1231 msec

;; SERVER: 69.25.142.1#53(dns1.name-services.com)

;; WHEN: Tue Oct 10 21:47:32 2006

;; MSG SIZE rcvd: 263

[werwin]

Here's another interesting "Cannot Resolve" error.

SpamCop says this:

Tracking link: http://enzonewor.info/fars/friskyx.html?nf....cvprqvw,ss,hvx

No recent reports, no history available

Cannot resolve http://enzonewor.info/fars/friskyx.html?nf....cvprqvw,ss,hvx

Tracking link: http://enzonewor.info/un/unsub.php

No recent reports, no history available

Cannot resolve http://enzonewor.info/un/unsub.php

However, http://enzonewor.info resolves from my ISP account. So, upon digging deeper, I tried resolving the IP using DNSStuff.com (http://www.dnsstuff.com/tools/lookup.ch?name=enzonewor.info&type=A) However, their MAIN server could not resolve it.

So I thought, maybe the NS is blocking their servers. Let's use their less-known, backup server.

So, trying the resolve at http://backup.dnsstuff.com/tools/lookup.ch...info&type=A and it resolved (enzonewor.info. A IN 600 222.173.243.30)

Which makes me think. There have been other reports and other times when I have seen links not being able to resolve through SpamCop, but are able to resolve through my ISP. Could it be possible that the spammers are getting smarter and are blocking the IP addresses such as SpamCop, DNSStuff, etc from doing lookups?

How do you think we can resolve this problem?

[turetzsr]

Here's another interesting "Cannot Resolve" error.

<snip>

So, trying the resolve at http://backup.dnsstuff.com/tools/lookup.ch...info&type=A and it resolved (enzonewor.info. A IN 600 222.173.243.30)

<snip>

How do you think we can resolve this problem?

...No expert I, but:

1 148 ms 3 ms 3 ms <munged: internal>

2 4 ms 3 ms 3 ms <munged: internal>

3 35 ms 41 ms 41 ms <munged: internal>

4 35 ms 41 ms 41 ms <munged: internal>

5 42 ms 42 ms 41 ms <munged: internal>

6 41 ms 38 ms 36 ms <munged: internal>

7 42 ms 42 ms 40 ms <munged: internal>

8 37 ms 41 ms 40 ms <munged: internal>

9 37 ms 39 ms 42 ms 12.119.53.89

10 113 ms 103 ms 108 ms tbr2-p012401.phlpa.ip.att.net [12.123.137.206]

11 109 ms 109 ms 141 ms tbr2-cl3641.cgcil.ip.att.net [12.122.10.93]

12 114 ms 110 ms 109 ms tbr2-cl7.sl9mo.ip.att.net [12.122.10.46]

13 115 ms 116 ms 111 ms tbr2-cl21.la2ca.ip.att.net [12.122.10.14]

14 113 ms 110 ms 110 ms ggr2-p3120.la2ca.ip.att.net [12.123.222.29]

15 * 118 ms 117 ms p4-0.att.nwrknj01.us.bb.verio.net [192.205.32.242]

16 291 ms 302 ms 295 ms 202.97.51.117

17 290 ms 285 ms 288 ms 202.97.33.13

18 309 ms 310 ms 319 ms 202.97.39.6

19 313 ms 311 ms 313 ms 219.146.19.6

20 302 ms 303 ms 307 ms 219.146.19.94

21 308 ms 306 ms 313 ms 222.173.225.2

22 314 ms 318 ms 312 ms 222.173.225.62

23 319 ms 317 ms 312 ms 219.146.144.54

24 319 ms 313 ms 313 ms 222.173.243.30

Those long times (> 300 ms) leads me to believe that although you and I are waiting long enough for a reply, the SpamCop parser may not. And a good thing, too, or parses would take forever and/or the parsing server would choke.

...IOW, "we" (tinw) don't resolve the problem, especially since reporting links isn't the parser's principal purpose.

[werwin]

...No expert I, but:Those long times (< 300 ms) leads me to believe that although you and I are waiting long enough for a reply, the SpamCop parser may not. And a good thing, too, or parses would take forever and/or the parsing server would choke.

...IOW, "we" don't resolve the problem, especially since reporting links isn't the parser's principal purpose.

You're probably right about the timeout problem.

Searching for enzonewor.info A record at c.root-servers.net [192.33.4.12]: Got referral to E9.INFO.AFILIAS-NST.info. (zone: info.) [took 169 ms]

Searching for enzonewor.info A record at E9.INFO.AFILIAS-NST.info. [192.100.59.33]: Got referral to ns1.frontdragon.info. (zone: enzonewor.info.) [took 173 ms]

Searching for enzonewor.info A record at ns1.frontdragon.info. [201.231.109.16]: Reports enzonewor.info. [took 848 ms]

848ms for an NS lookup. I do think that URL's should be reported though, even if the NS lookup is 848ms because the administrators hosting the spammer need to shut the site down, and might be able to shut the site down before the ISP can shut down the spammer's email access.

Even though reporting links isn't the parser's main purpose, reporting URL's does serve a purpose, even at 848ms.

**Not sure about this**

I think the other thing that might be a problem is that if a domain has multiple nameservers, and one nameserver is down (timed out, etc), SpamCop doesn't check to see if the other nameservers listed can resolve the domain. As I said, I'm not quite sure on this one yet.

[agsteele]

Even though reporting links isn't the parser's main purpose, reporting URL's does serve a purpose, even at 848ms.

I'm one of those that isn't convinced that reporting URLs is effective. I've not seen evidence that many such websites get closed by the ISPs. But I agree there is a logic and purpose behind the process.

But that's not why I think I probably disagree with you here. I think 848ms is a very long time for a NS look up and would probably kill SpamCop. On balance there is good reason to drop these long duration look-ups to preserve the parser for those lookups that can be quickly completed.

Andrew

[turetzsr]

<snip>

Even though reporting links isn't the parser's main purpose, reporting URL's does serve a purpose, even at 848ms.

...Please don't hesitate to submit complaints manually once you've determined the proper abuse address. But I don't think it's fair to expect those of us who expect good service from the SpamCop parser in its principal purpose to have to wait for these long resolves.