FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 04-15-2010, 12:36 AM
 
Default Apparent BIND problem doing RBL lookups for Postfix

My apologies if I'm posting the wrong place, or am asking a common
question. All my looking so far hasn't turned up anything very useful
in knowing what to look at, or what to modify.

---
CentOS 5, running BIND 9.3.6
i386

Hardware:
P4, 2.8Ghz, 1G memory
Sata drives - non mirrored etc.

Load is light, usually under 0.1

--
This box is running Postfix as our mail server. BIND (9.3.6) [Latest.]

--
Problem:
Postfix is doing RBL lookups on zen.spamhaus.org.
Everything goes along groovy - but then lookups start failing.

Early in the process, we get stuff like this: [We have a "successful"
lookup, and then a failure...]
---
Apr 14 14:25:05 mail postfix/smtpd[22281]: NOQUEUE: reject: RCPT from bzq-79-183-5-119.red.bezeqint.net[79.183.5.119]: 554 5.7.1 Service unavailable; Client host [79.183.5.119] blocked using zen.spamhaus.org; from=<contriveclaudia@royalmoore.com> to=<contriveclaudia@royalmoore.com> proto=SMTP helo=<bzq-79-183-5-119.red.bezeqint.net>

Apr 14 14:25:07 mail postfix/smtpd[22804]: warning: 33.229.242.205.zen.spamhaus.org: RBL lookup error: Host or domain name not found. Name service error for name=33.229.242.205.zen.spamhaus.org type=A: Host not found, try again
---
As you can see, we had a lookup succeed and then just right after, one fail - claiming it got no answer from BIND. I get others after this that SUCCEED - so it's not in 100% failure mode yet.
After time [how much, I don't know] eventually all the zen queries
[or most all] fail.

A bind restart fixes the problem. [Hmmm...]

---
I do some logging in bind, and I don't see any reason for them to fail. Here's a bind debug log of 5 on that failure above.

---
14-Apr-2010 14:24:57.654 queries: info: client 127.0.0.1#42018: query: 33.229.242.205.zen.spamhaus.org IN A +
14-Apr-2010 14:24:57.654 security: debug 3: client 127.0.0.1#42018: query (cache) '33.229.242.205.zen.spamhaus.org/A/IN' approved
14-Apr-2010 14:24:57.654 resolver: debug 1: createfetch: 33.229.242.205.zen.spamhaus.org A
14-Apr-2010 14:24:57.654 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): create
14-Apr-2010 14:24:57.654 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): join
14-Apr-2010 14:24:57.654 resolver: debug 3: fetch 0x94a0b20 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): created
14-Apr-2010 14:24:57.655 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): start
14-Apr-2010 14:24:57.655 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
14-Apr-2010 14:24:57.655 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelqueries
14-Apr-2010 14:24:57.655 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): getaddresses
14-Apr-2010 14:24:57.655 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
14-Apr-2010 14:24:57.655 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
14-Apr-2010 14:24:57.655 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
14-Apr-2010 14:24:57.655 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
14-Apr-2010 14:24:57.655 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
14-Apr-2010 14:24:59.657 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
14-Apr-2010 14:24:59.657 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
14-Apr-2010 14:24:59.657 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
14-Apr-2010 14:24:59.657 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
14-Apr-2010 14:24:59.657 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
14-Apr-2010 14:24:59.657 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
14-Apr-2010 14:24:59.657 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
14-Apr-2010 14:24:59.657 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
14-Apr-2010 14:25:01.658 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
14-Apr-2010 14:25:01.658 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
14-Apr-2010 14:25:01.658 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
14-Apr-2010 14:25:01.658 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
14-Apr-2010 14:25:01.658 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
14-Apr-2010 14:25:01.659 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
14-Apr-2010 14:25:01.659 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
14-Apr-2010 14:25:01.659 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
14-Apr-2010 14:25:02.653 queries: info: client 127.0.0.1#42018: query: 33.229.242.205.zen.spamhaus.org IN A +
14-Apr-2010 14:25:02.653 security: debug 3: client 127.0.0.1#42018: query (cache) '33.229.242.205.zen.spamhaus.org/A/IN' approved
14-Apr-2010 14:25:02.654 resolver: debug 1: createfetch: 33.229.242.205.zen.spamhaus.org A
14-Apr-2010 14:25:02.654 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): join
14-Apr-2010 14:25:02.654 resolver: debug 3: fetch 0x94d54c8 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): created
14-Apr-2010 14:25:03.660 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
14-Apr-2010 14:25:03.660 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
14-Apr-2010 14:25:03.660 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
14-Apr-2010 14:25:03.660 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
14-Apr-2010 14:25:03.660 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
14-Apr-2010 14:25:03.660 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
14-Apr-2010 14:25:03.660 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
14-Apr-2010 14:25:03.660 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
14-Apr-2010 14:25:03.660 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
14-Apr-2010 14:25:05.663 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
14-Apr-2010 14:25:05.663 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
14-Apr-2010 14:25:05.663 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
14-Apr-2010 14:25:05.663 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
14-Apr-2010 14:25:05.663 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
14-Apr-2010 14:25:05.663 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
14-Apr-2010 14:25:05.663 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
14-Apr-2010 14:25:05.663 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
14-Apr-2010 14:25:05.663 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
14-Apr-2010 14:25:07.664 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
14-Apr-2010 14:25:07.664 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
14-Apr-2010 14:25:07.664 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
14-Apr-2010 14:25:07.664 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
14-Apr-2010 14:25:07.664 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
14-Apr-2010 14:25:07.664 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
14-Apr-2010 14:25:07.665 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
14-Apr-2010 14:25:07.665 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
14-Apr-2010 14:25:07.665 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
14-Apr-2010 14:25:08.393 queries: info: client 127.0.0.1#50896: query: 33.229.242.205.zen.spamhaus.org IN A +
14-Apr-2010 14:25:08.393 security: debug 3: client 127.0.0.1#50896: query (cache) '33.229.242.205.zen.spamhaus.org/A/IN' approved
14-Apr-2010 14:25:08.393 resolver: debug 1: createfetch: 33.229.242.205.zen.spamhaus.org A
14-Apr-2010 14:25:08.393 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): join
14-Apr-2010 14:25:08.393 resolver: debug 3: fetch 0x94ad9c8 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): created
14-Apr-2010 14:25:09.666 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
14-Apr-2010 14:25:09.666 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
14-Apr-2010 14:25:09.666 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
14-Apr-2010 14:25:09.666 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
14-Apr-2010 14:25:09.666 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
14-Apr-2010 14:25:09.666 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
14-Apr-2010 14:25:09.666 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
14-Apr-2010 14:25:09.666 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
14-Apr-2010 14:25:09.666 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
14-Apr-2010 14:25:11.668 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
14-Apr-2010 14:25:11.668 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
14-Apr-2010 14:25:11.668 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
14-Apr-2010 14:25:11.668 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
14-Apr-2010 14:25:11.668 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
14-Apr-2010 14:25:11.668 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
14-Apr-2010 14:25:11.668 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
14-Apr-2010 14:25:11.668 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
14-Apr-2010 14:25:11.668 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
14-Apr-2010 14:25:13.669 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
14-Apr-2010 14:25:13.669 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
14-Apr-2010 14:25:13.669 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
14-Apr-2010 14:25:13.669 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
14-Apr-2010 14:25:13.669 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
14-Apr-2010 14:25:13.669 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
14-Apr-2010 14:25:13.670 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
14-Apr-2010 14:25:13.670 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
14-Apr-2010 14:25:13.670 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
14-Apr-2010 14:25:15.671 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
14-Apr-2010 14:25:15.671 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
14-Apr-2010 14:25:15.671 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
14-Apr-2010 14:25:15.671 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
14-Apr-2010 14:25:15.671 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
14-Apr-2010 14:25:15.671 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
14-Apr-2010 14:25:15.671 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
14-Apr-2010 14:25:15.671 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
14-Apr-2010 14:25:15.671 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
14-Apr-2010 14:25:17.673 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
14-Apr-2010 14:25:17.673 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
14-Apr-2010 14:25:17.673 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
14-Apr-2010 14:25:17.673 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
14-Apr-2010 14:25:17.673 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
14-Apr-2010 14:25:17.673 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
14-Apr-2010 14:25:17.673 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
14-Apr-2010 14:25:17.673 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
14-Apr-2010 14:25:17.673 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
14-Apr-2010 14:25:19.674 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
14-Apr-2010 14:25:19.674 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
14-Apr-2010 14:25:19.674 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
14-Apr-2010 14:25:19.674 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
14-Apr-2010 14:25:19.674 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
14-Apr-2010 14:25:19.674 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
14-Apr-2010 14:25:19.675 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
14-Apr-2010 14:25:19.675 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
14-Apr-2010 14:25:19.675 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
14-Apr-2010 14:25:21.676 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
14-Apr-2010 14:25:21.676 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
14-Apr-2010 14:25:21.676 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
14-Apr-2010 14:25:21.676 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
14-Apr-2010 14:25:21.676 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
14-Apr-2010 14:25:21.676 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
14-Apr-2010 14:25:21.676 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
14-Apr-2010 14:25:21.676 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
14-Apr-2010 14:25:21.676 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
14-Apr-2010 14:25:23.677 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
14-Apr-2010 14:25:23.678 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
14-Apr-2010 14:25:23.678 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
14-Apr-2010 14:25:23.678 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
14-Apr-2010 14:25:23.678 resolver: debug 3: resquery 0x94ae7b8 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
14-Apr-2010 14:25:23.678 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
14-Apr-2010 14:25:23.678 resolver: debug 3: resquery 0x94ae7b8 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
14-Apr-2010 14:25:23.678 resolver: debug 3: resquery 0x94ae7b8 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
14-Apr-2010 14:25:23.678 resolver: debug 3: resquery 0x94ae7b8 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
14-Apr-2010 14:25:23.912 resolver: debug 3: resquery 0x94ae7b8 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): response
14-Apr-2010 14:25:23.912 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): noanswer_response
14-Apr-2010 14:25:23.912 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): ncache_message
14-Apr-2010 14:25:23.912 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): clone_results
14-Apr-2010 14:25:23.912 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
14-Apr-2010 14:25:23.912 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): done
14-Apr-2010 14:25:23.912 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): stopeverything
14-Apr-2010 14:25:23.912 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelqueries
14-Apr-2010 14:25:23.913 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): sendevents
14-Apr-2010 14:25:23.913 resolver: debug 3: fetch 0x94a0b20 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): destroyfetch
14-Apr-2010 14:25:23.913 resolver: debug 3: fetch 0x94d54c8 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): destroyfetch
14-Apr-2010 14:25:23.913 resolver: debug 3: fetch 0x94ad9c8 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): destroyfetch
14-Apr-2010 14:25:23.914 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): shutdown
14-Apr-2010 14:25:23.914 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): doshutdown
14-Apr-2010 14:25:23.914 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): stopeverything
14-Apr-2010 14:25:23.914 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelqueries
14-Apr-2010 14:25:23.914 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): destroy
---
As far as I can see, the BIND query simply didn't get a response -
but no errors?

