ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-03-06T00:14:18Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4611Stub zones return unexpected NS records2024-03-06T00:14:18ZPeter DaviesStub zones return unexpected NS records### Summary
BIND server B with a static-stub zone configured with a server address of BIND
server A, a secondary for that zone, may return unexpected NS records.
### BIND version affected
```
I tested with BIND 9.19.21, but I belie...### Summary
BIND server B with a static-stub zone configured with a server address of BIND
server A, a secondary for that zone, may return unexpected NS records.
### BIND version affected
```
I tested with BIND 9.19.21, but I believe this behaviour probably goes back to BIND 9.11.x
named -V
BIND 9.19.21 (Development Release) <id:c030a67>
running on Linux x86_64 6.2.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 16:51:53 UTC 2023
built by make with '--enable-fixed-rrset' '--enable-dnstap' '--enable-querytrace=yes' '--with-openssl' '--with-libxml2' '--with-json-c' '--enable-full-report' 'PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/'
compiled by GCC 12.3.1 20230508 (Red Hat 12.3.1-1)
compiled with OpenSSL version: OpenSSL 3.0.9 30 May 2023
linked to OpenSSL version: OpenSSL 3.0.9 30 May 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.46.0
compiled with liburcu version: 0.15.0-pre
compiled with jemalloc version: 5.2.1
compiled with libnghttp2 version: 1.51.0
linked to libnghttp2 version: 1.51.0
compiled with libxml2 version: 2.10.3
linked to libxml2 version: 21004
compiled with json-c version: 0.15
linked to json-c version: 0.17
compiled with zlib version: 1.2.12
linked to zlib version: 1.2.12
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.1
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): no
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /usr/local/etc/named.conf
rndc configuration: /usr/local/etc/rndc.conf
nsupdate session key: /usr/local/var/run/named/session.key
named PID file: /usr/local/var/run/named/named.pid
```
### Steps to reproduce
1) set up servers A and B with the configurations below.
2) Query Server B repeatedly for an RR from the static-stub zone:
```
While true do dig hgw.ddi.com @127.0.0.1
; <<>> DiG 9.19.21 <<>> hgw.ddi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27748
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 23cb1ccef98f3bf00100000065df1c8b908417789e893016 (good)
;; QUESTION SECTION:
;hgw.ddi.com. IN A
;; ANSWER SECTION:
hgw.ddi.com. 300 IN A 10.0.0.1
;; AUTHORITY SECTION:
ddi.com. 260 IN NS bialistock.ddi.com.
ddi.com. 260 IN NS haparanda.ddi.com.
;; ADDITIONAL SECTION:
haparanda.ddi.com. 300 IN A 10.0.0.237
bialistock.ddi.com. 300 IN A 10.0.0.49
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Feb 28 11:44:11 UTC 2024
;; MSG SIZE rcvd: 165
```
### What is the current *bug* behavior?
When the NS records in the authority section expire, Server B add the server-names
from its static-stub configuration as NS records plus a NS record in the name of
the domain itself
```
...
; <<>> DiG 9.19.21 <<>> hgw.ddi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50265
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 88424ea83ed9b09d0100000065df1d8b76b871a0c1e4d1e7 (good)
;; QUESTION SECTION:
;hgw.ddi.com. IN A
;; ANSWER SECTION:
hgw.ddi.com. 44 IN A 10.0.0.1
;; AUTHORITY SECTION:
ddi.com. 4 IN NS bialistock.ddi.com.
ddi.com. 4 IN NS haparanda.ddi.com.
;; ADDITIONAL SECTION:
haparanda.ddi.com. 44 IN A 10.0.0.237
bialistock.ddi.com. 44 IN A 10.0.0.49
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Feb 28 11:48:27 UTC 2024
;; MSG SIZE rcvd: 165
; <<>> DiG 9.19.21 <<>> hgw.ddi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39703
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 329a1ed8e54b28d30100000065df1d90545987c64fe602f2 (good)
;; QUESTION SECTION:
;hgw.ddi.com. IN A
;; ANSWER SECTION:
hgw.ddi.com. 39 IN A 10.0.0.1
;; AUTHORITY SECTION:
ddi.com. 86400 IN NS StaticStubZoneNS-1.org.
ddi.com. 86400 IN NS ddi.com.
ddi.com. 86400 IN NS StaticStubZoneNS-2.org.
```
### What is the expected *correct* behavior?
I expect to see the NS records from the domain or none at all.
### Relevant configuration files
Server A config:
```
options {
directory "/home/named";
pid-file "named.pid";
listen-on-v6 { none; };
dnssec-validation auto;
recursion yes;
allow-recursion { any; };
};
zone "ddi.com" IN {
type secondary;
primaries { 10.0.0.4;};
file "s/db.ddi.com";
allow-transfer {any;};
notify false;
};
```
Server B config:
```
options {
directory "/home/named";
pid-file "named.pid";
listen-on-v6 { none; };
dnssec-validation no;
minimal-responses no;
recursion yes;
max-cache-size 90%;
allow-recursion { any; };
};
zone "ddi.com" IN {
type static-stub;
server-addresses {
10.0.0.182;
};
server-names {
"StaticStubZoneNS-1.org";
"StaticStubZoneNS-2.org";
};
};
```
Zone file:
```
ddi.com. 86400 IN SOA haparanda.ddi.com. support.ddi.com. 2024021733 1800 900 604800 86400
ddi.com. 260 IN NS haparanda.ddi.com.
ddi.com. 260 IN NS bialistock.ddi.com.
alice-laptop.ddi.com. 600 IN A 10.0.0.149
bag-local-lyset.ddi.com. 300 IN A 10.0.0.15
bialistock.ddi.com. 300 IN A 10.0.0.49
haparanda.ddi.com. 300 IN A 10.0.0.237
hgw.ddi.com. 300 IN A 10.0.0.1
...
```
### Relevant logs
Server B has no IPV6 connectivity the following was logged at startup:
```
Feb 28 11:44:11 bialistock named[235198]: network unreachable resolving 'StaticStubZoneNS-1.org/AAAA/IN': 2001:500:c::1#53
Feb 28 11:44:11 bialistock named[235198]: network unreachable resolving 'StaticStubZoneNS-2.org/A/IN': 2001:500:c::1#53
```
[SF00001680](https://isc.lightning.force.com/lightning/r/Case/500S60000054BVSIA2/view)https://gitlab.isc.org/isc-projects/kea/-/issues/3275Kea DB allows to store too short identifier in the lease table2024-03-21T14:50:56ZSlawek FigielKea DB allows to store too short identifier in the lease tableWhile performing some experiments in Stork, I found that the Kea database accepts identifiers that are too short (less than 3 bytes) in the `lease6` table. It causes the error to be thrown when the identifier is processed. I noticed it b...While performing some experiments in Stork, I found that the Kea database accepts identifiers that are too short (less than 3 bytes) in the `lease6` table. It causes the error to be thrown when the identifier is processed. I noticed it blocks fetching this lease by API. I don't know if it has any other internal consequences.
Steps to reproduce:
1. Setup Kea 2.3.8 or above with PostgreSQL.
2. Configure lease database.
3. Insert a lease with too short DUID (e.g., `00`)
```
INSERT INTO lease6(address, duid, valid_lifetime, expire, subnet_id, pref_lifetime, lease_type, iaid, prefix_len, hwtype, hwaddr_source, state) VALUES('3001:db8:1::2', DECODE('00', 'hex'), 3600, NOW() + interval '1' MONTH, 1, 1800, 0, 1, 128, 0, 0, 1);
```
4. Send the `lease-get` command with the specified address (i.e., `3001:db8:1::2`).
5. Observe the error:
```
stork-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'lease6-get'
stork-agent-kea6-1 | INFO CTRL_AGENT_COMMAND_RECEIVED command lease6-get received from remote address 127.0.0.1
stork-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'lease6-get'
stork-agent-kea6-1 | ERROR LEASE_CMDS_GET6_FAILED lease6-get command failed (parameters: { "ip-address": "3001:db8:1::2", "type": "IA_NA" }, reason: Could not convert data to Lease6, reason: identifier is too short (1), at least 3 is required)
stork-agent-kea6-1 | ERROR HOOKS_CALLOUT_ERROR error returned by callout on hook $lease6_get registered by library with index 1 (callout address 0x7f12e8310e90) (callout duration 0.593 ms)
stork-agent-kea6-1 | INFO CTRL_AGENT_COMMAND_FORWARDED command lease6-get successfully forwarded to the service dhcp6 from remote address 127.0.0.1
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3274Synchronous run script2024-03-14T14:37:11ZAndrei Pavelandrei@isc.orgSynchronous run scriptAs ARM states
> Currently, enabling synchronous calls to external scripts is not supported.
Sync run script is not supported.
With the addition of sync process spawn functionality in issue 3025, this is now doable.As ARM states
> Currently, enabling synchronous calls to external scripts is not supported.
Sync run script is not supported.
With the addition of sync process spawn functionality in issue 3025, this is now doable.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3273Upgrade schema on startup2024-03-14T14:36:20ZAndrei Pavelandrei@isc.orgUpgrade schema on startupKea could have a boolean database-level configuration knob with a default of false that, when enabled, makes the schema be upgraded on startup.
Should be straightforward to do following the work on automatic database init in issue 3025.Kea could have a boolean database-level configuration knob with a default of false that, when enabled, makes the schema be upgraded on startup.
Should be straightforward to do following the work on automatic database init in issue 3025.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3272Refactor ProcessSpawn2024-03-14T14:34:16ZAndrei Pavelandrei@isc.orgRefactor ProcessSpawnThere are a few things that could be improved in the ProcessSpawn implementation. They become more apparent now that the synchronous functionality has been added to it, but the issues were present before too.
- The asynchronous implemen...There are a few things that could be improved in the ProcessSpawn implementation. They become more apparent now that the synchronous functionality has been added to it, but the issues were present before too.
- The asynchronous implementation of ProcessSpawn relies on having a global IO signal set and on having the IO service being periodically polled in order to wait for child processes which is why it uses the main IO service. For this reason:
- There needs to be a dedicated AsyncProcessSpawn class that should be a singleton to signal to the developer that it has global dependency objects.
- There needs to be a method in AsyncProcessSpawn that sets the IO service. It needs to be callable only once and called as close as possible to the creation of the main IO service. Spawning would throw if the IO service is not initialized. This is to avoid the current behavior which sets the IO service on the first ProcessSpawn creation which could be on a null IOServicePtr. See `src/hooks/dhcp/run_script/run_script.cc` or `src/hooks/dhcp/forensic_log/rotating_file.cc`.
- There should be a new class encapsulating the synchronous implementation, say `SyncProcessSpawn`. It does not have to be a singleton since waiting for the child process is done in the scope it was declared, and the object can be safely deleted afterwards.
- It is worth considering to change the sync variant to use an IO signal set and an IO service like the async variant, but these should not be global, but declarable by the developer, or even better, hidden by the implementation.
- The dismiss feature in spawn is not used in code. I suggest removing it.
- The async process spawn is currently fire-and-forget. It would be nice for the async process spawn to have the ability to be notified that the process has finished and that its status is available. Maybe with the help of a condition variable?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3269Possible problem with RADIUS and shared networks2024-03-25T14:08:01ZFrancis DupontPossible problem with RADIUS and shared networksRADIUS uses the (re)selected subnet to fetch a cached host entry: this is not correct with shared networks where it should try all subnets of the shared networks without a guard incompatible with the query. And when RADIUS creates a new ...RADIUS uses the (re)selected subnet to fetch a cached host entry: this is not correct with shared networks where it should try all subnets of the shared networks without a guard incompatible with the query. And when RADIUS creates a new host entry for a reserved address it uses the (re)selected subnet instead of a subnet where the address belongs.
These two problems can make RADIUS to fail to find a cached entry: not a bug as the server will return the informations but not without performance impact...next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3268selectSubnet() should return a ConstSubnetXPtr2024-03-18T09:34:02ZFrancis DupontselectSubnet() should return a ConstSubnetXPtrTwo proposals to improve subnets:
- use for getSubnet the same code as for getBySubnetId (so O(log(N)) vs current O(N))
- selectSubnet should return a ConstSubnetXPtr i.e. `boost::shared_ptr<const SubnetX>`
The first proposal is trivi...Two proposals to improve subnets:
- use for getSubnet the same code as for getBySubnetId (so O(log(N)) vs current O(N))
- selectSubnet should return a ConstSubnetXPtr i.e. `boost::shared_ptr<const SubnetX>`
The first proposal is trivial tp implement so should be done ASAP if there is no good reason to keep the current full scan.
The second proposal is more complex: if a SubnetXPtr can be cast to a ConstSubnetXPtr it is not true for boost::any_cast (so for hook parameters) and of course it requires to not use a not const method (but as there is no reason to modify the subnet returned by selectSubnet one can consider that all not modifying methods should be const methods...).next-stable-2.6https://gitlab.isc.org/isc-projects/bind9/-/issues/4603Comments to CVE-2023-56802024-02-26T16:05:08ZPeter DaviesComments to CVE-2023-5680Comments to CVE-2023-5680:
Description: When reviewing the fix for CVE-2023-5680 due to the crash we
reported separately, we've noticed many other suspicious points in its implemen
-tation. Though these are based on code inspect...Comments to CVE-2023-5680:
Description: When reviewing the fix for CVE-2023-5680 due to the crash we
reported separately, we've noticed many other suspicious points in its implemen
-tation. Though these are based on code inspection and we haven't checked whether
the issue is real or it can cause any practical problem like a crash, we're
deeply concerned about the overall quality of this implementation, and would
like to suggest ISC revisiting it, perhaps fundamentally.
The issues we've noticed are as follows (there may be more):
- it looks like a longer prefix match in ->old_ecs_root will not be found if
a shorter prefix match is found in ->ecs_root. When using two address prefix
trees, we ought to search both and use the longest prefix match, with ->ecs_root
in preference if both have equal prefix lengths.
- On a related note, it seems possible that copying (moving) data in old_ecs_root
to ecs_root can result in separate rdatasetheaders at the top level for the same record type.
- unlikely to be a big deal in practice, but this code in clean_iptree_nodedata()
probably doesn't do what it appears to intend; it results in cleaning up to 12
- as a meta issue, we're afraid the introduction of old_ecs_root and incremental
cleaning needs a lot more tests, especially low level unit tests, given its comp
-lexity. For example, if the last point is indeed an oversight, it could have
been caught by a unit test easily.
See also #4587https://gitlab.isc.org/isc-projects/bind9/-/issues/4601wrong filename looked when reading key files2024-02-23T20:10:41ZMichael Tokarevwrong filename looked when reading key files### Summary
When bind9 tools read a zone file with DNSKEY records, for which no .key file is provided but .private exists, a misleading error message is generated. For example:
```
$ dnssec-signzone 168.192.in-addr.arpa
dnssec-signzone...### Summary
When bind9 tools read a zone file with DNSKEY records, for which no .key file is provided but .private exists, a misleading error message is generated. For example:
```
$ dnssec-signzone 168.192.in-addr.arpa
dnssec-signzone: warning: dns_dnssec_keylistfromrdataset: error reading ./K168.192.in-addr.arpa.+007+13293.private: file not found
$ ls -l ./K168.192.in-addr.arpa.+007+13293.*
-rw------- 1 root root 1707 Oct 28 2011 ./K168.192.in-addr.arpa.+007+13293.private
```
So, it reports an existing file as "not found", while actually (according to strace) it looked for a .key file (which indeed does not exist, since it is inlined in the zone itself).
The end result is that this key is not processed at all, despite the tool has all the information, - the .key file contents is in the zone already (that's where dnssec-signzone found the `+007+13293` part, so it does have the DNSKEY record and don't actually need the .key file), and the .private file which it reported as missing (while not even trying to open it), is actually exists.
### BIND version affected
```
BIND 9.18.24-1-Debian (Extended Support Version) <id:>
running on Linux x86_64 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/reproducible-path/bind9-9.18.24=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 12.2.0
compiled with OpenSSL version: OpenSSL 3.0.11 19 Sep 2023
linked to OpenSSL version: OpenSSL 3.0.11 19 Sep 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.52.0
linked to libnghttp2 version: 1.52.0
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
linked to maxminddb version: 1.7.1
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.1
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4599dns zone failed to reload after upgrade to latest ISC Bind (Ubuntu package)2024-02-26T15:38:01ZDavid Calafrancescodns zone failed to reload after upgrade to latest ISC Bind (Ubuntu package)<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confident...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confidential by clicking the checkbox at the bottom!
-->
### Summary
<!-- Concisely summarize the bug encountered. -->
### BIND version affected
<!--
Make sure you are testing with the **latest** supported version of BIND
for a given branch. Many bugs have been fixed over time!
See https://kb.isc.org/docs/supported-platforms for the current list.
The latest source is available from https://www.isc.org/download/#BIND
Paste the output of `named -V` here.
-->
named -V
```
BIND 9.16.48-Ubuntu (Extended Support Version) <id:0dab57e>
running on Linux x86_64 5.4.0-172-generic #190-Ubuntu SMP Fri Feb 2 23:24:22 UTC 2024
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--disable-isc-spnego' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-jSiMEl/bind9-9.16.48=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.4.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libuv version: 1.34.2
linked to libuv version: 1.34.2
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
**Upgraded yesterday from this version: **
named -V
```
BIND 9.16.1-Ubuntu (Stable Release) <id:d497c32>
running on Linux x86_64 5.4.0-162-generic #179-Ubuntu SMP Mon Aug 14 08:51:31 UTC 2023
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--disable-isc-spnego' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-uTvsKR/bind9-9.16.1=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.4.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
<!--
This is extremely important! Be precise and use itemized lists, please.
Even if a default configuration is affected, please include the full configuration
files _you were testing with_.
Example:
1. Use _attached_ configuration file
2. Start BIND server with command: `named -g -c named.conf ...`
3. Simulate legitimate clients using command `dnsperf -S1 -d legit-queries ...`
4. Simulate attack traffic using command `dnsperf -S1 -d attack-queries ...`
-->
1. Zone file that was loading previous to upgrade now fails when the following lines are present in zone:
```
$ORIGIN _domainkey.gvtc.communication.gvtc.net.
hs1-2082415 CNAME gvtc-communication-gvtc-net.hs17a.dkim.hubspotemail.net.
hs2-2082415 CNAME gvtc-communication-gvtc-net.hs17b.dkim.hubspotemail.net.
$ORIGIN gvtc.communication.gvtc.net.
TXT "v=spf1 include:2082415.spf07.hubspotemail.net -all"
$ORIGIN gvtc.net.
```
The above fails to load zone with these errors:
```
Feb 23 01:15:31 ns0-0 named[1003]: /etc/bind/masters/db.gvtc.net:167: record with inherited owner (hs2-2082415._domainkey.gvtc.communication.gvtc.net) immediately after $ORIGIN (gvtc.communication.gvtc.net)
Feb 23 01:15:31 ns0-0 named[1003]: dns_master_load: /etc/bind/masters/db.gvtc.net:167: hs2-2082415._domainkey.gvtc.communication.gvtc.net: CNAME and other data
Feb 23 01:15:31 ns0-0 named[1003]: zone gvtc.net/IN: loading from master file /etc/bind/masters/db.gvtc.net failed: CNAME and other data
Feb 23 01:15:31 ns0-0 named[1003]: zone gvtc.net/IN: not loaded due to errors.
Feb 23 01:15:54 ns0-0 named[1003]: received control channel command 'reload gvtc.net'
Feb 23 01:15:54 ns0-0 named[1003]: /etc/bind/masters/db.gvtc.net:168: record with inherited owner (hs2-2082415._domainkey.gvtc.communication.gvtc.net) immediately after $ORIGIN (gvtc.communication.gvtc.net)
Feb 23 01:15:54 ns0-0 named[1003]: dns_master_load: /etc/bind/masters/db.gvtc.net:168: hs2-2082415._domainkey.gvtc.communication.gvtc.net: CNAME and other data
Feb 23 01:15:54 ns0-0 named[1003]: zone gvtc.net/IN: loading from master file /etc/bind/masters/db.gvtc.net failed: CNAME and other data
Feb 23 01:15:54 ns0-0 named[1003]: zone gvtc.net/IN: not loaded due to errors.
```
Zone was last edited on Feb 13th, 2024 and loaded without issue on prior version of ISC BIND9
Edited the zone to show this construct:
```
$ORIGIN _domainkey.gvtc.communication.gvtc.net.
hs1-2082415 CNAME gvtc-communication-gvtc-net.hs17a.dkim.hubspotemail.net.
hs2-2082415 CNAME gvtc-communication-gvtc-net.hs17b.dkim.hubspotemail.net.
; $ORIGIN gvtc.communication.gvtc.net.
; TXT "v=spf1 include:2082415.spf07.hubspotemail.net -all"
$ORIGIN gvtc.net.
$ORIGIN communication.gvtc.net.
gvtc TXT "v=spf1 include:2082415.spf07.hubspotemail.net -all"
$ORIGIN gvtc.net.
```
Now zone file loads cleanly again.
If we remove comments on two lines and comment the replacement lines, the zone fails. Flip it back to this formation, zone loads.
Only thing different as far as we can tell was updating Bind9 via Ubuntu.
### What is the current *bug* behavior?
<!-- What actually happens. -->
### What is the expected *correct* behavior?
<!-- What you should see instead. -->
### Relevant configuration files
<!-- Paste any relevant configuration files here - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential issue, it is advisable to
obscure key secrets; this can be done automatically by using
`named-checkconf -px`. -->
### Relevant logs
<!-- Paste any relevant logs here - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise. -->https://gitlab.isc.org/isc-projects/bind9/-/issues/4594Reinstate '-T delay' support2024-02-21T22:55:09ZMark AndrewsReinstate '-T delay' supportThe following discussion from !8751 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8751#note_439018): (+3 comments)
> I wouldn't remove this. It needs to be rei...The following discussion from !8751 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8751#note_439018): (+3 comments)
> I wouldn't remove this. It needs to be reinstated at some point.
>
> bin/tests/system/pipelined/ns3/named.args:-m record,size,mctx -c named.conf -d 99 -D pipelined-ns3 -X named.lock -g -T delay=200https://gitlab.isc.org/isc-projects/kea/-/issues/3259IP allocation fails for reserved client with assingned class2024-03-21T09:54:44ZMichal Ć najdrIP allocation fails for reserved client with assingned classHello,
using KEA 2.4.1 and experiencing issue with assigning addresses to PXE clients with configured class for assigning different boot image depending on option 60.
I have anonymized MAC to aa:bb:cc:dd:ee:ff from real one and also an...Hello,
using KEA 2.4.1 and experiencing issue with assigning addresses to PXE clients with configured class for assigning different boot image depending on option 60.
I have anonymized MAC to aa:bb:cc:dd:ee:ff from real one and also anonymized IPs.
Same behavior for multiple hosts in multiple subnets, following one host for example. No issue on segments using reservations and not using client-class.
3 messages are logged for each DISCOVERY.
```plaintext
Feb 21 15:23:57 dhcp-srv1 kea-dhcp4: WARN [kea-dhcp4.alloc-engine.139809839666944] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1 aa:bb:cc:dd:ee:ff], cid=[no info], tid=0x3969612c: failed to allocate an IPv4 lease in the subnet 10.10.10.0/24, subnet-id 1251066000, shared network (none)
Feb 21 15:23:57 dhcp-srv1 kea-dhcp4: WARN [kea-dhcp4.alloc-engine.139809839666944] ALLOC_ENGINE_V4_ALLOC_FAIL_NO_POOLS [hwtype=1 aa:bb:cc:dd:ee:ff], cid=[no info], tid=0x3969612c: no pools were available for the address allocation
Feb 21 15:23:57 dhcp-srv1 kea-dhcp4: WARN [kea-dhcp4.alloc-engine.139809839666944] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1 aa:bb:cc:dd:ee:ff], cid=[no info], tid=0x3969612c: Failed to allocate an IPv4 address for client with classes: ALL, HA_dhcp-srv1.company.cz, archi00, UNKNOWN
```
As seen from log, subnet is correctly recognized and it doesn't have any pool. Checked that configuration file with segment definition is included.
Subnet definition, only reservations (shortened to one host, all reservations defined in same format, no typo on MAC, checked):
```plaintext
{
"subnet": "10.10.10.0/24",
"id": 1251066000,
"option-data": [
{
"name": "routers",
"data": "10.10.10.1"
},
{
"name": "domain-name",
"data": "company.cz"
}
],
"next-server": "10.30.30.30",
"reservations": [
.......
{
#"hostname": "server.company.cz",
"hw-address": "aa:bb:cc:dd:ee:ff",
"ip-address": "10.10.10.57"
},
.......
]
};
```
Configuration of client-classes:
```plaintext
"client-classes": [
{
"name": "archi07",
"test": "(substring(option[60].hex,0,20) == 'PXEClient:Arch:00007') and (pkt.src == 10.10.30.1 or pkt.src == 10.10.10.1 or pkt.src == 10.10.20.1)",
"option-data": [
{
"name": "boot-file-name",
"data": "/grub/x86_64-efi/core.efi"
}
]
},
{
"name": "archi09",
"test": "(substring(option[60].hex,0,20) == 'PXEClient:Arch:00009') and (pkt.src == 10.10.30.1 or pkt.src == 10.10.10.1 or pkt.src == 10.10.20.1)",
"option-data": [
{
"name": "boot-file-name",
"data": "/grub/x86_64-efi/core.efi"
}
]
},
{
"name": "archi00",
"test": "(pkt.src == 10.10.30.1 or pkt.src == 10.10.10.1 or pkt.src == 10.10.20.1) and (not member ('archi07') or not member ('archi09'))",
"option-data": [
{
"name": "boot-file-name",
"data": "/grub/i386-pc/core.0"
}
]
}
],
```
We had switched back to old isc-dhcp-server for affected segments for now. There clients are assigned with address.
Do we miss something or is this a bug?
Thanks Michalhttps://gitlab.isc.org/isc-projects/kea/-/issues/3258ddns-conflict-resolution-mode appears to not be documented2024-02-21T15:36:15ZThomas Markwalderddns-conflict-resolution-mode appears to not be documented#2276 changed boolean use-ddns-conflict-resolution to an enum ddns-conflict-resolution-mode but the latter was not documented in the ARM?#2276 changed boolean use-ddns-conflict-resolution to an enum ddns-conflict-resolution-mode but the latter was not documented in the ARM?https://gitlab.isc.org/isc-projects/kea/-/issues/3257ddns-update-on-renew and cache-threshold still produce ddns updates2024-03-27T12:52:01ZDarren Ankneyddns-update-on-renew and cache-threshold still produce ddns updatesIf a Kea server (2.4.1) has these settings:
```
...
"cache-threshold": 0.25,
"ddns-update-on-renew": true,
...
```
and a client renews their lease at under 25% of the lease length, ddns updates are still sent.
```
$ sudo tail -f /var/lo...If a Kea server (2.4.1) has these settings:
```
...
"cache-threshold": 0.25,
"ddns-update-on-renew": true,
...
```
and a client renews their lease at under 25% of the lease length, ddns updates are still sent.
```
$ sudo tail -f /var/log/kea/kea-dhcp4.log | egrep 'DHCP4_LEASE_REUSE|DHCPSRV_DHCP_DDNS_NCR_SENT'
2024-02-15 16:46:35.032 INFO [kea-dhcp4.leases/1192.140241126283008] DHCP4_LEASE_REUSE [hwtype=1 c8:7f:54:9e:cf:c8], cid=[01:c8:7f:54:9e:cf:c8], tid=0x17c6ef6f: lease 192.168.20.20 has been reused for 24845 seconds
2024-02-15 16:46:35.033 DEBUG [kea-dhcp4.dhcpsrv/1192.140241211900608] DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: Type: 1 (CHG_REMOVE)
2024-02-15 16:46:35.033 DEBUG [kea-dhcp4.dhcpsrv/1192.140241211900608] DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: Type: 0 (CHG_ADD)
2024-02-15 16:46:40.807 INFO [kea-dhcp4.leases/1192.140241159853824] DHCP4_LEASE_REUSE [hwtype=1 c8:7f:54:9e:cf:c8], cid=[01:c8:7f:54:9e:cf:c8], tid=0xfbfead04: lease 192.168.20.20 has been reused for 24840 seconds
2024-02-15 16:46:40.807 DEBUG [kea-dhcp4.dhcpsrv/1192.140241211900608] DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: Type: 1 (CHG_REMOVE)
2024-02-15 16:46:40.808 DEBUG [kea-dhcp4.dhcpsrv/1192.140241211900608] DHCPSRV_DHCP_DDNS_NCR_SENT NameChangeRequest sent to kea-dhcp-ddns: Type: 0 (CHG_ADD)
```
The customer who brought this to our attention notes:
> While looking at some customer logs I noticed that we were both reusing a lease and doing DDNS update for that reused lease. It seems like if a lease is being reused and therefore it doesn't have any changes to the client DNS name that Kea shouldn't redo the DDNS even if the configuration has update on renew enabled. As soon as the device renews outside of the threshold window I would expect it to do a DDNS update based on the update on renew option.
I've looked at the code and the design. It appears that in dhcp4_srv.cc:assignLease() the call to createNameChangeRequests() is called without checking the threshold and the threshold isn't checked within that function.
The design doesn't explicitly say anything but seems to suggest that the DDNS update shouldn't be done if a lease is reused.
I am unsure if this is a feature request or a bug report as I am not sure of the intended behavior here. It seems like it would be preferable to reduce load by not sending ddns updates on a reused lease.
[SF1707](https://isc.lightning.force.com/lightning/r/Case/500S6000005OUblIAG/view)next-stable-3.0https://gitlab.isc.org/isc-projects/stork/-/issues/1317Refactor creating Kea commands2024-03-05T15:01:41ZSlawek FigielRefactor creating Kea commandsThe Kea commands are created in several places in Stork. We construct them by writing the command name freely and passing the raw dictionary as arguments. It is error-prone and duplicates the code.
We should refactor it. We can define a...The Kea commands are created in several places in Stork. We construct them by writing the command name freely and passing the raw dictionary as arguments. It is error-prone and duplicates the code.
We should refactor it. We can define a dedicated constructor for each command to accept the necessary arguments in a structured form and ensure the command name is correct.
Additionally, the constructor could return the expected response type. Currently, the response definitions are distributed over the application, or we use raw maps to access data.backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4589Adjust SyncPublish Interval for dnssec-policy to minimize delay2024-02-20T05:29:16ZAzizbek KadirovAdjust SyncPublish Interval for dnssec-policy to minimize delayWhen enabling the dnssec-policy for a zone in BIND9, I've noticed that the default SyncPublish interval is set to 1 day + 5 minutes.
Steps to reproduce:
1. Create a zone:
```plaintext
zone "example.com" {
type master;
file "/var/cac...When enabling the dnssec-policy for a zone in BIND9, I've noticed that the default SyncPublish interval is set to 1 day + 5 minutes.
Steps to reproduce:
1. Create a zone:
```plaintext
zone "example.com" {
type master;
file "/var/cache/bind/zones/example.com.zone";
dnssec-policy "default";
inline-signing yes;
key-directory "/var/cache/bind/keys/example.com";
};
```
2. reload bind with `rndc reload`
3. 3 files generated: .key, .private, .state.
4. Inside file, in metadata we can see following:
```plaintext
; This is a key-signing key, keyid 9061, for example.com.
; Created: 20240219101033 (Mon Feb 19 15:10:33 2024)
; Publish: 20240219101033 (Mon Feb 19 15:10:33 2024)
; Activate: 20240219101033 (Mon Feb 19 15:10:33 2024)
; SyncPublish: 20240220111533 (Tue Feb 20 16:15:33 2024)
```
5. It appears more efficient to reduce this interval to just +5 minutes. Currently, the delay incurred by the default interval might lead to potential synchronization issues or delays in propagating changes. By minimizing the interval to +5 minutes, we can ensure timely synchronization of DNSSEC-related updates without unnecessary delay. I couldn't find how to reduce SyncPublish time using custom dnssec-policyhttps://gitlab.isc.org/isc-projects/kea/-/issues/3255CA reconfig doesn't pick up on new certificates2024-02-22T15:00:09ZPeter DaviesCA reconfig doesn't pick up on new certificatesCA reconfig doesn't pick up on new certificates:
After changing the certificates directory in the kea-ctrl-agent configuration
file and sending a SIGHUP signal, kea-ctrl-agent reports
DCTL_CONFIG_COMPLETE server has completed...CA reconfig doesn't pick up on new certificates:
After changing the certificates directory in the kea-ctrl-agent configuration
file and sending a SIGHUP signal, kea-ctrl-agent reports
DCTL_CONFIG_COMPLETE server has completed configuration:
However, the agent still uses the old certificates:
Users that employ the systemd restart command may expect a different behaviour
A workaround would be to kill the process and restart a new one.
[000016830](https://isc.lightning.force.com/lightning/r/Case/500S60000055eAC/view)backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/1316Create a page showing all connectivity errors2024-03-05T14:58:46ZMarcin SiodelskiCreate a page showing all connectivity errorsFollowing the work from #1222, I would like to propose that we add a page where we're going to show the apps with the connectivity issues. We can use the new endpoint from #1222 to get this list.Following the work from #1222, I would like to propose that we add a page where we're going to show the apps with the connectivity issues. We can use the new endpoint from #1222 to get this list.1.17https://gitlab.isc.org/isc-projects/bind9/-/issues/4585Add an option to named-compilezone to retain comments2024-02-18T03:27:07ZMarco DavidsAdd an option to named-compilezone to retain comments### Description
`named-compilezone` strips comments from zone files.
### Request
There might be use cases, where `named-compilezone` is used as a cleanup tool, while any comments that are present need to be retained.
It would be gre...### Description
`named-compilezone` strips comments from zone files.
### Request
There might be use cases, where `named-compilezone` is used as a cleanup tool, while any comments that are present need to be retained.
It would be great if this could be achieved by some command-line option.
Obviously there are some caveats, but it seems that these can be addressed by defining certain conditions that must be met and by properly documenting the right way of working. For example, just as a suggestion: to have any comments on the same line in the zonefile like this:
Undefined (may fail):
```
; comment 1
www AAAA 2001:db8::1
; comment 2
```
Well defined (will work):
`www AAAA 2001:db8::1 ; comment 1`
### Links / references
n/aNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4583BIND Upgrade2024-02-15T12:44:12ZGitLab Support BotBIND UpgradeHello,
Our bind version seems below. How can we upgrade bind version?
And if we upgrade bind version, is there any problem?
[root@ns2 ~]# named -v
BIND 9.11.36-RedHat-9.11.36-11.el8_9 (Extended Support Version) <id:68dbd5b>
Thanks
SemraHello,
Our bind version seems below. How can we upgrade bind version?
And if we upgrade bind version, is there any problem?
[root@ns2 ~]# named -v
BIND 9.11.36-RedHat-9.11.36-11.el8_9 (Extended Support Version) <id:68dbd5b>
Thanks
Semra