BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-03-01T09:43:01Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2257Follow-up from "use netmgr for xfrin"2022-03-01T09:43:01ZOndřej SurýFollow-up from "use netmgr for xfrin"The following discussion from !4246 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4246#note_175084): (+1 comment)
> This is the last weird thing:
>
> ...The following discussion from !4246 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4246#note_175084): (+1 comment)
> This is the last weird thing:
>
> a) how do we get here with the (previous) transfer still attached?
> b) should this be `dns_xfrin_shutdown(&zone->xfr);`?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2098Move wire_test to standalone tool with man page and such...2023-11-02T17:00:02ZOndřej SurýMove wire_test to standalone tool with man page and such...The following discussion from !4006 should be addressed:
- [ ] @each started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4006#note_156160): (+3 comments)
> We did this a while ago, but I had to revert...The following discussion from !4006 should be addressed:
- [ ] @each started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4006#note_156160): (+3 comments)
> We did this a while ago, but I had to revert it (see commit e45be9d1349). It's used for fuzz testing as well as system tests. I also use it myself sometimes for converting DNS data to and from wire format, and I know I'm not the only one because someone at infoblox asked me to restore it as part of the regular build instead of the test build.
>
> Rather than moving it to bin/tests/system I wonder if we should consider putting it in bin/tools, like we did with named-journalprint or named-rrchecker or nsec3hash.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1642lib/dns/zone.c refactoring2023-11-02T16:51:54ZOndřej Surýlib/dns/zone.c refactoringWhile reviewing a MR that touches `lib/dns/zone.c`, I have notice several things:
- [ ] `zone_postload()` needs to be refactored, the functions spans from line 4696 to to line 5290 (e.g. 400 lines)
- [ ] `zone_rekey()` also need to be re...While reviewing a MR that touches `lib/dns/zone.c`, I have notice several things:
- [ ] `zone_postload()` needs to be refactored, the functions spans from line 4696 to to line 5290 (e.g. 400 lines)
- [ ] `zone_rekey()` also need to be refactored as it spans from line 19317 to line 19734
- [ ] `keyfetch_done()` spans from line 9993 to line 10647 (600 lines)
- [ ] `zone_nsec3chain()` ~900 lines
- [ ] The locked parameter in `zone_locked()` should be removed in favor of just locking the zone prior to the call
- [ ] There's probably a missing lock in `dns_zone_catz_enable_db()`
- [ ] There's probably a missing lock around `dns_zone_rpz_disable_db()` and `dns_zone_catz_disable_db()` call
- [ ] There's lot of unlocked access to dns_zone_t members in `zone_nsec3chain()` and `zone_sign()` at the top of the function
- [ ] There's unlocked access to dns_zone_t members in `zone_maintenance()` (`zone->view`, `zone->type`, `zone->masters`, ...)
- [ ] There's unlocked access to `zone->maxrecords` in `dns_zone_getmaxrecords()` and `dns_zone_setmaxrecords()`
- [ ] There's unlocked access to `zone->origin`, `zone->flags`, `zone->dblock`, and other members of dns_zone_t in `zone_notify()`
- [ ] `zone_rekey()` contains unlocked access to `zone->mctx`, `zone->origin`, `zone->rdclass` and other members
The list here is neither complete or necessarily correct. Some of the struct members might be read-only (e.g. protected by reference counting), but the struct comment is saying "/* Locked */", so if they are truly read-only, perhaps casting them to `const` would be a right thing to do. Also I mostly checked only static functions and looked only at `dns_zone_t *` accesses.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/977Generate dlz_minimal.h from lib/dns/include/dns/clientinfo.h and others2023-11-02T16:42:09ZOndřej SurýGenerate dlz_minimal.h from lib/dns/include/dns/clientinfo.h and othersWhen keeping stuff in sync, it's very prone to break at some point in future. Instead of adding test that compares the data structures from dlz_minimal.h to their BIND library counterparts, we should rather generate dlz_minimal.h at the...When keeping stuff in sync, it's very prone to break at some point in future. Instead of adding test that compares the data structures from dlz_minimal.h to their BIND library counterparts, we should rather generate dlz_minimal.h at the build time from the pieces that needs to be included.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/723Use thread annotations2018-11-22T10:30:00ZOndřej SurýUse thread annotationsClang 8 (and maybe earlier) has support for Thread Safety Analysis:
https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
that allows thread annotations like `GUARDED_BY`, `REQUIRES(...)` and others to annotate variables, pointers and ...Clang 8 (and maybe earlier) has support for Thread Safety Analysis:
https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
that allows thread annotations like `GUARDED_BY`, `REQUIRES(...)` and others to annotate variables, pointers and functions with hints for the analysis engine.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/226refactor DLZ into a dyndb module?2018-04-24T16:14:53ZEvan Huntrefactor DLZ into a dyndb module?There was an offhand remark made at the ISC all-hands, which I think has potential.
It would be nice to reduce the number of external database API's for which BIND needs native support. Currently we have SDB (obsolete but still in use f...There was an offhand remark made at the ISC all-hands, which I think has potential.
It would be nice to reduce the number of external database API's for which BIND needs native support. Currently we have SDB (obsolete but still in use for built-in zones such as authors.bind), SDLZ (the DLZ driver API, semi-obsolete but still used for the dlz-dlopen driver and for one of the system tests), the DLZ module API (currently supported, and provided by the dlz-dlopen driver mentioned before). Finally there's dyndb (the new hotness with many advantages over the others, but seriously lacking in module support).
We could remove SDLZ and DLZ support from named by writing a dyndb module that provides the functions of the dlz-dlopen driver and the various helper functions in sdlz.c and dlz.c. The overall architecture could be substantially simplified, while keeping the interface for DLZ modules themselves unchanged.
We can keep configuration stable by having the dyndb module loaded automatically if "dlz" is used in named.conf. I think we still need to keep some DLZ-specific functions such as dns_view_searchdlz() but much of the DLZ enabling code could be moved out of named and pulled in only when needed.Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/38Statistics System Overhaul2023-07-12T15:30:36ZRay BellisStatistics System OverhaulThe statistics layer in BIND suffers from poor separation of concerns, with several parts of BIND and its libraries each containing code for rendering statistics in XML, JSON, or in plain text. This leads to inconsistencies in the outpu...The statistics layer in BIND suffers from poor separation of concerns, with several parts of BIND and its libraries each containing code for rendering statistics in XML, JSON, or in plain text. This leads to inconsistencies in the output, as well as making it harder to extend. The individual modules that generate statistics should be agnostic to the output format.
With some core parts of BIND likely to be moved into individual hooks modules (#15) we need a way to record and access statistics without them having to be allocated space in static built-in structures.
The proposal then is to replace the existing static statistics structures with an _abstract, extensible data store_ represented as a nested tree of key-value objects. BIND components would _register_ counter variables within the tree of objects, and retain fast access to those variables by retaining copies of an _opaque pointer_ for each variable.
The existing XML and JSON renderers would be replaced with generic code that can serialize the tree (or portions thereof) by enumeration without specific knowledge of the keys and values stored therein.
The supported data types would be:
* gauge
* counter
* timestamp
* text label
with additional structural types to create the tree of:
* object
* array
Wherever possible values should be accessed using atomic operations. Each variable should have a name that would be used in the XML renderer (or an implicit index for array elements). Each variable should have its associated description attached, although in cases where many variables share the same meaning (i.e. multiple entries in an array) we should be careful to avoid memory bloat.
Access to individual variables needs to be an O(1) operation for performance. Enumeration of the tree should be O(total size of tree). If variables are to be dynamically inserted or deleted, this should be O(log n) or better.Not planned