---
First, someone's going to ask - perhaps Zen's blocking you. I don't
think so. Here's why.
-We're non-commercial, using the definition set my spamhaus,
-mail connects TOTAL are well less than 100K a day. (Less than 10K in actuality)
-and thus having more than 300K queries is pretty unlikely.

-Also, let me remind you that a restart of the bind service seems to
make the failures go away for a while, so if zen were blocking our queries, I'd think that wouldn't make a difference.

---
I certainly suspect a problem with BIND, but I can't find it, and have no idea where to go from here.
I simply don't know where to look any more. If BIND were having a problem, say allocating memory, or something, shouldn't it be in a debug level 5 log?

HELP!

-Greg

[Cross posted from elsewhere, but I'm at a dead-end right now, so
looking for a steer in where to ask, or direct help! TIA]

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-15-2010, 01:51 AM
Larry Vaden
 
Default Apparent BIND problem doing RBL lookups for Postfix

On Wed, Apr 14, 2010 at 7:36 PM, <listserv.traffic@sloop.net> wrote:
> First, someone's going to ask - perhaps Zen's blocking you. I don't
> think so. Here's why.
> -We're non-commercial, using the definition set my spamhaus,
> -mail connects TOTAL are well less than 100K a day. (Less than 10K in actuality)
> -and thus having more than 300K queries is pretty unlikely.

