BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-04-19T07:17:42Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/707Remove ISC_MEMFLAG_INTERNAL2021-04-19T07:17:42ZOndřej SurýRemove ISC_MEMFLAG_INTERNALThe default system allocators are much better now on our supported systems, and it should be possible to just remove the `ISC_MEMFLAG_INTERNAL` magic without any performance loss.The default system allocators are much better now on our supported systems, and it should be possible to just remove the `ISC_MEMFLAG_INTERNAL` magic without any performance loss.BIND 9.17 BackburnerOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/713Use atomics instead of locks in isc_mem2019-05-10T21:20:28ZOndřej SurýUse atomics instead of locks in isc_memBIND 9.15.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/719Make isc_results static2021-10-07T06:48:12ZWitold KrecickiMake isc_results staticCurrently there's a dynamic list of results handled by lib/isc/result.c, and e.g. isc_result_totext requires a lock.
Since we don't have any external users now, and nobody will be adding any results from the outside, we can move all the...Currently there's a dynamic list of results handled by lib/isc/result.c, and e.g. isc_result_totext requires a lock.
Since we don't have any external users now, and nobody will be adding any results from the outside, we can move all the result codes from libdns, ns, isccfg, etc. to libisc - and make the list static.October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/722Refactor RBT2023-10-31T11:31:45ZOndřej SurýRefactor RBT(This is just a placeholder for future ideas for refactoring some RBT...)
Since RBT was invented in seventies, there has been some improvements to the algorithm since, namely:
* Lock-Free Red-Black Trees Using CAS
* https://www.cs.um...(This is just a placeholder for future ideas for refactoring some RBT...)
Since RBT was invented in seventies, there has been some improvements to the algorithm since, namely:
* Lock-Free Red-Black Trees Using CAS
* https://www.cs.umanitoba.ca/~hacamero/Research/RBTreesKim.pdf
* http://swapnil-pimpale.github.io/lock-free-BST/
* Left-leaning Red-Black Trees:
* http://www.cs.princeton.edu/~rs/talks/LLRB/RedBlack.pdf
* http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.139.282
* http://www.cs.princeton.edu/~rs/talks/LLRB/LLRB.pdf
* http://www.mew.org/~kazu/proj/red-black-tree/
* http://25thandclement.com/~william/projects/llrb.h.html
* OpenBSD's `<sys/tree.h>`:
* https://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/sys/tree.hBIND 9.19.xhttps://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/727Follow-up from "Bound tasks for resolver; Task quantum tweaks."2022-07-01T00:53:36ZWitold KrecickiFollow-up from "Bound tasks for resolver; Task quantum tweaks."The following discussion from !1117 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1117#note_32136): (+4 comments)
> What would happen if this would be the defaul...The following discussion from !1117 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1117#note_32136): (+4 comments)
> What would happen if this would be the default?
> ```
> if (c < 0) {
> c = task->threadid;
> }
> ```
> and just drop the `task->bound;` variable?Not plannedEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/733Rewrite various logging functions to variadic macros...2023-11-02T16:32:29ZOndřej SurýRewrite various logging functions to variadic macros...There's a lot of pre-C99 code that defines extra logging functions in different places in the code, like this:
```
static void
manager_log(isc__socketmgr_t *sockmgr,
isc_logcategory_t *category, isc_logmodule_t *module, int l...There's a lot of pre-C99 code that defines extra logging functions in different places in the code, like this:
```
static void
manager_log(isc__socketmgr_t *sockmgr,
isc_logcategory_t *category, isc_logmodule_t *module, int level,
const char *fmt, ...) ISC_FORMAT_PRINTF(5, 6);
static void
manager_log(isc__socketmgr_t *sockmgr,
isc_logcategory_t *category, isc_logmodule_t *module, int level,
const char *fmt, ...)
{
char msgbuf[2048];
va_list ap;
if (! isc_log_wouldlog(isc_lctx, level))
return;
va_start(ap, fmt);
vsnprintf(msgbuf, sizeof(msgbuf), fmt, ap);
va_end(ap);
isc_log_write(isc_lctx, category, module, level,
"sockmgr %p: %s", sockmgr, msgbuf);
}
```
With C99, this could be rewritten using variadic macros like this:
```
#define manager_log(sockmgr, category, module, level, fmt, ...) \
if (isc_log_wouldlog(isc_lctx, level)) { \
isc_log_write(isc_lctx, category, module, level, "sockmgr %p: " # fmt, sockmgr, __VA_ARGS__); \
}
```
Using variadic macros would lead to having fewer functions.
@joey, could you take care of it please?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/745start.pl refactoring2019-01-30T23:26:11ZBrian Conrystart.pl refactoringalso, the existing checks to ensure that named is running are insufficient for some cases with zones that need to be loaded.also, the existing checks to ensure that named is running are insufficient for some cases with zones that need to be loaded.Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/828version limits are ineffective when rolling logfiles with timestamp suffix2023-03-28T10:03:34ZEvan Huntversion limits are ineffective when rolling logfiles with timestamp suffixThe logfileconfig test is so badly written, I think it would be better to do it over than try to fix it.
Update: while working on the test, it turned out that timestamp logfiles that should have been removed when rolling, weren't. This ...The logfileconfig test is so badly written, I think it would be better to do it over than try to fix it.
Update: while working on the test, it turned out that timestamp logfiles that should have been removed when rolling, weren't. This bug needs fixing too.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/931getc_unlocked is POSIX.1, and Windows has _getchar_nolock, use that2021-06-16T22:34:00ZOndřej Surýgetc_unlocked is POSIX.1, and Windows has _getchar_nolock, use thatNot plannedOndřej SurýOndřej Surýhttps://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/987Update Catalog Zones2023-11-03T09:09:10ZVicky Riskvicky@isc.orgUpdate Catalog ZonesUpdate Catalog zones to align with the latest (04?) draft. (As discussed at All-Hands 2019)
At the same time, implement the filter controls in Gitlab issue #751Update Catalog zones to align with the latest (04?) draft. (As discussed at All-Hands 2019)
At the same time, implement the filter controls in Gitlab issue #751BIND 9.19.xArаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/988Refresh the way how we use GSSAPI Framework2021-10-04T19:13:03ZOndřej SurýRefresh the way how we use GSSAPI FrameworkThe following discussion from !1815 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1815#note_54333):
> Honestly, I would just remove all the custom code, and:
...The following discussion from !1815 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/1815#note_54333):
> Honestly, I would just remove all the custom code, and:
>
> 1. Add `pkg-config` method - both MIT and Heimdal has pkg-config support now
> 2. Keep `krb5-config` method
> 3. Switch from Kerberos.framework to GSS.framework on macOSNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1068Stop including <isc/json.h> and <isc/xml.h> from <isc/mem.h>, <isc/socket.h> ...2019-06-26T16:41:51ZOndřej SurýStop including <isc/json.h> and <isc/xml.h> from <isc/mem.h>, <isc/socket.h> and <isc/task.h>Only `named` binary needs to include with `<isc/json.h>` and `<isc/xml.h>`, but the current code enforces inclusion of `<isc/json.h>` everywhere because `<foo>_renderjson()` and `<foo>_renderxml()` methods use native datatypes.
Fixing t...Only `named` binary needs to include with `<isc/json.h>` and `<isc/xml.h>`, but the current code enforces inclusion of `<isc/json.h>` everywhere because `<foo>_renderjson()` and `<foo>_renderxml()` methods use native datatypes.
Fixing this would allow us make the Makefiles much simpler.
One way of fixing it (and probably simplest) would be making the function arguments opaque (`isc_json_t *` and `isc_xml_t *` types).
The other way would be to move `<foo>_renderjson()` and `<foo>_renderxml()` function declarations to their respective headers (`<isc/json.h>` and `<isc/xml.h>`), but that would be sort of namespace violation.
The last method that's probably cleanest would be to have just one `<foo>_render()` method that would accept `isc_render_t` structure with appropriate function calls. There's a lot of code duplication between `<foo>_renderxml()` and `<foo>_renderjson()` methods anyway.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1113Use per-query GeoIP2 entry cache2023-11-02T16:42:11ZEvan HuntUse per-query GeoIP2 entry cacheAn idea suggested by @ondrej in relation to https://gitlab.isc.org/isc-projects/bind9/merge_requests/2031#note_64941:
We can improve the GeoIP2 code by storing a copy of the `MMDB_entry` for each database we've consulted in the `ns_clie...An idea suggested by @ondrej in relation to https://gitlab.isc.org/isc-projects/bind9/merge_requests/2031#note_64941:
We can improve the GeoIP2 code by storing a copy of the `MMDB_entry` for each database we've consulted in the `ns_client` object. When we need to make another query to the same database for the same client address (or client ECS address, on 9.11), we already know it's going to get the same answer, so we can keep it and reuse it.
This is currently done with thread-specific state memory in lib/dns/geoip2.c, but would be simpler this way.Not plannedEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1118Simplify DNSSEC signing with KASP2020-01-23T08:19:28ZMatthijs Mekkingmatthijs@isc.orgSimplify DNSSEC signing with KASPMake DNSSEC signing simpler and more intuitive to configure.
1. Research current signing strategy
2. Introduce "dnssec-policy" statements to configure your Key and Signing Policy (KASP) in named.conf
3. Make sure it does not conflict wi...Make DNSSEC signing simpler and more intuitive to configure.
1. Research current signing strategy
2. Introduce "dnssec-policy" statements to configure your Key and Signing Policy (KASP) in named.conf
3. Make sure it does not conflict with existing DNSSEC sign configuration options
4. For each policy option:
4a. Adjust the code to implement the new policy features
4b. Update tests
4c. Update documentationDNSSEC Made Easyhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1156isc_refcount_increment0 is wrong, the code using it needs refactoring2023-11-02T16:42:12ZOndřej Surýisc_refcount_increment0 is wrong, the code using it needs refactoringThe `isc_refcount_increment0()` does two things and that's wrong.
1. The first purpose is to bump the value from `0` -> `1` making the object referenced.
2. The second purpose is to increment the reference counter.
This has several pr...The `isc_refcount_increment0()` does two things and that's wrong.
1. The first purpose is to bump the value from `0` -> `1` making the object referenced.
2. The second purpose is to increment the reference counter.
This has several problems:
1. You can't check whether the previous value really was `0`.
2. When object becomes dereferenced with `isc_refcount_decrement() == 1`, the `isc_refcount_increment0()` can make it referenced again while destroying the object.
There are two things that we could do about it:
1. Don't use isc_refcount API when it's not reference counting, prepare similar API for object counting (isc_objcount?)
2. Use `isc_refcount_init()` when initializing object for the first time (note that `isc_refcount_init()` is not atomic)
3. Always initialize the value to `1` and adjust the code that destroys the object
4. Split `isc_refcount_increment0()` to `isc_refcount_incfirst()` and existing `isc_refcount_increment()`
Nevertheless, the overloading of the API for `<1, MAX>` and `<0, MAX>` reference counting is wrong.Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1265BIND 9.14 option synth-from-dnssec causing high CPU consumption and degraded ...2022-02-18T12:12:52ZCathy AlmondBIND 9.14 option synth-from-dnssec causing high CPU consumption and degraded client experience### Summary
As reported in [Support ticket #15338](https://support.isc.org/Ticket/Display.html?id=15338)
```
### BIND version used
BIND 9.14.6 (Stable Release) <id:efd3496>
running on Linux x86_64 3.10.0-1062.1.1.el7.x86_64 #1 SMP Fri...### Summary
As reported in [Support ticket #15338](https://support.isc.org/Ticket/Display.html?id=15338)
```
### BIND version used
BIND 9.14.6 (Stable Release) <id:efd3496>
running on Linux x86_64 3.10.0-1062.1.1.el7.x86_64 #1 SMP Fri Sep 13 22:55:44 UTC 2019
built by make with '--prefix=/opt/bind' '--sysconfdir=/etc' '--disable-linux-caps' '--enable-dnsrps'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /opt/bind/var/run/named/session.key
named PID file: /opt/bind/var/run/named/named.pid
named lock file: /opt/bind/var/run/named/named.lock
```
### Steps to reproduce
This is an in-house resolver (one of a pair behind a load-balancer). DNSSEC and DNSSEC-validation are both disabled:
```
dnssec-enable no;
dnssec-validation no;
```
### What is the current *bug* behavior?
After upgrading one of the server pair from BIND 9.10 to 9.14, the server that had previously been running BIND 9.10 changed from running named at around 20% CPU consumption to 150%. It is also slower for clients: "it is slow after CPU usage reach 150%, even when I query the cached data on it, it takes more than 200ms to respond"
### What is the expected *correct* behavior?
As good (or better) performance than before upgrading
### Relevant configuration files
See above.
### Relevant logs and/or screenshots
There was nothing unusual or different in any of the logging, QPS or any of the usual suspects.
Of note, in 9.14, 'dnssec-enable' is no longer a functioning option - and, confirmed in the PCAPs, this server is setting the DO bit on queries to authoritative servers and receiving DNSSEC material with query responses (which will be being cached).
We captured a series of operating stack snapshots using pstack - which showed a surprising number of instances of worker threads calling find_coveringnsec() which was a surprise.
Notably on this server and in this environment, it was expected that there will be a high proportion of negative responses to clients: "there are a lot of invalid/NXDOMAIN dns queries".
Speculatively, we added:
`synth-from-dnssec no; `
With this new configuration option, performance returned to normal.
Per the ARM:
```
synth-from-dnssec
Synthesize answers from cached NSEC, NSEC3 and other RRsets that have been proved to be correct using DNSSEC. The default is yes.
Note:
• DNSSEC validation must be enabled for this option to be effective.
This initial implementation only covers synthesis of answers from NSEC records. Synthesis from NSEC3 is planned for the future. This will also be controlled by synth-from-dnssec.
```
I would have expected that to mean that the option would be disabled if DNSSEC-validation is disabled, but it could be interpreted to mean that the option doesn't do anything useful (which makes sense - as you wouldn't want to use unvalidated NSEC RRsets for this). But the high performance penalty was nevertheless surprising.
The problem may have been more significant in this case due to the notably high proportion of negative cached RRsets/pseudo-RRsets.
### Possible fixes
N/A (but there's a clear workaround - disable this feature)December 2021 (9.16.24, 9.16.24-S1, 9.17.21)https://gitlab.isc.org/isc-projects/bind9/-/issues/1293Change the return value for dns_name_dup() to void and cleanup the code2020-01-13T14:19:53ZOndřej SurýChange the return value for dns_name_dup() to void and cleanup the codeThe following discussion from !2452 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/2452#note_86460): (+1 comment)
> Would a follow-up MR that changes the return v...The following discussion from !2452 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/2452#note_86460): (+1 comment)
> Would a follow-up MR that changes the return value for `dns_name_dup()` to `void` make sense?December 2019 (9.11.14, 9.14.9, 9.15.7)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1329continue validator/keytable refactoring2023-10-31T13:33:14ZEvan Huntcontinue validator/keytable refactoring- simplify dns_keytable structure to have a single object at each node instead of a list
- convert DNSKEY trust anchors into DS format internally, so the validator only needs a single method for zone key validation
- run code coverage an...- simplify dns_keytable structure to have a single object at each node instead of a list
- convert DNSKEY trust anchors into DS format internally, so the validator only needs a single method for zone key validation
- run code coverage analysis
- add unit tests and system test cases as neededBIND 9.19.x