Jump to content
Sign in to follow this  
Pistol Pete

Spam mail

Recommended Posts

I have been a user of spamcop for some time, over the last 2 weeks I've noticed bl.spamcop.net is not blocking any spam mail at all. Any reason for this? <_<

Share this post


Link to post
Share on other sites

Assuming you have control over the system that is filtering your mail, from that system could you please try to get the following info and report back here?

  • The IP Addresses of the nameservers that system is using
  • The results of "dig bl.spamcop.net", including the NS and SOA dns records
  • The results of nslookup and dig on 2.0.0.127.bl.spamcop.net

You can also try having that system do its own lookups, especially if that system is doing lookups via AT&T nameservers. This worked for someone else with the same problem recently.

Share this post


Link to post
Share on other sites

Assuming you have control over the system that is filtering your mail, from that system could you please try to get the following info and report back here?

The IP Addresses of the nameservers that system is using

The results of "dig bl.spamcop.net", including the NS and SOA dns records

The results of nslookup and dig on 2.0.0.127.bl.spamcop.net

You can also try having that system do its own lookups, especially if that system is doing lookups via AT&T nameservers. This worked for someone else with the same problem recently.

Nameservers being used are 12.127.16.67, 12.127.17.71 (both ATT)

I have tried using different name servers with the same results.

I am not familiar with dig but I did try running nslookup on 2.0.0.127.bl.spamcop.net and this is what I got back.

C:\>nslookup 2.0.0.127.bl.spamcop.net

DNS request timed out.

timeout was 2 seconds.

*** Can't find server name for address 12.127.16.67: Timed out

*** Can't find server name for address 192.168.10.5: Non-existent domain

Server: dns-rs1.bgtmo.ip.att.net

Address: 12.127.17.71

*** dns-rs1.bgtmo.ip.att.net can't find 2.0.0.127.bl.spamcop.net: Non-existent d

omain

Also got this back

C:\>nslookup bl.spamcop.net

Server: rmtu.mt.rs.els-gms.att.net

Address: 12.127.16.67

Name: bl.spamcop.net

C:\>nslookup -q=soa bl.spamcop.net

Server: rmtu.mt.rs.els-gms.att.net

Address: 12.127.16.67

DNS request timed out.

timeout was 2 seconds.

bl.spamcop.net

primary name server = loopback

responsible mail addr = root.loopback

serial = 1

refresh = 3600 (1 hour)

retry = 600 (10 mins)

expire = 3600000 (41 days 16 hours)

default TTL = 86400 (1 day)

bl.spamcop.net nameserver = loopback

loopback internet address = 127.0.0.1

Share this post


Link to post
Share on other sites

