RE: Apparent BIND problem doing RBL lookups for Postfix
Hi, At the first sight it seems network problems, but when you restart bind, the problem goes away for a while. I suppose your dns server is resolving names for himself, try to put your ISP's dns servers on resolv.conf, perhaps it solve the problem. It could be a problem with your dns forwarders but I think it's unlikely, anyway, try different dns configurations on resolv.conf and if it works, update bind forwarders parameter accordingly. Regards, Nuno Paquete -Mensagem original- De: bind-users-bounces+nunopaquete=lusocargo...@lists.isc.org [mailto:bind-users-bounces+nunopaquete=lusocargo...@lists.isc.org] Em nome de listserv.traf...@sloop.net Enviada: quinta-feira, 15 de Abril de 2010 01:34 Para: bind-users@lists.isc.org Assunto: 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= to= proto=SMTP helo= 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 0x940
RE: Re[2]: Apparent BIND problem doing RBL lookups for Postfix
Greg, Usually we use forwarders so we don't always have to bother root servers. Because our ISP's deals with great amount of requests from all the clients, probably most of your new requests are already in their cache and it's much faster than query a root server, because it's on the same network. I mentioned the forwarders parameter because it's usual to use our ISP's dns servers as a forwarder and I thought you might had a misconfigured forwarder. Although you have forwarders configured, from the point of view of your dns clients your dns server still answers the requests the same way, and if you have a problem with your dns server, the problem still remains, so, you are not putting the problem away. > Well, using forwarders might fix "general" bind errors, but it's > likely to run into problems for RBL lookups at spamhaus.org - since they have > limits (100K SMTP connects a day, and 300K lookups) > So using my ISP's name servers which have higher volume is likely to > run afoul of those limits because it's aggregating traffic. Even if > it doesn't right now, it could at any time when someone else does the > same and that increase in lookups pushes us over the edge. I don't think so. All the requests to spamhaus.org will be made by your postfix box, not from your forwarders. And look, your server only queries forwarders when its own cache expired, before that your server answers the queries by himself, without bothering forwarders. I use spamhaus.org with postfix/spamassassin and I've got no problem with it. Best Regards, Nuno Paquete ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ACL for forward zone
Hi Prabhat,
I think you don't need this ACL in your forwarder server, define it on
the authoritative server (1.2.3.4 and 5.6.7.8, according to your
example).
Regards,
Nuno Paquete
No dia 2010/07/12, às 19:27, "Prabhat Rana"
escreveu:
Hello all,
I have BIND 9.7.1 installed in Solaris 10. I need to use a forwarder
for a certain internal private IP zone to a certain internal DNS
severs. In the meantime I need to use certain ACL so that it would
forward the queries and reply to them only from certain IP address
clients. So I used the following conifgs in named.conf
acl "Internal" {10.0.1.0/24)
zone "10.in-addr.arpa" in {
type forward;
forwarders { 1.2.3.4; 5.6.7.8; };
allow-query { "Internal"; };
However it appears I can't use 'allow query' option in forward zone
as seen in the syslog
/etc/named.conf:102: option 'allow-query' is not allowed in
'forward' zone '10.in-addr.arpa'
Basically you know what I'm trying to achieve. So if anyone has any
tip how can I use forward from the clients only within certain IP
address range, that would be great.
Prabhat.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to query the nameserver
Can you successfuly telnet port 53 from an external host? Have you seen your logs? There must be something logged. No dia 2010/10/04, às 23:56, "Dotan Cohen" escreveu: On Mon, Oct 4, 2010 at 23:37, Greg Whynott wrote: someone with way more bind clues than I would be able to give you a better answer.the error returned begs two questions.. 1. is this server behind or running a local firewall? No. 2. is bind actually listening on the proper interface? Yes -- Dotan Cohen http://gibberish.co.il http://what-is-what.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to query the nameserver
Are your servers running virtualized? No dia 2010/10/04, às 23:56, "Dotan Cohen" escreveu: On Mon, Oct 4, 2010 at 23:37, Greg Whynott wrote: someone with way more bind clues than I would be able to give you a better answer.the error returned begs two questions.. 1. is this server behind or running a local firewall? No. 2. is bind actually listening on the proper interface? Yes -- Dotan Cohen http://gibberish.co.il http://what-is-what.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind and blacklist IP file
Hi. This is NOT something BIND (or any DNS server) should do. Blocking web sites is business for web proxies, firewalls etc. Doing this stuff at DNS level could lead to many surprises. I definetly agree with this. In Norway we have what is basically a government requirement for ISPs to block child porn domains, using a list supplied by the police. Ok, but you can always browse by IP address and in this case there is no DNS server than can stop you from browsing what you want. If you want to block IP address access you have to use firewall, or if you are talking about http traffic and have a proxy, maybe you have to block there. That's why I completly agree this should not be blocked at DNS level. Nuno Paquete ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dynamic updates via libbind.
It would be interesting to have an API that we could use to make changes dynamically to DNS zones. I don't know if there is already such a tool. No dia 12 de Nov de 2010, às 18:57, "Jack Tavares" escreveu: > I am currently using libbind to do dynamic updates in "C". > > > > I have looked in the bind 9.7.x source and I don't see a replacement > mechanism for this. > > > > Is there one or is there one planned in bind10? > > > > Thanks > > -- > > Jack. > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Last transfer time?
Just check the logs. No dia 1 de Dez de 2010, às 20:45, "Chip Marshall" escreveu: > Just curious if there's an official and accurate way to > determine the last sucessful transfer time of a slave zone from > a BIND server. > > -- > Chip Marshall > http://weblog.2bithacker.net/ KB1QYWPGP key ID 43C4819E > v4sw5PUhw4/5ln5pr5FOPck4ma4u6FLOw5Xm5l5Ui2e4t4/5ARWb7HKOen6a2Xs5IMr2g6CM > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind replication
No dia 31 de Dez de 2010, às 08:18, "p...@mail.nsbeta.info" escreveu: > Anand Buddhdev writes: >> On 31/12/2010 05:33, p...@mail.nsbeta.info wrote: >>> Hi, >>> Is it a right way to run rsync for bind's zone files replication? >>> If we have dozons of zones, each zone has more than one view, under this >>> case setup the master/slave with standard zone-traff is the hard way IMO. >>> Thanks. >> Yes, that's just fine. You don't have to use zone transfers. > > Thanks. But I have another question, > how would bind know the zone files were changed before it reload zones? > Regards. I think you have to restart bind. That's why I believe it's better to use zone transfers because it's automatic. Nuno Paquete -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
