Pistol Pete Posted February 6, 2004 Posted February 6, 2004 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?
Jeff G. Posted February 6, 2004 Posted February 6, 2004 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.
Pistol Pete Posted February 6, 2004 Author Posted February 6, 2004 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
Jeff G. Posted February 6, 2004 Posted February 6, 2004 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.
Pistol Pete Posted February 6, 2004 Author Posted February 6, 2004 Can you recomend a name servers I can use which does not have a problem with bl.spamcop.net?
jefft Posted February 6, 2004 Posted February 6, 2004 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
Pistol Pete Posted February 6, 2004 Author Posted February 6, 2004 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
Jeff G. Posted February 6, 2004 Posted February 6, 2004 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)
Pistol Pete Posted February 10, 2004 Author Posted February 10, 2004 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?
Wazoo Posted February 10, 2004 Posted February 10, 2004 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.
Jeff G. Posted February 10, 2004 Posted February 10, 2004 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!
ahnah Posted February 11, 2004 Posted February 11, 2004 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
ahnah Posted February 11, 2004 Posted February 11, 2004 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.
ahnah Posted February 11, 2004 Posted February 11, 2004 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
Jeff G. Posted February 11, 2004 Posted February 11, 2004 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).
ahnah Posted February 11, 2004 Posted February 11, 2004 Oh my god .. i am using this Spade tool for 5 years already 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.
ahnah Posted February 11, 2004 Posted February 11, 2004 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]#
jefft Posted February 11, 2004 Posted February 11, 2004 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.txtThe 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
Jeff G. Posted February 11, 2004 Posted February 11, 2004 "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.
ahnah Posted February 12, 2004 Posted February 12, 2004 "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 ?
jefft Posted February 12, 2004 Posted February 12, 2004 "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
ahnah Posted February 12, 2004 Posted February 12, 2004 Err rr ... ok ... then I need to read up more and ask my vendor to do something ... thanks for the info and reminder.
jefft Posted February 12, 2004 Posted February 12, 2004 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
ahnah Posted February 13, 2004 Posted February 13, 2004 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.
jefft Posted February 13, 2004 Posted February 13, 2004 [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. 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
Recommended Posts
Archived
This topic is now archived and is closed to further replies.