Currently our ECS implementation caches all negative responses at the global scope.
A customer has requested that we store them at the learned scope.
RFC 7871 (Informational only) section 7.4, paragraph 4 notes that the original spec was ambiguous and hints that the interpretation of scoping negative answers is more likely to be used in future protocol specifications (if any) than caching them globally.
This issue is expected to be revisited in a future revision of the protocol, possibly blessing the mixing of positive and negative answers. There are implications for cache data structures that developers should consider when writing new ECS code.
As there are no customer waiting on this and is not going to be implemented this issue is now closed
Inconsistent "option_def" usage in client class definitions:
Using Kea 2.5.6 - I have yet to try with 2.4.1.
The following "option-def" statement is accepted in the global scope of a
configuration file:
...
"option-def": [ {
"name": "Option_122", "code": 122, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" }
],
...
However, if this "option-def" is defined within a client class as:
...
"client-classes": [{
"name": "Docsis_Class", "test": "substring(option[60].hex,0,6) == 'docsis'",
"option-def": [ {
"name": "Option_122", "code": 122, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" } ],
"option-data": [ {
"name": "Option_122_1", "data": "10.0.0.68", "code": 1, "space": "Option_122_Space" }, {
"name": "Option_122_2", "data": "10.0.0.69", "code": 2, "space": "Option_122_Space" } ]
}],
...
The following message is generated, and Kea exits:
Error encountered: Not allowed option definition for code '122' in space 'dhcp4'
If the "Option_122" "option-def" is changed to private option "224" as:
...
"client-classes": [{
"name": "Docsis_Class", "test": "substring(option[60].hex,0,6) == 'docsis'",
"option-def": [ {
"name": "Option_122", "code": 224, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" } ],
"option-data": [ {
"name": "Option_122_1", "data": "10.0.0.68", "code": 1, "space": "Option_122_Space" }, {
"name": "Option_122_2", "data": "10.0.0.69", "code": 2, "space": "Option_122_Space" } ]
}],
...
Then the following error is generated, and Kea exits:
Error encountered: Not allowed option definition for code '1' in space 'Option_122_Space'
This commit improves the documentation on the ephemeral TLS configuration and describes in more detail what is happening with TLS configurations on reconfiguration in general.
Closes #4156
duplicate o #4608 (closed)
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.
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
set up servers A and B with the configurations below.
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
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.
I expect to see the NS records from the domain or none at all.
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
...
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
This is thoroughly documented in the Kea Release Process guide.
Some of these checks and updates can be made before the actual freeze. For new stable releases or maintenance releases, please don't use the kea-dev
build farm; use a dedicated build farm for each release cycle.
KEA_HOOKS_VERSION
and notify developers.
a.b.c
is the version to be released and q.w.e
is the version previous to that).dhcpdb_create.*sql
, and nothing more nor less than what was added in this release, is present in a upgrade_*_to_*.sh.in
script that should also have been added in this release.Release-Notes
directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/Release-Notes/release-notes-2.3.4
Build with Parameters
.Packages
field, and the corresponding tarball build in the Tarball
field, leave the rest as they are PrivPubRepos: "private"
, TarballOrPkg: "packages"
, TestProdRepos: "testing"
and click Build
.The following steps may involve changing files in the repository.
GITLAB_TOKEN='...' ./update-code-for-release.py 2.3.4 --repo-dir ~/isc/repos/kea/
. GITLAB_TOKEN='...' ./update-code-for-release.py --help
. --repo-branch v2_4
. --upload-only
flag which:
./configure -h
says.This is the last moment to freeze code!
Build with Parameters
.Tarball
select picked tarball build.Pkg
select the corresponding pkg job.Release_Candidate
pick:
rc1
if this is the first selected build for release, it will push the selected tarballs to repo.isc.org, to a directory suffixed with indicated rc#Now it's time to publish the code.
Kea-2.3.4
).
Keep this build forever
button and edit description:
Build with Parameters
.Tarball
select picked tarball build.Pkg
select the corresponding pkg job.Release_Candidate
pick final
. This job will also:
Kea-a.b.c
in Kea main and premium repositories.Kea-a.b.c
in Kea main and premium repositories.make-available --public --symlink=cur/2.3 /data/shared/sweng/kea/releases/2.3.4
.--private
option.--debug
option.--force
option.Build with Parameters
.Packages
field, the corresponding tarball build in the Tarball
field, PrivPubRepos: "both"
, TarballOrPkg: "both"
, TestProdRepos: "production"
and click Build
.
Packages
.Upload
.TestProdRepos
to testing
.versionTag
ticked.latestTag
if this is a stable or a maintenance release.KeaDockerBranch
to the appropriate branch.Build
.TestProdRepos
to production
.Build version
on readthedocs.org.Versions
tab, scroll down to Activate a version
, search for kea-a.b.c
and click Activate
.Admin -> Advanced Settings -> Default version* -> Kea-a.b.c
.configure.ac
to next development version which could be, based on just released version a.b.c
:
a.b.z-git
where z == c + 1
most of the time, ora.y.0-git
where y == b + 2
if a new development series starts, orx.1.0-git
where x == a + 1
when the released minor version b
is 9 and a.b.c
was the last version in the development series and a new development version is coming up next.major.minor
version, SWENG will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Verify that the KB on installing from Cloudsmith has also been updated, then update the Kea document in the SF portal and notify support customers that this new private repo exists.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 #4587
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.
Also SF00001539