I'm not privy to spamhaus.org's rate limiting policies, but you show
two queries 2 seconds apart, or 86400/2 per day perhaps.

> -Also, let me remind you that a restart of the bind service seems to
> make the failures go away for a while, so if zen were blocking our queries, I'd think that wouldn't make a difference.

Read and understood.

> I certainly suspect a problem with BIND, but I can't find it, and have no idea where to go from here.
> I simply don't know where to look any more. If BIND were having a problem, say allocating memory, or something, shouldn't it be in a debug level 5 log?

Perhaps using 208.67.220.220 and 208.67.222.222 as resolvers or
directly asking spamhaus.org if they are rate limiting you would help.

kind regards/ldv
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-15-2010, 04:52 AM
Nataraj
 
Default Apparent BIND problem doing RBL lookups for Postfix

listserv.traffic@sloop.net wrote:
> My apologies if I'm posting the wrong place, or am asking a common
> question. All my looking so far hasn't turned up anything very useful
> in knowing what to look at, or what to modify.
>
> ---
> CentOS 5, running BIND 9.3.6
> i386
>
> Hardware:
> P4, 2.8Ghz, 1G memory
> Sata drives - non mirrored etc.
>
> Load is light, usually under 0.1
>
> --
> This box is running Postfix as our mail server. BIND (9.3.6) [Latest.]
>
> --
> Problem:
> Postfix is doing RBL lookups on zen.spamhaus.org.
> Everything goes along groovy - but then lookups start failing.
>
> Early in the process, we get stuff like this: [We have a "successful"
> lookup, and then a failure...]
> ---
> Apr 14 14:25:05 mail postfix/smtpd[22281]: NOQUEUE: reject: RCPT from bzq-79-183-5-119.red.bezeqint.net[79.183.5.119]: 554 5.7.1 Service unavailable; Client host [79.183.5.119] blocked using zen.spamhaus.org; from=<contriveclaudia@royalmoore.com> to=<contriveclaudia@royalmoore.com> proto=SMTP helo=<bzq-79-183-5-119.red.bezeqint.net>
>
> Apr 14 14:25:07 mail postfix/smtpd[22804]: warning: 33.229.242.205.zen.spamhaus.org: RBL lookup error: Host or domain name not found. Name service error for name=33.229.242.205.zen.spamhaus.org type=A: Host not found, try again
> ---
> As you can see, we had a lookup succeed and then just right after, one fail - claiming it got no answer from BIND. I get others after this that SUCCEED - so it's not in 100% failure mode yet.
> After time [how much, I don't know] eventually all the zen queries
> [or most all] fail.
>
> A bind restart fixes the problem. [Hmmm...]
>
Check out the following bug report. I would also look at other bind bug
reports. My sense is that redhat has deviated quite a bite from the ISC
version of bind. In particular I believe that they disabled or otherwise
modified the caching behavior back about 6-8 months ago when there were
major security issues with bind. I have felt that my Red Hat/Centos name
servers have not worked as well as Fedora or ISC bind name servers since
this time. You might try installing ISC bind and see if that solves your
problem.

https://bugzilla.redhat.com/show_bug.cgi?id=553334

Nataraj
> ---
> I do some logging in bind, and I don't see any reason for them to fail. Here's a bind debug log of 5 on that failure above.
>
> ---
> 14-Apr-2010 14:24:57.654 queries: info: client 127.0.0.1#42018: query: 33.229.242.205.zen.spamhaus.org IN A +
> 14-Apr-2010 14:24:57.654 security: debug 3: client 127.0.0.1#42018: query (cache) '33.229.242.205.zen.spamhaus.org/A/IN' approved
> 14-Apr-2010 14:24:57.654 resolver: debug 1: createfetch: 33.229.242.205.zen.spamhaus.org A
> 14-Apr-2010 14:24:57.654 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): create
> 14-Apr-2010 14:24:57.654 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): join
> 14-Apr-2010 14:24:57.654 resolver: debug 3: fetch 0x94a0b20 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): created
> 14-Apr-2010 14:24:57.655 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): start
> 14-Apr-2010 14:24:57.655 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
> 14-Apr-2010 14:24:57.655 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelqueries
> 14-Apr-2010 14:24:57.655 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): getaddresses
> 14-Apr-2010 14:24:57.655 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
> 14-Apr-2010 14:24:57.655 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
> 14-Apr-2010 14:24:57.655 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
> 14-Apr-2010 14:24:57.655 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
> 14-Apr-2010 14:24:57.655 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
> 14-Apr-2010 14:24:59.657 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
> 14-Apr-2010 14:24:59.657 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
> 14-Apr-2010 14:24:59.657 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
> 14-Apr-2010 14:24:59.657 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
> 14-Apr-2010 14:24:59.657 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
> 14-Apr-2010 14:24:59.657 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
> 14-Apr-2010 14:24:59.657 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
> 14-Apr-2010 14:24:59.657 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
> 14-Apr-2010 14:25:01.658 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
> 14-Apr-2010 14:25:01.658 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
> 14-Apr-2010 14:25:01.658 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
> 14-Apr-2010 14:25:01.658 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
> 14-Apr-2010 14:25:01.658 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
> 14-Apr-2010 14:25:01.659 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
> 14-Apr-2010 14:25:01.659 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
> 14-Apr-2010 14:25:01.659 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
> 14-Apr-2010 14:25:02.653 queries: info: client 127.0.0.1#42018: query: 33.229.242.205.zen.spamhaus.org IN A +
> 14-Apr-2010 14:25:02.653 security: debug 3: client 127.0.0.1#42018: query (cache) '33.229.242.205.zen.spamhaus.org/A/IN' approved
> 14-Apr-2010 14:25:02.654 resolver: debug 1: createfetch: 33.229.242.205.zen.spamhaus.org A
> 14-Apr-2010 14:25:02.654 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): join
> 14-Apr-2010 14:25:02.654 resolver: debug 3: fetch 0x94d54c8 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): created
> 14-Apr-2010 14:25:03.660 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
> 14-Apr-2010 14:25:03.660 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
> 14-Apr-2010 14:25:03.660 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
> 14-Apr-2010 14:25:03.660 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
> 14-Apr-2010 14:25:03.660 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
> 14-Apr-2010 14:25:03.660 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
> 14-Apr-2010 14:25:03.660 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
> 14-Apr-2010 14:25:03.660 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
> 14-Apr-2010 14:25:03.660 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
> 14-Apr-2010 14:25:05.663 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
> 14-Apr-2010 14:25:05.663 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
> 14-Apr-2010 14:25:05.663 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
> 14-Apr-2010 14:25:05.663 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
> 14-Apr-2010 14:25:05.663 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
> 14-Apr-2010 14:25:05.663 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
> 14-Apr-2010 14:25:05.663 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
> 14-Apr-2010 14:25:05.663 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
> 14-Apr-2010 14:25:05.663 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
> 14-Apr-2010 14:25:07.664 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
> 14-Apr-2010 14:25:07.664 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
> 14-Apr-2010 14:25:07.664 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
> 14-Apr-2010 14:25:07.664 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
> 14-Apr-2010 14:25:07.664 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
> 14-Apr-2010 14:25:07.664 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
> 14-Apr-2010 14:25:07.665 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
> 14-Apr-2010 14:25:07.665 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
> 14-Apr-2010 14:25:07.665 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
> 14-Apr-2010 14:25:08.393 queries: info: client 127.0.0.1#50896: query: 33.229.242.205.zen.spamhaus.org IN A +
> 14-Apr-2010 14:25:08.393 security: debug 3: client 127.0.0.1#50896: query (cache) '33.229.242.205.zen.spamhaus.org/A/IN' approved
> 14-Apr-2010 14:25:08.393 resolver: debug 1: createfetch: 33.229.242.205.zen.spamhaus.org A
> 14-Apr-2010 14:25:08.393 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): join
> 14-Apr-2010 14:25:08.393 resolver: debug 3: fetch 0x94ad9c8 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): created
> 14-Apr-2010 14:25:09.666 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
> 14-Apr-2010 14:25:09.666 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
> 14-Apr-2010 14:25:09.666 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
> 14-Apr-2010 14:25:09.666 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
> 14-Apr-2010 14:25:09.666 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
> 14-Apr-2010 14:25:09.666 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
> 14-Apr-2010 14:25:09.666 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
> 14-Apr-2010 14:25:09.666 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
> 14-Apr-2010 14:25:09.666 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
> 14-Apr-2010 14:25:11.668 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
> 14-Apr-2010 14:25:11.668 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
> 14-Apr-2010 14:25:11.668 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
> 14-Apr-2010 14:25:11.668 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
> 14-Apr-2010 14:25:11.668 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
> 14-Apr-2010 14:25:11.668 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
> 14-Apr-2010 14:25:11.668 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
> 14-Apr-2010 14:25:11.668 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
> 14-Apr-2010 14:25:11.668 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
> 14-Apr-2010 14:25:13.669 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
> 14-Apr-2010 14:25:13.669 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
> 14-Apr-2010 14:25:13.669 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
> 14-Apr-2010 14:25:13.669 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
> 14-Apr-2010 14:25:13.669 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
> 14-Apr-2010 14:25:13.669 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
> 14-Apr-2010 14:25:13.670 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
> 14-Apr-2010 14:25:13.670 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
> 14-Apr-2010 14:25:13.670 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
> 14-Apr-2010 14:25:15.671 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
> 14-Apr-2010 14:25:15.671 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
> 14-Apr-2010 14:25:15.671 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
> 14-Apr-2010 14:25:15.671 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
> 14-Apr-2010 14:25:15.671 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
> 14-Apr-2010 14:25:15.671 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
> 14-Apr-2010 14:25:15.671 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
> 14-Apr-2010 14:25:15.671 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
> 14-Apr-2010 14:25:15.671 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
> 14-Apr-2010 14:25:17.673 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
> 14-Apr-2010 14:25:17.673 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
> 14-Apr-2010 14:25:17.673 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
> 14-Apr-2010 14:25:17.673 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
> 14-Apr-2010 14:25:17.673 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
> 14-Apr-2010 14:25:17.673 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
> 14-Apr-2010 14:25:17.673 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
> 14-Apr-2010 14:25:17.673 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
> 14-Apr-2010 14:25:17.673 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
> 14-Apr-2010 14:25:19.674 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
> 14-Apr-2010 14:25:19.674 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
> 14-Apr-2010 14:25:19.674 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
> 14-Apr-2010 14:25:19.674 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
> 14-Apr-2010 14:25:19.674 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
> 14-Apr-2010 14:25:19.674 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
> 14-Apr-2010 14:25:19.675 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
> 14-Apr-2010 14:25:19.675 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
> 14-Apr-2010 14:25:19.675 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
> 14-Apr-2010 14:25:21.676 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
> 14-Apr-2010 14:25:21.676 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
> 14-Apr-2010 14:25:21.676 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
> 14-Apr-2010 14:25:21.676 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
> 14-Apr-2010 14:25:21.676 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
> 14-Apr-2010 14:25:21.676 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
> 14-Apr-2010 14:25:21.676 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
> 14-Apr-2010 14:25:21.676 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
> 14-Apr-2010 14:25:21.676 resolver: debug 3: resquery 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
> 14-Apr-2010 14:25:23.677 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): timeout
> 14-Apr-2010 14:25:23.678 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
> 14-Apr-2010 14:25:23.678 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): try
> 14-Apr-2010 14:25:23.678 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): query
> 14-Apr-2010 14:25:23.678 resolver: debug 3: resquery 0x94ae7b8 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): send
> 14-Apr-2010 14:25:23.678 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): too many timeouts, disabling EDNS0
> 14-Apr-2010 14:25:23.678 resolver: debug 3: resquery 0x94ae7b8 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): sent
> 14-Apr-2010 14:25:23.678 resolver: debug 3: resquery 0x94ae7b8 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): udpconnected
> 14-Apr-2010 14:25:23.678 resolver: debug 3: resquery 0x94ae7b8 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone
> 14-Apr-2010 14:25:23.912 resolver: debug 3: resquery 0x94ae7b8 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): response
> 14-Apr-2010 14:25:23.912 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): noanswer_response
> 14-Apr-2010 14:25:23.912 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): ncache_message
> 14-Apr-2010 14:25:23.912 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): clone_results
> 14-Apr-2010 14:25:23.912 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelquery
> 14-Apr-2010 14:25:23.912 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): done
> 14-Apr-2010 14:25:23.912 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): stopeverything
> 14-Apr-2010 14:25:23.912 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelqueries
> 14-Apr-2010 14:25:23.913 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): sendevents
> 14-Apr-2010 14:25:23.913 resolver: debug 3: fetch 0x94a0b20 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): destroyfetch
> 14-Apr-2010 14:25:23.913 resolver: debug 3: fetch 0x94d54c8 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): destroyfetch
> 14-Apr-2010 14:25:23.913 resolver: debug 3: fetch 0x94ad9c8 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): destroyfetch
> 14-Apr-2010 14:25:23.914 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): shutdown
> 14-Apr-2010 14:25:23.914 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): doshutdown
> 14-Apr-2010 14:25:23.914 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): stopeverything
> 14-Apr-2010 14:25:23.914 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): cancelqueries
> 14-Apr-2010 14:25:23.914 resolver: debug 3: fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A'): destroy
> ---
> As far as I can see, the BIND query simply didn't get a response -
> but no errors?
>
> ---
> First, someone's going to ask - perhaps Zen's blocking you. I don't
> think so. Here's why.
> -We're non-commercial, using the definition set my spamhaus,
> -mail connects TOTAL are well less than 100K a day. (Less than 10K in actuality)
> -and thus having more than 300K queries is pretty unlikely.
>
> -Also, let me remind you that a restart of the bind service seems to
> make the failures go away for a while, so if zen were blocking our queries, I'd think that wouldn't make a difference.
>
> ---
> I certainly suspect a problem with BIND, but I can't find it, and have no idea where to go from here.
> I simply don't know where to look any more. If BIND were having a problem, say allocating memory, or something, shouldn't it be in a debug level 5 log?
>
> HELP!
>
> -Greg
>
> [Cross posted from elsewhere, but I'm at a dead-end right now, so
> looking for a steer in where to ask, or direct help! TIA]
>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-15-2010, 09:18 AM
John Horne
 
