BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-03-01T09:41:21Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2527Confusing IXFR logging in BIND 9.17.7+2022-03-01T09:41:21ZMichał KępieńConfusing IXFR logging in BIND 9.17.7+A logging glitch slipped into !4246: ever since that MR got merged,
successful IXFRs started being accompanied by a "failed while receiving
responses: no more" log message. This problem was introduced by commit
934d6c6f92ff1761372c532ff...A logging glitch slipped into !4246: ever since that MR got merged,
successful IXFRs started being accompanied by a "failed while receiving
responses: no more" log message. This problem was introduced by commit
934d6c6f92ff1761372c532ff50b899ed4264d1d as it removed an early `return`
statement from `lib/dns/xfrin.c:xfrin_recv_done()`.
Here is what is logged for a successful IXFR in BIND 9.17.7+:
24-Feb-2021 22:17:23.280 zone nil/IN: transferred serial 2
24-Feb-2021 22:17:23.280 transfer of 'nil/IN' from 10.53.0.2#5300: failed while receiving responses: no more
24-Feb-2021 22:17:23.280 transfer of 'nil/IN' from 10.53.0.2#5300: Transfer status: IXFR failed
24-Feb-2021 22:17:23.280 transfer of 'nil/IN' from 10.53.0.2#5300: Transfer completed: 1 messages, 4 records, 179 bytes, 0.016 secs (11187 bytes/sec) (serial 2)
These messages are quite confusing because by the time the "failed while
receiving responses: no more" message is logged, the IXFR is already
journalled and applied to the zone.
The simplest solution seems to be to "promote" `ISC_R_NOMORE` to
`ISC_R_SUCCESS` [after going through the ANSWER section of the
transfer][1].
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/965848a11a1032d66807811e2f7e15676760d67f/lib/dns/xfrin.c#L1342-1344Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2526Example configuration for authoritative DNS server for docker container is mi...2021-02-24T20:45:03ZMalte BögershausenExample configuration for authoritative DNS server for docker container is misleadingThe example for the basic configuration for an authoritative DNS server given on https://hub.docker.com/r/internetsystemsconsortium/bind9 is misleading.
The lines:
```
listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };
```...The example for the basic configuration for an authoritative DNS server given on https://hub.docker.com/r/internetsystemsconsortium/bind9 is misleading.
The lines:
```
listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };
```
mean that the DNS server is not accessible from outside the container (and there is no reason to access it from inside the container).
Additionally there is no filename suggested for the config file. If `named.conf` is used the default structure for config files is overridden.https://gitlab.isc.org/isc-projects/bind9/-/issues/2525Automated test for upgrading BIND2023-11-02T16:26:05ZVicky Riskvicky@isc.orgAutomated test for upgrading BINDsuggestion - can we consider creating a test for updating BIND versions?
This will need to look at what persistent data needs to be preserved across the update.
The complexity is that users update across multiple versions, perhaps the f...suggestion - can we consider creating a test for updating BIND versions?
This will need to look at what persistent data needs to be preserved across the update.
The complexity is that users update across multiple versions, perhaps the first scenario to address is migrating from the latest 9.11 version to the latest 9.16 version.
It might be good to measure how long the update takes, the time to reload (in case either of these are surprising that might indicate a problem), of course that bind restarts and reloads, maybe run a few queries??Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2522Monitoring zone transfer dropped due to quota limits2022-03-01T09:58:59ZPeter DaviesMonitoring zone transfer dropped due to quota limitsMonitoring zone transfer dropped due to quota limits:
The maximum number of simultaneous outgoing zone transfers is defined by the value of “transfers-out” which is configurable within “options” and currently defaults to 10.
To b...Monitoring zone transfer dropped due to quota limits:
The maximum number of simultaneous outgoing zone transfers is defined by the value of “transfers-out” which is configurable within “options” and currently defaults to 10.
To better configure and supervise their servers, it would be useful for administrators to be able to retrieve information about the number of zone transfers that get dropped due to this quota limit.
An incremental counter that would record these occurrences has been suggested. The value of this counter could be exposed on the statistics channel.
[RT #17780 ](https://support.isc.org/Ticket/Display.html?id=17780)Not plannedArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2497Add counters for DoH queries2023-12-12T11:00:33ZVicky Riskvicky@isc.orgAdd counters for DoH queriesSince you can support DoH in addition to Do53 on the same BIND instance, it would be really nice to have some way to tell how much DoH traffic you are getting.
- [ ] Add some metric that enables the operator to tell specifically how mu...Since you can support DoH in addition to Do53 on the same BIND instance, it would be really nice to have some way to tell how much DoH traffic you are getting.
- [ ] Add some metric that enables the operator to tell specifically how much DoH traffic they are receiving.
- [ ] Please be sure to document this metric in the ARM and explain what it is measuring as specifically as possible (because we have a problem in general with not having good enough documentation of our metrics).
- [ ] Also, check to ensure that we are updating the existing counters for TCP v4 and TCP v6 queries with the DoH queries (I am told we are not entirely confident that these are always updated for DoH queries in 9.17.10)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2496Crash in isc_mem_checkdestroyed() with PKCS#112022-03-01T09:41:38ZMichal NowakCrash in isc_mem_checkdestroyed() with PKCS#11PKCS#11 job with SoftHSM 2.6 on Fedora 33 [asserted failure](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1498009) on `main` with the following output:
```
I:pkcs11:exit status: 0
I:pkcs11:stopping servers
I:pkcs11:Core dump(s) found...PKCS#11 job with SoftHSM 2.6 on Fedora 33 [asserted failure](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1498009) on `main` with the following output:
```
I:pkcs11:exit status: 0
I:pkcs11:stopping servers
I:pkcs11:Core dump(s) found: pkcs11/ns1/core.22627
D:pkcs11:backtrace from pkcs11/ns1/core.22627:
D:pkcs11:--------------------------------------------------------------------------------
D:pkcs11:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/lt-named -D pkcs11-ns1 -X named.lock'.
D:pkcs11:Program terminated with signal SIGABRT, Aborted.
D:pkcs11:#0 0x00007f70b07779d5 in raise () from /lib64/libc.so.6
D:pkcs11:#0 0x00007f70b07779d5 in raise () from /lib64/libc.so.6
D:pkcs11:#1 0x00007f70b07608a4 in abort () from /lib64/libc.so.6
D:pkcs11:#2 0x000000000041d679 in assertion_failed (file=<optimized out>, line=<optimized out>, type=isc_assertiontype_insist, cond=0x7f70b12310f2 "0") at main.c:259
D:pkcs11:#3 0x00007f70b11fc40e in isc_assertion_failed (file=file@entry=0x7f70b122eef1 "mem.c", line=line@entry=2092, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7f70b12310f2 "0") at assertions.c:46
D:pkcs11:#4 0x00007f70b120d89e in isc_mem_checkdestroyed (file=0x7f70b08ff440 <_IO_2_1_stderr_>) at mem.c:2092
D:pkcs11:#5 0x000000000041f736 in main (argc=16, argv=0x7fff9f83ca58) at main.c:1626
D:pkcs11:--------------------------------------------------------------------------------
D:pkcs11:full backtrace from pkcs11/ns1/core.22627 saved in pkcs11/ns1/core.22627-backtrace.txt
D:pkcs11:core dump pkcs11/ns1/core.22627 archived as pkcs11/ns1/core.22627.gz
R:pkcs11:FAIL
```
`named.run`:
```
17-Feb-2021 08:40:25.955 exiting
context: 0x179a180 (zonemgr-pool): 2 references
Dump of all outstanding memory allocations:
ptr 0x7f709c4b3020 size 214 file diff.c line 67
ptr 0x7f709c497f48 size 214 file diff.c line 67
mem.c:2092: INSIST(0) failed
```
Full backtrace:
```
[New LWP 22627]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/lt-named -D pkcs11-ns1 -X named.lock'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f70b07779d5 in raise () from /lib64/libc.so.6
Thread 1 (Thread 0x7f70b0382d80 (LWP 22627)):
#0 0x00007f70b07779d5 in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f70b07608a4 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x000000000041d679 in assertion_failed (file=<optimized out>, line=<optimized out>, type=isc_assertiontype_insist, cond=0x7f70b12310f2 "0") at main.c:259
tracebuf = {0x11, 0x7f70b1258f17 <_dl_fixup+215>, 0x5, 0x0, 0x7fff9f83c960, 0x7f70b11b94b0, 0x7fff9f83c8b0, 0x7f70b126056e <_dl_runtime_resolve_xsavec+126>, 0x0, 0x7f70b12310f2, 0x2, 0x82c, 0x7f70b122eef1, 0x0, 0x7fff9f83a5f6, 0x7f70b126056e <_dl_runtime_resolve_xsavec+126>, 0x0, 0x114a010, 0x1, 0xffff00001f80, 0x7f70b08ff440 <_IO_2_1_stderr_>, 0x7f709c1ba000, 0x7fff9f83c700, 0x7f70b07afd26 <fflush+134>, 0x7f70b03420e0, 0x1, 0x7fff9f83c800, 0xffff00001f80, 0x481a10 <dns_modules+400>, 0x1158a38, 0x1158968, 0x0, 0x0, 0x45dc61, 0x7f70b0341020, 0x7fff9f83c790, 0x2525252525252525, 0x2525252525252525, 0xffffffffffffff00, 0x0, 0xffffffffffffff00, 0x0, 0x475f4300, 0x0, 0x43006f666e497465, 0x746f6c537465475f, 0x5a5a5a5a5a5a5a5a, 0x5a5a5a5a5a5a5a5a, 0x2020202020202020, 0x2020202020202020, 0x0, 0x0, 0xa, 0x6165726874702828, 0x0, 0x0, 0x20202020, 0x2000202020202020, 0x0 <repeats 18 times>, 0x3535392e35323a, 0x0, 0x0, 0x0, 0x2, 0x800000000000000e, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0x800000000000000e, 0x0, 0xbe57a377d9ca5100, 0x0, 0xbe57a377d9ca5100, 0x7f704800a030, 0x7fff9f83c8c0, 0x7f70b08ff440 <_IO_2_1_stderr_>, 0x7f70b122e220, 0xab0, 0x7f70b08498e3 <__fprintf_chk+163>, 0x3000000030, 0x7fff9f83c888, 0x7fff9f83c7c0, 0xbe57a377d9ca5100, 0xd68, 0x7f70b07baf86 <new_do_write+102>, 0x179a180, 0x7f709c497f48, 0xd6, 0x7f70b114f01a, 0x7f70b0900320 <__GI__IO_file_jumps>, 0x2c, 0x2c, 0x7f70b07bc36e <__GI__IO_file_xsputn+366>, 0x173c990, 0x7f70b08ff440 <_IO_2_1_stderr_>, 0x2c, 0x2c, 0x1, 0x7f70b122e1f0, 0x7f70b0900320 <__GI__IO_file_jumps>, 0x7f70b07b0c11 <fwrite+193>, 0x0, 0x7f70b08ff440 <_IO_2_1_stderr_>, 0x7fff9f83c8c0, 0x7f70b08ff440 <_IO_2_1_stderr_>, 0x7f70b122f19c, 0x7f70b120a656 <print_active+137>}
nframes = 32624
result = <optimized out>
logsuffix = <optimized out>
#3 0x00007f70b11fc40e in isc_assertion_failed (file=file@entry=0x7f70b122eef1 "mem.c", line=line@entry=2092, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7f70b12310f2 "0") at assertions.c:46
No locals.
#4 0x00007f70b120d89e in isc_mem_checkdestroyed (file=0x7f70b08ff440 <_IO_2_1_stderr_>) at mem.c:2092
No locals.
#5 0x000000000041f736 in main (argc=16, argv=0x7fff9f83ca58) at main.c:1626
result = <optimized out>
```
Core file: [core.22627.gz](/uploads/854788c1a5b6f20c3cf5351c1ef90378/core.22627.gz)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2495Mitigation for cache bloat due to negative RRsets (NXDOMAIN and NXRRSET) when...2024-03-01T10:04:57ZCathy AlmondMitigation for cache bloat due to negative RRsets (NXDOMAIN and NXRRSET) when preserving expired RRsets using max-stale-ttlI'm tagging this as 'Customer' because it is affecting/has affected several customer caches (unanticipated cache bloat) with 'stale-cache-enable yes;'
----
By design, negative cache content is not used in the same way as positive cache...I'm tagging this as 'Customer' because it is affecting/has affected several customer caches (unanticipated cache bloat) with 'stale-cache-enable yes;'
----
By design, negative cache content is not used in the same way as positive cache content. 'stale-answer-client-timeout' does not apply to negative content, thus the clients will timeout and likely retry the same query several times before giving up, long before the resolver-query-timeout. Only when named has failed to get a response from the authoritative server(s) does the 'stale-refresh-time' window commence.
There is a good reason for this - when querying the authoritative servers for a name that is already NXDOMAIN or NXRRSET in cache, we don't know if this is going to be replaced with positive content or not. Therefore, to ensure that positive content is preferred, we have to wait to be sure that it's sensible to serve the stale negative content as a last resort.
UNFORTUNATELY:
1. Most negative content is single-use - so adding max-stale-ttl to its retention period can significantly increase cache bloat - for no useful reason whatsoever.
2. Most negative content has (also by design of sane zone administrators, or overridden by max-ncache-ttl) a much shorter TTL in cache than positive content.
So when we're not preserving stale content, the negative content is fairly quickly removed from cache, in comparison with the positive RRsets. But adding max-stale-ttl to the retention period can quite significantly tilt the balance in favour of all of this one-use-only cached negative content.
We don't have any statistics that measure cache hits for different RTYPEs, so we don't know for sure, what percentage of negative content is used again (cache hits) versus just sitting there for no good reason (cache misses) - perhaps we should? (Perhaps we should also have stats on stale hits and misses by RTYPE?)
But in any case, having seen too many caches overloaded with stale negative content, I should like to propose an option that can be used either to shorten the max-stale-ttl for negative content, but that also takes a value of zero, to disable its retention entirely.https://gitlab.isc.org/isc-projects/bind9/-/issues/2489Create test to ensure that TC responses are sent for answer sets that are too...2022-03-01T09:47:16ZBrian ConryCreate test to ensure that TC responses are sent for answer sets that are too largeAs described in #2487, this proper behavior doesn't seem to checked for in our current set of tests.As described in #2487, this proper behavior doesn't seem to checked for in our current set of tests.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2485DNS protocol cleanup: require correct AA bit2023-08-16T16:51:42ZPetr Špačekpspacek@isc.orgDNS protocol cleanup: require correct AA bit### Description
Allegedly different resolvers treat AA bit in responses differently, and this is causing different operational problems for each implementation. PowerDNS and Knot Resolver have had issues with that.
Proposal by Peter va...### Description
Allegedly different resolvers treat AA bit in responses differently, and this is causing different operational problems for each implementation. PowerDNS and Knot Resolver have had issues with that.
Proposal by Peter van Dijk is to be strict on AA bit and punish non-compliance. Main motivation seems to be code simplification when it comes various combinations of NXDOMAIN/NOERROR without SOA RR and/or "extra" NS records in authority which are sometimes added as "good measure" but do not actually mean a referral.
Anecdotes from the field:
a) Ralf Weber from Akamai has some reservations:
> Given that a lot of people use resolvers in front of their authoritative servers who don't send AA I fail to envision what resolvers should do. If we drop non AA answers I expect huge portion of the Internet to go dark, though I don't have hard numbers on that.
b) Recent versions of PowerDNS switched to stricter mode and insist on AA bit being correct. A person from Deutsche Telecom claims this:
> To give a sense of possible impact, we have tens of millions of subscribers and only 5-10 cases per year estimated. So I guess nothing would "go dark" :slightly_smiling_face:
### Links / references
Thread https://chat.dns-oarc.net/community/pl/57pcpenfkf86tr8onmhn1q5a4a
Personally I argue this is
a) not significant enough
b) not widespread enough
to warrant full fledged flag day, but we can start being stricter on AA bit if we decide to do so. PowerDNS already went in that direction so first-mover disadvantage is already paid :-)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2476"statschannel" system test setup may fail on slow systems2023-11-02T16:26:05ZMichał Kępień"statschannel" system test setup may fail on slow systemshttps://gitlab.isc.org/isc-private/bind9/-/jobs/1465497
```
S:statschannel:2021-02-04T12:09:33+0000
T:statschannel:1:A
A:statschannel:System test statschannel
I:statschannel:PORTRANGE:12500 - 12599
I:statschannel:setup.sh script failed
...https://gitlab.isc.org/isc-private/bind9/-/jobs/1465497
```
S:statschannel:2021-02-04T12:09:33+0000
T:statschannel:1:A
A:statschannel:System test statschannel
I:statschannel:PORTRANGE:12500 - 12599
I:statschannel:setup.sh script failed
R:statschannel:FAIL
E:statschannel:2021-02-04T12:09:40+0000
```
Based on the job artifacts, it looks like test setup failed in
`ns2/sign.sh`, specifically on line 37, where the `manykeys` zone is
signed:
```sh
"$SIGNER" -S -x -O full -e "now"+1s -o "$zone" -f "$zonefile" "$infile" > "signzone.out.$zone" 2>&1
```
`bin/tests/system/statschannel/ns2/signzone.out.manykeys.` contains:
```
No self-signed KSK DNSKEY found
Fetching manykeys/RSASHA256/51699 (ZSK) from key repository.
Fetching manykeys/ECDSAP256SHA256/19507 (KSK) from key repository.
Fetching manykeys/RSASHA256/24910 (KSK) from key repository.
Fetching manykeys/ECDSAP384SHA384/27336 (ZSK) from key repository.
Fetching manykeys/ECDSAP256SHA256/61056 (ZSK) from key repository.
Fetching manykeys/ECDSAP384SHA384/43460 (KSK) from key repository.
Zone verification failed (failure)
```
Since the `dnssec-signzone` invocation includes `-e now+1s` (signatures
are supposed to expire one second after `dnssec-signzone` startup) and
this failure is intermittent, what I believe happened here is that
`dnssec-signzone` ran long enough for at least some of the signatures to
already have become expired when zone verification took place.
The simplest solution here seems to be to employ the `-P` switch for
`dnssec-signzone`, which is something we routinely do in system tests.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2450Follow-up from "Draft: Resolve "XoT xfrin""2022-05-23T09:10:40ZOndřej SurýFollow-up from "Draft: Resolve "XoT xfrin""The following discussion from !4571 should be addressed:
- [ ] @each started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4571#note_189777):
> Rebased, squashed, pushed some suggestions, including CHAN...The following discussion from !4571 should be addressed:
- [ ] @each started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4571#note_189777):
> Rebased, squashed, pushed some suggestions, including CHANGES, release note, documentation (which may not be very good, I'm not sure I have the TLS terminology correct), added setter/getter functions for a few things that were left out, and a few other bits and bobs.
>
> I think `dns_transport` should be `isc_transport` so that it can be used with the netmgr and as a parameter to `isc_tlsctx_createserver()`. I almost made that change already but decided to leave it for now so that it would be easier to review the changes I've already made (moving a file makes it harder to read diffs).
>
> We urgently MUST create key and cert files so that we can test with something other than "ephemeral" in the system tests. I suspect non-ephemeral configurations may not work for DoT currently, and I'm certain they don't work for XoT.
>
> I'm about to reveal some possibly-embarrassing ignorance about TLS: does it make _sense_ to reference `tls` statements in `primaries`? `isc_tlsctx_createclient()` doesn't take any parameters, so I'm not sure what `tls <anything-but-ephemeral>` would even do. (I already confirmed it's basically a no-op by configuring it with "tls whatever", a configuration that uses /dev/null for both key and cert files, and it worked fine.)
>
> So, is configuring client-side TLS parameters a thing we want to be able to do but haven't implemented yet? Or is it a thing nobody ever does, and we should revise the syntax so as not to imply it's possible?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2439[ISC-support #17264] revisit hard-coded limit to ADB sizes with shared caches2023-11-02T17:00:03ZBrian Conry[ISC-support #17264] revisit hard-coded limit to ADB sizes with shared cachesCurrently when using a shared cache the ADB size is limited by a `#define` constant. This is documented as being done to allow an operator to specify a huge shared cache size without automatically allowing a similarly-huge ADB for each ...Currently when using a shared cache the ADB size is limited by a `#define` constant. This is documented as being done to allow an operator to specify a huge shared cache size without automatically allowing a similarly-huge ADB for each view attached to that cache.
There are some assumptions here that I believe may be incorrect.
The first incorrect assumption (and verifiable at that) is that BIND will continue to behave well when an ADB is overmem. Analysis on recent customer core files has determined that an overmem ADB may start to "thrash" impacting resolver performance (as noted by the customer's system monitoring).
A second assumption is that there will be enough differences between the query/recursion patterns for each view that no one view will have to worry about possibly needing to have ADB entries for every upstream nameserver. This is clearly false in the degenerate case of a single view using an attached cache, but even with multiple actual views this makes assumptions about how the operator is dividing up the query traffic that are unlikely to always be true.
If #2438 is completed then it may be sufficient to exempt an explicitly configured ADB size from this check. Other possible solutions include allowing this `#define` to be overridden at build-time or using a different scaling formula for shared caches than is used for exclusive caches.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2438[ISC-support #17264] add configuration option to set ADB size independent of ...2023-11-02T17:00:03ZBrian Conry[ISC-support #17264] add configuration option to set ADB size independent of cache sizeCurrently the maximum ADB size is set as a fraction (1/8) of the configured/effective `max-cache-size`.
It has been observed with at least one customer that this size is sometimes insufficient.
This may be related to the rise of CDNs w...Currently the maximum ADB size is set as a fraction (1/8) of the configured/effective `max-cache-size`.
It has been observed with at least one customer that this size is sometimes insufficient.
This may be related to the rise of CDNs with long CNAME chains spread across multiple domains with each domain typically hosted by a large group of geographically-diverse authoritative servers.
While there are other features necessary before an operator can tune this based on data rather than intuition, it may also be useful in our own explorations of ADB behavior in adverse conditions.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2436ADB stats don't provide any information useful to assess the utility that it ...2023-11-02T17:00:03ZBrian ConryADB stats don't provide any information useful to assess the utility that it is able to provideAs mentioned on #2405, the stats related to the ADB are inadequate for an operator to identify when there are issues.
The current ADB stats are limited to:
* `dns_adbstats_entriescnt` - "Addresses in hash table"
* `dns_adbstats_namescnt...As mentioned on #2405, the stats related to the ADB are inadequate for an operator to identify when there are issues.
The current ADB stats are limited to:
* `dns_adbstats_entriescnt` - "Addresses in hash table"
* `dns_adbstats_namescnt` - "Names in hash table"
* `dns_adbstats_nentries` - "Address hash table size"
* `dns_adbstats_nnames` - "Name hash table size"
It is also possible, using the stats channel, to see the stats for the memory contexts used by the ADBs, though there is not an explicit strong association between those memory contexts and the ADB (as identified by view).
It was perhaps expected that these would be sufficient to characterize what is going on in the hash table, but I have recently inspected a customer core file in which the ADB seems to have been in a state of near-constant overmem cleaning with about 73% of the address entries being marked as `ENTRY_IS_DEAD`.
It doesn't matter whether or not those "dead" entries are counted in those stats, the reported values are necessarily providing an incomplete picture of the state of the ADB.
At minimum there should be stats for the number of "live" entries separate from the number of "dead" entries. It may also be informative for an operator to see how many entries are associated with other flags, such as `NOEDNS`.
I have not yet done a thorough analysis to identify any other "missing" stats that may be useful to operators in understanding how their system is performing and utilizing resources.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2435No logging, at any level, related to ADB overmem cleaning2023-11-02T17:00:03ZBrian ConryNo logging, at any level, related to ADB overmem cleaningAs introduced in #2405, there is no logging associated with any of the decisions or actions relating to ADB overmem cleaning.
This makes it impossible to be certain about any of the decisions made, or even *if* decisions were made, with...As introduced in #2405, there is no logging associated with any of the decisions or actions relating to ADB overmem cleaning.
This makes it impossible to be certain about any of the decisions made, or even *if* decisions were made, without using a debugger.
When ADB overmem cleaning operates on a subset of the entries for servers authoritative for a zone it takes actions that will undermine all of the work done maintaining SRTT values and can cause the server to behave in non-intuitive ways.
Among other possible effects that are not yet properly characterized.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2426CID 316504: Untrusted loop bound (TAINTED_SCALAR)2022-03-01T09:57:30ZMichal NowakCID 316504: Untrusted loop bound (TAINTED_SCALAR)```
*** CID 316504: (TAINTED_SCALAR)
/lib/dns/rdata/generic/rrsig_46.c: 233 in totext_rrsig()
227
228 /*
229 * Time signed.
230 */
231 when = uint32_fromregion(&sr);
232 isc_region_consume(&sr, 4);
>>> ...```
*** CID 316504: (TAINTED_SCALAR)
/lib/dns/rdata/generic/rrsig_46.c: 233 in totext_rrsig()
227
228 /*
229 * Time signed.
230 */
231 when = uint32_fromregion(&sr);
232 isc_region_consume(&sr, 4);
>>> CID 316504: (TAINTED_SCALAR)
>>> Passing tainted expression "when" to "dns_time32_totext", which uses it as a loop boundary.
233 RETERR(dns_time32_totext(when, target));
234 RETERR(str_totext(" ", target));
235
236 /*
237 * Footprint.
238 */
/lib/dns/rdata/generic/rrsig_46.c: 225 in totext_rrsig()
219
220 /*
221 * Sig exp.
222 */
223 exp = uint32_fromregion(&sr);
224 isc_region_consume(&sr, 4);
>>> CID 316504: (TAINTED_SCALAR)
>>> Passing tainted expression "exp" to "dns_time32_totext", which uses it as a loop boundary.
225 RETERR(dns_time32_totext(exp, target));
226 RETERR(str_totext(" ", target));
227
228 /*
229 * Time signed.
230 */
```Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2425CID 316505: Insecure data handling (TAINTED_SCALAR)2022-03-01T09:57:33ZMichal NowakCID 316505: Insecure data handling (TAINTED_SCALAR)```
*** CID 316505: Insecure data handling (TAINTED_SCALAR)
/lib/dns/journal.c: 972 in journal_find()
966 return (ISC_R_SUCCESS);
967 }
968
969 current_pos = j->header.begin;
970 index_find(j, serial, &current...```
*** CID 316505: Insecure data handling (TAINTED_SCALAR)
/lib/dns/journal.c: 972 in journal_find()
966 return (ISC_R_SUCCESS);
967 }
968
969 current_pos = j->header.begin;
970 index_find(j, serial, ¤t_pos);
971
>>> CID 316505: Insecure data handling (TAINTED_SCALAR)
>>> Using tainted variable "current_pos.serial" as a loop boundary.
972 while (current_pos.serial != serial) {
973 if (DNS_SERIAL_GT(current_pos.serial, serial)) {
974 return (ISC_R_NOTFOUND);
975 }
976 result = journal_next(j, ¤t_pos);
977 if (result != ISC_R_SUCCESS) {
```Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2424CID 316506: Insecure data handling (TAINTED_SCALAR)2022-03-01T09:57:36ZMichal NowakCID 316506: Insecure data handling (TAINTED_SCALAR)```
*** CID 316506: Insecure data handling (TAINTED_SCALAR)
/lib/dns/journal.c: 1855 in read_one_rr()
1849 */
1850 if (isc_buffer_remaininglength(&j->it.source) != rdlen) {
1851 FAIL(DNS_R_FORMERR);
1852 }
1853 ...```
*** CID 316506: Insecure data handling (TAINTED_SCALAR)
/lib/dns/journal.c: 1855 in read_one_rr()
1849 */
1850 if (isc_buffer_remaininglength(&j->it.source) != rdlen) {
1851 FAIL(DNS_R_FORMERR);
1852 }
1853 isc_buffer_setactive(&j->it.source, rdlen);
1854 dns_rdata_reset(&j->it.rdata);
>>> CID 316506: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted expression "j->it.source.active" to "dns_rdata_fromwire", which uses it as a loop boundary.
1855 CHECK(dns_rdata_fromwire(&j->it.rdata, rdclass, rdtype, &j->it.source,
1856 &j->it.dctx, 0, &j->it.target));
1857 j->it.ttl = ttl;
1858
1859 j->it.xpos += sizeof(journal_rawrrhdr_t) + rrhdr.size;
1860 if (rdtype == dns_rdatatype_soa) {
```Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2422CID 316508: Insecure data handling (TAINTED_SCALAR)2022-03-01T09:57:39ZMichal NowakCID 316508: Insecure data handling (TAINTED_SCALAR)```
*** CID 316508: Insecure data handling (TAINTED_SCALAR)
/lib/dns/journal.c: 1714 in dns_journal_iter_init()
1708
1709 result = journal_next(j, &pos);
1710 if (result == ISC_R_NOMORE) {
1711 result = ISC_R...```
*** CID 316508: Insecure data handling (TAINTED_SCALAR)
/lib/dns/journal.c: 1714 in dns_journal_iter_init()
1708
1709 result = journal_next(j, &pos);
1710 if (result == ISC_R_NOMORE) {
1711 result = ISC_R_SUCCESS;
1712 }
1713 CHECK(result);
>>> CID 316508: Insecure data handling (TAINTED_SCALAR)
>>> Using tainted variable "pos.serial" as a loop boundary.
1714 } while (pos.serial != end_serial);
1715
1716 /*
1717 * For each RR, subtract the length of the RR header,
1718 * as this would not be present in IXFR messages.
1719 * (We don't need to worry about the transaction header
```Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2419CID 316511: Insecure data handling (TAINTED_SCALAR)2022-03-01T09:57:42ZMichal NowakCID 316511: Insecure data handling (TAINTED_SCALAR)```
*** CID 316511: Insecure data handling (TAINTED_SCALAR)
/lib/dns/rdata/generic/hip_55.c: 496 in casecompare_hip()
490 key_len = uint16_fromregion(&r1);
491 isc_region_consume(&r1, 2); /* key length */
492 isc_region_...```
*** CID 316511: Insecure data handling (TAINTED_SCALAR)
/lib/dns/rdata/generic/hip_55.c: 496 in casecompare_hip()
490 key_len = uint16_fromregion(&r1);
491 isc_region_consume(&r1, 2); /* key length */
492 isc_region_consume(&r2, 4);
493
494 INSIST(r1.length >= (unsigned)(hit_len + key_len));
495 INSIST(r2.length >= (unsigned)(hit_len + key_len));
>>> CID 316511: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted expression "hit_len + key_len" to "memcmp", which uses it as an offset.
496 order = memcmp(r1.base, r2.base, hit_len + key_len);
497 if (order != 0) {
498 return (order);
499 }
500 isc_region_consume(&r1, hit_len + key_len);
501 isc_region_consume(&r2, hit_len + key_len);
```Not plannedMark AndrewsMark Andrews