Re: Verify raw data within slaves on 9.9.x
If what you want is the basic functionality of "cat", what's wrong with "named-compilezone -with -some -options"? On Jun 14, 2012, at 11:00 AM, Walter Smith wrote: > So essentially if I'm scripting on a slave and would like to check-into-svn > changes within any particular 'raw' zone - I'll still need to rsync that > 'text' zone/file from master... > I wish '/usr/bin/strings' act as '/bin/cat' on this new default 'raw' format > > From: "Spain, Dr. Jeffry A." > To: Walter Smith > Cc: "bind-users@lists.isc.org" > Sent: Monday, June 11, 2012 4:44 PM > Subject: RE: Verify raw data within slaves on 9.9.x > > > What tools/commands I can run to get plain ascii/text data out of modern > > raw/binary on BIND 9.9.x slaves? > > I just want to verify that changes are correct down to the slaves. So - I > > can check-in these changes into svn etc. > > See the ARM under named-checkzone. > http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/man.named-checkzone.html. > For example "named-checkzone -f raw -F text -s relative -j -o > example.com.dumped.db example.com /var/lib/named/example.com.db" > > Jeffry A. Spain > Network Administrator > Cincinnati Country Day School > > > ___ > 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 ___ 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: BIND ignores changes in zonefiles
On Jun 14, 2012, at 5:54 AM, Marian Roess wrote: > Thank you for your quick answer. > >> You've possibly checked all this, but let me ask anyway: >> >> 1. Are you monitoring named logs when reload the zones? Any errors? > > Yes, I do. > > zone cs.uni-dortmund.de/IN: loaded serial 1121661332 > >> 2. Have you run your generated zonefiles through `named-checkzone'? >> Errors? Warnings? (e.g. an underscore in a name?) > > zone cs.uni-dortmund.de/IN: loaded serial 1121661332 > OK > >> 3. You say named is realoding the file with its correct SOA serial >> number. Have you verified by querying named? >> >>dig @127.0.0.1 SOA > > Here might be an error. > > cs.uni-dortmund.de. 86400 IN SOA > waldorf.cs.uni-dortmund.de. hostmaster.cs.uni-dortmund.de. 1121631141 > 14400 1800 360 7200 > > The serialnumber in the SOA record is lower than the serial number BIND > pretends to load in the logs. But why would BIND log to load the right > zone, but use an old one? Check to see if more than one copy of BIND is running. Maybe the new one loaded the new serial but there was already a BIND running with the old. Have you tried "rndc reload cs.uni-dortmund.de" to see if it will re-load the file from disk? ___ 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: about the non-authoritative CNAME
named is paranoid. It discards the rest of the response after processing the CNAME. thanks Mark, that sounds great. -- Email/Jabber/Gtalk: pa...@riseup.net Free DNS Hosting with www.DNSbed.com ___ 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: about the non-authoritative CNAME
In message <4fda9b90.8040...@riseup.net>, pangj writes: > > > In message<4fda970e.9080...@riseup.net>, pangj writes: > >> Hi, > >> > >> If BIND is authoritative for zone a, and is not authoritative for zone > >> b, but zone b is configured in BIND's zone file, and x.zonea.com is > >> CNAME'd to y.zoneb.com. > >> > >> When DNS client queries to this BIND for x.zonea.com, it gets the > >> authoritative answers for both x.zonea.com and y.zoneb.com, certainly > >> y.zoneb.com is a fake one. > >> > >> How DNS client handle this case? > >> Thanks. > > > > It depends on the client and whether the zones are signed or not > > and whether the client is validating responses or not. > > > > Stub clients will almost always trust the complete answer. > > For iterative clients it depends on their level of paranoia. > > > > Thanks Mark. > For a DNS caching only server, for example, BIND, it will validate the > response always, is it? named is paranoid. It discards the rest of the response after processing the CNAME. > -- > Email/Jabber/Gtalk: pa...@riseup.net > Free DNS Hosting with www.DNSbed.com > ___ > 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
Re: about the non-authoritative CNAME
In message<4fda970e.9080...@riseup.net>, pangj writes: Hi, If BIND is authoritative for zone a, and is not authoritative for zone b, but zone b is configured in BIND's zone file, and x.zonea.com is CNAME'd to y.zoneb.com. When DNS client queries to this BIND for x.zonea.com, it gets the authoritative answers for both x.zonea.com and y.zoneb.com, certainly y.zoneb.com is a fake one. How DNS client handle this case? Thanks. It depends on the client and whether the zones are signed or not and whether the client is validating responses or not. Stub clients will almost always trust the complete answer. For iterative clients it depends on their level of paranoia. Thanks Mark. For a DNS caching only server, for example, BIND, it will validate the response always, is it? -- Email/Jabber/Gtalk: pa...@riseup.net Free DNS Hosting with www.DNSbed.com ___ 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: about the non-authoritative CNAME
In message <4fda970e.9080...@riseup.net>, pangj writes: > Hi, > > If BIND is authoritative for zone a, and is not authoritative for zone > b, but zone b is configured in BIND's zone file, and x.zonea.com is > CNAME'd to y.zoneb.com. > > When DNS client queries to this BIND for x.zonea.com, it gets the > authoritative answers for both x.zonea.com and y.zoneb.com, certainly > y.zoneb.com is a fake one. > > How DNS client handle this case? > Thanks. It depends on the client and whether the zones are signed or not and whether the client is validating responses or not. Stub clients will almost always trust the complete answer. For iterative clients it depends on their level of paranoia. -- 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
about the non-authoritative CNAME
Hi, If BIND is authoritative for zone a, and is not authoritative for zone b, but zone b is configured in BIND's zone file, and x.zonea.com is CNAME'd to y.zoneb.com. When DNS client queries to this BIND for x.zonea.com, it gets the authoritative answers for both x.zonea.com and y.zoneb.com, certainly y.zoneb.com is a fake one. How DNS client handle this case? Thanks. ___ 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 handle zones that need to be the same in all views?
Hi. I've been trying to find examples on how to use TSIG to replicate several differents views to a slave server, but I could only find with two views, and I just couldn't figure out how to adapt that example to 3 or more views. Could you send me example on how to accomplish that? Thanks! 2012/6/13 Mark Andrews > > In message <4fd8b4e1.3070...@maxb.eu>, Max Bowsher writes: > > > Mark Andrews wrote: > > >> This really isn't that hard. Just use tsig and transfer the zone > > >> between views on the slave machine. Just ensure that you transfer > > >> from the view that is getting the notify messages from the master. > > > > Thanks Mark, that's definitely a workable (if not very intuitive!) > soluti= > > on. > > No problem. There were a number of ways to do this. Using TSIG > this way is one of the less complicated ways and works when you > don't have multiple addreses to play with. > > You can do a similar trick in older versions using server clauses > to set the tsigs in each view to daisy chain the zone transfer. > It's a lot more error prone however and has other issues. > > > On 13/06/12 14:59, Barry Margolin wrote: > > > I think his problem is that the master only has one view, while the=20 > > > slave has multiple views. > > > > Yes. > > > > Max. > -- > 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 > ___ 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: Verify raw data within slaves on 9.9.x
So essentially if I'm scripting on a slave and would like to check-into-svn changes within any particular 'raw' zone - I'll still need to rsync that 'text' zone/file from master... I wish '/usr/bin/strings' act as '/bin/cat' on this new default 'raw' format From: "Spain, Dr. Jeffry A." To: Walter Smith Cc: "bind-users@lists.isc.org" Sent: Monday, June 11, 2012 4:44 PM Subject: RE: Verify raw data within slaves on 9.9.x > What tools/commands I can run to get plain ascii/text data out of modern > raw/binary on BIND 9.9.x slaves? > I just want to verify that changes are correct down to the slaves. So - I can > check-in these changes into svn etc. See the ARM under named-checkzone. http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/man.named-checkzone.html. For example "named-checkzone -f raw -F text -s relative -j -o example.com.dumped.db example.com /var/lib/named/example.com.db" Jeffry A. Spain Network Administrator Cincinnati Country Day School___ 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: BIND ignores changes in zonefiles
Such problems usually end up in being something stupid, for example, does "pgrep named" return ONE pid ? Or maybe you are looking at log file on one server but dig another one. Did you try to stop named and start it over ? Maybe try to enable statistic-channel and see which serial BIND reports there. Alexander Gurvitz, net-me.net ___ 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: BIND ignores changes in zonefiles
Marian Röß wrote: > > That is what bothers me. Even the debug messages show, that a change is > detected and the zone is loaded into the database. Are you running one copy of named on the server? It might be that you have an old instance of the server running and serving the old zone, and a new instance that failed to bind to its listening sockets (since the old server owns them) but which is successfully loading the new zones and logging about it. Tony. -- f.anthony.n.finchhttp://dotat.at/ Southeast Biscay: Variable 3, becoming southeasterly 4 or 5 later. Slight or moderate, occasionally rough later. Occasional rain. Moderate or good.___ 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: BIND ignores changes in zonefiles
> But his log message showed that it loaded the correct file, or at least > a file with the correct serial number. That is what bothers me. Even the debug messages show, that a change is detected and the zone is loaded into the database. > How about this: does the server use "views"? If the zone is in multiple > views, you may only be updating one of them. We do not use views, the config is very rudimentaly. Greetings -- Marian Röß E-Mail: marian.roess[bei]cs.uni-dortmund.de PGP-Key: 0x446CDCF6 pgpl3DioTGhls.pgp Description: 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: BIND ignores changes in zonefiles
In article , Jan-Piet Mens wrote: > > The serialnumber in the SOA record is lower than the serial number BIND > > pretends to load in the logs. But why would BIND log to load the right > > zone, but use an old one? > > Because it's loading the wrong file? But his log message showed that it loaded the correct file, or at least a file with the correct serial number. How about this: does the server use "views"? If the zone is in multiple views, you may only be updating one of them. -- Barry Margolin Arlington, MA ___ 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: Delegation bit-rot detection?
For the domains that we're primary and authoritative we check the listing of each customer's WHOIS record to confirm they're using the right DNS servers and then query our upstream's DNS server (which is slaving it) to make sure they're responding authoritatively. We also query a public DNS server to make sure the NS records that it returns for the domain are the right DNS servers. This has caught countless customers who let their domain registrations expire or whose third-party website developer moved DNS records to their preferred website host. I can't tell you how many times SMB/SME customers think that their DNS records need to reside with the company that hosts or manages their website. If a customer lets their domain expire and does not respond in a few days to our outreach we just remove the domain. No reason to give our customers different information than the rest of the world (yes, our recursive and authoritative somewhat overlap). Frank From: bind-users-bounces+frnkblk=iname@lists.isc.org [mailto:bind-users-bounces+frnkblk=iname@lists.isc.org] On Behalf Of Fr34k Sent: Thursday, June 14, 2012 8:54 AM To: Phil Mayers; bind-users@lists.isc.org Subject: Re: Delegation bit-rot detection? We are exploring similar audits and opportunities for cleanup. For domains we delegate PTRs, we track NS hostnames (e.g. IN NS ns1.bogus.customer.tld) that have gone NXDOMAIN. If ns1.bogus.customer.tld remains NXDOMAIN for 30+ days, we remove the delegation. The idea behind 30+ days is to allow for a grace period. Why? If the domain expired and caught the owner by surprise, then 30 days allows time for the domain owner to renew before we make any changes (so that we do not waste time removing the delegation to only have to reinstate it). Perhaps a similar approach be worthwhile for auditing the secondary services. That is, parse BIND's config file (source of truth) for all secondary configs, run dedicated auditing tests (e.g. AXFR), record the outcomes, and act upon the defunct configurations per Policy. All that said, I am also interested in what others are doing. I am sure there are better methods out there. Thanks. _ From: Phil Mayers To: "bind-users@lists.isc.org" Sent: Thursday, June 14, 2012 9:19 AM Subject: Delegation bit-rot detection? All, Over the years, we have offered DNS secondary services to various organisations. Some of those organisations are (ahem) fairly small, and lots of the delegations and zone transfers have suffered bit-rot - there are zones delegated to us that I have no records on, and certainly can't AXFR from the masters (in some cases, the masters answer REFUSED as well). I'm wondering if anyone knows of a script that will process our logs looking for "refused" queries, and then post-process these by tracing the delegations and telling me what the nearest enclosing zone is, the NS records that led inbound queries to us, and (if any of the other NS records are responding) the SOA. I could write something, but there are a lot of corner cases, and I'm feeling lazy! OTOH if anyone has any suggestions (other than "ignore the refused", which is what we're currently doing) for dealing with these kinds of things... Cheers, Phil ___ 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 ___ 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: Delegation bit-rot detection?
Phil Mayers wrote: > > I'm wondering if anyone knows of a script that will process our logs looking > for "refused" queries, and then post-process these by tracing the delegations > and telling me what the nearest enclosing zone is, the NS records that led > inbound queries to us, and (if any of the other NS records are responding) the > SOA. One possibility is chiark-named-conf. It is oriented towards config file generation, but it also does a lot of sanity checking. http://www.chiark.greenend.org.uk/ucgi/~ian/git?p=chiark-utils.git;a=tree;f=scripts Tony. -- f.anthony.n.finchhttp://dotat.at/ North Bailey, Fair Isle, Faeroes, South-east Iceland: Mainly northerly or northeasterly 3 or 4, increasing 5 at times. Slight or moderate. Showers. Good. ___ 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: Delegation bit-rot detection?
We are exploring similar audits and opportunities for cleanup. For domains we delegate PTRs, we track NS hostnames (e.g. IN NS ns1.bogus.customer.tld) that have gone NXDOMAIN. If ns1.bogus.customer.tld remains NXDOMAIN for 30+ days, we remove the delegation. The idea behind 30+ days is to allow for a grace period. Why? If the domain expired and caught the owner by surprise, then 30 days allows time for the domain owner to renew before we make any changes (so that we do not waste time removing the delegation to only have to reinstate it). Perhaps a similar approach be worthwhile for auditing the secondary services. That is, parse BIND's config file (source of truth) for all secondary configs, run dedicated auditing tests (e.g. AXFR), record the outcomes, and act upon the defunct configurations per Policy. All that said, I am also interested in what others are doing. I am sure there are better methods out there. Thanks. > > From: Phil Mayers >To: "bind-users@lists.isc.org" >Sent: Thursday, June 14, 2012 9:19 AM >Subject: Delegation bit-rot detection? > >All, > >Over the years, we have offered DNS secondary services to various >organisations. Some of those organisations are (ahem) fairly small, and lots >of the delegations and zone transfers have suffered bit-rot - there are zones >delegated to us that I have no records on, and certainly can't AXFR from the >masters (in some cases, the masters answer REFUSED as well). > >I'm wondering if anyone knows of a script that will process our logs looking >for "refused" queries, and then post-process these by tracing the delegations >and telling me what the nearest enclosing zone is, the NS records that led >inbound queries to us, and (if any of the other NS records are responding) the >SOA. > >I could write something, but there are a lot of corner cases, and I'm feeling >lazy! > >OTOH if anyone has any suggestions (other than "ignore the refused", which is >what we're currently doing) for dealing with these kinds of things... > >Cheers, >Phil >___ >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 > > >___ 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
Delegation bit-rot detection?
All, Over the years, we have offered DNS secondary services to various organisations. Some of those organisations are (ahem) fairly small, and lots of the delegations and zone transfers have suffered bit-rot - there are zones delegated to us that I have no records on, and certainly can't AXFR from the masters (in some cases, the masters answer REFUSED as well). I'm wondering if anyone knows of a script that will process our logs looking for "refused" queries, and then post-process these by tracing the delegations and telling me what the nearest enclosing zone is, the NS records that led inbound queries to us, and (if any of the other NS records are responding) the SOA. I could write something, but there are a lot of corner cases, and I'm feeling lazy! OTOH if anyone has any suggestions (other than "ignore the refused", which is what we're currently doing) for dealing with these kinds of things... Cheers, Phil ___ 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: BIND ignores changes in zonefiles
> The serialnumber in the SOA record is lower than the serial number BIND > pretends to load in the logs. But why would BIND log to load the right > zone, but use an old one? Because it's loading the wrong file? Have you (or somebody else) changed `directory' option or path to master zone file? -JP ___ 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: BIND ignores changes in zonefiles
Thank you for your quick answer. > You've possibly checked all this, but let me ask anyway: > > 1. Are you monitoring named logs when reload the zones? Any errors? Yes, I do. zone cs.uni-dortmund.de/IN: loaded serial 1121661332 > 2. Have you run your generated zonefiles through `named-checkzone'? >Errors? Warnings? (e.g. an underscore in a name?) zone cs.uni-dortmund.de/IN: loaded serial 1121661332 OK > 3. You say named is realoding the file with its correct SOA serial >number. Have you verified by querying named? > > dig @127.0.0.1 SOA Here might be an error. cs.uni-dortmund.de. 86400 IN SOA waldorf.cs.uni-dortmund.de. hostmaster.cs.uni-dortmund.de. 1121631141 14400 1800 360 7200 The serialnumber in the SOA record is lower than the serial number BIND pretends to load in the logs. But why would BIND log to load the right zone, but use an old one? Greetings, Marian -- Marian Roess ___ 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: BIND ignores changes in zonefiles
> We have a script that generates the zonefiles for bind. This script is > working correct, i.e. the files are correctly generated and have no > syntax errors. When adding e.g a CNAME to our database, the script > generates a correct file, including this CNAME. BIND reloads this file > with its correct serial number, but when I dig the CNAME it is not > found. This also does not work with A records. You've possibly checked all this, but let me ask anyway: 1. Are you monitoring named logs when reload the zones? Any errors? 2. Have you run your generated zonefiles through `named-checkzone'? Errors? Warnings? (e.g. an underscore in a name?) 3. You say named is realoding the file with its correct SOA serial number. Have you verified by querying named? dig @127.0.0.1 SOA 4. Is the CNAME at the zone apex? (i.e. #2 will have found this) Regards, -JP ___ 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 ignores changes in zonefiles
Hello List, please be lenient towards me, for it is my first post on this list. I am administrator at the computing faculty at the TU Dortmund and responsible for the nameservers. Since yesterday we have the problem, that BIND is ignoring the changes in our zonefiles. This happened after updating the server from 9.4 to 9.6. We have a script that generates the zonefiles for bind. This script is working correct, i.e. the files are correctly generated and have no syntax errors. When adding e.g a CNAME to our database, the script generates a correct file, including this CNAME. BIND reloads this file with its correct serial number, but when I dig the CNAME it is not found. This also does not work with A records. We are running BIND-9.6-ESV-R7-P1, but this error is reproducible with BIND-9.4-ESV-R5-P1. I would be glad for every hint and advise. Greetings, Marian Roess -- Marian Roess ___ 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: OT: cached memory
On Jun 13, 2012, at 5:02 PM, Dan Letkeman wrote: > I understand the concept, as I have read many documents like that. I > am more interested in a real world example of how much free memory for > caching is recommended for an average server. > > Dan. It depends on many things, but what I'd do to find the optimum cache size is: (1) Start with some limit, say 128 MB. (2) Observe the server's performance over time, and memory usage. (3) Pick some reasonable time, like "I want it to hit the max memory size in 3 days" or "one week" (4) If it reaches the maximum too quickly, add more cache size. I suspect this is one metric that would help greatly to add to the XML stats... Cache hit rate is sort of a standard metric. --Michael ___ 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