Default Apparent BIND problem doing RBL lookups for Postfix

On Wed, 2010-04-14 at 17:36 -0700, listserv.traffic@sloop.net wrote:
> --
> Problem:
> Postfix is doing RBL lookups on zen.spamhaus.org.
> Everything goes along groovy - but then lookups start failing.
>
Does your network interface show any abnormalities - dropped packets
etc? I assume you have no local ratelimiting (via iptables etc)?



John.

--
John Horne, University of Plymouth, UK
Tel: +44 (0)1752 587287 Fax: +44 (0)1752 587001

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-15-2010, 06:20 PM
 
Default Apparent BIND problem doing RBL lookups for Postfix

> On Wed, 2010-04-14 at 17:36 -0700, listserv.traffic@sloop.net wrote:
>> --
>> Problem:
>> Postfix is doing RBL lookups on zen.spamhaus.org.
>> Everything goes along groovy - but then lookups start failing.
>>
> Does your network interface show any abnormalities - dropped packets
> etc? I assume you have no local ratelimiting (via iptables etc)?

No rate limiting, and ifconfig isn't showing any
errors/drops/overruns etc.

-Greg

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-15-2010, 06:22 PM
 
Default Apparent BIND problem doing RBL lookups for Postfix

>>
> Check out the following bug report. I would also look at other bind bug
> reports. My sense is that redhat has deviated quite a bite from the ISC
> version of bind. In particular I believe that they disabled or otherwise
> modified the caching behavior back about 6-8 months ago when there were
> major security issues with bind. I have felt that my Red Hat/Centos name
> servers have not worked as well as Fedora or ISC bind name servers since
> this time. You might try installing ISC bind and see if that solves your
> problem.

