Bugzilla – Bug 1233
per view stub-zone
Last modified: 2017-03-18 04:20:00 CET
I started looking/thinking into implementing per-view stub-zones. while per view local-zone/local-data allows providing custom "authoritative" answers based on subnet, if the number of record increases, it may be better to use custom stub-zones rather.
First off, I was wondering if this was on your radar somehow and saw this has potential evolution of views, and if you had any ideas on how to implement that.
As much as I can tell, the easy part would be to have a per view `struct iter_hints *hints;` which we can get done when loading up the config.
in worker.c, we can find out the view associated with a client with `acl_addr_lookup` and this will need to be carried around within the module_state in order to be able to find out the right servers to query. This may be more challenging.
Then, there is caching. It would also mean that entries for a view's stub-zone should be cached in a separate cache from the global cache, hence the need for a per view cache.
What is your opinion on this?
Checking in to see what is your point of you on this feature request. I am willing to work on this, but want to make sure we are on the same page and this could make it to master, or if there is other alternative you can think of that I am missing.
Yes, our plan is to extend the configuration options that can be used in views. We see stub and forwarder support as the next milestone for views.
This indeed requires a view specific cache. Combining this with ECS will make it even more challenging.
Great to hear. I will happily carve some time to contribute to this in any ways possible.