I have found the statistics channel useful for getting the active zone configuration - this lets my management GUI autoconfigure validity checks and pull-down menus for zones. This will be especially helpful when the dynamic add/delete zone situation is sorted out. But it's useful now because it avoids having the GUI follow all the nested includes of named's config files -- or, as that's so ugly, the separate configuration that I had before.
However, I ran into a few issues with this approach: o There is no way to distinguish a built-in zone from a user zone. I currently use serial == 0, but that's not guaranteed. Of course, _bind is in the CH domain, but that still leaves the built-in private address zones (like 8.B.D.0.1.0.0.2.IP6.ARPA/IN/internal). o The vast quantity of statistics are quite a lot for a perl XML parser to handle - especially on older machines. (XML::Simple using XML::Parser on a 400MHz machine takes 20 seconds because the structure of the XML generates zillions of deeply nested anonymous hashes!) o I build quite a few data structures, and want to cache them. But it's really hard (computes and lines of code) to separate out the dynamic data (statistics) from the fairly static (configured zones). In fact, the zone serial number, which is not relevant for configuration, is in that section. So it would require field by field decisions, and on-going maintenance. This resulted in the attached patch, which others may find useful (and I'd be really happy if it made it into the next release in some form). It implements the /config URL on the statistics channel. /config returns everything that's "fairly static". (e.g. If it weren't for dynamic zone addition/deletion, you'd find it in a config file - not a zone file or memory.) It uses exactly the same XML structure as the current / URL and in fact uses the same code. It also adds a <type> tag, with the values "builtin" or "user". (This is still based on serial == 0, but perhaps someone can find a better way to make the determination.) Except for this addition, the / URL's output is unchanged. With this, it's possible to do a simple hash of the returned data and invalidate the cache when it differs from the stored hash of the cached copy. This gets the whole thing down to ~1sec even on my slow machine, which is quite tolerable. It should be easy to add any other useful data, as long as the rule that /config must not have rapidly changing data is obeyed. I did not update the XSL to understand that the dynamic stuff is now optional. It just shows up as blank if you use a web browser. A side note - I was surprised that the <view><zones><zone><name> is of the form "name/class/view", since class and view names are available as separate tags. Easy enough to deal with, but it might be worth considering removing the redundant /class/view from the name at some point. I didn't because I wanted to stay compatible with the mainline. The patch only looks large - as kdiff3 would show, it's mostly indentation where I skip over the unwanted statistics when responding to the new URL. About 16 non-whitespace changes, mostly 1 line. Enjoy. --------------------------------------------------------- This communication may not represent the ACM or my employer's views, if any, on the matters discussed.
bind_config_url.patch
Description: Binary data
_______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users