ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-02-05T11:03:53Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/1359Integrate HA hook into base code2023-02-05T11:03:53ZTomek MrugalskiIntegrate HA hook into base codeThere were two original reasons to have HA implemented as a hook: we wanted it to be optional, so people not interested wouldn't run the code and the second was business. Neither of those aged well and it is now more of a burden to maint...There were two original reasons to have HA implemented as a hook: we wanted it to be optional, so people not interested wouldn't run the code and the second was business. Neither of those aged well and it is now more of a burden to maintain and extend HA.
As such, @marcin proposed to integrate the code into core Kea. This is a master-ticket covering this goal. If needed, feel free to create additional ticket(s) for design or split this into smaller tasks.
After looking at the problem in more detail, there's a depressingly long list of problems with this:
1. this would require updating every config. HA is very popular, so this would affect a large number of users
2. for the years to come, we would have to write every HA related doc or blog in if-else notation `if using 1.8.x or older, do ..... If using 1.9.x or newer, do ....`. We could possibly get rid of this after 1.8 is EOLed.
3. the internal packet parking mechanism is currently very tightly coupled with the hook point mechanism
And the potential benefits would be somewhat unimpressive:
1. simpler code
1. one fewer hook (fewer opportunities for people to misconfigure)kea1.9.1https://gitlab.isc.org/isc-projects/kea/-/issues/1358Incorrect catch clauses2020-08-18T08:52:36ZFrancis DupontIncorrect catch clausesReference https://gitlab.isc.org/isc-projects/kea/-/issues/1350#note_150059
Note if compilers do not complain catch clauses without a const reference do not make sense...Reference https://gitlab.isc.org/isc-projects/kea/-/issues/1350#note_150059
Note if compilers do not complain catch clauses without a const reference do not make sense...kea1.8.0Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2060Identify unused source files via gcov CI job2020-11-13T09:53:28ZMichal NowakIdentify unused source files via gcov CI jobOnce `gcov` CI job is present (via https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3606), detailed HTML reports with test code coverage will be generated as artifacts. With their help we should easily identify files, which are...Once `gcov` CI job is present (via https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3606), detailed HTML reports with test code coverage will be generated as artifacts. With their help we should easily identify files, which are compiled-in but their code is likely not being leveraged (such files will have 0% test coverage). Code blocks of dead code might too be identified this way.
Examples include:
* `lib/dns/portlist.c`
* `lib/isc/bufferlist.c`November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/kea/-/issues/1357Make Dhcp[46]SrvD2Test.forceUDPSendFailure to display the reason why startD2 ...2020-09-14T14:59:07ZFrancis DupontMake Dhcp[46]SrvD2Test.forceUDPSendFailure to display the reason why startD2 failedDhcp[46]SrvD2Test.forceUDPSendFailure unit tests fail when another process is using the D2 port. I suggest to put the startD2 call in a try catch block which displays (and fails) the error reason.Dhcp[46]SrvD2Test.forceUDPSendFailure unit tests fail when another process is using the D2 port. I suggest to put the startD2 call in a try catch block which displays (and fails) the error reason.kea1.9.0Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2059Failed assertion during shutdown: REQUIRE(VALID_NMHANDLE(handle));2020-09-30T15:45:09ZMichał KępieńFailed assertion during shutdown: REQUIRE(VALID_NMHANDLE(handle));https://gitlab.isc.org/isc-projects/bind9/-/jobs/1046503
```
D:shutdown:Program terminated with signal SIGABRT, Aborted.
D:shutdown:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:shutdown:[Current thread is ...https://gitlab.isc.org/isc-projects/bind9/-/jobs/1046503
```
D:shutdown:Program terminated with signal SIGABRT, Aborted.
D:shutdown:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:shutdown:[Current thread is 1 (Thread 0x7fd36f2b6700 (LWP 14624))]
D:shutdown:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:shutdown:#1 0x00007fd37dd81535 in __GI_abort () at abort.c:79
D:shutdown:#2 0x0000557fb2e42397 in assertion_failed (file=<optimized out>, line=<optimized out>, type=isc_assertiontype_require, cond=<optimized out>) at main.c:254
D:shutdown:#3 0x00007fd37eb9043c in isc_assertion_failed (file=file@entry=0x7fd37ebc6e9b "netmgr/netmgr.c", line=line@entry=1129, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7fd37ebc3060 "((__builtin_expect(!!((handle) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(handle))->magic == ((('N') << 24 | ('M') << 16 | ('H') << 8 | ('D')))), 1)) && ({ typeof((&(handle)->r"...) at assertions.c:46
D:shutdown:#4 0x00007fd37eb733a8 in isc_nmhandle_ref (handle=<optimized out>) at netmgr/netmgr.c:1131
D:shutdown:#5 0x0000557fb2e3ffb1 in control_command (task=<optimized out>, event=<optimized out>) at controlconf.c:364
D:shutdown:#6 0x00007fd37ebb331f in dispatch (threadid=<optimized out>, manager=0x557fb40743a0) at task.c:1152
D:shutdown:#7 run (queuep=<optimized out>) at task.c:1344
D:shutdown:#8 0x00007fd37e31bfa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
D:shutdown:#9 0x00007fd37de584cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
This is more than likely yet another manifestation of reference counting
issues introduced by !3724. Perhaps a fix for one of the related issues
(#2036, #2047, #2052, #2057) will make this one go away, but I decided
to open a separate issue nevertheless to keep track of all the distinct
crashes just to make sure we get all of them sorted out in due time.October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)https://gitlab.isc.org/isc-projects/kea/-/issues/1356How does Kea recognize the 'same client' when searching for a pre-existing le...2023-08-01T09:52:13ZVicky Riskvicky@isc.orgHow does Kea recognize the 'same client' when searching for a pre-existing lease?Request from support for more detail on how Kea recognizes the 'same client' when searching for a pre-existing lease?
This could be a kb or in the ARM.Request from support for more detail on how Kea recognizes the 'same client' when searching for a pre-existing lease?
This could be a kb or in the ARM.kea2.5.1Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1355More detail about Host Reservations vs ISC DHCP HRs2020-10-30T14:38:10ZVicky Riskvicky@isc.orgMore detail about Host Reservations vs ISC DHCP HRsUsers seem to be confused about host reservations in Kea.
I think we need a brief kb explaining how/when global and per subnet reservations in kea are evaluated, and how they compare to host reservations in ISC DHCP. We should provide ...Users seem to be confused about host reservations in Kea.
I think we need a brief kb explaining how/when global and per subnet reservations in kea are evaluated, and how they compare to host reservations in ISC DHCP. We should provide some advice about how to adapt an ISC DHCP configuration with HRs to a Kea configuration. It would be helpful to include a sample configuration of each illustrating the differences.
This could also be incorporated into the ARM, although it would be a little odd to include the comparison with ISC DHCP there.kea1.9.2Vicky Riskvicky@isc.orgVicky Riskvicky@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1354bump up libs versions for 1.6.32020-07-30T11:26:43ZMichal Nowikowskibump up libs versions for 1.6.3kea1.6.3Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1353Guarded subnets must stay allowed2022-02-03T13:31:01ZFrancis DupontGuarded subnets must stay allowedJust after the host reservation lookup the query classes can be cleared and evaluated again with the host reservation classes. During this it is possible to have a selected subnet with a guard (client-class) which finished to not be allo...Just after the host reservation lookup the query classes can be cleared and evaluated again with the host reservation classes. During this it is possible to have a selected subnet with a guard (client-class) which finished to not be allowed (i.e. the guard client class is no longer in the query classes). The whole code assumes the selected subnet is allowed so it can lead to very incorrect behavior.
The fix is easy: just unconditionally add again the guard class (the class add method puts its argument once in the classes: if it is already in them the method does nothing).
Or alternatively make all possible branches to handle this case: the selected subnet is no longer allowed so can be used only in a shared network and a new "start" subnet must be found.kea2.1.3Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2058`dnssec-signzone -N unixtime` behaves like `increment`2021-10-08T14:27:52ZSven Strickroth`dnssec-signzone -N unixtime` behaves like `increment`### Summary
I recently upgraded from Debian 9.13 to 10.4. Starting from this date "dnssec-signzone -N unixtime" does not work any more causing my DNS slaves to fail receiving changes.
With Debian 9 `dnssec-signzone -N unixtime` (9.10.3...### Summary
I recently upgraded from Debian 9.13 to 10.4. Starting from this date "dnssec-signzone -N unixtime" does not work any more causing my DNS slaves to fail receiving changes.
With Debian 9 `dnssec-signzone -N unixtime` (9.10.3.dfsg.P4-12.3+deb9u6) uses the current unix timestamp as the serial numer for the generated signed zone, however, with the version shipped with Debian 10 the serial number is just incremented from the to be signed zone file. As I use a common zone-template for a huge nubmer of zones, every further signing of the template will use the very same serial numer (template serial number + 1).
I use the following command to sign my zones (using a script):
/usr/sbin/dnssec-signzone -o ZONE.TLD. -e +1209600 -N unixtime zone.db K*.private
I don't get any warning or error. I checked that "-N date" uses the current date, however, "date" does not fit the needs of my scenario (see above).
Further investigation of Bernhard Schmidt (cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966422#10) revealed that this seems to be caused by a new check: If the "new" serial number is lower than the old one, increment is used instead of the requested unixtime.
cross-ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966422
### BIND version used
9.11.5-P4-5.1+deb10u1-Debian
### Steps to reproduce
1) Have a zonefile with a SOA serial number such as `2020072900`
2) Execute `/usr/sbin/dnssec-signzone -o ZONE.TLD. -e +1209600 -N unixtime zone.db K*.private`
### What is the current *bug* behavior?
The signed zone file has the serial number `2020072901`
### What is the expected *correct* behavior?
The signed zone file should have the current unix timestamp as serial number.
### Possible fixes
I understand that the new behavior might be a feature, so that the signed zone file never has a serial number less than the unsigned zone file. However, this behavior change caused lots of trouble for me. I would at least expect a warning of `dnssec-signzone` that the unix time was not used ...January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/2057Hangs on shutdown with netmgr-based rndc (reference counting glitch?)2021-04-28T09:31:28ZMichal NowakHangs on shutdown with netmgr-based rndc (reference counting glitch?)The `dnstap` test [fails](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1044433#L7898) 50 % of time on FreeBSD 12.1:
```
S:dnstap:2020-07-29T15:32:53+0200
T:dnstap:1:A
A:dnstap:System test dnstap
I:dnstap:PORTS:5421,5422,5423,5424,542...The `dnstap` test [fails](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1044433#L7898) 50 % of time on FreeBSD 12.1:
```
S:dnstap:2020-07-29T15:32:53+0200
T:dnstap:1:A
A:dnstap:System test dnstap
I:dnstap:PORTS:5421,5422,5423,5424,5425,5426,5427,5428,5429,5430
I:dnstap:starting servers
I:dnstap:checking that named-checkconf detects error in bad-fstrm-reopen-interval.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-buffer-hint-max.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-buffer-hint-min.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-flush-timeout-max.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-flush-timeout-min.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-input-queue-size-max.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-input-queue-size-min.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-input-queue-size-po2.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-output-notify-threshold.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-output-queue-size-max.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-output-queue-size-min.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-reopen-interval-max.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-reopen-interval-min.conf
I:dnstap:checking that named-checkconf detects error in bad-missing-dnstap-output-view.conf
I:dnstap:checking that named-checkconf detects error in bad-missing-dnstap-output.conf
I:dnstap:checking that named-checkconf detects error in bad-size-version.conf
I:dnstap:checking that named-checkconf detects no error in good-dnstap-in-options.conf
I:dnstap:checking that named-checkconf detects no error in good-dnstap-in-view.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-reopen-interval.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-buffer-hint.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-flush-timeout.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-input-queue-size.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-output-notify-threshold.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-output-queue-model-mpsc.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-output-queue-model-spsc.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-output-queue-size.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-reopen-interval.conf
I:dnstap:checking that named-checkconf detects no error in good-size-unlimited.conf
I:dnstap:checking that named-checkconf detects no error in good-size-version.conf
I:dnstap:wait for servers to finish loading
I:dnstap:checking initial message counts
I:dnstap:checking UDP message counts
I:dnstap:checking TCP message counts
I:dnstap:checking AUTH_QUERY message counts
I:dnstap:checking AUTH_RESPONSE message counts
I:dnstap:checking CLIENT_QUERY message counts
I:dnstap:checking CLIENT_RESPONSE message counts
I:dnstap:checking RESOLVER_QUERY message counts
I:dnstap:checking RESOLVER_RESPONSE message counts
I:dnstap:checking UPDATE_QUERY message counts
I:dnstap:checking UPDATE_RESPONSE message counts
I:dnstap:checking reopened message counts
dnstap-read: dns_dt_openfile: failure
dnstap-read: dns_dt_openfile: failure
dnstap-read: dns_dt_openfile: failure
dnstap-read: dns_dt_openfile: failure
dnstap-read: dns_dt_openfile: failure
dnstap-read: dns_dt_openfile: failure
dnstap-read: dns_dt_openfile: failure
dnstap-read: dns_dt_openfile: failure
dnstap-read: dns_dt_openfile: failure
dnstap-read: dns_dt_openfile: failure
I:dnstap:checking UDP message counts
I:dnstap:ns3 0 expected 2
I:dnstap:failed
I:dnstap:checking TCP message counts
I:dnstap:checking AUTH_QUERY message counts
I:dnstap:checking AUTH_RESPONSE message counts
I:dnstap:checking CLIENT_QUERY message counts
I:dnstap:ns3 0 expected 1
I:dnstap:failed
I:dnstap:checking CLIENT_RESPONSE message counts
I:dnstap:ns3 0 expected 1
I:dnstap:failed
I:dnstap:checking RESOLVER_QUERY message counts
I:dnstap:checking RESOLVER_RESPONSE message counts
I:dnstap:checking UPDATE_QUERY message counts
I:dnstap:checking UPDATE_RESPONSE message counts
I:dnstap:checking dnstap-read hex output
dnstap-read: dns_dt_openfile: failure
I:dnstap:failed
I:dnstap:checking unix socket message counts
I:dnstap:checking UDP message counts
I:dnstap:checking TCP message counts
I:dnstap:checking AUTH_QUERY message counts
I:dnstap:checking AUTH_RESPONSE message counts
I:dnstap:checking CLIENT_QUERY message counts
I:dnstap:checking CLIENT_RESPONSE message counts
I:dnstap:checking RESOLVER_QUERY message counts
I:dnstap:checking RESOLVER_RESPONSE message counts
I:dnstap:checking UPDATE_QUERY message counts
I:dnstap:checking UPDATE_RESPONSE message counts
I:dnstap:checking reopened unix socket message counts
I:dnstap:checking UDP message counts
I:dnstap:checking TCP message counts
I:dnstap:checking AUTH_QUERY message counts
I:dnstap:checking AUTH_RESPONSE message counts
I:dnstap:checking CLIENT_QUERY message counts
I:dnstap:checking CLIENT_RESPONSE message counts
I:dnstap:checking RESOLVER_QUERY message counts
I:dnstap:checking RESOLVER_RESPONSE message counts
I:dnstap:checking UPDATE_QUERY message counts
I:dnstap:checking UPDATE_RESPONSE message counts
I:dnstap:checking large packet printing
I:dnstap:checking 'rndc -roll <value>' (no versions)
I:dnstap:no response from ns3
I:dnstap:failed
I:dnstap:ns3 didn't die when sent a SIGTERM
rndc: connect failed: 10.53.0.3#5430: connection refused
I:dnstap:failed
I:dnstap:checking 'rndc -roll <value>' (versions)
I:dnstap:exit status: 5
I:dnstap:stopping servers
I:dnstap:ns3 died before a SIGTERM was sent
I:dnstap:stopping servers failed
I:dnstap:Core dump(s) found: dnstap/ns3/named.core
D:dnstap:backtrace from dnstap/ns3/named.core:
D:dnstap:--------------------------------------------------------------------------------
D:dnstap:Core was generated by `/usr/home/newman/bind9/bin/named/.libs/named -D dnstap-ns3 -X named.lock -m reco'.
D:dnstap:Program terminated with signal SIGABRT, Aborted.
D:dnstap:#0 0x0000000800e7793a in _nanosleep () from /lib/libc.so.7
D:dnstap:[Current thread is 1 (LWP 100491)]
D:dnstap:#0 0x0000000800e7793a in _nanosleep () from /lib/libc.so.7
D:dnstap:#1 0x0000000800d0f11c in ?? () from /lib/libthr.so.3
D:dnstap:#2 0x0000000800ecd356 in usleep () from /lib/libc.so.7
D:dnstap:#3 0x00000008002e65fa in isc_nm_destroy (mgr0=0x2740b0 <named_g_nm>) at netmgr/netmgr.c:422
D:dnstap:#4 0x000000000023884e in destroy_managers () at main.c:970
D:dnstap:#5 cleanup () at main.c:1304
D:dnstap:#6 main (argc=<optimized out>, argv=0x7fffffffda50) at main.c:1561
D:dnstap:--------------------------------------------------------------------------------
D:dnstap:full backtrace from dnstap/ns3/named.core saved in named.core-backtrace.txt
D:dnstap:core dump dnstap/ns3/named.core archived as dnstap/ns3/named.core.gz
R:dnstap:FAIL
E:dnstap:2020-07-29T15:35:09+0200
FAIL dnstap (exit status: 1)
```
(If the framework can't stop the server `ABRT` is sent, hence the backtrace.)
NS3 `named.run` file: [named.run](/uploads/a447239a4552585a689ddbe22a003ee8/named.run)
Git bisect says that 3551d3ffd2afe6542e79a5571b326bd77fdd265e is the culprit:
```
3551d3ffd2afe6542e79a5571b326bd77fdd265e is the first bad commit
commit 3551d3ffd2afe6542e79a5571b326bd77fdd265e
Author: Evan Hunt <each@isc.org>
Date: Thu Apr 16 13:06:42 2020 -0700
convert rndc and control channel to use netmgr
```October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/kea/-/issues/1352kea-dhcp4 is dynamically changing assigned subnet and overwrite correct selec...2020-07-29T14:03:47ZWlodzimierz Wencelkea-dhcp4 is dynamically changing assigned subnet and overwrite correct selectionSo my config is this:
```
{
"Dhcp4": {
"control-socket": {
"socket-name": "/tmp/control_socket",
"socket-type": "unix"
},
"interfaces-config": {
"dhcp-socket-type": "udp",
...So my config is this:
```
{
"Dhcp4": {
"control-socket": {
"socket-name": "/tmp/control_socket",
"socket-type": "unix"
},
"interfaces-config": {
"dhcp-socket-type": "udp",
"interfaces": [
"enp1s0f3"
]
},
"lease-database": {
"type": "memfile"
},
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "stdout"
}
],"debuglevel": 99,
"severity": "DEBUG"
}
],
"rebind-timer": 350000,
"renew-timer": 340000,
"shared-networks": [
{
"interface": "enp1s0f3",
"name": "one-network",
"subnet4": [
{
"id": 1,
"interface": "enp1s0f3",
"pools": [
{
"pool": "1.0.0.4-1.255.255.254"
}
],
"subnet": "1.0.0.0/8"
},
{
"id": 2,
"interface": "enp1s0f3",
"pools": [
{
"pool": "2.0.0.4-2.255.255.254"
}
],
"subnet": "2.0.0.0/8"
},
{
"id": 3,
"interface": "enp1s0f3",
"pools": [
{
"pool": "3.0.0.4-3.255.255.254"
}
],
"subnet": "3.0.0.0/8"
},
{
"id": 4,
"interface": "enp1s0f3",
"pools": [
{
"pool": "4.0.0.4-4.255.255.254"
}
],
"subnet": "4.0.0.0/8"
},
{
"id": 5,
"interface": "enp1s0f3",
"pools": [
{
"pool": "5.0.0.4-5.255.255.254"
}
],
"subnet": "5.0.0.0/8"
},
{
"id": 6,
"interface": "enp1s0f3",
"pools": [
{
"pool": "6.0.0.4-6.255.255.254"
}
],
"subnet": "6.0.0.0/8"
},
{
"id": 7,
"interface": "enp1s0f3",
"pools": [
{
"pool": "7.0.0.4-7.255.255.254"
}
],
"subnet": "7.0.0.0/8"
},
{
"id": 8,
"interface": "enp1s0f3",
"pools": [
{
"pool": "8.0.0.4-8.255.255.254"
}
],
"subnet": "8.0.0.0/8"
},
{
"id": 9,
"interface": "enp1s0f3",
"pools": [
{
"pool": "9.0.0.4-9.255.255.254"
}
],
"subnet": "9.0.0.0/8"
},
{
"id": 10,
"interface": "enp1s0f3",
"pools": [
{
"pool": "10.0.0.4-10.255.255.254"
}
],
"subnet": "10.0.0.0/8"
}
]
}
],
"valid-lifetime": 360000
}
}
```
perfdhcp mimic traffic from different relays (in this case there are 10 of them 1.0.0.1 - 10.0.0.1)
And first client get his address correct:
```
2020-07-29 12:38:37.191 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_BUFFER_RECEIVED received buffer from 11.0.0.3:67 to 11.0.0.1:67 over interface enp1s0f3
2020-07-29 12:38:37.191 DEBUG [kea-dhcp4.options/2697.140305702419520] DHCP4_BUFFER_UNPACK parsing buffer received from 11.0.0.3 to 11.0.0.1 over interface enp1s0f3
2020-07-29 12:38:37.191 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_PACKET_RECEIVED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: DHCPDISCOVER (type 1) received from 11.0.0.3 to 11.0.0.1 on interface enp1s0f3
2020-07-29 12:38:37.191 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_QUERY_DATA [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0, packet details: local_address=11.0.0.1:67, remote_address=11.0.0.3:67, msg_type=DHCPDISCOVER (1), transid=0x0,
options:
type=053, len=001: 1 (uint8)
type=055, len=007: 1(uint8) 28(uint8) 2(uint8) 3(uint8) 15(uint8) 6(uint8) 12(uint8)
type=061, len=007: 01:00:0c:01:02:03:04
2020-07-29 12:38:37.191 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.0.0.0/8 for packet received by matching address 10.0.0.1
2020-07-29 12:38:37.191 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_SUBNET_SELECTED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: the subnet with ID 10 was selected for client assignments
2020-07-29 12:38:37.191 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_SUBNET_DATA [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: the selected subnet details: 10.0.0.0/8
2020-07-29 12:38:37.191 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=000C01020304
2020-07-29 12:38:37.191 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=000C01020304, found 0 host(s)
2020-07-29 12:38:37.191 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: client-id=01000C01020304
2020-07-29 12:38:37.191 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier client-id=01000C01020304, found 0 host(s)
2020-07-29 12:38:37.191 DEBUG [kea-dhcp4.dhcp4/2697.140305702419520] DHCP4_CLASS_ASSIGNED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: client packet has been assigned to the following class(es): UNKNOWN
2020-07-29 12:38:37.192 DEBUG [kea-dhcp4.dhcp4/2697.140305702419520] DHCP4_CLASS_ASSIGNED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: client packet has been assigned to the following class(es): ALL, UNKNOWN
2020-07-29 12:38:37.192 DEBUG [kea-dhcp4.ddns/2697.140305702419520] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: processing client's Hostname option
2020-07-29 12:38:37.192 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_CLIENTID obtaining IPv4 leases for client ID 01:00:0c:01:02:03:04
2020-07-29 12:38:37.192 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_HWADDR obtaining IPv4 leases for hardware address hwtype=1 00:0c:01:02:03:04
2020-07-29 12:38:37.192 DEBUG [kea-dhcp4.alloc-engine/2697.140305702419520] ALLOC_ENGINE_V4_OFFER_NEW_LEASE allocation engine will try to offer new lease to the client [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0
2020-07-29 12:38:37.192 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.0.0.4
2020-07-29 12:38:37.192 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 10 and IPv4 address 10.0.0.4
2020-07-29 12:38:37.192 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 10.0.0.4
2020-07-29 12:38:37.192 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 10.0.0.4, found 0 host(s)
2020-07-29 12:38:37.192 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 10 and address 10.0.0.4
2020-07-29 12:38:37.192 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.0.0.4
2020-07-29 12:38:37.192 INFO [kea-dhcp4.leases/2697.140305702419520] DHCP4_LEASE_ADVERT [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: lease 10.0.0.4 will be advertised
2020-07-29 12:38:37.192 DEBUG [kea-dhcp4.options/2697.140305702419520] DHCP4_PACKET_PACK [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: preparing on-wire format of the packet to be sent
2020-07-29 12:38:37.192 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_PACKET_SEND [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: trying to send packet DHCPOFFER (type 2) from 11.0.0.1:67 to 11.0.0.3:67 on interface enp1s0f3
2020-07-29 12:38:37.193 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_RESPONSE_DATA [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: responding with packet DHCPOFFER (type 2), packet details: local_address=11.0.0.1:67, remote_address=11.0.0.3:67, msg_type=DHCPOFFER (2), transid=0x0,
options:
type=001, len=004: 4278190080 (uint32)
type=051, len=004: 360000 (uint32)
type=053, len=001: 2 (uint8)
type=054, len=004: 11.0.0.1
type=058, len=004: 340000 (uint32)
type=059, len=004: 350000 (uint32)
type=061, len=007: 01:00:0c:01:02:03:04
2020-07-29 12:38:37.193 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_BUFFER_RECEIVED received buffer from 11.0.0.3:67 to 11.0.0.1:67 over interface enp1s0f3
2020-07-29 12:38:37.193 DEBUG [kea-dhcp4.options/2697.140305702419520] DHCP4_BUFFER_UNPACK parsing buffer received from 11.0.0.3 to 11.0.0.1 over interface enp1s0f3
2020-07-29 12:38:37.193 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_PACKET_RECEIVED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: DHCPREQUEST (type 3) received from 11.0.0.3 to 11.0.0.1 on interface enp1s0f3
2020-07-29 12:38:37.193 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_QUERY_DATA [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0, packet details: local_address=11.0.0.1:67, remote_address=11.0.0.3:67, msg_type=DHCPREQUEST (3), transid=0x0,
options:
type=050, len=004: 10.0.0.4 (ipv4-address)
type=053, len=001: 3 (uint8)
type=054, len=004: 11.0.0.1 (ipv4-address)
type=055, len=007: 1(uint8) 28(uint8) 2(uint8) 3(uint8) 15(uint8) 6(uint8) 12(uint8)
type=061, len=007: 01:00:0c:01:02:03:04
2020-07-29 12:38:37.193 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.0.0.0/8 for packet received by matching address 10.0.0.1
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_SUBNET_SELECTED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: the subnet with ID 10 was selected for client assignments
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_SUBNET_DATA [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: the selected subnet details: 10.0.0.0/8
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=000C01020304
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=000C01020304, found 0 host(s)
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: client-id=01000C01020304
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier client-id=01000C01020304, found 0 host(s)
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.dhcp4/2697.140305702419520] DHCP4_CLASS_ASSIGNED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: client packet has been assigned to the following class(es): UNKNOWN
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.dhcp4/2697.140305702419520] DHCP4_CLASS_ASSIGNED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: client packet has been assigned to the following class(es): ALL, UNKNOWN
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.ddns/2697.140305702419520] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: processing client's Hostname option
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_CLIENTID obtaining IPv4 leases for client ID 01:00:0c:01:02:03:04
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_HWADDR obtaining IPv4 leases for hardware address hwtype=1 00:0c:01:02:03:04
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 10 and IPv4 address 10.0.0.4
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 10.0.0.4
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 10.0.0.4, found 0 host(s)
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 10 and address 10.0.0.4
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.0.0.4
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.alloc-engine/2697.140305702419520] ALLOC_ENGINE_V4_REQUEST_ALLOC_REQUESTED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: trying to allocate requested address 10.0.0.4
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.0.0.4
2020-07-29 12:38:37.194 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_ADD_ADDR4 adding IPv4 lease with address 10.0.0.4
2020-07-29 12:38:37.194 INFO [kea-dhcp4.leases/2697.140305702419520] DHCP4_LEASE_ALLOC [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: lease 10.0.0.4 has been allocated for 360000 seconds
2020-07-29 12:38:37.195 DEBUG [kea-dhcp4.options/2697.140305702419520] DHCP4_PACKET_PACK [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: preparing on-wire format of the packet to be sent
2020-07-29 12:38:37.195 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_PACKET_SEND [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: trying to send packet DHCPACK (type 5) from 11.0.0.1:67 to 11.0.0.3:67 on interface enp1s0f3
2020-07-29 12:38:37.195 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_RESPONSE_DATA [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: responding with packet DHCPACK (type 5), packet details: local_address=11.0.0.1:67, remote_address=11.0.0.3:67, msg_type=DHCPACK (5), transid=0x0,
options:
type=001, len=004: 4278190080 (uint32)
type=051, len=004: 360000 (uint32)
type=053, len=001: 5 (uint8)
type=054, len=004: 11.0.0.1
type=058, len=004: 340000 (uint32)
type=059, len=004: 350000 (uint32)
type=061, len=007: 01:00:0c:01:02:03:04
```
problem is with all next packets, despite selecting correct subnet first it was changed later in the process:
```
020-07-29 12:38:38.190 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_BUFFER_RECEIVED received buffer from 11.0.0.3:67 to 11.0.0.1:67 over interface enp1s0f3
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.options/2697.140305702419520] DHCP4_BUFFER_UNPACK parsing buffer received from 11.0.0.3 to 11.0.0.1 over interface enp1s0f3
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_PACKET_RECEIVED [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: DHCPDISCOVER (type 1) received from 11.0.0.3 to 11.0.0.1 on interface enp1s0f3
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_QUERY_DATA [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1, packet details: local_address=11.0.0.1:67, remote_address=11.0.0.3:67, msg_type=DHCPDISCOVER (1), transid=0x1,
options:
type=053, len=001: 1 (uint8)
type=055, len=007: 1(uint8) 28(uint8) 2(uint8) 3(uint8) 15(uint8) 6(uint8) 12(uint8)
type=061, len=007: 01:00:0c:01:02:03:05
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 8.0.0.0/8 for packet received by matching address 8.0.0.1
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_SUBNET_SELECTED [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: the subnet with ID 8 was selected for client assignments
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_SUBNET_DATA [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: the selected subnet details: 8.0.0.0/8
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=000C01020305
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=000C01020305, found 0 host(s)
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: client-id=01000C01020305
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier client-id=01000C01020305, found 0 host(s)
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.dhcp4/2697.140305702419520] DHCP4_CLASS_ASSIGNED [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: client packet has been assigned to the following class(es): UNKNOWN
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.dhcp4/2697.140305702419520] DHCP4_CLASS_ASSIGNED [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: client packet has been assigned to the following class(es): ALL, UNKNOWN
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.ddns/2697.140305702419520] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: processing client's Hostname option
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_CLIENTID obtaining IPv4 leases for client ID 01:00:0c:01:02:03:05
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_HWADDR obtaining IPv4 leases for hardware address hwtype=1 00:0c:01:02:03:05
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.alloc-engine/2697.140305702419520] ALLOC_ENGINE_V4_OFFER_NEW_LEASE allocation engine will try to offer new lease to the client [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.0.0.5
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 10 and IPv4 address 10.0.0.5
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 10.0.0.5
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 10.0.0.5, found 0 host(s)
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 10 and address 10.0.0.5
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.0.0.5
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_SUBNET_DYNAMICALLY_CHANGED [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: changed selected subnet 8.0.0.0/8 to subnet 10.0.0.0/8 from shared network one-network for client assignments
2020-07-29 12:38:38.192 INFO [kea-dhcp4.leases/2697.140305702419520] DHCP4_LEASE_ADVERT [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: lease 10.0.0.5 will be advertised
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.options/2697.140305702419520] DHCP4_PACKET_PACK [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: preparing on-wire format of the packet to be sent
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_PACKET_SEND [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: trying to send packet DHCPOFFER (type 2) from 11.0.0.1:67 to 11.0.0.3:67 on interface enp1s0f3
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_RESPONSE_DATA [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: responding with packet DHCPOFFER (type 2), packet details: local_address=11.0.0.1:67, remote_address=11.0.0.3:67, msg_type=DHCPOFFER (2), transid=0x1,
options:
type=001, len=004: 4278190080 (uint32)
type=051, len=004: 360000 (uint32)
type=053, len=001: 2 (uint8)
type=054, len=004: 11.0.0.1
type=058, len=004: 340000 (uint32)
type=059, len=004: 350000 (uint32)
type=061, len=007: 01:00:0c:01:02:03:05
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.alloc-engine/2697.140305702419520] ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.alloc-engine/2697.140305702419520] ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.054 ms
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.alloc-engine/2697.140305702419520] ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_BUFFER_RECEIVED received buffer from 11.0.0.3:67 to 11.0.0.1:67 over interface enp1s0f3
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.options/2697.140305702419520] DHCP4_BUFFER_UNPACK parsing buffer received from 11.0.0.3 to 11.0.0.1 over interface enp1s0f3
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_PACKET_RECEIVED [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: DHCPREQUEST (type 3) received from 11.0.0.3 to 11.0.0.1 on interface enp1s0f3
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_QUERY_DATA [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1, packet details: local_address=11.0.0.1:67, remote_address=11.0.0.3:67, msg_type=DHCPREQUEST (3), transid=0x1,
options:
type=050, len=004: 10.0.0.5 (ipv4-address)
type=053, len=001: 3 (uint8)
type=054, len=004: 11.0.0.1 (ipv4-address)
type=055, len=007: 1(uint8) 28(uint8) 2(uint8) 3(uint8) 15(uint8) 6(uint8) 12(uint8)
type=061, len=007: 01:00:0c:01:02:03:05
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 8.0.0.0/8 for packet received by matching address 8.0.0.1
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_SUBNET_SELECTED [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: the subnet with ID 8 was selected for client assignments
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_SUBNET_DATA [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: the selected subnet details: 8.0.0.0/8
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=000C01020305
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=000C01020305, found 0 host(s)
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: client-id=01000C01020305
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier client-id=01000C01020305, found 0 host(s)
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.dhcp4/2697.140305702419520] DHCP4_CLASS_ASSIGNED [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: client packet has been assigned to the following class(es): UNKNOWN
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.dhcp4/2697.140305702419520] DHCP4_CLASS_ASSIGNED [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: client packet has been assigned to the following class(es): ALL, UNKNOWN
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.ddns/2697.140305702419520] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: processing client's Hostname option
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_CLIENTID obtaining IPv4 leases for client ID 01:00:0c:01:02:03:05
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_HWADDR obtaining IPv4 leases for hardware address hwtype=1 00:0c:01:02:03:05
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 8 and IPv4 address 10.0.0.5
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 10.0.0.5
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 10.0.0.5, found 0 host(s)
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 8 and address 10.0.0.5
2020-07-29 12:38:38.193 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.0.0.5
2020-07-29 12:38:38.194 DEBUG [kea-dhcp4.alloc-engine/2697.140305702419520] ALLOC_ENGINE_V4_REQUEST_ALLOC_REQUESTED [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: trying to allocate requested address 10.0.0.5
2020-07-29 12:38:38.194 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.0.0.5
2020-07-29 12:38:38.194 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_ADD_ADDR4 adding IPv4 lease with address 10.0.0.5
2020-07-29 12:38:38.194 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_SUBNET_DYNAMICALLY_CHANGED [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: changed selected subnet 8.0.0.0/8 to subnet 10.0.0.0/8 from shared network one-network for client assignments
2020-07-29 12:38:38.194 INFO [kea-dhcp4.leases/2697.140305702419520] DHCP4_LEASE_ALLOC [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: lease 10.0.0.5 has been allocated for 360000 seconds
2020-07-29 12:38:38.194 DEBUG [kea-dhcp4.options/2697.140305702419520] DHCP4_PACKET_PACK [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: preparing on-wire format of the packet to be sent
2020-07-29 12:38:38.194 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_PACKET_SEND [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: trying to send packet DHCPACK (type 5) from 11.0.0.1:67 to 11.0.0.3:67 on interface enp1s0f3
2020-07-29 12:38:38.194 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_RESPONSE_DATA [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: responding with packet DHCPACK (type 5), packet details: local_address=11.0.0.1:67, remote_address=11.0.0.3:67, msg_type=DHCPACK (5), transid=0x1,
options:
type=001, len=004: 4278190080 (uint32)
type=051, len=004: 360000 (uint32)
type=053, len=001: 5 (uint8)
type=054, len=004: 11.0.0.1
type=058, len=004: 340000 (uint32)
type=059, len=004: 350000 (uint32)
type=061, len=007: 01:00:0c:01:02:03:05
```
correct subnet selection:
```
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 8.0.0.0/8 for packet received by matching address 8.0.0.1
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_SUBNET_SELECTED [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: the subnet with ID 8 was selected for client assignments
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_SUBNET_DATA [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: the selected subnet details: 8.0.0.0/8
```
address assigned from different subnet:
```
UG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.0.0.5
2020-07-29 12:38:38.191 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 10 and IPv4 address 10.0.0.5
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 10.0.0.5
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 10.0.0.5, found 0 host(s)
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.hosts/2697.140305702419520] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 10 and address 10.0.0.5
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.dhcpsrv/2697.140305702419520] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.0.0.5
2020-07-29 12:38:38.192 DEBUG [kea-dhcp4.packets/2697.140305702419520] DHCP4_SUBNET_DYNAMICALLY_CHANGED [hwtype=1 00:0c:01:02:03:05], cid=[01:00:0c:01:02:03:05], tid=0x1: changed selected subnet 8.0.0.0/8 to subnet 10.0.0.0/8 from shared network one-network for client assignments
```
and it all depends on first received packet. In multiple iteration of this tests I am observing this results, all depends on first packet.https://gitlab.isc.org/isc-projects/bind9/-/issues/2056Make dig print all query parameters2020-12-11T09:01:35ZAnand BuddhdevMake dig print all query parameters### Description
In recent weeks, I have gotten confused twice by dig's behaviour. Please see issues #1816 and #2054. In both of these case, dig was doing something I hadn't expected. One was a bug, and the other a change in default beha...### Description
In recent weeks, I have gotten confused twice by dig's behaviour. Please see issues #1816 and #2054. In both of these case, dig was doing something I hadn't expected. One was a bug, and the other a change in default behaviour that I wasn't aware of. The problem is that dig doesn't show the user all the query parameters. It shows flags explicitly set by the user with the +cmd flag, but not the defaults. Additionally, a .digrc file can change dig's behaviour without it being obvious.
### Request
It would be really cool if dig would display *all* the query parameters, such as transport (UDP/TCP), EDNS in use or not, and which extended options have been set, and to what values. When a user sees this, they can better understand why a server responded in a certain way. It's also clear to them what defaults dig is using for some EDNS options. With more and more EDNS options appearing, and dig setting some to OFF and some to ON by default, and sometimes changing these defaults between releases, it's becoming very confusing for a user. I have to constantly keep going back to the man page to see what the default is, and whether it has changed. But by printing all the attributes clearly, it would make a user's life much easier.
### Links / referencesJanuary 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/2055[CVE-2020-8624] "update-policy" rules of type "subdomain" are enforced incorr...2020-08-25T06:59:03ZJoop Boonen[CVE-2020-8624] "update-policy" rules of type "subdomain" are enforced incorrectly<!--
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 do *NOT* report it here, but send an
email to [...<!--
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 do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
update-policy { grant dev.DOMAIN.TLD subdomain dev.DOMAIN.TLD a aaaa txt; } is not handled correctly
It is also possible to change entries in DOMAIN.TLD
### BIND version used
9.16.5 opensuse
9.11.5 debian buster
Both exactly the same Problem
### Steps to reproduce
Configuration:
````
include "/etc/bind/dev.key";
zone DOMAIN.TLD {
type master;
file "/var/lib/bind/zones/DOMAIN.TLD";
key-directory "/var/lib/bind/keys";
masterfile-format raw;
update-policy {
grant dhcp zonesub a dhcid;
grant local-ddns zonesub any;
grant dev.DOMAIN.TLD subdomain dev.DOMAIN.TLD a aaaa txt;
};
allow-transfer {
local;
};
};
````
Key
````
cat /etc/bind/dev.key
key "dev.DOMAIN.TLD" {
algorithm hmac-sha512;
secret "******";
};
````
````
nsupdate -k dev.key
> server 192.168.122.129
> ttl 3600
> update add test3.dev.DOMAIN.TLD a 192.0.2.3
> send
> update add test.DOMAIN.TLD a 192.0.2.1
> send
````
````
Jul 28 16:48:59 leap152-bind named[5894]: client @0x7f5718000c80 192.168.122.1#40886/key dev.DOMAIN.TLD: updating zone 'DOMAIN.de/IN': adding an RR at 'test3.dev.DOMAIN.de' A 192.0.2.3
Jul 28 16:48:59 leap152-bind named[5894]: zone DOMAIN.de/IN: sending notifies (serial 2020050521)
Jul 28 16:49:07 leap152-bind named[5894]: client @0x7f5718000c80 192.168.122.1#40886/key dev.DOMAIN.TLD: updating zone 'DOMAIN.de/IN': adding an RR at 'test.DOMAIN.de' A 192.0.2.1
Jul 28 16:49:07 leap152-bind named[5894]: zone DOMAIN.de/IN: sending notifies (serial 2020050522)
````
### What is the current *bug* behavior?
It is also possible to change entries in DOMAIN.TLD
### What is the expected *correct* behavior?
````
nsupdate -k dev.key
> server 192.168.122.129
> ttl 3600
> update add test4.dev.DOMAIN.TLD a 192.0.2.4
> send
> update add test4.DOMAIN.TLD a 192.0.2.4
> send
update failed: REFUSED
````
````
Jul 28 19:55:24 leap152-bind named[7625]: client @0x7ff5580a6970 192.168.122.1#46061/key dev.DOMAIN.TLD: updating zone 'DOMAIN.de/IN': adding an RR at 'test4.dev.DOMAIN.de' A 192.0.2.4
Jul 28 19:55:24 leap152-bind named[7625]: zone DOMAIN.de/IN: sending notifies (serial 2020050523)
Jul 28 19:55:38 leap152-bind named[7625]: client @0x7ff5580a6970 192.168.122.1#46061/key dev.DOMAIN.TLD: updating zone 'DOMAIN.de/IN': update failed: rejected by secure update (REFUSED)
````
This is seen on:
````
9.11.2 opensuse
9.10.3 debian stretch
````
### Relevant configuration files
````
zone DOMAIN.TLD {
type master;
file "/var/lib/bind/zones/DOMAIN.TLD";
key-directory "/var/lib/bind/keys";
masterfile-format raw;
update-policy {
grant dhcp zonesub a dhcid;
grant local-ddns zonesub any;
grant dev.DOMAIN.TLD subdomain dev.DOMAIN.TLD a aaaa txt;
};
allow-transfer {
local;
};
};
cat /etc/bind/dev.key
key "dev.DOMAIN.TLD" {
algorithm hmac-sha512;
secret "******";
};
````
### Relevant logs and/or screenshots
````
nsupdate -k dev.key
> server 192.168.122.129
> ttl 3600
> update add test3.dev.DOMAIN.TLD a 192.0.2.3
> send
> update add test.DOMAIN.TLD a 192.0.2.1
> send
````
````
Jul 28 16:48:59 leap152-bind named[5894]: client @0x7f5718000c80 192.168.122.1#40886/key dev.DOMAIN.TLD: updating zone 'DOMAIN.de/IN': adding an RR at 'test3.dev.DOMAIN.de' A 192.0.2.3
Jul 28 16:48:59 leap152-bind named[5894]: zone DOMAIN.de/IN: sending notifies (serial 2020050521)
Jul 28 16:49:07 leap152-bind named[5894]: client @0x7f5718000c80 192.168.122.1#40886/key dev.DOMAIN.TLD: updating zone 'DOMAIN.de/IN': adding an RR at 'test.DOMAIN.de' A 192.0.2.1
Jul 28 16:49:07 leap152-bind named[5894]: zone DOMAIN.de/IN: sending notifies (serial 2020050522)
````
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/kea/-/issues/1351add v4 option 108: v6only-preferred2020-09-25T16:26:54ZTomek Mrugalskiadd v4 option 108: v6only-preferredThere's an I-D being evaluated by IESG right now: https://datatracker.ietf.org/doc/draft-ietf-dhc-v6only/
It went through the early allocation phase and got 108 code assigned. We should update Kea to handle this option.
Note: This is D...There's an I-D being evaluated by IESG right now: https://datatracker.ietf.org/doc/draft-ietf-dhc-v6only/
It went through the early allocation phase and got 108 code assigned. We should update Kea to handle this option.
Note: This is DHCPv4 option, not v6. It informs dual-stack devices that v6-only is the preferred way to go, but it's delivered using DHCPv4.kea1.9.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1350Sanity Checks for 1.7.10 rc12020-09-25T09:14:48ZMichal NowikowskiSanity Checks for 1.7.10 rc1```
Please verify the packages and files according to
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, "4. Sanity Checks" chapter
and your imagination.
!!!!!!!
Before starting any checks. please, state in Sanity Checks issue in GitLa...```
Please verify the packages and files according to
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, "4. Sanity Checks" chapter
and your imagination.
!!!!!!!
Before starting any checks. please, state in Sanity Checks issue in GitLab
https://gitlab.isc.org/isc-projects/kea/-/issues/1350
what check you are doing in a thread/discussion (not as comment).
When you finish given check state in the same thread/discussion what is the result.
This way we know what is covered upfront and we can avoid repeating ourselves.
!!!!!!!
Release content is located on:
1) [tarballs] repo.isc.org in the following folders:
/data/shared/sweng/kea/releases/1.7.10-rc1
/data/shared/sweng/kea/releases/premium-1.7.10-rc1
/data/shared/sweng/kea/releases/subscription-1.7.10-rc1
SHA256 (1.7.10-rc1/kea-1.7.10.tar.gz) = 4e121f0e58b175a827581c69cb1d60778647049fa47f142940dddc9ce58f3c82
SHA256 (subscription-1.7.10-rc1/kea-subscription-1.7.10.tar.gz) = 70db4dd2d8ec6205bc68fe102c2823c3516c19b577c071b0922980d2518b4df5
SHA256 (premium-1.7.10-rc1/kea-premium-1.7.10.tar.gz) = c352f291c6e9346ba691f079353b8c9c3b8426b9dcddda35b2d1c6b4d8ec600b
2) [rpm/deb packages] on packages.isc.org, exact packages versions are stored here:
https://jenkins.isc.org/job/kea-1.7/job/pkg/337/
Release version is 1.7.10-isc0030920200728082656 (please verify if it is this version while installing).
Install instruction is here: https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, chapter 4. Sanity Checks, point 9.
```kea1.9.0https://gitlab.isc.org/isc-projects/bind9/-/issues/2054dig +bufsize=0 sets bufsize to 40962022-04-26T13:12:08ZAnand Buddhdevdig +bufsize=0 sets bufsize to 4096### Summary
When I send a query with dig, and set bufsize to 0, dig appears to ignore this and sets the bufsize to 4096.
### BIND version used
9.16.5
### Steps to reproduce
Use dig to send such a query:
`dig +norec +bufsize=0 ke so...### Summary
When I send a query with dig, and set bufsize to 0, dig appears to ignore this and sets the bufsize to 4096.
### BIND version used
9.16.5
### Steps to reproduce
Use dig to send such a query:
`dig +norec +bufsize=0 ke soa @kenic.anycastdns.cz`
### What is the current *bug* behavior?
dig sends an EDNS query with the bufsize set to 4096.
### What is the expected *correct* behavior?
dig should send a non-EDNS query, as described in the man page. Even better, dig should send an EDNS query but with bufsize set to 0, as instructed by the user.
### Relevant configuration files
No relevant configuration files.
### Relevant logs and/or screenshots
Here is a tcpdump showing how dig has ignored my `+bufsize=0` setting, and set the buffer to 4096:
```
12:48:39.756643 IP (tos 0x0, ttl 64, id 15958, offset 0, flags [none], proto UDP (17), length 59)
192.168.178.34.51981 > 185.28.194.194.53: [udp sum ok] 8443 [1au] SOA? ke. ar: . OPT UDPsize=4096 (31)
```
### Possible fixes
I don't have enough knowledge of the code to suggest a fix.September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)https://gitlab.isc.org/isc-projects/kea/-/issues/1349lease commands should not accept invalid lease (PD in declined state)2020-08-03T12:12:50ZRazvan Becheriulease commands should not accept invalid lease (PD in declined state)related to #1065related to #1065kea1.8.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1348perfdhcp split nack from duplicate address in counters2020-08-20T16:43:11ZRazvan Becheriuperfdhcp split nack from duplicate address in counterskea1.8.0https://gitlab.isc.org/isc-projects/bind9/-/issues/2053Test --disable-buffer-useinline in GitLab CI2020-08-25T14:16:09ZMichał KępieńTest --disable-buffer-useinline in GitLab CI#2031 would have been caught early if we were testing the
`--enable-buffer-useinline` compile-time switch in GitLab CI. We should
probably make one build job use it - maybe the CentOS 8 one?
One obstacle is that such a build does not c...#2031 would have been caught early if we were testing the
`--enable-buffer-useinline` compile-time switch in GitLab CI. We should
probably make one build job use it - maybe the CentOS 8 one?
One obstacle is that such a build does not currently work with
`--enable-developer` as the warnings issued are turned into errors.
These warnings should thus be addressed first.September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)Michal NowakMichal Nowak