nsupdate failed with using database mysql as backup
hi all, i have another problem:when i use sdb mysql as a backup storing zone data, i found this method doesn't support dynamic update message. but i need a database backup and dynamic shema. is there any solutions? thank you very much! Best regards! Sincerely, aiHua Zhang State Key Lab. of Networking Technology Research Institute, BeiJing University of Posts and Telecommunications, 100876, P.R.China Email ：aih...@bupt.cn ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Apparent BIND problem doing RBL lookups for Postfix
Hello, Looks like NXDOMAIN can be one of the responses. http://www.spamhaus.org/faq/answers.lasso?section=DNSBL%20Usage#252 That said, I think it is working correctly (a la name=33.229.242.205.zen.spamhaus.org type=A: Host not found, try again). However, perhaps tweak the number of queries so that the MTA doesn't waste too many cycles on RBL lookups which are NXDOMAIN. Or, I may be missing something. I'm not an MTA guru, but I know sendmail more than I know Postfix. Hope this helps. - Original Message From: listserv.traf...@sloop.net listserv.traf...@sloop.net To: bind-users@lists.isc.org Sent: Wed, April 14, 2010 8:33:55 PM Subject: 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=contriveclau...@royalmoore.com to=contriveclau...@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
logging forwarding reqs
Hey all,
I've setup bind9 to be a forwarder only. However I'm not understanding how
to confirm requests for queries are being sent through to the forwarded dns
servers. Even running in debug mode, I can see the req, but I dont see
anything in the debug msg that says its been forwarded on to any of my
forwarders.
named.conf.options:
options {
directory /var/cache/bind;
forward only;
forwarders {
172.20.4.1;
172.20.4.3;
172.20.4.10;
};
allow-query {
127.0.0.1;
172.0.0.0/8;
};
};
Im run the server in debug and make a request for google.ca from the client.
But this doesnt tell me that the request was actually sent to my forwarding
servers. I want to be able to confirn this and know that my localhost isnt
answering these queries for the client. Perhaps theres a logging config that
will show me this? Any ideas?
$ sudo named -d9 -g -c /etc/bind/named.conf
15-Apr-2010 12:21:32.682 client 172.18.4.214#43801: UDP request
15-Apr-2010 12:21:32.682 client 172.18.4.214#43801: using view '_default'
15-Apr-2010 12:21:32.682 client 172.18.4.214#43801: request is not signed
15-Apr-2010 12:21:32.682 client 172.18.4.214#43801: recursion available
15-Apr-2010 12:21:32.682 client 172.18.4.214#43801: query
15-Apr-2010 12:21:32.682 client 172.18.4.214#43801: query (cache) '
google.ca/A/IN' approved
15-Apr-2010 12:21:32.682 client 172.18.4.214#43801: replace
15-Apr-2010 12:21:32.682 clientmgr @0x7f803f2d0760: createclients
15-Apr-2010 12:21:32.682 clientmgr @0x7f803f2d0760: create new
15-Apr-2010 12:21:32.683 client @0x7f80412ae2a0: create
15-Apr-2010 12:21:32.683 createfetch: google.ca A
15-Apr-2010 12:21:32.683 client @0x7f80412ae2a0: udprecv
15-Apr-2010 12:21:32.684 fctx 0x7f8038643010(google.ca/A'): create
15-Apr-2010 12:21:32.684 fctx 0x7f8038643010(google.ca/A'): join
15-Apr-2010 12:21:32.684 fetch 0x7f803f2c5140 (fctx 0x7f8038643010(
google.ca/A)): created
15-Apr-2010 12:21:32.684 fctx 0x7f8038643010(google.ca/A'): start
15-Apr-2010 12:21:32.684 fctx 0x7f8038643010(google.ca/A'): try
15-Apr-2010 12:21:32.684 fctx 0x7f8038643010(google.ca/A'): cancelqueries
15-Apr-2010 12:21:32.684 fctx 0x7f8038643010(google.ca/A'): getaddresses
15-Apr-2010 12:21:32.684 fctx 0x7f8038643010(google.ca/A'): query
15-Apr-2010 12:21:32.684 resquery 0x7f8038649010 (fctx 0x7f8038643010(
google.ca/A)): send
15-Apr-2010 12:21:32.684 resquery 0x7f8038649010 (fctx 0x7f8038643010(
google.ca/A)): sent
15-Apr-2010 12:21:32.684 resquery 0x7f8038649010 (fctx 0x7f8038643010(
google.ca/A)): udpconnected
15-Apr-2010 12:21:32.684 resquery 0x7f8038649010 (fctx 0x7f8038643010(
google.ca/A)): senddone
15-Apr-2010 12:21:32.715 resquery 0x7f8038649010 (fctx 0x7f8038643010(
google.ca/A)): response
15-Apr-2010 12:21:32.715 fctx 0x7f8038643010(google.ca/A'): answer_response
15-Apr-2010 12:21:32.715 fctx 0x7f8038643010(google.ca/A'): cache_message
15-Apr-2010 12:21:32.715 fctx 0x7f8038643010(google.ca/A'): clone_results
15-Apr-2010 12:21:32.716 fctx 0x7f8038643010(google.ca/A'): cancelquery
15-Apr-2010 12:21:32.716 fctx 0x7f8038643010(google.ca/A'): done
15-Apr-2010 12:21:32.716 fctx 0x7f8038643010(google.ca/A'): stopeverything
15-Apr-2010 12:21:32.716 fctx 0x7f8038643010(google.ca/A'): cancelqueries
15-Apr-2010 12:21:32.716 fctx 0x7f8038643010(google.ca/A'): sendevents
15-Apr-2010 12:21:32.716 client 172.18.4.214#43801: send
15-Apr-2010 12:21:32.716 client 172.18.4.214#43801: sendto
15-Apr-2010 12:21:32.716 client 172.18.4.214#43801: senddone
15-Apr-2010 12:21:32.716 client 172.18.4.214#43801: next
15-Apr-2010 12:21:32.716 client 172.18.4.214#43801: endrequest
15-Apr-2010 12:21:32.716 fetch 0x7f803f2c5140 (fctx 0x7f8038643010(
google.ca/A)): destroyfetch
15-Apr-2010 12:21:32.716 fctx 0x7f8038643010(google.ca/A'): shutdown
15-Apr-2010 12:21:32.716 fctx 0x7f8038643010(google.ca/A'): doshutdown
15-Apr-2010 12:21:32.716 fctx 0x7f8038643010(google.ca/A'): stopeverything
15-Apr-2010 12:21:32.716 fctx 0x7f8038643010(google.ca/A'): cancelqueries
15-Apr-2010 12:21:32.716 fctx 0x7f8038643010(google.ca/A'): destroy
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
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=contriveclau...@royalmoore.com to=contriveclau...@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
dig +trace
Hello Folks, I got a strange issue going on.. I dig for a specific record against a ISP cache server , and the cache server doesn't seem to see it, but When I do dig +any, then the record stays in the cache for say 5minutes and then vanishes. any idea? ~LA ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: logging forwarding reqs
Indeed I have setup querylog, and I have these show in my logs:
Apr 15 14:20:00 TOR-HYPER-01 named[10228]: client 172.18.4.214#47149: query:
google.ca IN A +
Apr 15 14:20:09 TOR-HYPER-01 named[10228]: client 172.18.4.214#51366: query:
yahoo.ca IN A +
Apr 15 14:23:32 TOR-HYPER-01 named[10228]: client 127.0.0.1#48177: query:
google.ca IN A +
But I am still unable to determine if those reqs are asking the forwarders.
The forwarders are all Windows boxes which I dont have rights to access.
Still hoping there is something within bind9 that can say the req went to
fwd'er.
On Thu, Apr 15, 2010 at 12:31 PM, Jonathan Reed jreed...@gmail.com wrote:
Hey all,
I've setup bind9 to be a forwarder only. However I'm not understanding how
to confirm requests for queries are being sent through to the forwarded dns
servers. Even running in debug mode, I can see the req, but I dont see
anything in the debug msg that says its been forwarded on to any of my
forwarders.
named.conf.options:
options {
directory /var/cache/bind;
forward only;
forwarders {
172.20.4.1;
172.20.4.3;
172.20.4.10;
};
allow-query {
127.0.0.1;
172.0.0.0/8;
};
};
Im run the server in debug and make a request for google.ca from the
client. But this doesnt tell me that the request was actually sent to my
forwarding servers. I want to be able to confirn this and know that my
localhost isnt answering these queries for the client. Perhaps theres a
logging config that will show me this? Any ideas?
$ sudo named -d9 -g -c /etc/bind/named.conf
15-Apr-2010 12:21:32.682 client 172.18.4.214#43801: UDP request
15-Apr-2010 12:21:32.682 client 172.18.4.214#43801: using view '_default'
15-Apr-2010 12:21:32.682 client 172.18.4.214#43801: request is not signed
15-Apr-2010 12:21:32.682 client 172.18.4.214#43801: recursion available
15-Apr-2010 12:21:32.682 client 172.18.4.214#43801: query
15-Apr-2010 12:21:32.682 client 172.18.4.214#43801: query (cache) '
google.ca/A/IN' approved
15-Apr-2010 12:21:32.682 client 172.18.4.214#43801: replace
15-Apr-2010 12:21:32.682 clientmgr @0x7f803f2d0760: createclients
15-Apr-2010 12:21:32.682 clientmgr @0x7f803f2d0760: create new
15-Apr-2010 12:21:32.683 client @0x7f80412ae2a0: create
15-Apr-2010 12:21:32.683 createfetch: google.ca A
15-Apr-2010 12:21:32.683 client @0x7f80412ae2a0: udprecv
15-Apr-2010 12:21:32.684 fctx
0x7f8038643010(google.ca/A'http://google.ca/A%27):
create
15-Apr-2010 12:21:32.684 fctx
0x7f8038643010(google.ca/A'http://google.ca/A%27):
join
15-Apr-2010 12:21:32.684 fetch 0x7f803f2c5140 (fctx 0x7f8038643010(
google.ca/A) http://google.ca/A%29): created
15-Apr-2010 12:21:32.684 fctx
0x7f8038643010(google.ca/A'http://google.ca/A%27):
start
15-Apr-2010 12:21:32.684 fctx
0x7f8038643010(google.ca/A'http://google.ca/A%27):
try
15-Apr-2010 12:21:32.684 fctx
0x7f8038643010(google.ca/A'http://google.ca/A%27):
cancelqueries
15-Apr-2010 12:21:32.684 fctx
0x7f8038643010(google.ca/A'http://google.ca/A%27):
getaddresses
15-Apr-2010 12:21:32.684 fctx
0x7f8038643010(google.ca/A'http://google.ca/A%27):
query
15-Apr-2010 12:21:32.684 resquery 0x7f8038649010 (fctx 0x7f8038643010(
google.ca/A) http://google.ca/A%29): send
15-Apr-2010 12:21:32.684 resquery 0x7f8038649010 (fctx 0x7f8038643010(
google.ca/A) http://google.ca/A%29): sent
15-Apr-2010 12:21:32.684 resquery 0x7f8038649010 (fctx 0x7f8038643010(
google.ca/A) http://google.ca/A%29): udpconnected
15-Apr-2010 12:21:32.684 resquery 0x7f8038649010 (fctx 0x7f8038643010(
google.ca/A) http://google.ca/A%29): senddone
15-Apr-2010 12:21:32.715 resquery 0x7f8038649010 (fctx 0x7f8038643010(
google.ca/A) http://google.ca/A%29): response
15-Apr-2010 12:21:32.715 fctx
0x7f8038643010(google.ca/A'http://google.ca/A%27):
answer_response
15-Apr-2010 12:21:32.715 fctx
0x7f8038643010(google.ca/A'http://google.ca/A%27):
cache_message
15-Apr-2010 12:21:32.715 fctx
0x7f8038643010(google.ca/A'http://google.ca/A%27):
clone_results
15-Apr-2010 12:21:32.716 fctx
0x7f8038643010(google.ca/A'http://google.ca/A%27):
cancelquery
15-Apr-2010 12:21:32.716 fctx
0x7f8038643010(google.ca/A'http://google.ca/A%27):
done
15-Apr-2010 12:21:32.716 fctx
0x7f8038643010(google.ca/A'http://google.ca/A%27):
stopeverything
15-Apr-2010 12:21:32.716 fctx
0x7f8038643010(google.ca/A'http://google.ca/A%27):
cancelqueries
15-Apr-2010 12:21:32.716 fctx
0x7f8038643010(google.ca/A'http://google.ca/A%27):
sendevents
15-Apr-2010 12:21:32.716 client 172.18.4.214#43801: send
15-Apr-2010 12:21:32.716 client 172.18.4.214#43801: sendto
15-Apr-2010 12:21:32.716 client 172.18.4.214#43801: senddone
15-Apr-2010 12:21:32.716 client 172.18.4.214#43801: next
15-Apr-2010 12:21:32.716 client 172.18.4.214#43801: endrequest
15-Apr-2010 12:21:32.716 fetch 0x7f803f2c5140 (fctx 0x7f8038643010(
google.ca/A) http://google.ca/A%29): destroyfetch
15-Apr-2010 12:21:32.716 fctx
Re: Understanding 'format error Messages
b19...@anl.gov wrote: I am trying to understand format error messages like this one from BIND 9.7.0-P1: Apr 15 15:36:02 dnsserver.it.anl.gov named[8662]: [ID 873579 daemon.notice] DNS format error from 209.234.234.42#53 resolving markets.nytimes.wallst.com/ for client 164.54.214.14#13132: invalid response I haven't looked at the code too closely (maybe someone from ISC can chime in), but I am also interested in understanding the range of possible errors that this message indicates. In this particular case, the authoritative nameserver is giving out an obviously bogus NS record for wallst.com: manasquan# dig wallst.com @209.234.224.42 any ; DiG 9.7.0-P1 wallst.com @209.234.224.42 any ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 17612 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;wallst.com.IN ANY ;; ANSWER SECTION: wallst.com. 500 IN SOA lb-www-p1-bb2-01.mgmt.local. hostmaster.lb-www-p1-bb2-01.mgmt.local. 390 10800 3600 604800 60 wallst.com. 500 IN NS lb-www-p1-bb2-01.mgmt.local. Not sure if that's causing the format error, but it is obviously broken (and all too common still). michael ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig +trace
In message t2r707abafb1004151035s6b7ee489sdcf19e662aaff...@mail.gmail.com, Li nux Addict writes: Hello Folks, I got a strange issue going on.. I dig for a specific record against a ISP cache server , and the cache server doesn't seem to see it, but When I do dig +any, then the record stays in the cache for say 5minutes and then vanishes. any idea? ~LA There are lots of broken servers out there. Without knowing the actual query anything would be pure speculation. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Unexpected issues with nslookup command
Hello, I have tried to research my problem, but haven't found an answer from the collected Google wisdom of the ages, unfortunately. We have a situation where we are getting strange results from the nslookup command (with knock-on effects to name resolution in general). We have two primary (internal) name servers; if we select one of our clients, and use either name server by itself in the /etc/resolv.conf file, all works well. However, specifying BOTH name servers in the /etc/resolv.conf file causes nslookup binary to state ;; Got recursion not available from first-server-IP, trying next server, but then successfully returns the name query. If we reverse the order in /etc/resolv.conf, then the message changes to reflect the changed order. So, if we have the following /etc/resolv.conf: domain blah.com nameserver 1.2.3.4 nameserver 5.6.7.8 running nslookup client.blah.com we get: ;; Got recursion not available from 1.2.3.4 trying next server Server: 5.6.7.8 Address:5.6.7.8#53 Name: client.blah.com Address: 192.168.222.111 and to show what I mean, if we reverse the order so that /etc/resolv.conf contains: domain blah.com nameserver 5.6.7.8 nameserver 1.2.3.4 the nslookup output says: ;; Got recursion not available from 5.6.7.8 trying next server Server: 1.2.3.4 Address:1.2.3.4#53 Name: client.query.com Address: 192.168.222.111 Each name server works fine; each name server works fine when it is the only nameserver listed in /etc/resolv.conf. The queries on the wire are the same (I've snooped the traffic with TCPDUMP). The problem continues if I add a third server to /etc/resolv.conf, thus: example /etc/resolv.conf domain blah.com nameserver 127.0.0.1 nameserver 1.2.3.4 nameserver 5.6.7.8 and the output from nslookup: ;; Got recursion not available from 10.163.134.22, trying next server ;; Got recursion not available from 10.35.6.21, trying next server ;; connection timed out; no servers could be reached (This is how we first noticed the issue - the localhost caching nameserver died, and all name resolution ground to a halt). This happens on any of the clients running ISC Bind nslookup (I've even recompiled the latest v9.7.0 binary, too). Can anyone explain what may be happening here, please? Thanks! James Roberts-Thomson (My apologies for the following disclaimer, over which I have no control) --- This email and any attachments may contain information that is confidential and subject to legal privilege. If you are not the intended recipient, any use, dissemination, distribution or duplication of this email and attachments is prohibited. If you have received this email in error please notify the author immediately and erase all copies of the email and attachments. The Ministry of Social Development accepts no responsibility for changes made to this message or attachments after transmission from the Ministry. --- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unexpected issues with nslookup command
In message 9b2fff1719120e4c83de53c2f70cc60755d5899...@secmclust01a.corp.ssi.go vt.nz, James Roberts-Thomson writes: Can anyone explain what may be happening here, please? Stub resolvers really should be talking to nameservers that offer recursion. If it is talking to a nameserver that doesn't offer recursion then some of the answers returned may be mis-interpreted by the calling code. The warning is telling you that you have a configuration error. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unexpected issues with nslookup command
In message 9b2fff1719120e4c83de53c2f70cc60755d5899...@secmclust01a.corp.ssi.go
vt.nz, James Roberts-Thomson writes:
Hi Mark,
Thanks for your response; whilst I accept what your saying, I'm not convinced
it applies in this case.
As far as I can tell, recursion is enabled on the servers. (We don't have an
allow-recursion entry in the named.conf, and my reading of the documentation
implies recursion is enabled by default). An rndc status shows recursive
clients: 0/0/1000, which suggests to me that I can have up to 1000 recursiv
e clients simultaneously, and using the same configuration file on a test mac
hine and turning up the debugging level gives 16-Apr-2010 15:34:37.026 clien
t x.x.x.x#35622: recursion available
allow-recursion defaults to { localnets; localhost; };.
If the client was not on a directly connected network it
will NOT get recursion by default.
When a piece of software is complaining about something it
is usually a pretty good bet that it is right and you are
wrong.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: Unexpected issues with nslookup command
Hi Mark,
allow-recursion defaults to { localnets; localhost; };.
If the client was not on a directly connected network it
will NOT get recursion by default.
So it would seem; I had made an assumption about subnetting that apparently was
not entirely accurate. Oh well, you know what they say about assumptions...
When a piece of software is complaining about something it
is usually a pretty good bet that it is right and you are
wrong.
Ah! Humour. Yes, aware of the concept, thanks. :-)
Seriously, whilst I would have been suprised if I'd found a bug in a fairly
well used piece of code like Bind, it has been known to happen.
Thanks for your assistance in helping my understanding of what was happening.
James.
Usual apologies for the disclaimer:
---
This email and any attachments may contain information that is confidential
and subject to legal privilege. If you are not the intended recipient, any use,
dissemination, distribution or duplication of this email and attachments is
prohibited. If you have received this email in error please notify the author
immediately and erase all copies of the email and attachments. The Ministry of
Social Development accepts no responsibility for changes made to this message
or attachments after transmission from the Ministry.
---
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
