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
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, 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 recursive clients simultaneously, and using the same configuration file on a test machine and turning up the debugging level gives "16-Apr-2010 15:34:37.026 client x.x.x.x#35622: recursion available" Thanks, James Roberts-Thomson -Original Message- From: ma...@isc.org [mailto:ma...@isc.org] Sent: Friday, 16 April 2010 2:57 p.m. To: James Roberts-Thomson Cc: bind-users@lists.isc.org Subject: 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 Please consider the environment before printing this email and its attachments. Avoid printing, or print double-sided if you can. --- 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
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 , 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: Understanding 'format error" Messages
In message <20100415204352.3695b40...@britaine.cis.anl.gov>, b19...@anl.gov wri tes: > 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 > > dnsserver% dig markets.nytimes.wallst.com @209.234.224.42 > > ; <<>> DiG 8.3 <<>> markets.nytimes.wallst.com @209.234.224.42 > ; (1 server found) > ;; res options: init recurs defnam dnsrch > ;; got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > ;; QUERY SECTION: > ;; markets.nytimes.wallst.com, type = A, class = IN > > ;; ANSWER SECTION: > markets.nytimes.wallst.com. 1M IN A 209.234.225.89 > > ;; Total query time: 56 msec > ;; FROM: dnsserver.it.anl.gov to SERVER: 209.234.224.42 209.234.224.42 > ;; WHEN: Thu Apr 15 15:36:39 2010 > ;; MSG SIZE sent: 44 rcvd: 60 > > dnsserver% dig markets.nytimes.wallst.com @209.234.224.42 > > ; <<>> DiG 8.3 <<>> markets.nytimes.wallst.com @209.234.224.42 > ; (1 server found) > ;; res options: init recurs defnam dnsrch > ;; got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > ;; QUERY SECTION: > ;; markets.nytimes.wallst.com, type = , class = IN > > ;; AUTHORITY SECTION: > wallst.com. 1M IN SOA lb-www-p1-bb2-01.mgmt.local. hostmast > er.lb-www-p1-bb2-01.mgmt.local. ( > 390 ; serial > 3H ; refresh > 1H ; retry > 1W ; expiry > 1M ); minimum > > > ;; Total query time: 56 msec > ;; FROM: dnsserver.it.anl.gov to SERVER: 209.234.224.42 209.234.224.42 > ;; WHEN: Thu Apr 15 15:36:56 2010 > ;; MSG SIZE sent: 44 rcvd: 118 > > dnsserver% > > I do not see what the error is in the response to the query. In this case the wrong SOA is being returned. Looks like yet another badly configured load balancer where the backing nameserver has the wrong zone configured, "wallst.com" rather than the correct zone "markets.nytimes.wallst.com". Mark ; <<>> DiG 9.3.6-P1 <<>> +trace markets.nytimes.wallst.com ;; global options: printcmd . 309595 IN NS l.root-servers.net. . 309595 IN NS g.root-servers.net. . 309595 IN NS b.root-servers.net. . 309595 IN NS k.root-servers.net. . 309595 IN NS e.root-servers.net. . 309595 IN NS i.root-servers.net. . 309595 IN NS m.root-servers.net. . 309595 IN NS j.root-servers.net. . 309595 IN NS f.root-servers.net. . 309595 IN NS c.root-servers.net. . 309595 IN NS a.root-servers.net. . 309595 IN NS d.root-servers.net. . 309595 IN NS h.root-servers.net. ;; Received 492 bytes from 127.0.0.1#53(127.0.0.1) in 8 ms com.172800 IN NS a.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. com.172800 IN NS h.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS j.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. com.172800 IN NS l.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. ;; Received 507 bytes from 2001:500:3::42#53(l.root-servers.net) in 184 ms wallst.com. 172800 IN NS dns01.wallst.com. wallst.com. 172800 IN NS dns02.wallst.com. wallst.com. 172800 IN NS dns03.wallst.com. wallst.com. 172800 IN NS ns4.wallst.com. ;; Received 186 bytes from 2001:503:a83e::2:30#53(a.gtld-servers.net) in 177 ms markets.nytimes.wallst.com. 300 IN NS gtm02.wallst.com. markets.nytimes.wallst.com. 300 IN NS gtm03.wallst.com. markets.nyti
Re: Intermittent failures resolving .org domains in BIND 9.7.0 with DLV enabled
> Actually there *is* DNSSEC involved or the query would not have > failed. Yes, sorry. I meant to imply that there is no DNSSEC involved beyond the verification of the covering NSEC that proves the lack of a DLV record. > There is a bug in the BIND 9.7.0-P1 fixes that triggers this. The > fix below is in review at the moment. Interesting - so it sounds like the problems I was seeing with 9.7.0 were probably unrelated. The patch certainly seems to fix the issue with www.bbc.net.uk. I'll run with it for a few days and see if the .org issue I was having earlier recurs. Thanks, -roy ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig +trace
In message , 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
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
Understanding 'format error" Messages
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 dnsserver% dig markets.nytimes.wallst.com @209.234.224.42 ; <<>> DiG 8.3 <<>> markets.nytimes.wallst.com @209.234.224.42 ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; markets.nytimes.wallst.com, type = A, class = IN ;; ANSWER SECTION: markets.nytimes.wallst.com. 1M IN A 209.234.225.89 ;; Total query time: 56 msec ;; FROM: dnsserver.it.anl.gov to SERVER: 209.234.224.42 209.234.224.42 ;; WHEN: Thu Apr 15 15:36:39 2010 ;; MSG SIZE sent: 44 rcvd: 60 dnsserver% dig markets.nytimes.wallst.com @209.234.224.42 ; <<>> DiG 8.3 <<>> markets.nytimes.wallst.com @209.234.224.42 ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; markets.nytimes.wallst.com, type = , class = IN ;; AUTHORITY SECTION: wallst.com. 1M IN SOA lb-www-p1-bb2-01.mgmt.local. hostmaster.lb-www-p1-bb2-01.mgmt.local. ( 390 ; serial 3H ; refresh 1H ; retry 1W ; expiry 1M ); minimum ;; Total query time: 56 msec ;; FROM: dnsserver.it.anl.gov to SERVER: 209.234.224.42 209.234.224.42 ;; WHEN: Thu Apr 15 15:36:56 2010 ;; MSG SIZE sent: 44 rcvd: 118 dnsserver% I do not see what the error is in the response to the query. -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re[2]: Apparent BIND problem doing RBL lookups for Postfix
Hello Nuno, Thursday, April 15, 2010, 9:43:52 AM, you wrote: > 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. 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. Unless I misunderstand your recommendations - it seems like your fix to a broken bind server is to use someone else's bind server. :( While it may solve a symptom, it's not really a fix, and in this case it's unlikely to even solve the symptom either. Thanks for your thoughts though. -Greg > -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)): send
Re: logging forwarding reqs
> Date: Thu, 15 Apr 2010 14:25:35 -0400 > Subject: Re: logging forwarding reqs > From: Jonathan Reed > To: bind-users@lists.isc.org > > 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. Since you don't have access to the Windows boxen, it seems to me that this is a candidate for the "old sniff the firewall" trick. Sniff the DNS traffic on the internal facing connection of your firewall (you DO have a firewall, don't you?) and see which IP addresses the DNS requests are originating from. If from your Windows boxen, then the forwarding is working correctly. (You ARE getting dns requests resolved on the non-windows clients are you not?) If not from the Windows boxen, then there is an error in your setup. Regards, Gregory Hicks - Gregory Hicks | Principal Systems Engineer | Direct: 408.569.7928 People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf -- George Orwell The price of freedom is eternal vigilance. -- Thomas Jefferson "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton ___ 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 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'):
> 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 fet
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: 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 0x940ec38 (fctx 0x932e140(33.229.242.205.zen.spamhaus.org/A)): senddone 14-Apr-2010 14:25:01.658 resolver: debug 3: fctx 0x9
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
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" 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= 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 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:0
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
