Jump to content

Bad authority section in NXDOMAIN


peak

Recommended Posts

NXDOMAIN answers from bl.spamcop.net's nameservers include spamcop.net SOA in their authority sections. Here is an example:

$ dig 239.172.166.62.bl.spamcop.net txt [at]66.6.205.130 +norec +multiline

; <<>> DiG 9.2.1 <<>> 239.172.166.62.bl.spamcop.net txt [at]66.6.205.130 +norec +multiline

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7423

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

;; QUESTION SECTION:

;239.172.166.62.bl.spamcop.net. IN TXT

;; AUTHORITY SECTION:

spamcop.net. 0 IN SOA bl.spamcop.net. hostmaster.admin.spamcop.net. (

1095065330 ; serial

3600 ; refresh (1 hour)

1800 ; retry (30 minutes)

3600 ; expire (1 hour)

0 ; minimum (0 seconds)

)

;; Query time: 180 msec

;; SERVER: 66.6.205.130#53(66.6.205.130)

;; WHEN: Mon Sep 13 10:50:54 2004

;; MSG SIZE rcvd: 103

This is WRONG. bl's nameservers are not authoritative for spamcop.net.

This misbehaviour makes my BIND very unhappy and it generates tons of (slightly misleading) error messages reading "bad referral (spamcop.net !< bl.spamcop.NET) from [X.Y.Z.W].53".

Link to comment
Share on other sites

Hi,

i'm using the spamcop blacklist with a sendmail 8.12.11 with this setup:

define(`confBIND_OPTS', `WorkAroundBrokenAAAA')dnl

FEATURE(`enhdnsbl', `bl.spamcop.net', `"spam blocked: http://spamcop.net/bl.shtml?"$&{client_addr}', `t')dnl

These lines are taken from the FAQ and worked fine since the mailserver setup in june. There has been no config changes since then.

According to the server logs these entries case sendmail to return "reject=451 4.7.1 Temporary lookup failure of <ip> at bl.spamcop.net", rejecting any incoming mail. This started at 09/11 00:00 GMT (midnight). I had to remove the spamcop blacklist from sendmail to receive emails again.

Anyone an idea what's up with bl.spamcop.net?

Dr. Disaster

Link to comment
Share on other sites

Rushing thru some sendmail docs i found that removing the last parameter `t' from

FEATURE(`enhdnsbl', `bl.spamcop.net', `"spam blocked: http://spamcop.net/bl.shtml?"$&{client_addr}', `t')dnl

enables me to have bl.spamcop.net in the RBL-List without getting incoming mail rejected. It simply tells sendmail to ignore errors from bl.spamcop.net.

Nothing against a quick workaround but since everything was running fine for 3 months and now having to tweak sendmail makes me think that bl.spamcop.net behavior has somehow changed.

Any news anyone?

Dr. Disaster

Link to comment
Share on other sites

I actually feel like I'm doing something wrong here ... Ellen provided the following, referencing data provided by Julian ... It was referenced by someone else in a later newsgroup posting, and the discussion there led to Ellen stating that she shouldn't have posted this data to begin with. However, the only available answer to this query is what Ellen originally posted. So here's some data, take with the caveat that things are in progress and may have changed between the time of the query being posted and when you read this .....

-=-=-=-=-=-=-=-

> Sep 11 13:37:54 masterofthenet named[10643]: bad referral (spamcop.net !<

> bl.spamcop.net) from [209.92.188.201].53

I think this is the answer to your question, from Julian:

>"Thanks for bringing this up. We are migrating to a

>different dns server - rbldnsd. It allows us to add some new features,

>but I think the problem is due to the lack of an NS record returned with

>the query. We'll see what we can do about that (more complicated than it

>sounds)..

>

>In the meantime though, you could try upgrading bind or just disabling

>that message - it is not fatal, just a warning and in this case (and 99%

>of other cases) it does not indicate any real problem.

>

>Currently, only some of our mirrors are using the new system, so this

>may only show up sometimes - depending on which mirror your system decides

>to use. But we will gradually be migrating the whole set over."

Ellen

-=-=-=-=-=-=-=-

Link to comment
Share on other sites

NXDOMAIN answers from bl.spamcop.net's nameservers include spamcop.net SOA in their authority sections. Here is an example:

$ dig 239.172.166.62.bl.spamcop.net txt [at]66.6.205.130 +norec +multiline

; <<>> DiG 9.2.1 <<>> 239.172.166.62.bl.spamcop.net txt [at]66.6.205.130 +norec +multiline

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7423

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

;; QUESTION SECTION:

;239.172.166.62.bl.spamcop.net. IN TXT

;; AUTHORITY SECTION:

spamcop.net.  0 IN SOA bl.spamcop.net. hostmaster.admin.spamcop.net. (

    1095065330 ; serial

    3600    ; refresh (1 hour)

    1800    ; retry (30 minutes)

    3600    ; expire (1 hour)

    0          ; minimum (0 seconds)

    )

;; Query time: 180 msec

;; SERVER: 66.6.205.130#53(66.6.205.130)

;; WHEN: Mon Sep 13 10:50:54 2004

;; MSG SIZE  rcvd: 103

This is WRONG. bl's nameservers are not authoritative for spamcop.net.

This misbehaviour makes my BIND very unhappy and it generates tons of (slightly misleading) error messages reading "bad referral (spamcop.net !< bl.spamcop.NET) from [X.Y.Z.W].53".

16985[/snapback]

Yes they are working on this. It was/is an untintended consequence of transitioning the mirrors to use rbldnsd rather than rsync. And yes it makes BIND unhappy and generates those error messages for NXDOMAIN responses to queries.

And in answer to wazoo further down -- what I originally posted was what Julian thought was the problem but more investigation has been done and the cause of the problem is more complicated. Or in other words the Friday information has been replaced with the Sunday nite/Monday information :-)

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...