Re: Inline-signing feature request: Directly set the signed zone's serial number
Hi, After reinitialising the inline-signing process (for example by removing the journal files or redeploying the master server) the freshly signed zone's serial number will usually be behind the authoritative version on the slaves causing transfers to fail possibly leading to expired signatures, zone expiry, etc. If you redeploy the master server, couldn't you just copy the journal files over from the old server? And, the rest of the time, never remove journal files. Currently, bumping the serial number of the unsigned zones to exceed that of the slaves is required, however it would be /convenient/ to have a one-shot method (perhaps via rndc) for specifying the signed zone serial number such that this doesn't require edits to the unsigned zone files. This is especially useful in bootstrapping scenarios where the zone data is held under strict revision control or generated by some provisioning system that owns the serial number. Am I on my own with this or would others find this useful? Thanks, Terry Tom Schulz Applied Dynamics Intl. sch...@adi.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: bind-9.10.0-P2 memory leak?
... Heh thanks, yeah...initially I was erring on the side of caution and using 9.9.x because it's served us well (~20k recursive clients without any significant problems). Meanwhile we've been keeping a close eye on community comments, and to be honest opinions wax and wane. Just as I think it's stabilized, someone else complains. I suppose sticking to 9.9.x a bit longer is wise. That said, based on the 9.10.1 fixes, we will run it through our own perf tests for comparison. Upgrades are automated and easy, but I'd obviously like to go live with the latest version unless there is a strong technical reason otherwise. FYI, 9.9 is the current Extended Support Version (ESV). If you're looking for a version of BIND with a long period of maintenance, there will be ongoing 9.9.x, 9.9.x+1 etc. releases and interim patches if needed. http://www.isc.org/downloads/software-support-policy/ I mentioned this earlier, but I have been seeing the very large increases in process size with Bind 9.9.5-P1 and 9.9.6b1. I have just installed 9.10.1rc2 on one of our secondary name servers. In time I will be able to see if 9.10.1rc2 shows a bigger increase in process size than 9.9.5-P1 did. I have restarted 9.9.6b1 with max-cache-size 30M on our primary server. Both experiments will take some time before I can tell what is happening. For those seeing this problem on bind 9.10.1, did you upgrade from 9.9.6 or from an earlier version of bind 9.9.*? As mentioned above, I am seeing this problem on 9.9.6. I do not find bind 9.10.1 growing any faster than 9.9.6 does. I restarted bind 9.9.6 with a max-cache-size of 30M. We have 3 views. The inital process size was 36 MB. The process grew to 184 MB. It grew to 596 MB without the max-cache-size being set and was still growing when I restarted it. BUT when I now do an rndc dumpdb -cache, the named_dump.db file contains only the line ; Dump complete and nothing else. So, if you put any limit on the cache size, you will end up with an empty cache. I do believe that there is a bug that needs to be fixed. Tom Schulz Applied Dynamics Intl. sch...@adi.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: bind-9.10.0-P2 memory leak?
On Monday 13/10/2014 at 1:32 pm, sch...@adi.com (Thomas Schulz) wrote: ... Heh thanks, yeah...initially I was erring on the side of caution and using 9.9.x because it's served us well (~20k recursive clients without any significant problems). Meanwhile we've been keeping a close eye on community comments, and to be honest opinions wax and wane. Just as I think it's stabilized, someone else complains. I suppose sticking to 9.9.x a bit longer is wise. That said, based on the 9.10.1 fixes, we will run it through our own perf tests for comparison. Upgrades are automated and easy, but I'd obviously like to go live with the latest version unless there is a strong technical reason otherwise. FYI, 9.9 is the current Extended Support Version (ESV). If you're looking for a version of BIND with a long period of maintenance, there will be ongoing 9.9.x, 9.9.x+1 etc. releases and interim patches if needed. http://www.isc.org/downloads/software-support-policy/ I mentioned this earlier, but I have been seeing the very large increases in process size with Bind 9.9.5-P1 and 9.9.6b1. I have just installed 9.10.1rc2 on one of our secondary name servers. In time I will be able to see if 9.10.1rc2 shows a bigger increase in process size than 9.9.5-P1 did. I have restarted 9.9.6b1 with max-cache-size 30M on our primary server. Both experiments will take some time before I can tell what is happening. For those seeing this problem on bind 9.10.1, did you upgrade from 9.9.6 or from an earlier version of bind 9.9.*? As mentioned above, I am seeing this problem on 9.9.6. I do not find bind 9.10.1 growing any faster than 9.9.6 does. I restarted bind 9.9.6 with a max-cache-size of 30M. We have 3 views. The inital process size was 36 MB. The process grew to 184 MB. It grew to 596 MB without the max-cache-size being set and was still growing when I restarted it. BUT when I now do an rndc dumpdb -cache, the named_dump.db file contains only the line ; Dump complete and nothing else. So, if you put any limit on the cache size, you will end up with an empty cache. I do believe that there is a bug that needs to be fixed. With Freebsd 10.0, I tried the 9.10 leak work around by with max-cache-size, and it didn't stop the named memory foot print from growing to 2+ GB. I need 9.10 for the its white listing of RPZ hits. I'm building a new Freebsd 9.3 VM and bind 9.10. (vmtools doesn't support fbsd 10) Len ___ 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-9.10.0-P2 memory leak?
On Mon, 13 Oct 2014, Thomas Schulz wrote: I restarted bind 9.9.6 with a max-cache-size of 30M. We have 3 views. The inital process size was 36 MB. The process grew to 184 MB. It grew to 596 MB without the max-cache-size being set and was still growing when I restarted it. BUT when I now do an rndc dumpdb -cache, the named_dump.db file contains only the line ; Dump complete and nothing else. So, if you put any limit on the cache size, you will end up with an empty cache. I do believe that there is a bug that needs to be fixed. I wasn't able to reproduce this with 9.9.6 (or a recent master). Can you please send your configuration (like named-checkconf -px) to bind9-bugs AT isc.org? Thank you. ___ 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-9.10.0-P2 memory leak?
Hi Thomas On Mon, Oct 13, 2014 at 02:31:37PM -0400, Thomas Schulz wrote: I restarted bind 9.9.6 with a max-cache-size of 30M. We have 3 views. The inital process size was 36 MB. The process grew to 184 MB. It grew to 596 MB without the max-cache-size being set and was still growing when I restarted it. BUT when I now do an rndc dumpdb -cache, the max-cache-size affects the size of an internal memory context that's used for cache. But the process size is made up of all the memory the program uses (its various memory contexts, memory used outside contexts such as by libraries used by BIND, direct allocations, BSS and other maps). If you want to check how much memory is used by the cache, and if it goes above max-cache-size, enable the statistics channels in the named configuration and dump XML statistics to look at the usage for the cache contexts. If you have max-cache-size set, any unchecked growth above it of the cache contexts is a bug. But don't compare max-cache-size against the process size. Other parts of the process apart from the cache use memory too. Also as Jeremy asked, you may want to share your named configuration with us so we can check it. Mukund pgpGvc4x_Tf1_.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
