ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-08-18T12:07:03Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/1384leaseX-resend-ddns return value incorrect in the ARM2020-08-18T12:07:03ZThomas MarkwalderleaseX-resend-ddns return value incorrect in the ARMPer Wlodek:
```
I'm testing lease6-resend-ddns command https://jenkins.isc.org/job/Kea_doc/KeaAdministratorReferenceManual/index.html#the-lease4-resend-ddns-lease6-resend-ddns-commands
and when I'm sending this command with an address t...Per Wlodek:
```
I'm testing lease6-resend-ddns command https://jenkins.isc.org/job/Kea_doc/KeaAdministratorReferenceManual/index.html#the-lease4-resend-ddns-lease6-resend-ddns-commands
and when I'm sending this command with an address that has no lease
result, according to ARM should be 2; but in reality it's 3
and I am wondering if I should open a ticket to update docs or to change behaviour
or maybe code 2 is when lease exist but without fqdn
```
The code returns CONTROL_RESULT_EMPTY which is 3. The ARM section below should be corrected.
https://jenkins.isc.org/job/Kea_doc/KeaAdministratorReferenceManual/index.html#the-lease4-resend-ddns-lease6-resend-ddns-commandskea1.8.0Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2077negative hook point value in filter-aaaa.c2020-08-31T12:39:25ZMichael McNallynegative hook point value in filter-aaaa.cJinmei points out (via [Support #16987](https://support.isc.org/Ticket/Display.html?id=16987)) what may be an extraneous '-' character in the code.
FWIW I agree with him -- if this is unintentional it should be removed, even if currentl...Jinmei points out (via [Support #16987](https://support.isc.org/Ticket/Display.html?id=16987)) what may be an extraneous '-' character in the code.
FWIW I agree with him -- if this is unintentional it should be removed, even if currently harmless, and if it *is* intended for some reason then a comment would be advisable, as without explanation it looks pretty suspect.
```
I have one simple question about this line of bind-9.16.5/bin/plugins/filter-aaaa.c:
ns_hook_add(hooktable, mctx, -NS_QUERY_QCTX_INITIALIZED, &filter_init);
What's the purpose [of] the "minus" sign prepended to NS_QUERY_QCTX_INITIALIZED?
NS_QUERY_QCTX_INITIALIZED seems to happen to be 0, so that wouldn't
have any effect, but if it's ever renumbered it could cause a
disaster; most likely to just trigger a REQUIRE failure, but in the
worst case corrupt memory. Or is that actually the intent?
If it's not intentional, I'd suggest removing the minus sign as it's
just cryptic. If it's intentional, I'd suggest leaving a comment
about it's intent, since it's...well, cryptic.
```September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)https://gitlab.isc.org/isc-projects/dhcp/-/issues/129Subnet parameters should be overridable per-host2022-01-13T11:20:30ZPhilip PrindevilleSubnet parameters should be overridable per-host---
name: Per-host subnet overrides
about: It's occasionally useful to drop an option on a one-off basis in a group
---
**Initial Questions**
If you have a configuration like:
```
authoritative;
log-facility daemon;
default-lease-tim...---
name: Per-host subnet overrides
about: It's occasionally useful to drop an option on a one-off basis in a group
---
**Initial Questions**
If you have a configuration like:
```
authoritative;
log-facility daemon;
default-lease-time 3600;
max-lease-time 86400;
option domain-name "example.com";
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.128 192.168.1.254;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
default-lease-time 43200;
max-lease-time 43200;
option routers 192.168.1.1;
option domain-name-servers 192.168.1.1;
option ntp-servers 192.168.1.40;
}
...
# and a bunch of static allocations in as "host" reservations
host switch {
hardware ethernet 00:01:02:03:04:05;
fixed-address 192.168.1.2;
option host-name "switch";
}
...
# and an alarm system that should never have a default-route
host alarm {
hardware ethernet 00:01:02:0a:0b:0c;
fixed-address 192.168.1.8;
option host-name "alarm";
option routers none;
}
```
In this case, it's easier to default all of the hosts as getting a default-route, except for one where that isn't the case and call that out explicitly.
In the special case of IPv4 routers, you can set it to "0.0.0.0" and an ISC-DHCP client will reject this value, but the same is not true of many other DHCP clients, including the built-in one in NetworkManager, and indeed this should be handled server-side anyway ("Be conservative in what you send...").
**Prior Discussion**
This has been brought up on the `#isc-dhcp` IRC channel as well as the `dhcp-workers` mailing list.
**Limitations/Genesis**
If I have a subnet with 250 hosts, 249 of which should receive a default route, and 1 of which shouldn't, I shouldn't have to write 250 `host` definitions... and if I'm using dynamic allocations, this isn't even possible. Configuration should be powerful, simple, and easy.
**Desired Solution**
Be able to override subnet defaults on a per-host basis.
**Alternatives**
There really aren't any. Even if I were to use classes as a shorthand, I'd still need to default all hosts on my network.
**Additional context**
None
**Funding its development**
See below.
**Participating in development**
I'd be willing to drive the development of this feature and do most of it myself, but I might need some guidance navigating the code base as I'm not well-versed in it.
**Contacting you**
Comments on this issue, or as `philipp@redfish-solutions.com` via email, or as `philipp64` on IRC (`freenode.org`).https://gitlab.isc.org/isc-projects/stork/-/issues/374Notes from Second User test2020-11-23T17:36:51ZVicky Riskvicky@isc.orgNotes from Second User testThe recording of this session is stored in my home directory on our shared drive (only accessible to ISC staff, sorry). Note that the application refresh was particularly slow during this session so a few observations may be due to that...The recording of this session is stored in my home directory on our shared drive (only accessible to ISC staff, sorry). Note that the application refresh was particularly slow during this session so a few observations may be due to that (perhaps the screen would have updated if he had waited longer.)
- [x] As with the first user, this user wanted to add new machines under settings, or under hosts. However, when subsequently looking for machines, was perfectly able to find them under the services menu. Perhaps add a link on the Stork settings page to the Machines page? https://gitlab.isc.org/isc-projects/stork/-/issues/386
- [ ] Tracking from one screen to another is still confusing, even for a fairly experienced user. "I am not finding ID numbers useful." Initially thought the ID number was for the host, not the app.
- [ ] The AppID is one key that is available on multiple screens. Consider permitting the user to alias that to a term that is more meaningful to the user. If we do that, please reflect the alias everywhere we currently have AppID.
- [x] The user tried to look at the scopes held by each member of the HA pair. This information doesn't seem to be available. He also seemed to think that HA was not configured correctly because the standby machine reported it was not serving any scopes. I think that is as designed, but perhaps we could use a tip under HA/ scopes to say that if the server is not presently active, no scopes will be shown. https://gitlab.isc.org/isc-projects/stork/-/issues/387
- The user felt that a time-series graph of the # of addresses in each subnet is not useful. (Grafana) (no action)
- Grafana, # of leases assigned was not clear enough to the user. Are these active leases? User thought the # of leases assigned was not very useful. (we decided to leave this for now and see if any other users find this confusing)
- [x] The user was not satisfied with the CPU load factor shown. Look at around minute 35 of the recording. The user disagrees with the definition of CPU load displayed. (@Godfryd to view the tape to see if he can discover the issue. The display we are using is a standard OS function.)
- This user thought that the DHCP administrator would not be responsible for upgrading the OS on the hosts and thought that a DHCP dashboard is not the right place to monitor OS versions. (no action - this will vary by the organization size and complexity.)
- In the Kea detail app view, couldn't tell if the display was communicating which hooks are installed on disk or which hooks are actually loaded. Might be something to check in the documentation. (we decided to leave this for now and see if any other users find this confusing)
- The user was easily able to turn off monitoring for a specific daemon. The user was not confused about the ability to separately turn off monitoring for the daemon vs the CA. (no action required)
- [x] When clicking on the More button on the dashboard under the subnets display, it should display just the DHCPv4 or DHCPv6 subnets (depending on which More button is clicked). https://gitlab.isc.org/isc-projects/stork/-/issues/389
- [x] When the user disabled monitoring on the agent-kea6 application, the subnets on that application did not disappear from the subnets list. The same occurred with turning off monitoring for a DHCPv4 daemon. Utilization numbers on the subnets on this application that was not supposed to be monitored kept updating in Stork. This seems like a bug. https://gitlab.isc.org/isc-projects/stork/-/issues/390
- [x] The user suggested he would like to 'ignore' or stop monitoring a specific subnet. (I think that what he really wanted to do was to no longer see alerts on high utilization on that subnet.) (No action at this time.)
- [x] Some of the events are initiated by a User. Please provide a way to determine from the event which Stork user made the change (e.g. monitoring on/off, adding or removing a machine) https://gitlab.isc.org/isc-projects/stork/-/issues/388
- [x] The user was expecting when clicking on an event in the dashboard to drill down on the event, not to navigate to the app the event related to. (at the moment there IS no more detail, but if we add events with more detail, we will consider this) No action at this time.
- [x] The user is OK with not being able to see details on a machine that was removed, but the user wants to retain events associated with removed machine (what user removed the machine, when, etc). https://gitlab.isc.org/isc-projects/stork/-/issues/357
- [x] The user would like to see MORE on the events panel to see more event history. (https://gitlab.isc.org/isc-projects/stork/-/issues/357)
- The user had no difficulty finding and viewing the log tail. (no action)
- [x] On the Subnets list, the user thought it would be more helpful in the last column to show the hostname, instead of the IP address. [Not everyone will have defined hostnames and screen real estate is an issue. We discussed adding a hostname field, and having it hidden by default, with a configuration option to display it.] https://gitlab.isc.org/isc-projects/stork/-/issues/391
- [ ] The user observed that it would be helpful to have names for the subnets in some situations. If the subnets have names (perhaps use the comment field?) in the Kea configuration, it would be good to have an option here to display that comment/name rather than address/mask.
- [ ] When we have alerting, the user will require per-subnet alerting rules.
- [x] On the drill down for the machine, it would be helpful to display the IP address.
- [ ] On the summary list of machines, it the AppID@Address field is not really helpful The user would prefer to see the hostname, or at least, for whatever they DO see, they would like to see it reflected in the drill down they see when they click on the AppID@ link.
- [ ] On the drill down for an individual machine, the admin can rename the machine 'address.' This is reflected as 'Location' on the summary Machines panel. We should use the same term in both places.
- [ ] On the drill down for an individual machine, the admin can rename the machine 'address.' If what we are doing is permitting the admin to add an alias, we should be clearer about that (that this is a 'tag' or alias, not a new or different ip address necessarily). We also need to provide info about what sort of name is permitted (the user tried to add a name with spaces and that didn't work).
- [ ] On the drill down for an individual machine, the admin can rename the machine 'address', including the port. If the user changes both and there is a failure, there is no feedback about which change caused the failure. Perhaps these should be separate change dialogs, or we should not permit changing the port number, if this is intended to be an alias,
- In this instance, we changed the machine address to one that did not work, and the user did not notice/realize that the machine was no longer being monitored. Perhaps we should grey out the display of the cached information on a machine we can no longer reach so it is more obvious that this is old information. There is a message at the bottom of the machine detail panel saying that the machine was unreachable, but the user did not notice this.
- [ ] This user would like to be able to provide an alias for the APPID - some name that is more meaningful to the administrator
- The user commented that he liked the (?) info boxes.
- [ ] The user was surprised that the Grafana menu item under services went to an external application. This should probably open in a new window, rather than taking the user out of Stork.
- User wondered - "why are the DHCP services not under the DHCP menu? It is obviously DHCP...."
- [x] The user kept looking for machine information under Hosts. Consider renaming that 'Reservations' to avoid confusion with host machines.
- [ ] This user felt that the list of pools per subnet could be in a subnet drill down, rather than on the summary list of subnets. The user would also like to see a name for the subnet, if the subnet has a name in the Kea configuration (not sure if this is even supported)
- [ ] On the subnets list summary page, the far right column, the user requested that this be two links one to the machine and one to the app (clicking on either goes to the app).Vicky Riskvicky@isc.orgVicky Riskvicky@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2076geoip2 & runtime DLZ support in/for Fedora (other OS?) packaging?2020-09-08T05:01:50Zpgndgeoip2 & runtime DLZ support in/for Fedora (other OS?) packaging?### Description
### Request
I'm considering moving a bind9 instance from a DIY, from-source build to ISC-maintained Fedora32 packages,
BIND 9.16 Stable Version Packages
https://copr.fedorainfracloud.org/coprs/isc/bind/
The pkg'd bi...### Description
### Request
I'm considering moving a bind9 instance from a DIY, from-source build to ISC-maintained Fedora32 packages,
BIND 9.16 Stable Version Packages
https://copr.fedorainfracloud.org/coprs/isc/bind/
The pkg'd bin
named -v
BIND 9.16.5 (Stable Release) <id:c00b458>
appears to lack geoip2 support,
named -V
...
default paths:
...
geoip-directory: /usr/share/GeoIP <======= (missing)
enabled by config opts,
'--enable-geoip' '--with-maxminddb'
missing in these builds.
also, DLZ runtime modules support is not built/included for, in my case, 2 modules, prepared in my source-builds with
cd contrib/dlz/modules/
cd ./bdbhpt
make V=1
ldd dlz_bdbhpt_dynamic.so
linux-vdso.so.1 (0x00007fffa312c000)
libdb-4.8.so => /usr/lib64/libdb-4.8.so (0x00007f50edc43000)
libc.so.6 => /lib64/libc.so.6 (0x00007f50ed89b000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f50ed67d000)
/lib64/ld-linux-x86-64.so.2 (0x000056482796b000)
cd ../filesystem
make V=1
ldd dlz_filesystem_dynamic.so
linux-vdso.so.1 (0x00007ffd99f34000)
libc.so.6 => /lib64/libc.so.6 (0x00007fbb2713e000)
/lib64/ld-linux-x86-64.so.2 (0x0000564e6ae95000)
prior to the master build.
can GeoIP2 & DLZ runtime support be _added_ to these pkgs? similar to libfstrm pkg-ing?
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2075Enable the implicit "max-cache-size 90%;" default to be overridden2020-11-13T18:31:42ZMichał KępieńEnable the implicit "max-cache-size 90%;" default to be overridden!3865 caused RBT hash tables to be pre-allocated. This makes `named`
use more memory immediately from startup; how much more memory it uses
depends on the size of memory available on the host as the default value
of `max-cache-size` is ...!3865 caused RBT hash tables to be pre-allocated. This makes `named`
use more memory immediately from startup; how much more memory it uses
depends on the size of memory available on the host as the default value
of `max-cache-size` is `90%` (and the hash table size is derived from
that value).
This is not expected to cause problems on systems which run a single
instance of BIND, but it may trigger memory use issues e.g. on CI hosts,
which run numerous instances of BIND in parallel and each of these
instances assumes it is okay for it to use all of the memory available
on the host. The most prominent display of that problem was addressed
by !3919, but certain issues are still manifesting themselves
intermittently - most notably, the FreeBSD QEMU VMs are often being
killed off, which causes the FreeBSD GitLab CI jobs to appear to be
hung, e.g.:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1082066
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1082411
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1082632
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1082794
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1083286
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/1083287
Since `named` instances used in BIND system tests do not really need
large caches, what would address these memory use issues is a way of
overriding the default `max-cache-size 90%;` setting present in
`bin/named/config.c`. Any mechanism implemented for that purpose would
still need to honor explicit `max-cache-size` settings present in
`named.conf`.September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/kea/-/issues/1383kea1.7.9 中的 stat-lease6-get 返回可用地址总数问题2020-08-14T10:09:28ZBingoGukea1.7.9 中的 stat-lease6-get 返回可用地址总数问题stat-lease6-get 挂钩 获取的数据中如果 v6地址前缀为64的话则 返回可用地址总数会变成-1
查看源码发现统计数据类型都是uint_64 虽然在函数sumPoolCapacity判断了如果
// Check if we can add it. If sum + x > uint64::max, then we would have overflown if we tried to add it.
但我不知道其实际意义在哪,因为数量值还是-1(因为地址总数...stat-lease6-get 挂钩 获取的数据中如果 v6地址前缀为64的话则 返回可用地址总数会变成-1
查看源码发现统计数据类型都是uint_64 虽然在函数sumPoolCapacity判断了如果
// Check if we can add it. If sum + x > uint64::max, then we would have overflown if we tried to add it.
但我不知道其实际意义在哪,因为数量值还是-1(因为地址总数超过了uint_64的范围)
现在我将sumPoolCapacity以及相关函数改为double类型的,但是在这种情况下,虽然stat-lease6-get获取的数量正常,但是有两个实质性问题
1、返回的是科学计数法,无法显示正常数目
2、如果分配地址后,再次重启kea提示配置文件加载失败(Error while processing command 'config-set':Invalid statistic type requested: float(1), but the actual type is integer(0))提示这一串报错,但是将租约文件删除后,就会正常启动,所以我想知道,启动加载配置时,哪里会出现判断数据类型的那一块。
我更改的源码内容如下:
/kea-1.7.9/src/lib/dhcpsrv/subnet.cc 181行 214行 头文件同步修改
尝试修改了函数 getPoolCapacity ,sumPoolCapacity的类型从uint64_t到double
/kea-1.7.9/src/lib/dhcpsrv/cfg_subnets4.cc
updateStatistics函数中 getPoolCapacity的使用类型改为double 512行
/kea-1.7.9/src/lib/dhcpsrv/cfg_subnets6.cc
updateStatistics函数中 getPoolCapacity的使用类型改为double 432行
/kea-1.7.9/src/lib/dhcpsrv/alloc_engine.cc
getPoolCapacity函数赋值调用变成double 1006行 与之有关的都uint64_t到double
/kea-1.7.9/src/lib/dhcpsrv/lease_mgr.h
修改LeaseStatsRow类中state_count类型为double
/kea-1.7.9/src/hooks/dhcp/stat_cmds/stat_cmds.cc
getSubnetStat函数类型由uint64_t到double
我对kea的源码过程了解还是很少,而且我的开发技术也不是很厉害,希望有大能能够帮助我一下。
我的子网是 2001:db8:1::/64
以下几张图是我修改前以及修改后的对比
![hou](/uploads/61d2e1ba6d5871752e86b5f400f11e42/hou.png)
![qian](/uploads/feafff5395c04728c91627b01e360b50/qian.png)
![wenti](/uploads/35b9bb6cbf0732a8839f1c9b3d31e68a/wenti.png)https://gitlab.isc.org/isc-projects/kea/-/issues/1382Kea Config Backend fails to fetch the data from the database on MariaDB 10.4.142020-08-20T14:37:46ZMarcin SiodelskiKea Config Backend fails to fetch the data from the database on MariaDB 10.4.14When the server with CB is started, it tries to fetch all audit entries and the corresponding data from the database to update the runtime configuration. Because this mechanism generic, i.e. can also fetch further incremental changes it ...When the server with CB is started, it tries to fetch all audit entries and the corresponding data from the database to update the runtime configuration. Because this mechanism generic, i.e. can also fetch further incremental changes it uses a moving timestamp value from which it considers that the data are new. This timestamp is initially set to January 1st 1970. The problem is that is that MySQL's lowest possible timestamp is January 1st 1970 at 00:00:01 UTC. In addition, the date we're using as an input to the query is time zone dependent, because MySQL consumes data in local time and converts to UTC. So, it is not that we're off by 1 second with the lowest timestamp we use as input to MySQL, but we may be off by a couple of hours if we live in a distant timezone.
Earlier MySQL versions we have tested are not sensitive to this and seem to work fine. The issue was first found on MariaDB 10.4.13 and also reproduced by myself on MariaDB 10.4.14. I applied local changes to the code to set the initial timestamp to 1980-01-01 and the whole thing worked fine. I did another similar experiment and set the initial date to 1970-01-02, which is within the range of all possible timezones and it worked too. This seems to confirm the theory about CB using out of range value. I'd suggest that we maybe simply set this date to 2000-01-01 and not bother...kea1.8.0Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/373stork-db-migrate man page not installed2020-08-31T14:45:42ZTomek Mrugalskistork-db-migrate man page not installedThe recently added stork-db-migrate man page is not installed when DEB (tested on Ubuntu 20.04) or RPM packages (on RHEL7.8) are installed.The recently added stork-db-migrate man page is not installed when DEB (tested on Ubuntu 20.04) or RPM packages (on RHEL7.8) are installed.0.11https://gitlab.isc.org/isc-projects/stork/-/issues/371The list of most active subnets is not dynamic2020-09-04T15:47:00ZTomek MrugalskiThe list of most active subnets is not dynamicYou can click the refresh button to reload the pool utilization for the 5 subnets that are shown there, but those will always be the same 5 subnets, until you reload the dashboard.
How to reproduce this:
1. `rake docker_up`
1. add kea w...You can click the refresh button to reload the pool utilization for the 5 subnets that are shown there, but those will always be the same 5 subnets, until you reload the dashboard.
How to reproduce this:
1. `rake docker_up`
1. add kea with some subnets
1. open dashboards
1. open traffic panel and generate traffic in some subnets that are not on the list.
1. wait a bit, hit refresh.0.12https://gitlab.isc.org/isc-projects/bind9/-/issues/2074BIND allows an empty 'cm' value for optional LOC RDATA fields2020-09-16T21:01:07ZCathy AlmondBIND allows an empty 'cm' value for optional LOC RDATA fieldsFrom Support ticket [https://support.isc.org/Ticket/Display.html?id=16882](#16882)
Customer says:
```
(Checked the behavior with some recent version on the public git repo, but I believe it's the same
for all versions that support LOC...From Support ticket [https://support.isc.org/Ticket/Display.html?id=16882](#16882)
Customer says:
```
(Checked the behavior with some recent version on the public git repo, but I believe it's the same
for all versions that support LOC).
I've just noticed somewhat awkward behavior of BIND about parsing textual LOC RDATA: it accepts an
empty 'cm' part after a 'dot' of the SIZE or HORIZ/VERT PRE field. For example, it accepts the
following textual RDATA as part of a zone file:
22 21 54.000 N 71 6 18.000 W -24.00m 30m 100m 1.
22 21 54.000 N 71 6 18.000 W -24.00m 30m 100m 1.m
in this case, the VERT PRE field is specified that way (and is interpreted as "1m").
Is this intentional? The syntax format described in RFC1876 is not very formal, so it could be
left to the implementor's discretion. But it looks quite awkward to me at least, and I wonder whether
this was not really intentional. In that case, you may want to tighten the validation.
I'm reporting this just because I've noticed it. I'm fine if you decided to keep it as is.
```
Then follows up with:
```
(Essentially the same issue but) maybe this looks even more awkward. BIND accepts these
fields just containing a dot (with or without the 'm' suffix):
22 21 54.000 N 71 6 18.000 W -24.00m 30m 100m .
22 21 54.000 N 71 6 18.000 W -24.00m 30m 100m .m
and interprets it as "0.00m" (<1cm).
```
And:
```
and one more...it even accepts just with an 'm' (interpreting it as 0.00m):
22 21 54.000 N 71 6 18.000 W -24.00m 30m 0100m m
```September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)https://gitlab.isc.org/isc-projects/stork/-/issues/3690.10 release2020-08-13T13:35:34ZWlodzimierz Wencel0.10 releasehttps://gitlab.isc.org/isc-projects/kea/-/issues/1381update json syntax section in ARM2020-08-19T09:47:33ZWlodzimierz Wencelupdate json syntax section in ARMhttps://jenkins.isc.org/job/Kea_doc/KeaAdministratorReferenceManual/index.html#json-syntax
```
The configuration file consists of a single object (often colloquially called a map) started with a curly bracket. It comprises one or more ...https://jenkins.isc.org/job/Kea_doc/KeaAdministratorReferenceManual/index.html#json-syntax
```
The configuration file consists of a single object (often colloquially called a map) started with a curly bracket. It comprises one or more of the “Dhcp4”, “Dhcp6”, “DhcpDdns”, “Control-agent”, and “Netconf” objects. It is possible to define additional elements but they will be ignored.
```
and
```
The specification of several supported elements (e.g. “Dhcp4”, “Dhcp6”) in a single configuration file can be confusing and works badly with the commands that fetch and write new configurations. Support for it will be removed in a future release of Kea, after which each component will require its own configuration file.
```
since 1.7.10 we do not support this.kea1.8.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2073dnssec-verify tries all keys which results in poor performance2021-02-17T21:37:02ZDaniel Stirnimanndnssec-verify tries all keys which results in poor performance<!--
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
I noticed that for zones with many signatures (>= ~50'000) `dnssec-verify` can perform
noticeably slower the more stand-by keys are included in the DNSKEY RR.
It looks like all ZSK keys in the DNSKEY RR are tried to verify the signatures until one is
found which succeeds. It now depends on the DNSKEY RR data structure which key is tried first and whether
the validation process is fast or slow. It would be good to first compare the RRSIG key-id with the DNSKEY key-id before attempting any cryptographic operations.
### BIND version used
dnssec-verify 9.16.5
### Steps to reproduce
````
# Create keys
# KSK
dnssec-keygen -a ECDSAP256SHA256 -f KSK foo.
Generating key pair.
Kfoo.+013+59071
# ZSK
dnssec-keygen -a ECDSAP256SHA256 foo.
Generating key pair.
Kfoo.+013+29053
# Add keys to foo.zone using an editor
$INCLUDE Kfoo.+013+59071.key
$INCLUDE Kfoo.+013+29053.key
# sign zone
dnssec-signzone -o foo. -P -t -x foo.zone Kfoo.+013+59071.private Kfoo.+013+29053.private
# verify zone
time dnssec-verify -o foo. foo.zone.signed
````
### What is the current *bug* behavior?
Depending on the key id and how many stand-by keys are present, the validation time of `dnssec-verify` slows down noticeably.
Some examples below:
**active ZSK: Kfoo.+013+39828, no stand-by ZSK**
```
time dnssec-verify -o foo. foo.zone.signed
Loading zone 'foo.' from file 'foo.zone.signed'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
real 0m9.677s
user 0m9.645s
sys 0m0.026s
```
About ~9-10sec is the baseline
**active ZSK: Kfoo.+013+59286 , stand-by ZSK: Kfoo.+013+39828**
```
time dnssec-verify -o foo. foo.zone.signed
Loading zone 'foo.' from file 'foo.zone.signed'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 1 stand-by, 0 revoked
real 0m9.662s
user 0m9.630s
sys 0m0.026s
```
Result is correct and within the baseline.
**active ZSK: Kfoo.+013+39828 , stand-by ZSK: Kfoo.+013+59286**
```
time dnssec-verify -o foo. foo.zone.signed
Loading zone 'foo.' from file 'foo.zone.signed'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 1 stand-by, 0 revoked
real 0m14.210s
user 0m14.173s
sys 0m0.029s
```
Result is **poor**!
**active ZSK: Kfoo.+013+39828 , stand-by ZSK: Kfoo.+013+59286, Kfoo.+013+51653**
```
time dnssec-verify -o foo. foo.zone.signed
Loading zone 'foo.' from file 'foo.zone.signed'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 2 stand-by, 0 revoked
real 0m18.310s
user 0m18.274s
sys 0m0.029s
```
Result is **poor**!
### What is the expected *correct* behavior?
No matter how many stand-by keys are present, the validation time is more or less constant.
### Possible fixes
Check the key id before attempting to validate each signature with each key.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)https://gitlab.isc.org/isc-projects/stork/-/issues/368Evaluate existing open source alerting systems2021-05-17T13:37:47ZTomek MrugalskiEvaluate existing open source alerting systemsBefore we settle to use one, we should investigate what kind of alerting systems are available out there.
- https://www.prometheus.io/docs/alerting/latest/alertmanager/
- https://grafana.com/docs/grafana/latest/alerting/notifications/
-...Before we settle to use one, we should investigate what kind of alerting systems are available out there.
- https://www.prometheus.io/docs/alerting/latest/alertmanager/
- https://grafana.com/docs/grafana/latest/alerting/notifications/
- ...0.18Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2072host: misleading documentation for the -a option2021-10-05T15:23:19Zwferihost: misleading documentation for the -a option`host.rst` states:
```
The -a ("all") option is normally equivalent to -v -t ANY. It also affects the behavior of the -l list zone option.
```
However, `-t ANY` uses TCP by default, whereas `-a` uses UDP.
(Aside: it's also unclear how `-...`host.rst` states:
```
The -a ("all") option is normally equivalent to -v -t ANY. It also affects the behavior of the -l list zone option.
```
However, `-t ANY` uses TCP by default, whereas `-a` uses UDP.
(Aside: it's also unclear how `-a` affects the `-l` option.)
Please fix the documentation or the code as you see fit. Thanks.https://gitlab.isc.org/isc-projects/stork/-/issues/367migration tool up to version X doesn't work, doesn't report its own version (-h)2021-04-09T10:44:12ZTomek Mrugalskimigration tool up to version X doesn't work, doesn't report its own version (-h)Two problems with the migration tool:
- the migration to specific version doesn't work, `stork-db-migrate up 20` always migrates to latest version.
- Every software should be able to return its own version using -v or --version.Two problems with the migration tool:
- the migration to specific version doesn't work, `stork-db-migrate up 20` always migrates to latest version.
- Every software should be able to return its own version using -v or --version.outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2071BIND stuck after error "unable to obtain neither an IPv4 nor an IPv6 dispatch"2021-10-08T14:37:43ZAnand BuddhdevBIND stuck after error "unable to obtain neither an IPv4 nor an IPv6 dispatch"### Summary
Server appeared to be stuck in some strange state after "rndc reconfig".
### BIND version used
```
BIND 9.16.5 (Stable Release) <id:c00b458>
running on Linux x86_64 3.10.0-1127.13.1.el7.x86_64 #1 SMP Tue Jun 23 15:46:38 UT...### Summary
Server appeared to be stuck in some strange state after "rndc reconfig".
### BIND version used
```
BIND 9.16.5 (Stable Release) <id:c00b458>
running on Linux x86_64 3.10.0-1127.13.1.el7.x86_64 #1 SMP Tue Jun 23 15:46:38 UTC 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/named' '--disable-static' '--with-pic' '--without-python' '--with-libtool' '--without-lmdb' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabled
default paths:
named configuration: /etc/named/named.conf
rndc configuration: /etc/named/rndc.conf
DNSSEC root key: /etc/named/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Haven't been able to reproduce this. We run "rndc reconfig" frequently on many of our BIND servers, and this is the first time I've seen such behaviour. On this specific server, after log rotation, logrotate ran "rndc reconfig" and BIND logged this:
### What is the current *bug* behavior?
After logging that error, BIND appeared to be stuck in a strange state. It was answering queries over UDP (did not check TCP). However, it was not refreshing any of the secondary zones. However, I don't know what was going on, because logrotate compressed the rotated log file and deleted the original, but the named process still held it open. However, it couldn't write any logs. "rndc zonestatus" for various zones showed them loaded and stuck on older serials.
### What is the expected *correct* behavior?
BIND should have reloaded its configuration and created a new log file in /var/log/named/named.log
### Relevant configuration files
I'm not including the entire config file here, but here are the relevant snippets:
```
logging {
channel "default" {
file "/var/log/named/named.log";
severity info;
print-time yes;
print-category yes;
};
channel "ratelimit" {
file "/var/log/named/ratelimit.ringlog" versions 10 size 10485760;
print-time yes;
};
category "default" {
"default";
};
category "rate-limit" {
"ratelimit";
};
category "update" {
"null";
};
category "update-security" {
"null";
};
};
options {
answer-cookie no;
directory "/var/named";
keep-response-order {
"any";
};
listen-on {
127.0.0.1/32;
IPv4 address/32;
};
listen-on-v6 {
::1/128;
IPv6 address/128;
};
server-id hostname;
tcp-clients 1000;
transfers-in 100;
transfers-out 100;
version "9.16";
dnssec-validation no;
ixfr-from-differences yes;
minimal-responses yes;
recursion no;
allow-transfer {
"internal";
};
max-journal-size 10485760;
notify explicit;
zero-no-soa-ttl no;
zone-statistics none;
};
```
### Relevant logs and/or screenshots
This was the last thing logged in the rotated file:
```
10-Aug-2020 09:21:29.548 general: received control channel command 'reconfig'
10-Aug-2020 09:21:29.548 general: loading configuration from '/etc/named/named.conf'
10-Aug-2020 09:21:29.848 general: unable to open '/etc/named/bind.keys'; using built-in keys instead
10-Aug-2020 09:21:29.851 general: using default UDP/IPv4 port range: [32768, 60999]
10-Aug-2020 09:21:29.851 general: using default UDP/IPv6 port range: [32768, 60999]
10-Aug-2020 09:21:29.853 general: sizing zone task pool based on 4615 zones
10-Aug-2020 09:21:30.253 config: none:98: 'max-cache-size 90%' - setting to 57795MB (out of 64216MB)
10-Aug-2020 09:21:30.253 general: ./server.c:4530: unexpected error:
10-Aug-2020 09:21:30.253 general: unable to obtain neither an IPv4 nor an IPv6 dispatch
10-Aug-2020 09:21:30.276 general: reloading configuration failed: unexpected error
```
We were debugging the issue the next day, on Aug 11. When we couldn't figure anything out, we tried to restart BIND. It runs under systemd on our server, and this is what appeared in the systemd journal:
```
Aug 11 09:08:00 hostname systemd[1]: Stopping BIND...
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:09:30 hostname systemd[1]: named.service stop-sigterm timed out. Killing.
```
BIND logged those errors, but failed to exit, so systemd sent it a KILL signal after 90s.
### Possible fixes
I don't have any suggestion for a fix.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)https://gitlab.isc.org/isc-projects/kea/-/issues/1380call mysql_autocommit in openDatabase2020-08-14T12:28:20ZRazvan Becheriucall mysql_autocommit in openDatabaseThe mysql_autocommit is already called, but that's done separately for each connection type (lease, hosts, cb). We should move this to common code.The mysql_autocommit is already called, but that's done separately for each connection type (lease, hosts, cb). We should move this to common code.kea1.8.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1379deb ddns package has different socket path than CA2020-08-19T07:07:35ZTomek Mrugalskideb ddns package has different socket path than CAI've installed packages from cloudsmith.io:
```
dpkg -l 'isc-kea*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppe...I've installed packages from cloudsmith.io:
```
dpkg -l 'isc-kea*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-========================-=============================-============-================================================
ii isc-kea-admin 1.7.10-isc0030920200728082656 amd64 Administration utilities for ISC Kea DHCP server
ii isc-kea-common 1.7.10-isc0030920200728082656 amd64 Common libraries for the ISC Kea DHCP server
ii isc-kea-ctrl-agent 1.7.10-isc0030920200728082656 amd64 ISC Kea DHCP server REST API service
ii isc-kea-dhcp-ddns-server 1.7.10-isc0030920200728082656 amd64 ISC Kea DHCP Dynamic DNS service
ii isc-kea-dhcp4-server 1.7.10-isc0030920200728082656 amd64 ISC Kea IPv4 DHCP server
```
isc-kea-ctrl-agent package has /tmp/kea-ddns-ctrl-socket in /etc/kea/kea-ctrl-agent.conf, but isc-kea-dhcp-ddns-server package has /tmp/ddns-ctrl-socket in /etc/kea/kea-dhcp-ddns.conf. Those two must match for the solution to work out of the box.kea1.8.0Wlodzimierz WencelWlodzimierz Wencel