> https://bugzilla.redhat.com/show_bug.cgi?id=553334

> Nataraj

Interesting - though in our case it's failing long before a few
million lookups. I don't much relish compiling ISC versions to run on
my box - the security implications and other hassles don't seem
trivial. [We don't allow external [the world] lookups - just local
"trusted" users, but that only mitigates some of the security concerns.]

Perhaps it's possible to use an older version that's security
patched. Ugh.

-Greg

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-15-2010, 07:36 PM
Nataraj
 
Default Apparent BIND problem doing RBL lookups for Postfix

listserv.traffic@sloop.net wrote:
>> Check out the following bug report. I would also look at other bind bug
>> reports. My sense is that redhat has deviated quite a bite from the ISC
>> version of bind. In particular I believe that they disabled or otherwise
>> modified the caching behavior back about 6-8 months ago when there were
>> major security issues with bind. I have felt that my Red Hat/Centos name
>> servers have not worked as well as Fedora or ISC bind name servers since
>> this time. You might try installing ISC bind and see if that solves your
>> problem.
>>
>
>
>> https://bugzilla.redhat.com/show_bug.cgi?id=553334
>>
>
>
>> Nataraj
>>
>
> Interesting - though in our case it's failing long before a few
> million lookups. I don't much relish compiling ISC versions to run on
> my box - the security implications and other hassles don't seem
> trivial. [We don't allow external [the world] lookups - just local
> "trusted" users, but that only mitigates some of the security concerns.]
>
> Perhaps it's possible to use an older version that's security
> patched. Ugh.
>
Though I have not done it in a while, It's not a big deal to build ISC
bind. If you have compilers installed, you untar it and run "make" or
"make install", maybe setting up the path for installation. With the
security issues today, I often run a separate system for name servers
(actually I use virtual machines). In fact, mostly I setup both an
internal and a external nameserver where the internal one forwards
queries to the external one so it never receives packets from the
Internet. So the internal one could be on your mail server and the
external one could be a seperate box. For test purposes, you could try
ISC bind on any old box just to determine if it solves the problem.