In this case (AT&T appearing to sabotage their customers' use of the SCBL via bl.spamcop.net), I would try asking AT&T, having that server do its own nameservice, or using one or more other nameservers.

Share this post


Link to post
Share on other sites
Can you recomend a name servers I can use which does not have a problem with bl.spamcop.net?

Well, I can't recommend that you use any nameservers which you're not actually authorized to use. However, I think you'll find that lots of big ISP's leave their nameservers open to the world for recursive queries. (They shouldn't, but that's another issue). So, you can probably hunt around for ns.bigisp.com and find one that accepts your queries pretty easily.

JT

Share this post


Link to post
Share on other sites

Also I made a mistake on the name servers they are

nameserver = dmtu.mt.ns.els-gms.att.net

nameserver = dbru.br.ns.els-gms.att.net

nameserver = cbru.br.ns.els-gms.att.net

Share this post


Link to post
Share on other sites

These other AT&T nameservers don't appear to have the same problem:

KCGW1.att.com (192.128.133.77)

CKGW1.att.com (209.219.209.77)

ALGW1.att.com (192.128.167.77)

Share this post


Link to post
Share on other sites

I have been using bl.spamcop.net for some time. Within the last 2-3 weeks I have not received any results. I have tried changes name servers and I still do not receive any lookups against bl.spamcop.net. Can you make any suggestions?

Share this post


Link to post
Share on other sites
I have been using bl.spamcop.net for some time. Within the last 2-3 weeks I have not received any results. I have tried changes name servers and I still do not receive any lookups against bl.spamcop.net. Can you make any suggestions?

Not without some kind of additional data. What e-mail app are you running? What command strings have you invoked? How about some clips from the server logs to see what's happening?

I could make an asumption that you just might be talking about filter selections in your SpamCop e-mail account, as this is where you posted, but in trying to do that, I get confused over your "changed name servers" and "not recieved any results" ... So I'd rather guess that you mis-posted this into a wrong forum, but ????

Only you can fill in the details.

Share this post


Link to post
Share on other sites

Pistol Pete,

Your new Topic had nothing to do with SpamCop Email, so I merged it in with your previous Topic discussing the same problem.

Did you switch to the nameservers I suggested above?

If you did, can you please repeat your testing with nslookup and ask AT&T why you're not getting the full internet access you're paying for?

If you didn't, why not?

Thanks!

Edited by JeffG

Share this post


Link to post
Share on other sites
Assuming you have control over the system that is filtering your mail, from that system could you please try to get the following info and report back here?

The IP Addresses of the nameservers that system is using

The results of "dig bl.spamcop.net", including the NS and SOA dns records

The results of nslookup and dig on 2.0.0.127.bl.spamcop.net

You can also try having that system do its own lookups, especially if that system is doing lookups via AT&T nameservers. This worked for someone else with the same problem recently.

Nameservers being used are 12.127.16.67, 12.127.17.71 (both ATT)

I have tried using different name servers with the same results.

I am not familiar with dig but I did try running nslookup on 2.0.0.127.bl.spamcop.net and this is what I got back.

C:\>nslookup 2.0.0.127.bl.spamcop.net

DNS request timed out.

    timeout was 2 seconds.

*** Can't find server name for address 12.127.16.67: Timed out

*** Can't find server name for address 192.168.10.5: Non-existent domain

Server:  dns-rs1.bgtmo.ip.att.net

Address:  12.127.17.71

*** dns-rs1.bgtmo.ip.att.net can't find 2.0.0.127.bl.spamcop.net: Non-existent d

omain

Also got this back

C:\>nslookup bl.spamcop.net

Server:  rmtu.mt.rs.els-gms.att.net

Address:  12.127.16.67

Name:    bl.spamcop.net

C:\>nslookup -q=soa bl.spamcop.net

Server:  rmtu.mt.rs.els-gms.att.net

Address:  12.127.16.67

DNS request timed out.

    timeout was 2 seconds.

bl.spamcop.net

        primary name server = loopback

        responsible mail addr = root.loopback

        serial  = 1

        refresh = 3600 (1 hour)

        retry = 600 (10 mins)

        expire  = 3600000 (41 days 16 hours)

        default TTL = 86400 (1 day)

bl.spamcop.net  nameserver = loopback

loopback        internet address = 127.0.0.1

I do a dig using Spade and this is the result.

02/11/04 15:18:27 dig bl.spamcop.net [at] 10.28.1.1

Dig bl.spamcop.net[at]blns12.spamcop.net (216.127.43.91) ...

failed, couldn't connect to nameserver

Dig bl.spamcop.net[at]blns15.spamcop.net (207.152.133.2) ...

failed, couldn't connect to nameserver

Dig bl.spamcop.net[at]blns18.spamcop.net (69.93.117.162) ...

failed, couldn't connect to nameserver

Dig bl.spamcop.net[at]blns8.spamcop.net (66.6.205.130) ...

failed, couldn't connect to nameserver

Dig bl.spamcop.net[at]blns6.spamcop.net (209.198.142.147) ...

failed, couldn't connect to nameserver

Dig bl.spamcop.net[at]blns9.spamcop.net (208.39.222.110) ...

failed, couldn't connect to nameserver

Dig bl.spamcop.net[at]blns11.spamcop.net (209.92.188.201) ...

failed, couldn't connect to nameserver

Dig bl.spamcop.net[at]blns4.spamcop.net (194.109.6.147) ...

failed, couldn't connect to nameserver

Dig bl.spamcop.net[at]10.28.1.1 ...

Non-authoritative answer

Query for bl.spamcop.net type=255 class=1

  bl.spamcop.net NS (Nameserver) blns16.spamcop.net

  bl.spamcop.net NS (Nameserver) blns15.spamcop.net

  bl.spamcop.net NS (Nameserver) blns10.spamcop.net

  bl.spamcop.net NS (Nameserver) blns8.spamcop.net

  bl.spamcop.net NS (Nameserver) blns17.spamcop.net

  bl.spamcop.net NS (Nameserver) blns11.spamcop.net

  bl.spamcop.net NS (Nameserver) blns5.spamcop.net

  bl.spamcop.net NS (Nameserver) blns13.spamcop.net

  blns16.spamcop.net A (Address) 193.136.29.17

  blns15.spamcop.net A (Address) 207.152.133.2

  blns10.spamcop.net A (Address) 206.67.234.112

  blns8.spamcop.net A (Address) 66.6.205.130

  blns17.spamcop.net A (Address) 204.108.129.10

  blns11.spamcop.net A (Address) 209.92.188.201

  blns5.spamcop.net A (Address) 198.145.240.35

  blns13.spamcop.net A (Address) 65.75.147.150

Share this post


Link to post
Share on other sites

but when I do a whois command .. i get this result

whois bl.spamcop.net

.net is a domain of Network services

Searches for .net can be run at http://www.crsnic.net/

whois -h whois.crsnic.net spamcop.net ...

Whois Server Version 1.3

Domain names in the .com and .net domains can now be registered

with many different competing registrars. Go to http://www.internic.net

for detailed information.

Domain Name: SPAMCOP.NET

Registrar: ENOM, INC.

Whois Server: whois.enom.com

Referral URL: http://www.enom.com

Name Server: USE1.AKAM.NET

Name Server: NS1-93.AKAM.NET

Name Server: NS1-11.AKAM.NET

Name Server: NS1-73.AKAM.NET

Name Server: NS1-90.AKAM.NET

Name Server: NS1-109.AKAM.NET

Name Server: NS1-117.AKAM.NET

Name Server: ASIA3.AKAM.NET

Status: REGISTRAR-LOCK

Updated Date: 10-jan-2004

Creation Date: 30-jan-1999

Expiration Date: 30-jan-2006

Redirecting to ENOM, INC.

whois -h whois.enom.com spamcop.net ...

Domain not found.

:blink::blink:

Share this post


Link to post
Share on other sites

The results of nslookup and dig on 2.0.0.127.bl.spamcop.net

is

[root[at]smtp log]# nslookup 2.0.0.127.bl.spamcop.net

Note:  nslookup is deprecated and may be removed from future releases.

Consider using the `dig' or `host' programs instead.  Run nslookup with

the `-sil[ent]' option to prevent this message from appearing.

Server:      165.21.83.88

Address:        165.21.83.88#53

Non-authoritative answer:

Name: 2.0.0.127.bl.spamcop.net

Address: 127.0.0.2

and

[root[at]smtp log]# dig 2.0.0.127.bl.spamcop.net

; <<>> DiG 9.2.1 <<>> 2.0.0.127.bl.spamcop.net

;; global options:  printcmd

;; Got answer:

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

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 8

;; QUESTION SECTION:

;2.0.0.127.bl.spamcop.net.      IN      A

;; ANSWER SECTION:

2.0.0.127.bl.spamcop.net. 2048  IN      A    127.0.0.2

;; AUTHORITY SECTION:

bl.spamcop.net.      5873    IN      NS      blns15.spamcop.net.

bl.spamcop.net.      5873    IN      NS      blns17.spamcop.net.

bl.spamcop.net.      5873    IN      NS      blns18.spamcop.net.

bl.spamcop.net.      5873    IN      NS      blns4.spamcop.net.

bl.spamcop.net.      5873    IN      NS      blns5.spamcop.net.

bl.spamcop.net.      5873    IN      NS      blns6.spamcop.net.

bl.spamcop.net.      5873    IN      NS      blns8.spamcop.net.

bl.spamcop.net.      5873    IN      NS      blns10.spamcop.net.

;; ADDITIONAL SECTION:

blns4.spamcop.net.      13094 IN      A    194.109.6.147

blns5.spamcop.net.      11420 IN      A    198.145.240.35

blns6.spamcop.net.      12343 IN      A    209.198.142.147

blns8.spamcop.net.      15797 IN      A    66.6.205.130

blns10.spamcop.net.  11698 IN      A    206.67.234.112

blns15.spamcop.net.  11964 IN      A    207.152.133.2

blns17.spamcop.net.  6523    IN      A    204.108.129.10

blns18.spamcop.net.  6523    IN      A    69.93.117.162

;; Query time: 306 msec

;; SERVER: 165.21.83.88#53(165.21.83.88)

;; WHEN: Wed Feb 11 15:57:15 2004

;; MSG SIZE  rcvd: 350

Share this post


Link to post
Share on other sites
I do a dig using Spade and this is the result.

02/11/04 15:18:27 dig bl.spamcop.net [at] 10.28.1.1

Dig bl.spamcop.net[at]blns12.spamcop.net (216.127.43.91) ...

failed, couldn't connect to nameserver

Dig bl.spamcop.net[at]blns15.spamcop.net (207.152.133.2) ...

failed, couldn't connect to nameserver

Dig bl.spamcop.net[at]blns18.spamcop.net (69.93.117.162) ...

failed, couldn't connect to nameserver

Dig bl.spamcop.net[at]blns8.spamcop.net (66.6.205.130) ...

failed, couldn't connect to nameserver

Dig bl.spamcop.net[at]blns6.spamcop.net (209.198.142.147) ...

failed, couldn't connect to nameserver

Dig bl.spamcop.net[at]blns9.spamcop.net (208.39.222.110) ...

failed, couldn't connect to nameserver

Dig bl.spamcop.net[at]blns11.spamcop.net (209.92.188.201) ...

failed, couldn't connect to nameserver

Dig bl.spamcop.net[at]blns4.spamcop.net (194.109.6.147) ...

failed, couldn't connect to nameserver

Dig bl.spamcop.net[at]10.28.1.1 ...

Non-authoritative answer

Query for bl.spamcop.net type=255 class=1

  bl.spamcop.net NS (Nameserver) blns16.spamcop.net

  bl.spamcop.net NS (Nameserver) blns15.spamcop.net

  bl.spamcop.net NS (Nameserver) blns10.spamcop.net

  bl.spamcop.net NS (Nameserver) blns8.spamcop.net

  bl.spamcop.net NS (Nameserver) blns17.spamcop.net

  bl.spamcop.net NS (Nameserver) blns11.spamcop.net

  bl.spamcop.net NS (Nameserver) blns5.spamcop.net

  bl.spamcop.net NS (Nameserver) blns13.spamcop.net

  blns16.spamcop.net A (Address) 193.136.29.17

  blns15.spamcop.net A (Address) 207.152.133.2

  blns10.spamcop.net A (Address) 206.67.234.112

  blns8.spamcop.net A (Address) 66.6.205.130

  blns17.spamcop.net A (Address) 204.108.129.10

  blns11.spamcop.net A (Address) 209.92.188.201

  blns5.spamcop.net A (Address) 198.145.240.35

  blns13.spamcop.net A (Address) 65.75.147.150

This is because the five year old Sam Spade (Beta) Version 1.14 [for Windows] does not support UDP server port 53 lookups and SpamCop's and Akamai's nameservers do not support TCP server port 53 lookups.

Sam Spade, SpamCop's Name Servers, and Akamai's Name Servers should all support both UDP and TCP server port 53 lookups, per the following paragraph from Internet Standard 13, RFC 1035, "Domain Implementation and Specification", Section 4.2, Page 32, as represented online at http://www.rfc-editor.org/rfc/std/std13.txt and http://www.rfc-editor.org/rfc/rfc1035.txt

The Internet supports name server access using TCP [RFC-793] on server

port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP

port 53 (decimal).

Edited by JeffG

Share this post


Link to post
Share on other sites

Oh my god .. i am using this Spade tool for 5 years already :P

let me do a dig on the Linux machine and show the result here again.

cause i do

grep "relay_check" maillog

on my Linux machine (Sendmail) and doesn't have this log information.

Share this post


Link to post
Share on other sites

the result i get is

[root[at]smtp log]# dig bl.spamcop.net

; <<>> DiG 9.2.1 <<>> bl.spamcop.net

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54733

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;bl.spamcop.net.                        IN      A

;; Query time: 2157 msec

;; SERVER: 165.21.83.88#53(165.21.83.88)

;; WHEN: Wed Feb 11 22:48:13 2004

;; MSG SIZE  rcvd: 32

and

[root[at]smtp log]# dig [at]10.28.1.1 bl.spamcop.net

; <<>> DiG 9.2.1 <<>> [at]10.28.1.1 bl.spamcop.net

;; global options:  printcmd

;; connection timed out; no servers could be reached

[root[at]smtp log]#

Share this post


Link to post
Share on other sites
Sam Spade, SpamCop's Name Servers, and Akamai's Name Servers should all support both UDP and TCP server port 53 lookups, per the following paragraph from Internet Standard 13, RFC 1035, "Domain Implementation and Specification", Section 4.2, Page 32, as represented online at http://www.rfc-editor.org/rfc/std/std13.txt and http://www.rfc-editor.org/rfc/rfc1035.txt
The Internet supports name server access using TCP [RFC-793] on server

port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP

port 53 (decimal).

Well, you can't always make declarations like that based on a cursory reading of a 16-year-old RFC. In fact, the internet does support both TCP and UDP DNS, but that standard doesn't say that any particular server must support both.

Look at RFC1123 and you'll find the following text:

DNS servers MUST be able to service UDP queries and SHOULD be able to service TCP queries.

So, you can see that the DNS servers that SpamCop (and the rest of the blacklists) use obey the letter of that spec. Yes, they don't obey a SHOULD clause but that's because of the special nature of DNSBL lookups. Both specs agree that UDP lookups are preferred. TCP lookups are required when the answer set is greater than 512 bytes. However, in the case of DNSBL lookups, we know a priori that the results of the lookups will be small. Generally, only a single IP address is returned (or NXDOMAIN). Because of that, the two common RBL DNS daemons both support only UDP queries.

JT

Share this post


Link to post
Share on other sites

"Domain Implementation and Specification" is not just an RFC, it's an Internet Standard.

In addition, in the discussion after the text you quoted from Internet Standard 3, RFC 1123, "Requirements for Internet Hosts -- Communication Layers", Section 6.1.3.2, Page 75, as represented online at http://www.rfc-editor.org/rfc/std/std3.txt and http://www.rfc-editor.org/rfc/rfc1123.txt , occurs the following paragraph on Page 76:

              However, it is also clear that some new DNS record

              types defined in the future will contain information

              exceeding the 512 byte limit that applies to UDP, and

              hence will require TCP.  Thus, resolvers and name

              servers should implement TCP services as a backup to

              UDP today, with the knowledge that they will require

              the TCP service in the future.

Share this post


Link to post
Share on other sites
"Domain Implementation and Specification" is not just an RFC, it's an Internet Standard.

In addition, in the discussion after the text you quoted from Internet Standard 3, RFC 1123, "Requirements for Internet Hosts -- Communication Layers", Section 6.1.3.2, Page 75, as represented online at http://www.rfc-editor.org/rfc/std/std3.txt and http://www.rfc-editor.org/rfc/rfc1123.txt , occurs the following paragraph on Page 76:

                 However, it is also clear that some new DNS record

                 types defined in the future will contain information

                 exceeding the 512 byte limit that applies to UDP, and

                 hence will require TCP.  Thus, resolvers and name

                 servers should implement TCP services as a backup to

                 UDP today, with the knowledge that they will require

                 the TCP service in the future.

errr ... from a technical question to Internet Standard ... guess have a little bit out of topics.

Can we stay on the same issue on solving the "dig" and nslookup ?

Share this post


Link to post
Share on other sites
"Domain Implementation and Specification" is not just an RFC, it's an Internet Standard.

In addition, in the discussion after the text you quoted from Internet Standard 3, RFC 1123, "Requirements for Internet Hosts -- Communication Layers", Section 6.1.3.2, Page 75, as represented online at http://www.rfc-editor.org/rfc/std/std3.txt and http://www.rfc-editor.org/rfc/rfc1123.txt , occurs the following paragraph on Page 76:

              However, it is also clear that some new DNS record

              types defined in the future will contain information

              exceeding the 512 byte limit that applies to UDP, and

              hence will require TCP.  Thus, resolvers and name

              servers should implement TCP services as a backup to

              UDP today, with the knowledge that they will require

              the TCP service in the future.

Well, you do understand the difference between "SHOULD" and "MUST" in internet RFC's I assume. MUST is a requirement. SHOULD is a recommendation.

In any case, the additional text you're talking about refers to mythical large records which will be over 512 bytes long. But the DNS servers which implement the RBL's are not general-purpose servers. They are deployed to serve two specific records: A records and short TXT records. They people who deploy these servers know, in advance, exactly what kinds of records they will be serving and how long they will be. There's no need to make the software more complicated just to satisfy a recommendation that doesn't really apply to them anyway.

JT

Share this post


Link to post
Share on other sites

Err rr ... ok ... then I need to read up more and ask my vendor to do something ... thanks for the info and reminder.

:(

Share this post


Link to post
Share on other sites
the result i get is

[root[at]smtp log]# dig bl.spamcop.net

; <<>> DiG 9.2.1 <<>> bl.spamcop.net

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54733

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;bl.spamcop.net.                        IN      A

;; Query time: 2157 msec

;; SERVER: 165.21.83.88#53(165.21.83.88)

;; WHEN: Wed Feb 11 22:48:13 2004

;; MSG SIZE  rcvd: 32

and

[root[at]smtp log]# dig [at]10.28.1.1 bl.spamcop.net

; <<>> DiG 9.2.1 <<>> [at]10.28.1.1 bl.spamcop.net

;; global options:  printcmd

;; connection timed out; no servers could be reached

[root[at]smtp log]#

Your dig assumes that there is an A record for bl.spamcop.net, but there isn't.

If you really want to debug this, dig for the NS records for bl.spamcop.net at each of the NS records published for spamcop.net. It's a hierarchial thing:

dig [at]c.gtld-servers.net bl.spamcop.net NS

then you see that one nameserver, for instance, is use1.akam.net

dig [at]use1.akam.net bl.spamcop.net NS

There, you see that one of the nameservers for bl.spamcop.net is blns6.spamcop.net

dig [at]blns6.spamcop.net 2.0.0.127.bl.spamcop.net

and you'll see that you get a response.

If a dig at your own nameservers doesn't give the same response, you'll need to debug them. We do know, though, that AT&T is returning bogus records for the bl.spamcop.net nameservers and so is blocking all bl.spamcop.net lookups if you try to use their nameservers.

JT

Share this post


Link to post
Share on other sites
Your dig assumes that there is an A record for bl.spamcop.net, but there isn't.

If you really want to debug this, dig for the NS records for bl.spamcop.net at each of the NS records published for spamcop.net. It's a hierarchial thing:

dig [at]c.gtld-servers.net bl.spamcop.net NS

then you see that one nameserver, for instance, is use1.akam.net

dig [at]use1.akam.net bl.spamcop.net NS

There, you see that one of the nameservers for bl.spamcop.net is blns6.spamcop.net

dig [at]blns6.spamcop.net 2.0.0.127.bl.spamcop.net

and you'll see that you get a response.

If a dig at your own nameservers doesn't give the same response, you'll need to debug them. We do know, though, that AT&T is returning bogus records for the bl.spamcop.net nameservers and so is blocking all bl.spamcop.net lookups if you try to use their nameservers.

JT

First dig

; <<>> DiG 9.2.1 <<>> [at]c.gtld-servers.net bl.spamcop.net NS

;; global options:  printcmd

;; Got answer:

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

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 8

;; QUESTION SECTION:

;bl.spamcop.net.                        IN      NS

;; AUTHORITY SECTION:

spamcop.net.            172800  IN      NS      asia3.akam.net.

spamcop.net.            172800  IN      NS      ns1-109.akam.net.

spamcop.net.            172800  IN      NS      ns1-11.akam.net.

spamcop.net.            172800  IN      NS      ns1-117.akam.net.

spamcop.net.            172800  IN      NS      ns1-73.akam.net.

spamcop.net.            172800  IN      NS      ns1-90.akam.net.

spamcop.net.            172800  IN      NS      ns1-93.akam.net.

spamcop.net.            172800  IN      NS      use1.akam.net.

;; ADDITIONAL SECTION:

asia3.akam.net.      172800  IN      A    193.108.154.9

ns1-109.akam.net.    172800  IN      A    193.108.91.109

ns1-11.akam.net.        172800  IN      A    193.108.91.11

ns1-117.akam.net.    172800  IN      A    193.108.91.117

ns1-73.akam.net.        172800  IN      A    193.108.91.73

ns1-90.akam.net.        172800  IN      A    193.108.91.90

ns1-93.akam.net.        172800  IN      A    193.108.91.93

use1.akam.net.          172800  IN      A    63.209.170.136

;; Query time: 288 msec

;; SERVER: 192.26.92.30#53(c.gtld-servers.net)

;; WHEN: Fri Feb 13 10:42:25 2004

;; MSG SIZE  rcvd: 332

second dig.

[root[at]smtp log]# dig [at]asia3.akam.net bl.spamcop.net NS

; <<>> DiG 9.2.1 <<>> [at]asia3.akam.net bl.spamcop.net NS

;; global options:  printcmd

;; Got answer:

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

;; flags: qr rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 8

;; QUESTION SECTION:

;bl.spamcop.net.                        IN      NS

;; ANSWER SECTION:

bl.spamcop.net.      172800  IN      NS      blns13.spamcop.net.

bl.spamcop.net.      172800  IN      NS      blns14.spamcop.net.

bl.spamcop.net.      172800  IN      NS      blns16.spamcop.net.

bl.spamcop.net.      172800  IN      NS      blns4.spamcop.net.

bl.spamcop.net.      172800  IN      NS      blns18.spamcop.net.

bl.spamcop.net.      172800  IN      NS      blns17.spamcop.net.

bl.spamcop.net.      172800  IN      NS      blns10.spamcop.net.

bl.spamcop.net.      172800  IN      NS      blns11.spamcop.net.

;; ADDITIONAL SECTION:

blns13.spamcop.net.  172800  IN      A    65.75.147.150

blns14.spamcop.net.  172800  IN      A    63.246.133.50

blns16.spamcop.net.  172800  IN      A    193.136.29.17

blns4.spamcop.net.      172800  IN      A    194.109.6.147

blns18.spamcop.net.  172800  IN      A    69.93.117.162

blns17.spamcop.net.  172800  IN      A    204.108.129.10

blns10.spamcop.net.  172800  IN      A    206.67.234.112

blns11.spamcop.net.  172800  IN      A    209.92.188.201

;; Query time: 139 msec

;; SERVER: 193.108.154.9#53(asia3.akam.net)

;; WHEN: Fri Feb 13 10:43:38 2004

;; MSG SIZE  rcvd: 338

and then third dig

[root[at]smtp log]# dig [at]blns10.spamcop.net bl.spamcop.net NS

; <<>> DiG 9.2.1 <<>> [at]blns10.spamcop.net bl.spamcop.net NS

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 1573

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;bl.spamcop.net.                        IN      NS

;; Query time: 273 msec

;; SERVER: 206.67.234.112#53(blns10.spamcop.net)

;; WHEN: Fri Feb 13 10:45:56 2004

;; MSG SIZE  rcvd: 32

why they refuse us ???

Let me get my vendors for help. :wacko::wacko::blink:

Share this post


Link to post
Share on other sites

[root[at]smtp log]# dig [at]blns10.spamcop.net bl.spamcop.net NS

; <<>> DiG 9.2.1 <<>> [at]blns10.spamcop.net bl.spamcop.net NS

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 1573

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;bl.spamcop.net.                        IN      NS

;; Query time: 273 msec

;; SERVER: 206.67.234.112#53(blns10.spamcop.net)

;; WHEN: Fri Feb 13 10:45:56 2004

;; MSG SIZE  rcvd: 32

why they refuse us ???

Let me get my vendors for help. :wacko::wacko::blink:

You don't need to ask blns10.spamcop.net what the NS records for bl.spamcop.net are. You were already told those by the nameservers for spamcop.net.

In fact, no resolver actually queries for NS records. It will actually be querying for A records. So, repeat the tests like this:

dig [at]c.gtld-servers.net 2.0.0.127.bl.spamcop.net

this will return a referral to the spamcop.net nameservers

then, dig [at]use1.akam.net 2.0.0.127.bl.spamcop.net

this will return a referral to the bl.spamcop.net nameservers

then, dig [at]blns10.spamcop.net 2.0.0.127.bl.spamcop.net

and, you'll see the correct answer.

Trust me, the bl.spamcop.net nameservers are working fine.

JT

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×