delegation broken after migrating to new BIND config
I migrated our bind resolvers to a new config (new named.conf) and I see delegation broken. How do I trouble-shoot? - The resolvers (are slaves) and are authoritative for zone1.example.com and example.com - the resolvers forward queries to our companies DNS to resolve external names like microsoft.com, isc.com etc - The resolver has views and match same destinations in both old and new config. the zone is zone1.example.com which contains a record name1.zone1.example.com as below: name1.zone1.example.com. NS othername1.example.com. othername1.example.com.A 1.2.3.4 dig @localhost name1.zone1.example.com. # this doesn't give any hint. Here are the steps I tried and still no luck: 1. Compared zone transfer output of zone1.example.com before and after migration, both look similar and contains delegation entry. 2. I tried this and works ok (before and after migration) in both cases indicating that the NS is still reachable and respond to DNS queries before and after migration. dig @othername1.example.com. name1.zone1.example.com. ## Returns 5.6.7.8 as expected ACLs broken 3. Checked cache dump file (db file) - I see the following entry when it works (pre-migration): cache_dump.db:; 1.2.3.4 [srtt 0] [flags ] [ttl 1797] however, the above entry is missing after I migrate to new BIND config. I compared the BIND configs before and after migration and I don't see any significant difference which might cause this issue.. wondering what am I missed? Thanks Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Error while building BIND 9.11 on linux host
These steps helped (openssl-1.0.2j and BIND 9.11 P1) ./config --prefix=/usr/local --openssldir=/usr/local/openssl make make install ### Then BIND can be compiled as below: ./configure —with-openssl=yes make make install named -v BIND 9.11.0-P1 Carl, I will also try RPM in a bit. Wondering if I can get these bundled? - openssl - XML (for stats) - JSON (for stats) - dnstap -multithreading support I will try using traditional approach (config + make + make install) and see if I have success. thanks Blr On Sunday, November 20, 2016 at 4:29:22 PM UTC-8, Carl Byington wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On Sun, 2016-11-20 at 16:12 -0800, blrmaani wrote: > > I am trying to build BIND 9.11 on RHEL linux host and see this error. > > What am I missing? > > I am not sure, but you might want to build a full RPM, possibly starting > from http://www.five-ten-sg.com/mapper/bind > > That source rpm contains a .spec file which does a RH compatible > configure/make/... > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.14 (GNU/Linux) > > iEYEAREKAAYFAlgyP9IACgkQL6j7milTFsEd2wCdHdvMHhc3l/fokiLm4ALNU0K+ > 1jgAmQEZOKhByBo9CX/Dl4LgSd9JEdOz > =1LCv > -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Error while building BIND 9.11 on linux host
Good to know Mark. I retried again using openssl 1.0.2j as below (as a root user): ./config make make install and then tried building BIND 9.11 P1 as below: ./configure --with-openssl=/usr/local/ssl make I see these errors now after several minutes ... -- gcc -shared -o sample.so db.o driver.o instance.o lock.o log.o syncptr.o zone.o \ ../../../../../lib/dns/libdns.a ../../../../../lib/isc/libisc.a -lgssapi_krb5 -L/usr/local/ssl/lib -lcrypto -ldl ../../../../../lib/dns/libdns.a ../../../../../lib/isc/libisc.a -ldl -lz -lrt -lpthread /usr/bin/ld: /usr/local/ssl/lib/libcrypto.a(cryptlib.o): relocation R_X86_64_32 against `OPENSSL_ia32cap_P' can not be used when making a shared object; recompile with -fPIC /usr/local/ssl/lib/libcrypto.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[5]: *** [sample.so] Error 1 make[5]: Leaving directory `/root/BIND911ETC/bind-9.11.0-P1/bin/tests/system/dyndb/driver' make[4]: *** [subdirs] Error 1 make[4]: Leaving directory `/root/BIND911ETC/bind-9.11.0-P1/bin/tests/system/dyndb' make[3]: *** [subdirs] Error 1 make[3]: Leaving directory `/root/BIND911ETC/bind-9.11.0-P1/bin/tests/system' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/root/BIND911ETC/bind-9.11.0-P1/bin/tests' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/root/BIND911ETC/bind-9.11.0-P1/bin' make: *** [subdirs] Error 1 --- Investigating On Sunday, November 20, 2016 at 4:40:47 PM UTC-8, Mark Andrews wrote: > What version of OpenSSL are you trying to compile against? OpenSSL > broken backwards API compatibility with OpenSSL 1.1.0. This has > forced every application that uses OpenSSL to update their code to > cope and OpenSSL took a long time to provide a fully working API. > > We tried building with the early releases and the necessary code > just wasn't yet written. Named uses the low level APIs. > > The next maintainence release of BIND has support for OpenSSL 1.1.0 > but you loose support for GOST. > > Mark > > In message <800c7d82-63b4-4aec-9f12-5e259f48c...@googlegroups.com>, blrmaani > wr > ites: > > I am trying to build BIND 9.11 on RHEL linux host and see this error. > > What am I missing? > > > > ./configure > > make > > > > > > make4: Leaving directory > > `/root/BIND911ETC/bind-9.11.0-P1/lib/isc/x86_32/include' > > make3: Leaving directory `/root/BIND911ETC/bind-9.11.0-P1/lib/isc/x86_32' > > gcc -I/root/BIND911ETC/bind-9.11.0-P1 -I../.. -I./unix/include > > -I./pthreads/include -I./x86_32/include -I./include -I./include > > -I/root/BIND911ETC/bind-9.11.0-P1/lib/dns/include -I../../lib/dns/include > > -D_REENTRANT -DOPENSSL -DPK11_LIB_LOCATION=\"undefined\" -D_GNU_SOURCE > > -g -O2 -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings > > -Wformat -Wpointer-arith -fno-strict-aliasing > > -fno-delete-null-pointer-checks -c aes.c > > aes.c: In function isc_aes128_crypt: > > aes.c:31: error: storage size of c isnt known > > aes.c:31: warning: unused variable c > > > > > > Thanks > > Blr > > ___ > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > > unsubscribe from this list > > > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Error while building BIND 9.11 on linux host
I am trying to build BIND 9.11 on RHEL linux host and see this error. What am I missing? ./configure make make[4]: Leaving directory `/root/BIND911ETC/bind-9.11.0-P1/lib/isc/x86_32/include' make[3]: Leaving directory `/root/BIND911ETC/bind-9.11.0-P1/lib/isc/x86_32' gcc -I/root/BIND911ETC/bind-9.11.0-P1 -I../.. -I./unix/include -I./pthreads/include -I./x86_32/include -I./include -I./include -I/root/BIND911ETC/bind-9.11.0-P1/lib/dns/include -I../../lib/dns/include -D_REENTRANT -DOPENSSL -DPK11_LIB_LOCATION=\"undefined\" -D_GNU_SOURCE -g -O2 -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -fno-delete-null-pointer-checks -c aes.c aes.c: In function ‘isc_aes128_crypt’: aes.c:31: error: storage size of ‘c’ isn’t known aes.c:31: warning: unused variable ‘c’ Thanks Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: merging reverse zone data obtained from two different masters
On Sunday, October 23, 2016 at 2:56:37 PM UTC-7, blrmaani wrote: > We have hosts in two different zones but use same subnet. Zone1 is generated > by Master1 and Zone2 is generated by Master2. > > Slave1 runs BIND and would like to merge the reverses generated on Master1 > and Master2. How do I do this? > > thanks > Blr I know couple of hacky way to achieve this. Just curious if anyone tried it ? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
merging reverse zone data obtained from two different masters
We have hosts in two different zones but use same subnet. Zone1 is generated by Master1 and Zone2 is generated by Master2. Slave1 runs BIND and would like to merge the reverses generated on Master1 and Master2. How do I do this? thanks Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Querying locally on a nameserver - odd behavior
On Wednesday, September 21, 2016 at 8:10:16 AM UTC-7, Graham Clinch wrote: > >>> I have a DNS server (which is both forwarder and authoritative NS) and I > >>> see this odd behavior locally on the host: > >>> > >>> dig @localhost # returns immediately with right response > >>> > >>> dig @ # returns sometimes, timesout most > >>> of the time > > [...] > > during this behavior, I saw lots of UDP packet loss on the host: > > > > netstat -s | egrep -A4 "Udp:" > > ... > > .. > > > > > > I tried similar local queries when traffic reduced (and when UDP pkt loss > > was zero) and both local queries succeeded. > > Which version of Bind are you running? This sounds like an issue I've > seen with prefetch in 9.10 before 9.10.4. > > https://kb.isc.org/article/AA-01315/0/prefetch-performance-in-BIND-9.10.html > > Graham BIND 9.8.x. This behavior is seen when there are flood of NXDOMAIN queries sent to our nameserver running BIND 9.8.x As a short-term fix, we have added our nameservers behind a netscalar VIP and provided additional capacity to hadoop applications. I hope I'll have some time soon to get to the bottom of this problem (or just upgrade to BIND 9.10.x ? :) ) thanks Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
root zone on a nameserver which cannot reach root-servers
We have a DNS server setup where all zones are either slaves or forwards to a internal DNS servers which resolves external names. Questions: 1. Do we still need a root zone (type=hint) ? 2. What is the side effect of having root zone when our nameserver cannot reach root servers? (additional load on DNS if yes what percentage?) Thanks Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Querying locally on a nameserver - odd behavior
On Wednesday, September 21, 2016 at 1:04:50 AM UTC-7, Matus UHLAR - fantomas
wrote:
> On 20.09.16 20:27, blrmaani wrote:
> >I have a DNS server (which is both forwarder and authoritative NS) and I see
> >this odd behavior locally on the host:
> >
> >dig @localhost # returns immediately with right response
> >
> >dig @ # returns sometimes, timesout most of
> >the time
> >
> >
> >I have allow-query {any;} in BIND config and the above is local on
> >the host (obtained via slaving). The listen-on is set to 'any' on port-53
> >
> >What am I missing? Why this odd behavior?
>
> a firewall probably?
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Atheism is a non-prophet organization.
I checked for firewall, didn't find any locally on the host (no tcpwrapper
enabled). Also, during this behavior, I saw lots of UDP packet loss on the host:
netstat -s | egrep -A4 "Udp:"
...
..
I tried similar local queries when traffic reduced (and when UDP pkt loss was
zero) and both local queries succeeded.
Still struggling to identify the root cause.
PS: There were several NXDOMAIN queries (around 95%) sent to this DNS server
during peak hours and NXDOMAIN reduced after business hours.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Querying locally on a nameserver - odd behavior
I have a DNS server (which is both forwarder and authoritative NS) and I see
this odd behavior locally on the host:
dig @localhost # returns immediately with right response
dig @ # returns sometimes, timesout most of
the time
I have allow-query {any;} in BIND config and the above is local on the
host (obtained via slaving). The listen-on is set to 'any' on port-53
What am I missing? Why this odd behavior?
thanks
Blr
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Disabling rate-limit?
>From tcpdump, it appears that customers are receiving delayed response and are >too sensitive for timeouts. The queries they are sending are authoritative i.e the zone is on our nameserver. How do I trouble-shoot this issue? This is really intermittent and hard to reproduce.. thanks Blr On Monday, August 15, 2016 at 7:27:44 PM UTC-7, John Miller wrote: > Hi Blr, > > First things first: if your customers are sending queries, this is > probably about their own recursive queries timing out, rather than > incoming authoritative queries timing out. > > Something else you should check: are your customers receiving a > delayed (say a few seconds) SERVFAIL response, or are they receiving > no response at all? > > There's a different set of options in BIND for recursive rate limiting > versus authoritative rate limiting. > > Recursive queries: > > * recursive-clients > * clients-per-query > * max-clients-per-query > > Running 'rndc status' is a good way to see how close you are to these > limits; you'll see log messages like > > "no more recursive clients: quota reached" > > There's also a newer set of "recursive client rate-limiting" features > available in newer (9.9 and 9.10) versions of BIND, but I'm pretty > sure this doesn't apply to your case. > > Authoritative queries: > https://kb.isc.org/article/AA-00994/0/Using-the-Response-Rate-Limiting-Feature-in-BIND-9.10.html > IIRC, rate-limiting for authoritative queries (called "Response rate > limiting" or "RRL") wasn't enabled by default until BIND 9.10.x, and > required a specific build in BIND 9.9.x. It's not available in BIND > 9.8.x. > > John > > On Mon, Aug 15, 2016 at 9:22 PM, blrmaani <blrma...@gmail.com> wrote: > > I inherited a DNS server which is running BIND 9.8.x. There was a DNS > > incident where our customers complained that they saw query timeouts > > intermittently (Our customers run cassandra/hadoop applications and send > > same queries repeatedly). They also run nscd on their hosts but I was told > > all have same TTL value of 3600 indicating all names expire at the same > > time on thousands of client hosts). > > > > I tried to reproduce the issue by sending hostname.bind queries and I see > > logs similar to the one below: > > > > named[]: limit responses to for > > hostname.bind CH TXT > > named[]: *stop limiting responses to > > for hostname.bind CH TXT > > > > > > I reviewed /etc/named.conf and do not see 'rate-limit' configuration. I am > > confused because BIND ARM says rate-limit is disabled by default. But logs > > indicate otherwise. > > > > ( I did "grep rate /etc/*" and didn't see anything. There are no includes > > in named.conf) > > > > Please advice on how I can disable rate-limit on my DNS server. > > > > > > I did a strings on 'named' binary and see this: > > > > strings /usr/sbin/named | egrep -i rrl > > dns_rrl > > dns_rrl_init > > dns_rrl_view_destroy > > > > What else do I need to check to identify if RRL is enabled? > > > > > > Thanks > > Blr > > ___ > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > > unsubscribe from this list > > > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > > > > -- > John Miller > Systems Engineer > Brandeis University > johnm...@brandeis.edu > (781) 736-4619 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Disabling rate-limit?
I inherited a DNS server which is running BIND 9.8.x. There was a DNS incident where our customers complained that they saw query timeouts intermittently (Our customers run cassandra/hadoop applications and send same queries repeatedly). They also run nscd on their hosts but I was told all have same TTL value of 3600 indicating all names expire at the same time on thousands of client hosts). I tried to reproduce the issue by sending hostname.bind queries and I see logs similar to the one below: named[]: limit responses to for hostname.bind CH TXT named[]: *stop limiting responses to for hostname.bind CH TXT I reviewed /etc/named.conf and do not see 'rate-limit' configuration. I am confused because BIND ARM says rate-limit is disabled by default. But logs indicate otherwise. ( I did "grep rate /etc/*" and didn't see anything. There are no includes in named.conf) Please advice on how I can disable rate-limit on my DNS server. I did a strings on 'named' binary and see this: strings /usr/sbin/named | egrep -i rrl dns_rrl dns_rrl_init dns_rrl_view_destroy What else do I need to check to identify if RRL is enabled? Thanks Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Overriding TTL per resource-record on slave
Sorry for not being clear. Our DNS server scrapes entries from a database and creates a DNS zone entries. Our DNS server is configured as a DNS master i.e type=master in BIND config for this zone. The database is the source of truth for DNS hosts which are in multiple locations and we do not want to modify per resource-record TTL value in the database since it impacts all locations. Our DNS server needs to customized such that TTL values for few 'special' records needs to be customized. How do I modify per resource-record TTL on our DNS master? On Tuesday, July 26, 2016 at 11:14:19 AM UTC+5:30, blrmaani wrote: > We slave a zone and would like to override default TTL for bunch of > resource-records. What is the right way to do it? > > For example, here are few records for which we have to customize TTLs: > > host1.zone1.com.: > default_ttl = 300 > preferred_ttl = 3600 > > host2.zone1.com: > default_ttl = 300 > preferred_ttl = 86400 > > Since we want these preferred TTL values only for few regions, we don't want > to make changes on our hidden master and prefer to do it on the slave sitting > in a specific region. > > My Idea is to run a dynamic update (nsupdate) wrapper script to update TTL > entries for desired resource-records on our slave. Is there a better way to > achieve this? > > thanks > Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Overriding TTL per resource-record on slave
We slave a zone and would like to override default TTL for bunch of resource-records. What is the right way to do it? For example, here are few records for which we have to customize TTLs: host1.zone1.com.: default_ttl = 300 preferred_ttl = 3600 host2.zone1.com: default_ttl = 300 preferred_ttl = 86400 Since we want these preferred TTL values only for few regions, we don't want to make changes on our hidden master and prefer to do it on the slave sitting in a specific region. My Idea is to run a dynamic update (nsupdate) wrapper script to update TTL entries for desired resource-records on our slave. Is there a better way to achieve this? thanks Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
what does "max-ncache-ttl 0;" mean?
man pages for named.conf says "max-ncache-ttl " and only talks about default values and max values - no mention of minimum-value. Does "max-ncache-ttl 0;" mean never cache negative queries (queries resulting in NXDOMAIN) or does it mean cache negative queries forever? Too lazy to test this option or look bind code :), hence posting here - apologies in advance..!! Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Intermittent NXDOMAIN for a name we are forwarding
On Sunday, February 21, 2016 at 8:46:19 PM UTC-8, Mark Andrews wrote: > In message <2f868c2b-d04b-4caf-abd7-8176352cc...@googlegroups.com>, blrmaani > wr > ites: > > On Friday, February 19, 2016 at 5:09:02 PM UTC-8, blrmaani wrote: > > > We have a DNS setup where we forward a name in one domain to 5 external > > > nam > > eservers. We see NXDOMAIN error intermittently (once in couple of weeks). > > How > > do I debug this issue? > > > > > > I took a cache dump on our DNS and 2 out of 5 nameserver IPs appear in > > > "Una > > ssociated entries" when the problem happens. > > > > > > Any advice to troubleshoot this issue is greatly appreciated. > > > > > > Thanks > > > Blr > > > > the cache dump also has this entry (myname.mydomain.com is name I am > > interest > > ed in) > > > > myname.mydomain.com 10324 \-ANY ;-$NXDOMAIN > > > > Which probably means if anyone requests for myname.mydomain.com, they will > > be > > handed NXDOMAIN for upto 10324 seconds from now.. > > Correct. > > > Our current work around is to restart named (which cache) or we could do a > > 'r > > ndc flush'. > > > > Question: Is there a BIND option to say 'Don't cache myname.mydomain.com > > for > > NXDOMAIN error code?' > > No. Fix the source of the NXDOMAIN. Ask all the external nameservers > for "myname.mydomain.com type666" and see what they respond with. If > it is NXDOMAIN then you have the source(s) if the NXDOMAIN. > > e.g. > dig @server myname.mydomain.com type666 > > This is a case of Garbage In (NXDOMAIN) - Garbage Out (NXDOMAIN). > > > Alternatively, I can have a local query for this and flush cache if error > > cod > > e is NXDOMAIN, but is hacky.. I would like a config option > > > > ___ > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > > unsubscribe > > from this list > > > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org Thanks a lot for the responses .. I ran dig several times in a loop querying for the name with type=type666 and see only SERVFAIL. The NXDOMAIN occurs approx once in 2 weeks (per incident report). I guess I have to run several iterations of queries to see NXDOMAIN.. I see this in the cache dump: ... ... ; authauthority myname.mydomain.com 10324 \-ANY ;-$NXDOMAIN ... ... ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Intermittent NXDOMAIN for a name we are forwarding
On Friday, February 19, 2016 at 5:09:02 PM UTC-8, blrmaani wrote: > We have a DNS setup where we forward a name in one domain to 5 external > nameservers. We see NXDOMAIN error intermittently (once in couple of weeks). > How do I debug this issue? > > I took a cache dump on our DNS and 2 out of 5 nameserver IPs appear in > "Unassociated entries" when the problem happens. > > Any advice to troubleshoot this issue is greatly appreciated. > > Thanks > Blr the cache dump also has this entry (myname.mydomain.com is name I am interested in) myname.mydomain.com 10324 \-ANY ;-$NXDOMAIN Which probably means if anyone requests for myname.mydomain.com, they will be handed NXDOMAIN for upto 10324 seconds from now.. Our current work around is to restart named (which cache) or we could do a 'rndc flush'. Question: Is there a BIND option to say 'Don't cache myname.mydomain.com for NXDOMAIN error code?' Alternatively, I can have a local query for this and flush cache if error code is NXDOMAIN, but is hacky.. I would like a config option ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Intermittent NXDOMAIN for a name we are forwarding
We have a DNS setup where we forward a name in one domain to 5 external nameservers. We see NXDOMAIN error intermittently (once in couple of weeks). How do I debug this issue? I took a cache dump on our DNS and 2 out of 5 nameserver IPs appear in "Unassociated entries" when the problem happens. Any advice to troubleshoot this issue is greatly appreciated. Thanks Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Extracting stats from BIND XML stats file : issues
On Wednesday, January 13, 2016 at 11:34:16 AM UTC-8, blrmaani wrote: > Hi, > I am trying to get Ipv4 query rate for our DNS server. I am taking 2 > snapshots with a delay of 60 seconds between these snapshots. > > curl : > /tmp/snapshot1.xml > sleep 60 > curl : > /tmp/snapshot2.xml > > > I am calculating queryrate as below > > query_rate = (Queryv4_value2 - Queryv4_value1) / (current_time2 - > current_time1) > > where Queryv4 values are the values extracted from XML file and current_time > are the values from XML files ( and I am converting this to epoch to get > number of seconds between these snapshots which is typically 60 seconds) > > 2012-08-07T21:47:36Z > > Here is the issue: > I am sending approx 200 'A' queries to the DNS server and my above > calculation is showing a value of 2 queries-per-second. > > What am I doing wrong? > > thanks > Blr Sorry, missed some references during earlier post: https://deepthought.isc.org/article/AA-00769/0 The time extracted from XML file is as below: 2012-08-07T21:47:36Z The Queryv4 from XML looks as below: ... Queryv4 31129 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Extracting stats from BIND XML stats file : issues
Hi, I am trying to get Ipv4 query rate for our DNS server. I am taking 2 snapshots with a delay of 60 seconds between these snapshots. curl : > /tmp/snapshot1.xml sleep 60 curl : > /tmp/snapshot2.xml I am calculating queryrate as below query_rate = (Queryv4_value2 - Queryv4_value1) / (current_time2 - current_time1) where Queryv4 values are the values extracted from XML file and current_time are the values from XML files ( and I am converting this to epoch to get number of seconds between these snapshots which is typically 60 seconds) 2012-08-07T21:47:36Z Here is the issue: I am sending approx 200 'A' queries to the DNS server and my above calculation is showing a value of 2 queries-per-second. What am I doing wrong? thanks Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Did anyone try to extract query-rate etc using xml-stats?
Latest version of BIND supports BIND stats via http i.e we can do this (assuming appropriate configs already done in named.conf for this to work): curl : > bind-stats.xml What other tools are available to read this XML file and extract stats? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Panic due to insist assertion error in BIND 9.6.2-P2
On Thursday, December 3, 2015 at 2:30:24 AM UTC-8, manasa gowda wrote: > Hi, > > > Bind version used is 9.6.2-P2. > Named crashed (In panic State) with INSIST Assertion error. The following is > backtrace > > > > #2 0x0041b635 in assertion_failed (file=0x5b2e78 > "src/contrib/bind9/lib/isc/unix/socket.c", line=2605, > type=isc_assertiontype_insist, cond=0x5b420f "!sock->pending_recv") > atsrc/contrib/bind9/bin/named/main.c:162 > #3 0x0056f723 in dispatch_recv (sock=) > atsrc/contrib/bind9/lib/isc/unix/socket.c:2605 > #4 process_fd (writeable=, readable=, fd=513, > manager=) atsrc/contrib/bind9/lib/isc/unix/socket.c:3256 > #5 process_fds (nevents=, events=, > manager=) at src/contrib/bind9/lib/isc/unix/socket.c:3322 > #6 watcher (uap=0x8022300c0) atsrc/contrib/bind9/lib/isc/unix/socket.c:3581 > #7 0x00080198f1bc in thread_start (curthread=0x802205600) > at../../../../../lib/libthr/thread/thr_create.c:292 > > > I did a google search but I found the insist assertion error with other bind > versions also. Can you please help me in finding it out the reason for this > panic. Also tell me in which version of the bind this insist assertion > failure due to pending receive on the socket is fixed. > > > Regards & Thanks, > Manasa S Short answer - you are using a vulnerable version of BIND, upgrade it.. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: putting several master DNS hosts behind a vip
On Thursday, December 10, 2015 at 9:04:48 AM UTC-8, Bob Harold wrote: > On Wed, Dec 9, 2015 at 6:32 PM, blrmaani <blrm...@gmail.com> wrote: > Hi, > > I would like to put 4 DNS masters behind a vip and have several slaves > doing the zone transfer from the VIP-IP. Is this normal? > > > > The usual approach is to have slaves getting zone transfers from multiple > masters. What is the disadvantage of having slaves using just the vip and > have all masters behind the vip? > > > > thanks > > Blr > > > As others have said, I think the recommended approach is to do zone transfers > to the real servers. That is what I do, and it works well. > > > -- > Bob Harold > Thanks all. Somewhat related topic - when do you use a combination of load-balancer and DNS? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
putting several master DNS hosts behind a vip
Hi, I would like to put 4 DNS masters behind a vip and have several slaves doing the zone transfer from the VIP-IP. Is this normal? The usual approach is to have slaves getting zone transfers from multiple masters. What is the disadvantage of having slaves using just the vip and have all masters behind the vip? thanks Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.9.7 complains and dies if you use same zonefile for multiple zones
Hi, named exits with failure on my host when I try to use same physical file for multiple zones: /var/log/all look something like below ... - starting BIND 9.10.2rc1 -u bind -t /var/named -f ... writeable file 'slave/zone1.txt': already in use: name.conf:1221 writeable file 'slave/zone2.txt': already in use: name.conf:1285 writeable file 'slave/zone3.txt': already in use: name.conf:1391 ... loading configuration: failure exiting (due to fatal error) ... -- end log --- BIND 9.9.6 works ok and the above problem is seen while using BIND 9.9.7 or higher versions. I guess this is a bug because I would like to use same physical files for multiple zones (atleast we have been using it in our setup since several years now ..) Thoughts? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
recursive-clients : recommended value for a high traffic recursive nameserver
Our nameservers take upto 10KQPS (mostly NOERROR type most of the time). Twice or thrice a week, I have seen upto 10% of the queries are SERVFAIL and we have started exceeding the default value of 2000 for recursive-clients settings in BIND 9.9.x. Is there a recommended value for recursive-clients option assuming huge number of SERVFAIL queries once in a 2/3 days? I'm not convinced to increase it to some arbitrary huge number 20,000 or 200,000. I am looking for answer like - if your peak SERVFAIL queries are 2000/second, then your recursive-clients value should be N. Please help! thanks in advance Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND10 : how do I import zone files stored in mysql to BIND10 ?
Is there a easy way to import zone files stored in Mysql DB to Bind10? I checked for all the commands available here: http://bind10.isc.org/docs/bind10-guide.html and didn't find anything. Thanks Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND10 : how do I import zone files stored in mysql to BIND10 ?
Thanks. ok, so, If I have mysql DNS tables converted to sqlite3 format (binary files) and then upload to BIND10, how do I do it? I will also try digging code meanwhile .. Thanks Blr On Monday, December 16, 2013 3:08:13 PM UTC-8, Jeremy C. Reed wrote: On Mon, 16 Dec 2013, blrmaani wrote: Is there a easy way to import zone files stored in Mysql DB to Bind10? I checked for all the commands available here: http://bind10.isc.org/docs/bind10-guide.html and didn't find anything. BIND10 currently doesn't support MySQL. (There was some experimental research but not completed.) BIND10 does support SQLite3 and static text master files. You may need to convert your data to other format first. Sorry we don't yet have docs on the database schema. Here is the code: http://bind10.isc.org/docs/developers/cpp/dc/d2c/sqlite3__accessor_8cc_source.html Jeremy C. Reed ISC ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to suppress ADDITIONAL SECTION per zone
We are noticing that a handful of our domains are being used for amplification attacks and we would like to reduce outgoing (DNS response) packet size. One solution is to reduce the additional sections in the response for these handful zones and I would like to know if there is any way to add something similar to additional-from-auth no per zone basis and achieve what I want. On Monday, June 24, 2013 1:13:24 AM UTC-7, Steven Carr wrote: On 24 June 2013 08:14, Matus UHLAR - fantomas uh...@fantomas.sk wrote: You still have not answered my question, so I repeat it: What is the point of your question? I think what Matus wants to know is your reasoning/problem/issue about not returning records from the cache for those zones? The answer is no you can't restrict it to zones only to global or a view, but if you can give us some more information on what/why then we may be able to help come up with some other solution that would help. Steve ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to suppress ADDITIONAL SECTION per zone
Yes, works in Global view. I am trying to prevent additional records being sent from a selected list of zone in our configuration.. blr On Friday, June 21, 2013 11:26:25 AM UTC-7, Lawrence K. Chen, P.Eng. wrote: I thought I had read somewhere (which I can't locate), that additional-from-auth can be used in global or view scope. - Original Message - On 21.06.13 02:00, blrmaani wrote: The additional-from-auth yes_or_no ; option is a global option. I would like to know if there is a per-zone configuration to do the same in BIND9 configuration? I couldn't find it in BIND9 ARM. What is the point of your question? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. On the other hand, you have different fingers. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator For: Enterprise Server Technologies (EST) -- SafeZone Ally Snail: Computing and Telecommunications Services (CTS) Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102 Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkc...@ksu.edu Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
How to suppress ADDITIONAL SECTION per zone
The additional-from-auth yes_or_no ; option is a global option. I would like to know if there is a per-zone configuration to do the same in BIND9 configuration? I couldn't find it in BIND9 ARM. Thanks! Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
querying TLD nameservers - limitations
I am developing a monitoring script for internal use and this requires extensive querying of TLD nameservers (a .. m).tld servers. Questions: 1. Are there any rate limitations imposed by TLD servers i.e these servers allows only certain number of DNS queries per IP per second? 2. Are there other limitations I should be aware of while developing my script? Any experience among this group members in developing these kind of scripts using Net::DNS::Resolver perl module? Thanks! Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to flush MX records from the cache
On Wednesday, February 27, 2013 8:41:08 PM UTC-8, Abdul Khader wrote: Dear All, Is there a way to flush MX records from the cache of a caching DNS server ? Thanks Abdul Khader Also, just try 'rndc' on command prompty - it shows various rndc options for flush subcommand. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: querying TLD nameservers - limitations
hmm.. I see delay in response to some of my queries.. wondering if its our network? On Sunday, March 24, 2013 5:02:57 PM UTC-7, Liu Mingxing wrote: According to my experience, less restriction is imposed by TLD operator because TLD servers have sufficient ability and it is not secure for their service to limit, especially when too much limitations are added. Liu Mingxing From: blrmaani Date: 2013-03-25 07:55 To: comp-protocols-dns-bind Subject: querying TLD nameservers - limitations I am developing a monitoring script for internal use and this requires extensive querying of TLD nameservers (a .. m).tld servers. Questions: 1. Are there any rate limitations imposed by TLD servers i.e these servers allows only certain number of DNS queries per IP per second? 2. Are there other limitations I should be aware of while developing my script? Any experience among this group members in developing these kind of scripts using Net::DNS::Resolver perl module? Thanks! Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-...@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Dynamically Reducing TTL of few selected ResourceRecords
Our development team complains about waiting for an hour for the deleted resource records to disappear from recursive resolver cache. I thought of changing the $TTL value to 1 for that zone but realize that its not efficient. Are there any BIND specific options to support this? I know I can have a cron to flush cache of selected records, but a BIND option to support this would be nice.. Thanks Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig to a nameserver from a host in particular subnet fails
On Wednesday, December 14, 2011 4:36:24 PM UTC-8, Barry Margolin wrote: In article mailman.542.1323902502.68562.bind-us...@lists.isc.org, : Our email group have been complaining about a issue of email sent by certain users bouncing and I started debugging and found out that those users are using email-servers in subnet1. Emails sent out by users in subnet2 were OK. The email-client-hosts use dns-recursive-resolvers depending on their location. The names being queried by email-client-hosts are external names (not in our named config) and our recursive resolvers recurse and gets response to these queries as expected. Summary of my investigation: # dns-recursive-resolver1 is in subnet1 # I execute this on dns-recursive-resolver1 and the query times out dig @other-auth-nameserver name1.com. A# TIMEOUT dig @other-auth-nameserver name1.com. MX # TIMEOUT # dns-recursive-resolver2 is in subnet2 # I execute the following dig command on dns-recursive-resolver2 and it returns response (A record) as # expected. dig @other-auth-nameserver name1.com. A# OK - responds correctly dig @other-auth-nameserver name1.com. MX # OK - responds correctly I spoke to the sysadmin who maintains 'other-auth-nameserver' and he responded that they are NOT 'black-hole'ing or 'bogus'ing subnet1 in named.conf on 'other-auth-nameserver'. Also, they don't have any network ACL or firewall config to block DNS queries from subnet1. Question: What else should I be looking? Do packet captures on both networks, and see where the DNS request and response packets are getting lost. That won't explain the cause, but it will narrow down where you should be looking for the problem. -- Barry Margolin Arlington, MA Thanks. The difficult part here is to co-ordinate with external party. The external sysadmin says its the problem in our network i.e we are dropping incoming DNS packet. I guess I should check with our network team to dig into this.. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursive-clients recommended values
I On Thursday, July 12, 2012 3:49:27 AM UTC-7, Niall O#39;Reilly wrote: On 12 Jul 2012, at 03:21, blrmaani wrote: gt; I searched earlier posts but noticed that people are recommending it to just increase it to suppress the errors in log. gt; gt; Any pointers on this? If it#39;s set too low for your normal operating circumstances, you do need to increase it. I#39;ve never needed to do this, as the default values just works for me. In abnormal operating circumstances, it#39;s probably neither posssible, nor useful to try, to eliminate the log messages. See, for example, https://lists.isc.org/pipermail/bind-users/2009-August/077589.html. Best regards, Niall O#39;Reilly I saw a related post and response in other group. http://osdir.com/ml/network.dns.bind.user/2003-07/msg00042.html I am still trying to figure out the '90 second' part... thanks Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
recursive-clients recommended values
Sorry for the repeat post.. but I know that the value of 'recursive-clients' option is based on: 1. Query rate 2. RAM size and various other factors. I vaguely recollect that it is 90 x query-rate x something , but I forgot why... I searched earlier posts but noticed that people are recommending it to just increase it to suppress the errors in log. Any pointers on this? thanks blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Recommended value for max-cache-size for cache-only shared hosts..
We are planning to use cache-only BIND configuration on our hosts. These hosts are shared hosts i.e BIND runs along with other applications on these hosts. RAM size on these hosts = 8GB and hard- disk size=500GB. Question: what is the recommended configuration for 'max-cache-size' for optimum usage ? I was thinking to use the default value of 32M.. any suggestions.. thanks blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dig to a nameserver from a host in particular subnet fails
Our email group have been complaining about a issue of email sent by certain users bouncing and I started debugging and found out that those users are using email-servers in subnet1. Emails sent out by users in subnet2 were OK. The email-client-hosts use dns-recursive-resolvers depending on their location. The names being queried by email-client-hosts are external names (not in our named config) and our recursive resolvers recurse and gets response to these queries as expected. Summary of my investigation: # dns-recursive-resolver1 is in subnet1 # I execute this on dns-recursive-resolver1 and the query times out dig @other-auth-nameserver name1.com. A# TIMEOUT dig @other-auth-nameserver name1.com. MX # TIMEOUT # dns-recursive-resolver2 is in subnet2 # I execute the following dig command on dns-recursive-resolver2 and it returns response (A record) as # expected. dig @other-auth-nameserver name1.com. A# OK - responds correctly dig @other-auth-nameserver name1.com. MX # OK - responds correctly I spoke to the sysadmin who maintains 'other-auth-nameserver' and he responded that they are NOT 'black-hole'ing or 'bogus'ing subnet1 in named.conf on 'other-auth-nameserver'. Also, they don't have any network ACL or firewall config to block DNS queries from subnet1. Question: What else should I be looking? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Controlling many DNS servers using rndc
What is the best approach to control 100s of DNS servers using rndc ? All these servers run BIND 9.3.x and are unix hosts. I was thinking about a script which does a ssh to each of these hosts in sequence and execute 'rndc command'. But I was looking for much more efficient/parallel way to do this.. thoughts? Blr ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named’s “/dev/random error on AIX
Can't see what you posted.. can you post as a text? From subject message it appears that you see /dev/random failure in syslog. What is the impact? Do you see issues in dnssec-keygen etc? On Jan 8, 10:47 pm, Fuhua Zhang harr...@21cn.com wrote: This is a multi-part message in MIME format. --===1396204079421272685== Content-Type: multipart/alternative; boundary==_NextPart_000_007A_01C97250.199BA270 This is a multi-part message in MIME format. --=_NextPart_000_007A_01C97250.199BA270 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 TXkgQUlYNS4zIHN5c3Rlcm0gZG9lcyBoYXZlIGEgL2Rldi9yYW5kb20gYW5kIC9kZXYvdXJhbmRv baO6DQoNCmRuczg6LyNjZCAvZGV2DQpkbnM4Oi9kZXYjbHMgLWwgKnJhbmQqDQpjcnctci0tci0t ICAgIDEgcm9vdCAgICAgc3lzdGVtICAgICAgIDM5LCAgMCBEZWMgMTYgMTM6NDIgcmFuZG9tDQpj cnctci0tci0tICAgIDEgcm9vdCAgICAgc3lzdGVtICAgICAgIDM5LCAgMSBEZWMgMTYgMTM6NDIg dXJhbmRvbQ0KDQphbmQNCg0KdHpkbnM4Oi8jb2RtZ2V0IEN1RHZEciB8IGdyZXAgLXAgcmFuZG9t DQpDdUR2RHI6DQogICAgICAgIHJlc291cmNlID0gImRkaW5zIg0KICAgICAgICB2YWx1ZTEgPSAi cmFuZG9tIg0KICAgICAgICB2YWx1ZTIgPSAiMzkiDQogICAgICAgIHZhbHVlMyA9IA0KDQp0aGUg ZXJyb3IgbWVzc2FnZXMgc3RpbGwgY2FtZSBvdXQgYXMgZm9sbG93czoNCg0KZG5zODojLi9uYW1l ZCAtZyAtZCA5OQ0KLi4uLg0KMDktSmFuLTIwMDkgMTE6NDE6NDYuOTU0IHNldCBtYXhpbXVtIHN0 YWNrIHNpemUgdG8gMjE0NzQ4MzY0NjogWW91IG11c3QgdXNlIHRoZSBrZXlib2FyZCB0byBjcmVh dGUgZW50cm9weSwgc2luY2UgeW91ciBzeXN0ZW0gaXMgbGFja2luZw0KIC9kZXYvcmFuZG9tIChv ciBlcXVpdmFsZW50KQ0KDQoNCjA5LUphbi0yMDA5IDExOjQxOjQ2Ljk1NCBzZXQgbWF4aW11bSBk YXRhIHNpemUgdG8gMjE0NzQ4MzY0NzogWW91IG11c3QgdXNlIHRoZSBrZXlib2FyZCB0byBjcmVh dGUgZW50cm9weSwgc2luY2UgeW91ciBzeXN0ZW0gaXMgbGFja2luZw0KIC9kZXYvcmFuZG9tIChv ciBlcXVpdmFsZW50KQ0KDQoNCjA5LUphbi0yMDA5IDExOjQxOjQ2Ljk1NCBzZXQgbWF4aW11bSBj b3JlIHNpemUgdG8gMjE0NzQ4MzY0NzogWW91IG11c3QgdXNlIHRoZSBrZXlib2FyZCB0byBjcmVh dGUgZW50cm9weSwgc2luY2UgeW91ciBzeXN0ZW0gaXMgbGFja2luZw0KIC9kZXYvcmFuZG9tIChv ciBlcXVpdmFsZW50KQ0KDQoNCjA5LUphbi0yMDA5IDExOjQxOjQ2Ljk1NCBzZXQgbWF4aW11bSBv cGVuIGZpbGVzIHRvIC0xOiBZb3UgbXVzdCB1c2UgdGhlIGtleWJvYXJkIHRvIGNyZWF0ZSBlbnRy b3B5LCBzaW5jZSB5b3VyIHN5c3RlbSBpcyBsYWNraW5nDQogL2Rldi9yYW5kb20gKG9yIGVxdWl2 YWxlbnQpDQoNCi4uLi4NCg0KMDktSmFuLTIwMDkgMTE6NDE6NDcuMTMzIGxvYWRfY29uZmlndXJh dGlvbjogWW91IG11c3QgdXNlIHRoZSBrZXlib2FyZCB0byBjcmVhdGUgZW50cm9weSwgc2luY2Ug eW91ciBzeXN0ZW0gaXMgbGFja2luZw0KIC9kZXYvcmFuZG9tIChvciBlcXVpdmFsZW50KQ0KDQp0 aGFua3MuDQpoYXJyeQ0K --=_NextPart_000_007A_01C97250.199BA270 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC41NzMwLjEzIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0KPEJP RFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+DQo8RElWPjxGT05UIHNpemU9 Mj5NeSBBSVg1LjMgc3lzdGVybSBkb2VzIGhhdmUgPC9GT05UPjxGT05UIHNpemU9Mz5hIA0KL2Rl di9yYW5kb20mbmJzcDthbmQgL2Rldi91cmFuZG9to7o8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ZG5zODovI2NkIC9kZXY8QlI+ZG5zODovZGV2I2xz IC1sIA0KKnJhbmQqPEJSPmNydy1yLS1yLS0mbmJzcDsmbmJzcDsmbmJzcDsgMSByb290Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0Kc3lzdGVtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDM5LCZuYnNwOyAwIERlYyAxNiAxMzo0MiANCnJhbmRvbTxCUj5jcnctci0tci0tJm5i c3A7Jm5ic3A7Jm5ic3A7IDEgcm9vdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCnN5c3RlbSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzOSwmbmJzcDsgMSBEZWMgMTYgMTM6 NDIgDQp1cmFuZG9tPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+YW5kPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+dHpkbnM4Oi8jb2Rt Z2V0IEN1RHZEciB8IGdyZXAgLXAgDQpyYW5kb208QlI+Q3VEdkRyOjxCUj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVzb3VyY2UgPSANCiJkZGlucyI8QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZhbHVlMSA9IA0KInJhbmRv bSI8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZhbHVlMiA9 IA0KIjM5IjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmFs dWUzID0gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+dGhlIGVycm9yIG1lc3NhZ2VzIHN0aWxsIGNhbWUgb3V0IGFz IGZvbGxvd3M6PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PEJSPmRuczg6Iy4vbmFt ZWQgLWcgLWQgOTk8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4uLi4uPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+MDktSmFuLTIwMDkgMTE6NDE6NDYuOTU0IHNldCBtYXhp bXVtIHN0YWNrIHNpemUgdG8gMjE0NzQ4MzY0NjogDQpZb3UgbXVzdCB1c2UgdGhlIGtleWJvYXJk IHRvIGNyZWF0ZSBlbnRyb3B5LCBzaW5jZSB5b3VyIHN5c3RlbSBpcyANCmxhY2tpbmc8QlI+Jm5i c3A7L2Rldi9yYW5kb20gKG9yIGVxdWl2YWxlbnQpPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjxGT05UIHNpemU9Mj4NCjxESVY+PEJSPjA5LUphbi0y MDA5IDExOjQxOjQ2Ljk1NCBzZXQgbWF4aW11bSBkYXRhIHNpemUgdG8gMjE0NzQ4MzY0NzogWW91
