BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-02-14T23:14:00Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/743Improvements to dnssec-verify2024-02-14T23:14:00ZCathy AlmondImprovements to dnssec-verify### Summary
This is both a bug report and a feature request.
dnssec-verify is not finding everything that is wrong with a zone, possibly because it is only looking for faults that would cause its RRs to fail validation and/or it is ign...### Summary
This is both a bug report and a feature request.
dnssec-verify is not finding everything that is wrong with a zone, possibly because it is only looking for faults that would cause its RRs to fail validation and/or it is ignoring RRsets that ordinarily would be considered to be occluded, even though their DNSSEC-state is ambiguous in the zone itself.
### BIND version used
9.11.5
### Potential new features/fixes
1. Detect RRsets that are DNSSEC-signed that shouldn't be because they're out-of-zone - for example necessary glue, unnecessary glue (usually occluded) and DNSKEY RRs that have inappropriately been added to the parent along with the DS RRs.
2. Check that the NSEC/NSEC3 RRs don't 'cover' any RTYPEs that they should not (I'm assuming that the check already includes matching the RRsets at the name being covered with the type list)
3. Better 'this is broken' error messages detailing what is wrong, particularly when it is that an NSEC/NSEC3 chain is broken
4. Match NSEC3 RRs to the names that they cover when reporting problems
5. [ ] #1863 Add an option for retrospective checking of a historic copy of a zone file by introducing an option to provide a date/time to be treated as 'now' for the purposes of DNSSEC validation
See also https://support.isc.org/Ticket/Display.html?id=13752Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/738Cleanup unused checks from configure.ac2020-07-02T06:26:14ZOndřej SurýCleanup unused checks from configure.acThere's a lot of accumulated cruft in `configure.ac`, it would be great to cross-check macros in generated `config.h` with their actual usage in the rest of the code, and remove the cruft from `configure.ac`, and matching stuff from `win...There's a lot of accumulated cruft in `configure.ac`, it would be great to cross-check macros in generated `config.h` with their actual usage in the rest of the code, and remove the cruft from `configure.ac`, and matching stuff from `win32util/Configure`.BIND 9.15.xOndřej SurýOndřej Surýhttps://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/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/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/691Add thread safety testing in the CI2021-03-04T15:27:01ZOndřej SurýAdd thread safety testing in the CIWe should expand our testing in our CI to test for thread safety.
* It will need some annotation for parts that are not synchronized, but safe
* Both Helgrind and ThreadSanitizer should be used
Let's start by doing comparative tests on...We should expand our testing in our CI to test for thread safety.
* It will need some annotation for parts that are not synchronized, but safe
* Both Helgrind and ThreadSanitizer should be used
Let's start by doing comparative tests on the release branches in the Jenkins CI, and build the tools to compare the TS and Helgrind results, and use those tools to have a GitLab CI job that would not allow regressions.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/669Intermittent TCP test failure2019-11-28T12:25:32ZOndřej SurýIntermittent TCP test failureJob [#86348](https://gitlab.isc.org/isc-projects/bind9/-/jobs/86348) failed for 68ca9877921892968c718865363e9115ba5095bf:Job [#86348](https://gitlab.isc.org/isc-projects/bind9/-/jobs/86348) failed for 68ca9877921892968c718865363e9115ba5095bf:BIND 9.15.xWitold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/658$sysconfdir is silently overridden with /etc when "--prefix" is not used2020-01-14T21:16:05ZMichał Kępień$sysconfdir is silently overridden with /etc when "--prefix" is not used@pspacek pointed out to me that when you use `./configure` without `--prefix`, `make install` puts everything under `/usr/local`... except the configuration files. I ran `./configure --help`, which yielded:
```
...
Installation directo...@pspacek pointed out to me that when you use `./configure` without `--prefix`, `make install` puts everything under `/usr/local`... except the configuration files. I ran `./configure --help`, which yielded:
```
...
Installation directories:
--prefix=PREFIX install architecture-independent files in PREFIX
[/usr/local]
...
--sysconfdir=DIR read-only single-machine data [PREFIX/etc]
...
...
```
So far so good. Then I checked `configure.ac` and found [this][1]:
```sh
#
# Special processing of paths depending on whether --prefix,
# --sysconfdir or --localstatedir arguments were given. What's
# desired is some compatibility with the way previous versions
# of BIND built; they defaulted to /usr/local for most parts of
# the installation, but named.boot/named.conf was in /etc
# and named.pid was in /var/run.
#
# So ... if none of --prefix, --sysconfdir or --localstatedir are
# specified, set things up that way. If --prefix is given, use
# it for sysconfdir and localstatedir the way configure normally
# would. To change the prefix for everything but leave named.conf
# in /etc or named.pid in /var/run, then do this the usual configure way:
# ./configure --prefix=/somewhere --sysconfdir=/etc
# ./configure --prefix=/somewhere --localstatedir=/var
#
# To put named.conf and named.pid in /usr/local with everything else,
# set the prefix explicitly to /usr/local even though that's the default:
# ./configure --prefix=/usr/local
#
case "$prefix" in
NONE)
case "$sysconfdir" in
'${prefix}/etc')
sysconfdir=/etc
;;
esac
case "$localstatedir" in
'${prefix}/var')
localstatedir=/var
;;
esac
;;
esac
```
`git blame` indicates that this bit was added in 2000. I think that in 2018 this is wrong and confusing, especially given that `./configure --help` claims that the default value for `$sysconfdir` is `PREFIX/etc`. IMHO we should at least address this in *master*.
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/d88efa7e40cbf244ca7886d8ddf0f0361ce8a518/configure.ac#L334-367BIND 9.15.xMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/651Add an option to disable qname minimization for selected domains2021-10-04T13:33:45ZWitold KrecickiAdd an option to disable qname minimization for selected domainsNot plannedWitold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/622BIND should accept trust anchors / keys in DS format too, not just DNSKEY2021-05-11T13:17:24ZRay BellisBIND should accept trust anchors / keys in DS format too, not just DNSKEYper title.
This would simplify use for those registries that would prefer to only receive DS records from their delegated children.
Also, the ICANN root trust anchor is mostly only distributed in DS format.per title.
This would simplify use for those registries that would prefer to only receive DS records from their delegated children.
Also, the ICANN root trust anchor is mostly only distributed in DS format.BIND 9.15.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/605Add SipHash24 and synchronize the Cookie algorithm with other vendors2019-07-22T12:15:37ZOndřej SurýAdd SipHash24 and synchronize the Cookie algorithm with other vendorsBIND 9.15.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/599assertion error in isc__timer_create(): task != ((void *)0)2018-11-13T13:25:12ZAndreas Hasenackandreas@canonical.comassertion error in isc__timer_create(): task != ((void *)0)<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
The command `host -t soa local.` crashed with an assertion error:
`#2 0x00007fe590c645ef in isc_assertion_failed (file=file@entry=0x7fe590cb769c "../../../lib/isc/timer.c", line=line@entry=392, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7fe590cb0103 "task != ((void *)0)") at ../../../lib/isc/assertions.c:52`
Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1797926
### BIND version used
1:9.11.4+dfsg-3ubuntu5 in Ubuntu Cosmic 18.10 (https://launchpad.net/ubuntu/+source/bind9/1:9.11.4+dfsg-3ubuntu5)
### Steps to reproduce
Unknown, but reporter indicated it was after his computer came back from sleep.
### What is the current *bug* behavior?
The `host` command failed with an assertion error.
### What is the expected *correct* behavior?
The `host` command should produce a result, or timeout and fail gracefully.
### Relevant logs and/or screenshots
Backtrace:
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
[Error: raise.c was not found in source tree]
#1 0x00007fe590a44535 in __GI_abort () at abort.c:79
[Error: abort.c was not found in source tree]
#2 0x00007fe590c645ef in isc_assertion_failed (file=file@entry=0x7fe590cb769c "../../../lib/isc/timer.c", line=line@entry=392, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7fe590cb0103 "task != ((void *)0)") at ../../../lib/isc/assertions.c:52
47: void
48: isc_assertion_failed(const char *file, int line, isc_assertiontype_t type,
49: const char *cond)
50: {
51: isc_assertion_failed_cb(file, line, type, cond);
52: abort();
53: /* NOTREACHED */
54: }
55:
56: /*% Set callback. */
57: void
#3 0x00007fe590c9245a in isc__timer_create (manager0=0x7fe58d741010, type=<optimized out>, expires=<optimized out>, interval=<optimized out>, task=0x0, action=0x55bcf1af75c0 <connect_timeout>, arg=0x7fe58d74e018, timerp=0x7fe58d74e288) at ../../../lib/isc/timer.c:457
452: timer->index = 0;
453: result = isc_mutex_init(&timer->lock);
454: if (result != ISC_R_SUCCESS) {
455: isc_task_detach(&timer->task);
456: isc_mem_put(manager->mctx, timer, sizeof(*timer));
457: return (result);
458: }
459: ISC_LINK_INIT(timer, link);
460: timer->common.impmagic = TIMER_MAGIC;
461: timer->common.magic = ISCAPI_TIMER_MAGIC;
462: timer->common.methods = (isc_timermethods_t *)&timermethods;
#4 0x000055bcf1aef75a in bringup_timer (query=0x7fe58d74e018, default_timeout=<optimized out>) at ../../../bin/dig/dighost.c:2949
2944: }
2945: debug("have local timeout of %d", local_timeout);
2946: isc_interval_set(&l->interval, local_timeout, 0);
2947: if (query->timer != NULL)
2948: isc_timer_detach(&query->timer);
2949: result = isc_timer_create(timermgr, isc_timertype_once, NULL,
2950: &l->interval, global_task, connect_timeout,
2951: query, &query->timer);
2952: check_result(result, "isc_timer_create");
2953: }
2954:
#5 0x000055bcf1af6e22 in send_udp (query=0x7fe58d74e018) at ../../../bin/dig/dighost.c:3135
3130: dig_query_t *next;
3131:
3132: debug("send_udp(%p)", query);
3133:
3134: l = query->lookup;
3135: bringup_timer(query, UDP_TIMEOUT);
3136: l->current_query = query;
3137: debug("working on lookup %p, query %p", query->lookup, query);
3138: if (!query->recv_made) {
3139: /* XXX Check the sense of this, need assertion? */
3140: query->waiting_connect = ISC_FALSE;
#6 0x000055bcf1af76c5 in connect_timeout (task=<optimized out>, event=<optimized out>) at ../../../bin/dig/dighost.c:3265
3260:
3261: if (l->retries > 1) {
3262: if (!l->tcp_mode) {
3263: l->retries--;
3264: debug("resending UDP request to first server");
3265: send_udp(ISC_LIST_HEAD(l->q));
3266: } else {
3267: debug("making new TCP request, %d tries left",
3268: l->retries);
3269: l->retries--;
3270: requeue_lookup(l, ISC_TRUE);
#7 0x00007fe590c8c439 in dispatch (manager=0x7fe58d73f010) at ../../../lib/isc/task.c:1141
1136: ISC_MSGSET_TASK,
1137: ISC_MSG_EXECUTE,
1138: "execute action"));
1139: if (event->ev_action != NULL) {
1140: UNLOCK(&task->lock);
1141: (event->ev_action)(
1142: (isc_task_t *)task,
1143: event);
1144: LOCK(&task->lock);
1145: }
1146: dispatch_count++;
#8 run (uap=0x7fe58d73f010) at ../../../lib/isc/task.c:1313
1308: isc__taskmgr_t *manager = uap;
1309:
1310: XTHREADTRACE(isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
1311: ISC_MSG_STARTING, "starting"));
1312:
1313: dispatch(manager);
1314:
1315: XTHREADTRACE(isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
1316: ISC_MSG_EXITING, "exiting"));
1317:
1318: #ifdef OPENSSL_LEAKS
#9 0x00007fe590c14164 in start_thread (arg=<optimized out>) at pthread_create.c:486
[Error: pthread_create.c was not found in source tree]
#10 0x00007fe590b3cdef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
[Error: clone.S was not found in source tree]
```
The `host` call that triggered the assertion was most likely the same one from issue https://gitlab.isc.org/isc-projects/bind9/issues/520BIND 9.13.xMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/504mirror system test died on shutdown with a quota != 0.2019-01-28T10:47:18ZMark Andrewsmirror system test died on shutdown with a quota != 0.in ns_server_detach isc_quota_destroy(&sctx->tcpquota) failed. used was 1.in ns_server_detach isc_quota_destroy(&sctx->tcpquota) failed. used was 1.BIND 9.13.xMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/472Intermittent statschannel test failure2019-11-28T12:25:18ZOndřej SurýIntermittent statschannel test failureProbably timing issue, but it needs to be investigated.
https://gitlab.isc.org/isc-projects/bind9/-/jobs/35045Probably timing issue, but it needs to be investigated.
https://gitlab.isc.org/isc-projects/bind9/-/jobs/35045BIND 9.15.xWitold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/469Typo in validate-glue branch2018-11-08T17:40:01ZOndřej SurýTypo in validate-glue branchThe !300 introduced typo (it can be seen in the review history) `!!validate` should be `!validate`.
The thing that troubles me most, that it wasn't detected by the tests, so together with fixing the typo, the test should be prepared to ...The !300 introduced typo (it can be seen in the review history) `!!validate` should be `!validate`.
The thing that troubles me most, that it wasn't detected by the tests, so together with fixing the typo, the test should be prepared to catch this kind of error.Long-termEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/463Socket layer alternative based on libuv2021-06-03T15:01:18ZWitold KrecickiSocket layer alternative based on libuvFirst part of #29First part of #29Long-termWitold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/444isc_refcount_decrement() uses invalid memory ordering2018-12-05T19:35:38ZOndřej Surýisc_refcount_decrement() uses invalid memory orderingCurrently, `isc_refcount_decrement()` uses `memory_order_relaxed` which is wrong for substracting the value.
The boost library has an example on reference counting and memory ordering here: https://www.boost.org/doc/libs/1_57_0/doc/html...Currently, `isc_refcount_decrement()` uses `memory_order_relaxed` which is wrong for substracting the value.
The boost library has an example on reference counting and memory ordering here: https://www.boost.org/doc/libs/1_57_0/doc/html/atomic/usage_examples.html#boost_atomic.usage_examples.example_reference_countersNot plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/433`dig -4` just hangs if ::1 is default resolver2018-11-13T13:52:44ZVladimír Čunátvladimir.cunat@nic.cz`dig -4` just hangs if ::1 is default resolver### Summary
`dig -4` just hangs if ::1 is default resolver
- Bad: DiG 9.12.2 & 9.13.2 &ndash; hangs indefinitely.
- Reasonable: DiG 9.10.3-P4 &ndash; it asks 127.0.0.1 instead.
### Steps to reproduce
- put `nameserver ::1` (only) int...### Summary
`dig -4` just hangs if ::1 is default resolver
- Bad: DiG 9.12.2 & 9.13.2 – hangs indefinitely.
- Reasonable: DiG 9.10.3-P4 – it asks 127.0.0.1 instead.
### Steps to reproduce
- put `nameserver ::1` (only) into `/etc/resolv.conf`.
- run `dig -4 isc.org`
### What is the expected *correct* behavior?
Behavior of 9.10 sounds okay to me. Failing with some understandable error is another option I see.BIND 9.13.xMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/368Certain named builds improperly check writability of some directories when -u...2021-10-04T12:54:47ZMichał KępieńCertain named builds improperly check writability of some directories when -u is usedBIND 9.12 [introduced](16d6fab2e59f1fdf63eb71fc59e138031f5c5005) mandatory checks for writability of certain directories. Certain build types perform some of these checks in incorrect order when `-u` is used.
Here is what happens for n...BIND 9.12 [introduced](16d6fab2e59f1fdf63eb71fc59e138031f5c5005) mandatory checks for writability of certain directories. Certain build types perform some of these checks in incorrect order when `-u` is used.
Here is what happens for non-threaded Linux builds with support for capabilities:
1. `named` drops capabilities to the initial set,
2. `directory` and potentially `managed-keys-directory` are checked for writability,
3. `setuid()` is called.
This means the checks in step 2 are made with the root user's privileges, albeit severely diminished by the limited capabilities which are in effect after step 1 (namely, `CAP_DAC_OVERRIDE` is no longer set). So if e.g. `directory` is set to a path which is writable by the user specified with `-u`, but not for the root user (stripped of its superuser privileges), `named` will (wrongly) refuse to start.
These same checks are differently broken for non-threaded Linux builds without support for capabilities *and* **all** builds on other platforms because step 1 above is never executed. This means that writability checks from step 2 always succeed, because they are performed with full superuser privileges rather than `-u` user's privileges.
The only type of build where the problem does not exist are threaded Linux builds, because in their case, `setuid()` is called between steps 1 and 2 above.
Fixing the problem likely requires moving the directory checks from the view configuration routines until after the last possible call to `named_os_changeuser()`, similarly to how the current working directory is checked.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/348PKCS#11 implementation of DH is broken (at least with SoftHSMv2)2018-07-03T22:23:31ZOndřej SurýPKCS#11 implementation of DH is broken (at least with SoftHSMv2)The PKCS#11 implementation of DH algorithm doesn't work with SoftHSMv2 and although I very much doubt anybody uses TKEY or SIG(0) with HSMs, it will need to be fixed eventually.
The best way to test it is to checkout `328-make-openssl-m...The PKCS#11 implementation of DH algorithm doesn't work with SoftHSMv2 and although I very much doubt anybody uses TKEY or SIG(0) with HSMs, it will need to be fixed eventually.
The best way to test it is to checkout `328-make-openssl-mandatory` branch and revert the commit with commit message "Disable DH test with PKCS#11" and compile with `./configure --enable-developer --with-atf=/usr/local --with-openssl=/usr/local/opt/openssl --enable-native-pkcs11 --with-pkcs11=/usr/local/lib/softhsm/libsofthsm2.so` and the `dh_test` in `lib/dns/tests` fails with:
```
$ ./dh_test isc_dh_computesecret
failed: dh_test.c:65: ret != DST_R_COMPUTESECRETFAILURE
```
this is due to `CKA_VALUE2` attribute is not found (https://gitlab.isc.org/isc-projects/bind9/blob/master/lib/dns/pkcs11dh_link.c#L127). I strongly suspect that (ab)using CKA_PRIVATE_EXPONENT for this might at fault:
```
* reuse CKA_PRIVATE_EXPONENT for key pair private value
[...]
#define CKA_VALUE2 CKA_PRIVATE_EXPONENT
```
but the PKCS#11 interface is written by cryptographers for cryptographers, so normal people can just blankly stare when reading the code using PKCS#11 API.
That said, the official specification for PKCS#11 Diffie-Hellman [Section 2.4.4](http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/csprd03/pkcs11-curr-v2.40-csprd03.html#_Toc395187782) is quite clear on the number of attributes, so my suggestion would be to follow the specification when fixing this.Not plannedFrancis DupontFrancis Dupont