Alternatively, if the problem is urgent I guess you could buy a red hat
license and try to get them to up the priority on resolving this. If
you have the time and skills, you could install a debug compiled version
of CentOS bind and try to either debug it or capture a dump of it when
it breaks and submit that to developers.

I don't think running ISC bind for a short time is a major risk. It's
quite widely deployed in the field.

Nataraj

> -Greg
>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-15-2010, 07:54 PM
sys Admin
 
Default Apparent BIND problem doing RBL lookups for Postfix

What happens if you change your resolv.conf to google's dns ?


On 4/15/10, Nataraj <incoming-centos@rjl.com> wrote:
> listserv.traffic@sloop.net wrote:
>>> Check out the following bug report. I would also look at other bind bug
>>> reports. My sense is that redhat has deviated quite a bite from the ISC
>>> version of bind. In particular I believe that they disabled or otherwise
>>> modified the caching behavior back about 6-8 months ago when there were
>>> major security issues with bind. I have felt that my Red Hat/Centos name
>>> servers have not worked as well as Fedora or ISC bind name servers since
>>> this time. You might try installing ISC bind and see if that solves your
>>> problem.
>>>
>>
>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=553334
>>>
>>
>>
>>> Nataraj
>>>
>>
>> Interesting - though in our case it's failing long before a few
>> million lookups. I don't much relish compiling ISC versions to run on
>> my box - the security implications and other hassles don't seem
>> trivial. [We don't allow external [the world] lookups - just local
>> "trusted" users, but that only mitigates some of the security concerns.]
>>
>> Perhaps it's possible to use an older version that's security
>> patched. Ugh.
>>
> Though I have not done it in a while, It's not a big deal to build ISC
> bind. If you have compilers installed, you untar it and run "make" or
> "make install", maybe setting up the path for installation. With the
> security issues today, I often run a separate system for name servers
> (actually I use virtual machines). In fact, mostly I setup both an
> internal and a external nameserver where the internal one forwards
> queries to the external one so it never receives packets from the
> Internet. So the internal one could be on your mail server and the
> external one could be a seperate box. For test purposes, you could try
> ISC bind on any old box just to determine if it solves the problem.
>
> Alternatively, if the problem is urgent I guess you could buy a red hat
> license and try to get them to up the priority on resolving this. If
> you have the time and skills, you could install a debug compiled version
> of CentOS bind and try to either debug it or capture a dump of it when
> it breaks and submit that to developers.
>
> I don't think running ISC bind for a short time is a major risk. It's
> quite widely deployed in the field.
>
> Nataraj
>
>> -Greg
>>
>> _______________________________________________
>> CentOS mailing list
>> CentOS@centos.org
>> http://lists.centos.org/mailman/listinfo/centos
>>
>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>

