ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-05-24T11:27:31Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4024named took too long to terminate in respdiff-long-third-party job2023-05-24T11:27:31ZMichal Nowaknamed took too long to terminate in respdiff-long-third-party jobJob [#3333558](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3333558) failed for 6892e463bf7daf93c332d33919c20f978a39b539.
60 seconds wasn't enough for `named` in `respdiff-long-third-party` to terminate and has been aborted instead....Job [#3333558](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3333558) failed for 6892e463bf7daf93c332d33919c20f978a39b539.
60 seconds wasn't enough for `named` in `respdiff-long-third-party` to terminate and has been aborted instead.
```
[Current thread is 1 (Thread 0x7f80690d6140 (LWP 17957))]
#0 0x00007f806b984d56 in epoll_wait (epfd=4, events=0x7ffe696dc2c0, maxevents=1024, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
#1 0x00007f806bd6d83a in uv__io_poll (loop=0x7f8068ca2220, timeout=-1) at /usr/src/libuv-v1.44.1/src/unix/epoll.c:236
#2 0x00007f806bd528ae in uv_run (loop=0x7f8068ca2220, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.44.1/src/unix/core.c:391
#3 0x00007f806c3e1b73 in loop_run (loop=loop@entry=0x7f8068ca2200) at loop.c:272
#4 0x00007f806c3e1c16 in loop_thread (arg=0x7f8068ca2200) at loop.c:299
#5 0x00007f806c3e29af in isc_loopmgr_run (loopmgr=0x7f8068c1c1c0) at loop.c:473
#6 0x000055ea5742e0e0 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1513
```
Full backtrace and logs were saved as part of CI artifacts.https://gitlab.isc.org/isc-projects/bind9/-/issues/4017delv +ns does not respect +nomultiline2023-07-24T09:40:40ZPetr Špačekpspacek@isc.orgdelv +ns does not respect +nomultiline### Summary
`delv +ns` even with `+nomultiline` (which is still presumably default) still produces records split across lines.
### BIND version used
* ~"Affects v9.19": 453aaac
### Steps to reproduce
```console
$ delv +ns +nomultili...### Summary
`delv +ns` even with `+nomultiline` (which is still presumably default) still produces records split across lines.
### BIND version used
* ~"Affects v9.19": 453aaac
### Steps to reproduce
```console
$ delv +ns +nomultiline
```
### What is the current *bug* behavior?
See RRSIG at the bottom:
```
;; ANSWER SECTION:
;. 518400 IN NS g.root-servers.net.
;. 518400 IN NS j.root-servers.net.
;. 518400 IN NS e.root-servers.net.
;. 518400 IN NS l.root-servers.net.
;. 518400 IN NS d.root-servers.net.
;. 518400 IN NS a.root-servers.net.
;. 518400 IN NS b.root-servers.net.
;. 518400 IN NS i.root-servers.net.
;. 518400 IN NS m.root-servers.net.
;. 518400 IN NS h.root-servers.net.
;. 518400 IN NS c.root-servers.net.
;. 518400 IN NS k.root-servers.net.
;. 518400 IN NS f.root-servers.net.
;. 518400 IN RRSIG NS 8 0 518400 (
; 20230430050000 20230417040000 60955 .
; ixbH/37glxgsTPCpCAuQPTDMH98e
; 70cquz9G9NRI+ex75JQzxeAUMcsw
; TtiY19vVTEPfrbRorDAxLRC720BV
; pJ9ZOQBBl8A9ss2R022TCSoBR44d
; BqY2e7M5nyUBaIkFkvF9+wyxa24+
; MHBli9qC91C+4uuTpqVhZjtnOjKQ
; 8UMRVZoZ5qTrn6EV9x5qq5akItf7
; hi1BEjJKylYdcplg5x3JDqkKGnso
; OS45mvo3fOt0owujArlEnsPy8+I3
; LwL1W68VdjG1CnTEp2HFpqbnoxQ1
; KhpKWErf/HEYxOnDgsXljUDuWOEX
; wj+UOYSnRzRekFGfSu211D447iHl
; 8XHISQ== )
```
### What is the expected *correct* behavior?
RRSIG (or any other RR) is not split across lines.https://gitlab.isc.org/isc-projects/bind9/-/issues/4014Implement tests for maximum global and idle time for incoming XFR2023-05-04T14:23:14ZOndřej SurýImplement tests for maximum global and idle time for incoming XFRSpin-off from !7810 to not forget to write pytests for maximum global and idle time for incoming XFR.Spin-off from !7810 to not forget to write pytests for maximum global and idle time for incoming XFR.Not plannedTom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4013Add more tests for #4001 and #40022023-07-03T15:47:55ZOndřej SurýAdd more tests for #4001 and #4002This is a follow up from !7805 to add more tests for the source-port configuration.
To quote @pspacek:
> Well, this is pretty large change and needs tests. If nothing else I would like to see what happens if:
>
> * attempt to open TCP...This is a follow up from !7805 to add more tests for the source-port configuration.
To quote @pspacek:
> Well, this is pretty large change and needs tests. If nothing else I would like to see what happens if:
>
> * attempt to open TCP connection ends up in packet black-hole
> * connection is established and the remote side does not respond (established connection hangs)
> * the remote side responds with some something which does not parse as DNS
> * the remote side sends mismatching NOTIFY answer (say different zone name)Not plannedTom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/280format string report2023-04-20T08:11:52ZPeter Daviesformat string reportformat string bugs in ISC DHCP
While examining ISC DHCP's source code, I noticed a couple of format string bugs in the following locations:
https://github.com/isc-projects/dhcp/blob/572032cb0e514606559de3784e3f7ca8e1539d17/common/parse...format string bugs in ISC DHCP
While examining ISC DHCP's source code, I noticed a couple of format string bugs in the following locations:
https://github.com/isc-projects/dhcp/blob/572032cb0e514606559de3784e3f7ca8e1539d17/common/parse.c#L5611
https://github.com/isc-projects/dhcp/blob/572032cb0e514606559de3784e3f7ca8e1539d17/keama/keama.c#L209
To reproduce these bugs on Ubuntu 22.04, you may follow these steps:
```
raptor@fnord:~$ cp /sbin/dhclient . # copy to local directory to bypass apparmor policy
raptor@fnord:~$ echo "include foo" > %n%n%n%n
raptor@fnord:~$ echo "include foo" > %x%x%x%x
raptor@fnord:~$ ./dhclient -cf %n%n%n%n # write to memory, caught by exploit mitigations
*** %n in writable segment detected ***
raptor@fnord:~$ ./dhclient -cf %x%x%x%x # read from memory, notice the leak in the syslog file
RTNETLINK answers: Operation not permitted
RTNETLINK answers: Operation not permitted
raptor@fnord:~$ grep "filename string expected" /var/log/syslog
Apr 7 19:28:01 fnord dhclient[5389]: 7cb92e0d7200 line 1: filename string expected.
```
I've just noticed ISC DHCP has recently reached EOL and I can't think of any scenario in which these bugs could be exploited in order to cross a security boundary. However, as format string bugs are a very powerful exploitation primitive, in my opinion they should be fixed in any case just to be careful.
Please let me know if you intend to issue a fix and/or request a CVE ID.
Regards,
--
Marco Ivaldihttps://gitlab.isc.org/isc-projects/bind9/-/issues/4010Allow for scripts / hooks for key rollovers2023-04-11T12:43:32ZKarol BabiochAllow for scripts / hooks for key rollovers### Description
It seems like currently there is no good way on how to automate a KSK rollover, since the corresponding DS record has to published in the parent zone. While there is [RFC7344](https://datatracker.ietf.org/doc/html/rfc734...### Description
It seems like currently there is no good way on how to automate a KSK rollover, since the corresponding DS record has to published in the parent zone. While there is [RFC7344](https://datatracker.ietf.org/doc/html/rfc7344), in reality it is not widely adopted. Personally I don't know any registrar who supports this yet. Anyway, this would require TSIG to be secure anyway.
One of my registrars offers an HTTPS-based API to manage DNSSEC records. Hence, its possible to write scripts that will automate the key rollover process.
### Request
There should be a way to trigger a script (with some inputs such as the key id, the DS record, etc.) whenever BIND is about to rotate a key. This way it should be possible to use `dnssec-policy` and fully automate the key rollover process, including the `KSK` key (rather than only the `ZSK` key).
### Links / referencesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4007mkeys: exceeded time limit waiting for 'dump_done' in ns5/named.run2023-04-06T12:42:02ZMichal Nowakmkeys: exceeded time limit waiting for 'dump_done' in ns5/named.runJob [#3300214](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3300214) failed for 8f73f5d0886d9e0f57f593fbf3bae862d13f9853:
```
I:mkeys:check 'rndc managed-keys' and islands of trust now that root is reachable (39)
I:mkeys:exceeded ti...Job [#3300214](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3300214) failed for 8f73f5d0886d9e0f57f593fbf3bae862d13f9853:
```
I:mkeys:check 'rndc managed-keys' and islands of trust now that root is reachable (39)
I:mkeys:exceeded time limit waiting for 'dump_done' in ns5/named.run
```
I've seen the 20-second limit exceeded several times.
Bumping it to 60 might be a good thing.Not plannedhttps://gitlab.isc.org/isc-projects/stork/-/issues/1021The breadcrumbs are sometimes not refreshed.2023-04-18T13:42:22ZSlawek FigielThe breadcrumbs are sometimes not refreshed.The issue was reported by @slawek during 1.10 sanity checks. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/1009#note_364605).
The breadcrumbs are sometimes not refreshed.
Steps to reproduce:
1. Go to Kea Apps page using ...The issue was reported by @slawek during 1.10 sanity checks. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/1009#note_364605).
The breadcrumbs are sometimes not refreshed.
Steps to reproduce:
1. Go to Kea Apps page using navbar menu: Services => Kea Apps
1. Observe breacrumbs: `Home > Services > Kea Apps`
1. Go to BIND 9 Apps page using navbar menu: Services => BIND 9 Apps
1. Observe the breadcrumbs are not refreshed. It is still `Home > Services > Kea Apps`.
![image](https://gitlab.isc.org/isc-projects/stork/uploads/30d80c2a1601a935660b2862bd65c23d/image.png)backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/1013Configure Kea Control Agent with TLS in demo2023-05-30T13:39:16ZSlawek FigielConfigure Kea Control Agent with TLS in demoThe issue was reported by @slawek during 1.10 sanity checks. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/1009#note_364515).
At least one Kea Control Agent in the demo should be configured to accept only TLS connections.The issue was reported by @slawek during 1.10 sanity checks. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/1009#note_364515).
At least one Kea Control Agent in the demo should be configured to accept only TLS connections.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/1012Hide "Use HTTP credentials" entry for BIND 9 apps2023-04-18T13:28:47ZSlawek FigielHide "Use HTTP credentials" entry for BIND 9 appsThe issue was found by @slawek during 1.10 sanity checks. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/1009#note_364514).
The "Use HTTP credentials" entry for Bind9-only machines should be hidden on the machine page. This...The issue was found by @slawek during 1.10 sanity checks. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/1009#note_364514).
The "Use HTTP credentials" entry for Bind9-only machines should be hidden on the machine page. This field applies only to Kea machines.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/1011"How to Install Agent on New Machine" help tip for non-super-admins2023-04-18T13:27:56ZSlawek Figiel"How to Install Agent on New Machine" help tip for non-super-adminsThe issue was found by @slawek during 1.10 sanity checks. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/1009#note_364511).
The `admin` is not permitted to show the "How to Install Agent on New Machine" help tip. After clic...The issue was found by @slawek during 1.10 sanity checks. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/1009#note_364511).
The `admin` is not permitted to show the "How to Install Agent on New Machine" help tip. After clicking the button, the ugly error page is presented.
The help panel could be available for users with the `admin` role but with the hidden server token.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/1010Hide "Authorize" button for non-super-admin users2024-03-13T10:34:59ZSlawek FigielHide "Authorize" button for non-super-admin usersThe issue was found by @slawek during 1.10 sanity checks. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/1009#note_364510).
The users in an `admin` role are not permitted to authorize machines, but the "Authorize" button is...The issue was found by @slawek during 1.10 sanity checks. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/1009#note_364510).
The users in an `admin` role are not permitted to authorize machines, but the "Authorize" button is presented for them. After clicking the button, the ugly error page is presented. The "Authorize" button should be hidden for users with the `admin` role.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2829Factor v4 BLQ unit tests2023-07-07T12:36:42ZFrancis DupontFactor v4 BLQ unit testsSQL unit tests for SQL backends can share a lot of code with memfile as they were copied from...
This creates a generic set of tests in testutils and then derive the tests for each of the backends.SQL unit tests for SQL backends can share a lot of code with memfile as they were copied from...
This creates a generic set of tests in testutils and then derive the tests for each of the backends.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2828Document or fix database conflicts between v4 hosts and v6 hosts2023-04-20T13:38:11ZAndrei Pavelandrei@isc.orgDocument or fix database conflicts between v4 hosts and v6 hostsSay there are a kea-dhcp4 server and a kea-dhcp6 server with both their `hosts-databases` set to the same database.
If an administrator wants to reserve v4 resources and v6 resources for the same client identified by a common identifier...Say there are a kea-dhcp4 server and a kea-dhcp6 server with both their `hosts-databases` set to the same database.
If an administrator wants to reserve v4 resources and v6 resources for the same client identified by a common identifier type, say hardware address, the host schema goes out if its way to allow this, having separate `dhcp4_subnet_id` and `dhcp6_subnet_id` columns, separate `dhcp4_options` and `dhcp6_options` tables, and so on.
However, the response to the second of the two `reservation-add` commands that are issued for each server, is `Database duplicate entry error`.
What's worse is that the administrator might assume that there is already a reservation with that identifier in the database, but if you follow up with a `reservation-get-all` to check it out, it doesn't show up, because it only shows hosts from the server version that is queried and the duplicate is for the other server version.
I'm suggesting that this needs to be either documented in the ARM, or fixed which is not difficult and is doable, and backwards-compatible, by including `dhcp4_subnet_id` and `dhcp6_subnet_id` as part of the primary key in the `hosts` table.outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3992The XFR unreachable cache redesign2024-03-01T09:52:29ZOndřej SurýThe XFR unreachable cache redesignThe unreachable cache for **dead primaries** was added to BIND 9 in 2006 via 1372e172d0e0b08996376b782a9041d1e3542489. It features a 10-slot LRU array with 600 seconds (10 minutes) fixed delay. During this time, any primary with a hicc...The unreachable cache for **dead primaries** was added to BIND 9 in 2006 via 1372e172d0e0b08996376b782a9041d1e3542489. It features a 10-slot LRU array with 600 seconds (10 minutes) fixed delay. During this time, any primary with a hiccup would be blocked for the whole block duration (unless overwritten by a different dead primary).
One can argue:
- 10 minutes is too long for a fixed, non-configurable delay
- 10 slots are not enough - servers could be running 1M and more zones with different primaries; and especially in situations like these, there's a high chance that more primaries would be having problems
I think this needs a redesign, but meanwhile - I think that we can drop the `UNREACH_HOLD_TIME` to something like 10 seconds (or 60?) - this should still prevent a thundering herd over the unresponsive server, but the recovery is going to be much faster.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3987Change DNSKEY TTL of inline-signed zone2024-02-24T07:55:08ZGerald VogtChange DNSKEY TTL of inline-signed zone### Description
I have a few zones using inline-signing which I have set up originally with 2d TTL. Due to this the existing DNSKEY RRs also have 2d TTL. Now I have been trying to reduce the TTL to 1d but it seems there is no supported ...### Description
I have a few zones using inline-signing which I have set up originally with 2d TTL. Due to this the existing DNSKEY RRs also have 2d TTL. Now I have been trying to reduce the TTL to 1d but it seems there is no supported way or tool to do so.
I have set dnskey-ttl to 1d and replace keys, still all DNSKEY RRs have 2d TTL. Setting it on the key with dnssec-settime doesn't help either and man pages specifically mention:
```
This option sets the default TTL to use for this key when it is converted into a DNSKEY RR.
This is the TTL used when the key is imported into a zone, unless there was already a DNSKEY
RRset in place, in which case the existing TTL takes precedence.
```
Running AlmaLinux 9 bind-9.16.23-5.el9_1.x86_64.
### Request
Add some way to change the TTL of DNSKEY RRs in inline-signed zones.
### Links / references
I have found a thread from 2016 about the same problem: https://www.mail-archive.com/bind-users@lists.isc.org/msg23186.htmlMay 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2825Deprecate extended JSON in favor for compliant JSON comments2023-04-20T12:55:56ZCarsten StrotmannDeprecate extended JSON in favor for compliant JSON comments---
name: Deprecate extended JSON in favor for compliant JSON comments/includes
Kea DHCP uses an extended JSON format with comments and includes that deviates from "standard" JSON (RFC 8259).
While it is nice to have comments and incl...---
name: Deprecate extended JSON in favor for compliant JSON comments/includes
Kea DHCP uses an extended JSON format with comments and includes that deviates from "standard" JSON (RFC 8259).
While it is nice to have comments and includes in the configuration file, the current implementation is not compliant with the JSON specs and breaks other tools JSON parser.
For non-trivial Kea DHCP configuration files, it is highly recommended to use a text editor with JSON support (VS Code, VIM, Emacs, BBEdit etc) or a JSON editor. However, the current "extensions" break the JSON support in these tools/editors so that they cannot be used. The loss of these tools is hurting more than the extra functions implemented in the extended JSON format.
I propose that the current extension are being deprecated and replaced with comments and includes that are valid according to the JSON RFC, so that non-Kea tools can be used when working with Kea configuration files.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2824Optimizations in the allocator selection: copy the existing state2023-04-13T13:49:14ZMarcin SiodelskiOptimizations in the allocator selection: copy the existing stateThe random and flq allocators maintain their states. It is particularly long for the FLQ allocator to populate its initial state. It can take from milliseconds to minutes. When a subnet is reconfigured without changing the allocator and ...The random and flq allocators maintain their states. It is particularly long for the FLQ allocator to populate its initial state. It can take from milliseconds to minutes. When a subnet is reconfigured without changing the allocator and the subnet pools, we could perhaps avoid re-building the allocator state but keeping the existing state aside, and then copying the pointer to the allocation state to the new subnet instance. In that case we'd only have the overhead during the startup, renumbering and an allocator change. In all other cases, the reconfiguration would be smooth.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2820Optionally log transaction ID with log messages2024-03-27T12:55:48ZDarren AnkneyOptionally log transaction ID with log messagesIt could be useful to have a `%` parameter available for the pattern in the loggers section to add the transaction id to each message logged. It's already logged on some messages but not all.
Example:
```
2023-03-30 20:26:27.518 DEBUG ...It could be useful to have a `%` parameter available for the pattern in the loggers section to add the transaction id to each message logged. It's already logged on some messages but not all.
Example:
```
2023-03-30 20:26:27.518 DEBUG [kea-dhcp4.hosts/283769.281473780088704] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 1 and IPv4 address 192.168.115.202
```
vs.
```
2023-03-30 20:26:27.518 DEBUG [kea-dhcp4.alloc-engine/283769.281473780088704] ALLOC_ENGINE_V4_REQUEST_ALLOC_REQUESTED [hwtype=1 00:0c:01:02:03:06], cid=[01:00:0c:01:02:03:06], tid=0x3: trying to allocate requested address 192.168.115.202
```
Having a way to log it consistently before the start of the message would be helpful when trying to find all of the messages that occurred with a particular exchange. It could even be useful to match these up to packets in a pcap.
[RT21953](https://support.isc.org/Ticket/Display.html?id=21953)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2819Add max TTL time to D22024-03-27T12:49:15ZDarren AnkneyAdd max TTL time to D2With the addition of being able to set the DDNS TTL with `ddns-ttl-percent` to some percentage of lease time, it might be a good idea to add a maximum possible TTL to the `kea-ddns` configuration. This should be an absolute time limit. ...With the addition of being able to set the DDNS TTL with `ddns-ttl-percent` to some percentage of lease time, it might be a good idea to add a maximum possible TTL to the `kea-ddns` configuration. This should be an absolute time limit. For example, `3600` for one hour maximum TTL length. In this example, if Kea sent something higher than this, D2 would truncate the TTL to `3600`. If the proposed setting is not present in D2 then there should be no change from current behavior which, I believe, is no limit to the length of the TTL.
[RT21610](https://support.isc.org/Ticket/Display.html?id=21610)next-stable-3.0