BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-10-05T07:43:44Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1573Rewrite qmin ans.py services2021-10-05T07:43:44ZWitold KrecickiRewrite qmin ans.py servicesLong-termWitold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1550[ISC-support #15905] rndc stop issued after server (or single zone) rndc relo...2024-03-13T21:08:58ZCathy Almond[ISC-support #15905] rndc stop issued after server (or single zone) rndc reload and during ixfr-from-differences processing leaves the .jnl file corruptedFrom Support ticket [#15905](https://support.isc.org/Ticket/Display.html?id=15905)
9.11.x (but I don't anticipate that the BIND version makes any difference)
This problem is readily reproducible (and, I suspect, occurs because "rndc st...From Support ticket [#15905](https://support.isc.org/Ticket/Display.html?id=15905)
9.11.x (but I don't anticipate that the BIND version makes any difference)
This problem is readily reproducible (and, I suspect, occurs because "rndc stop" doesn't recognise that the zone is effectively 'dynamic' because it has been reloaded with 'ixfr-from-differences yes;').
Here's what is being done, per the server logs. First the reload (the outcome is also the same with 'reload zone'):
```
09-Jan-2020 14:50:29.157 general: info: received control channel command 'reload' ============>>> RELOAD COMMAND
09-Jan-2020 14:50:29.179 general: info: loading configuration from '/etc/named.conf'
... etcetera
09-Jan-2020 14:50:29.202 general: info: reloading configuration succeeded
09-Jan-2020 14:50:29.202 general: info: reloading zones succeeded
09-Jan-2020 14:50:29.202 general: notice: all zones loaded
09-Jan-2020 14:50:29.202 general: notice: running
```
Note that the reload has completed, as far as the logging is concerned, but, it would appear that the regeneration of the .jnl files via 'ixfr-from-differences yes;' has not (high CPU use by named - suggests that it is busy doing this).
Then the 'rndc stop' is issued - and it completes almost immediately (no evidence that it is waiting for the processing to complete), in fact, it seems to log that it has aborted a zone reload, even though the previous logging said that the reload *had* completed:
```
09-Jan-2020 14:50:33.211 general: info: received control channel command 'stop -p'
09-Jan-2020 14:50:33.212 general: info: shutting down: flushing changes
.. etcetera (just the logs of the various sockets being closed here)
09-Jan-2020 14:50:33.216 general: error: zone test.com/IN: loading from master file dynamic/test.com.zone failed: operation canceled
09-Jan-2020 14:50:33.216 general: error: zone test.com/IN: not loaded due to errors.
09-Jan-2020 14:50:34.265 general: notice: exiting
```
And then after this, restarting named - the zone can no longer be loaded - the journal file does not tally with the zone itself:
```
...
09-Jan-2020 14:51:28.141 general: error: zone test.com/IN: journal rollforward failed: journal out of sync with zone
09-Jan-2020 14:51:28.141 general: error: zone test.com/IN: not loaded due to errors.
09-Jan-2020 14:51:28.142 general: notice: all zones loaded
09-Jan-2020 14:51:28.142 general: notice: running
```
======
Something has gone badly wrong during the 'rndc stop' - which is supposed to be a graceful shutdown of named. I'm assuming that the problem is that the .jnl file itself is corrupt, rather than that something has happened to the zone file on disk - but will ask for more data to confirm this.
```
stop [-p]
Stop the server, making sure any recent changes made through dynamic update
or IXFR are first saved to the master files of the updated zones. If -p is
specified named’s process id is returned. This allows an external process
to determine when named had completed stopping.
```
Now, since ixfr-from-differences processing could take an age to complete, I don't think it's reasonable to wait forever on the rndc stop. Possibly one solution would be have a (configurable?) timeout, after which any pending ixfr-from-differences .jnl file generation is terminated and the incomplete .jnl file discarded/removed. After all, the administrator in this scenario has just presented named with a new zone file that it asked named to load - so we know that the full copy of the zone on disk should be good and valid - we just loaded from it.
====
The workaround if this happens, is presumably to manually discard the corrupted .jnl file and restart named.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1395Convert dns_dispatchmgr_t->buffers to atomic / reference counter.2021-10-04T20:14:01ZMark AndrewsConvert dns_dispatchmgr_t->buffers to atomic / reference counter.BIND 9.17 Backburnerhttps://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.xhttps://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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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ý