--
Sent from my mobile device
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-15-2010, 08:00 PM
 
Default Apparent BIND problem doing RBL lookups for Postfix

> What happens if you change your resolv.conf to google's dns ?
I haven't tried this, but from reports, spamhaus.org blocks google's dns. [The
traffic limits are too high. If they didn't, no one would buy a
commercial zone transfer license...]

So, while it's not likely to fix this problem, even if it were, it
seems like your "solution" to the broken DNS server is to use
someone else's DNS server.

So, yeah, I could drive the neighbor's car when mine doesn't work.
But that doesn't fix my car.

I'm interested in fixing mine, or at least understanding how and why it's broken.

Thanks for your time and thoughts though.

-Greg

> On 4/15/10, Nataraj <incoming-centos@rjl.com> wrote:
>> listserv.traffic@sloop.net wrote:
>>>> Check out the following bug report. I would also look at other bind bug
>>>> reports. My sense is that redhat has deviated quite a bite from the ISC
>>>> version of bind. In particular I believe that they disabled or otherwise
>>>> modified the caching behavior back about 6-8 months ago when there were
>>>> major security issues with bind. I have felt that my Red Hat/Centos name
>>>> servers have not worked as well as Fedora or ISC bind name servers since
>>>> this time. You might try installing ISC bind and see if that solves your
>>>> problem.
>>>>
>>>
>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=553334
>>>>
>>>
>>>
>>>> Nataraj
>>>>
>>>
>>> Interesting - though in our case it's failing long before a few
>>> million lookups. I don't much relish compiling ISC versions to run on
>>> my box - the security implications and other hassles don't seem
>>> trivial. [We don't allow external [the world] lookups - just local
>>> "trusted" users, but that only mitigates some of the security concerns.]
>>>
>>> Perhaps it's possible to use an older version that's security
>>> patched. Ugh.
>>>
>> Though I have not done it in a while, It's not a big deal to build ISC
>> bind. If you have compilers installed, you untar it and run "make" or
>> "make install", maybe setting up the path for installation. With the
>> security issues today, I often run a separate system for name servers
>> (actually I use virtual machines). In fact, mostly I setup both an
>> internal and a external nameserver where the internal one forwards
>> queries to the external one so it never receives packets from the
>> Internet. So the internal one could be on your mail server and the
>> external one could be a seperate box. For test purposes, you could try
>> ISC bind on any old box just to determine if it solves the problem.
>>
>> Alternatively, if the problem is urgent I guess you could buy a red hat
>> license and try to get them to up the priority on resolving this. If
>> you have the time and skills, you could install a debug compiled version
>> of CentOS bind and try to either debug it or capture a dump of it when
>> it breaks and submit that to developers.
>>
>> I don't think running ISC bind for a short time is a major risk. It's
>> quite widely deployed in the field.
>>
>> Nataraj
>>


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-15-2010, 08:03 PM
Ned Slider
 
Default Apparent BIND problem doing RBL lookups for Postfix

sys Admin wrote:
> What happens if you change your resolv.conf to google's dns ?
>
>

Changing dns to public services such as google or OpenDNS is not going
to help as DNSBLs like Spamhaus will have blocked access by these
services. Otherwise it would be simple to avoid paying for (business)
access to Spamhaus.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 08:40 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org