ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-10-12T13:12:40Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/506Remember user preferences2021-10-12T13:12:40ZTomek MrugalskiRemember user preferencesDuring UI review, Cathy changed various lists to show 30 items rather then the default of 10. This information is forgotten as soon as you navigate away from the page. This information should be persistent to some degree. Maybe stored in...During UI review, Cathy changed various lists to show 30 items rather then the default of 10. This information is forgotten as soon as you navigate away from the page. This information should be persistent to some degree. Maybe stored in cookies?
Over time, there will be a lot more personal preferences that we should keep somehow. So the solution should be more flexible than just this example.
For background, see #278, second to last item.backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2485DNS protocol cleanup: require correct AA bit2023-08-16T16:51:42ZPetr Špačekpspacek@isc.orgDNS protocol cleanup: require correct AA bit### Description
Allegedly different resolvers treat AA bit in responses differently, and this is causing different operational problems for each implementation. PowerDNS and Knot Resolver have had issues with that.
Proposal by Peter va...### Description
Allegedly different resolvers treat AA bit in responses differently, and this is causing different operational problems for each implementation. PowerDNS and Knot Resolver have had issues with that.
Proposal by Peter van Dijk is to be strict on AA bit and punish non-compliance. Main motivation seems to be code simplification when it comes various combinations of NXDOMAIN/NOERROR without SOA RR and/or "extra" NS records in authority which are sometimes added as "good measure" but do not actually mean a referral.
Anecdotes from the field:
a) Ralf Weber from Akamai has some reservations:
> Given that a lot of people use resolvers in front of their authoritative servers who don't send AA I fail to envision what resolvers should do. If we drop non AA answers I expect huge portion of the Internet to go dark, though I don't have hard numbers on that.
b) Recent versions of PowerDNS switched to stricter mode and insist on AA bit being correct. A person from Deutsche Telecom claims this:
> To give a sense of possible impact, we have tens of millions of subscribers and only 5-10 cases per year estimated. So I guess nothing would "go dark" :slightly_smiling_face:
### Links / references
Thread https://chat.dns-oarc.net/community/pl/57pcpenfkf86tr8onmhn1q5a4a
Personally I argue this is
a) not significant enough
b) not widespread enough
to warrant full fledged flag day, but we can start being stricter on AA bit if we decide to do so. PowerDNS already went in that direction so first-mover disadvantage is already paid :-)Not plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/1697Disabling high-availability hook leaves "DHCP service is globally disabled" a...2021-03-31T12:57:54ZMike KazantsevDisabling high-availability hook leaves "DHCP service is globally disabled" after reconfiguration**Describe the bug**
Running "config-set" on Kea to disable HA hook can leave DHCP service in a disabled state, refusing to handle any DHCP requests.
**To Reproduce**
Steps to reproduce the behavior:
1. Start kea-dhcpv4 with HA hook...**Describe the bug**
Running "config-set" on Kea to disable HA hook can leave DHCP service in a disabled state, refusing to handle any DHCP requests.
**To Reproduce**
Steps to reproduce the behavior:
1. Start kea-dhcpv4 with HA hook enabled and configured to have primary/secondary role, which will transition it to WAITING state, disabling DHCP service until partner host can be contacted.
2. Run "config-set" API command to update Kea configuration with HA hook disabled in that new configuration.
3. Try testing DHCP service using any client.
4. Verbose Kea logs should report something like "DHCP service is globally disabled".
**Expected behavior**
- HA hook does not leave DHCP service in a disabled state after unloading.
- DHCP service working normally after reconfiguration that disables HA hook.
**Environment:**
- Kea version: 1.8.2
- OS: Alpine Linux 3.13
- Built and used with memfile backend.
**Additional Information**
Running this as a testing setup in a docker containers, with python script configuring Kea.\
Not sure if issue is 100% reproducible, but happened to me at least a couple of times already.
Attached logs:
- [kea-ha-service-disabling.debug-brief.log](/uploads/99f490081744c6b69d3e42812cf6acfd/kea-ha-service-disabling.debug-brief.log)
- [kea-ha-service-disabling.debug-all.log](/uploads/d65c6d01d3ff6dc6e329d1337173163c/kea-ha-service-disabling.debug-all.log)
Full configuration loaded each time should be available in the attached kea-ha-service-disabling.debug-all.log file, in DHCP4_CONFIG_RECEIVED lines, don't think it has anything special or very relevant, aside from that hook being present in one configuration and removed in the next one.
Attached kea-ha-service-disabling.debug-brief.log is a filtered version of "debug-all" file, which I believe illustrates the issue well, without any extra noise in it, with even shorter gist being:
```
2021-02-06T18:39:01.624 a DEBUG kea-dhcp4.dhcp4 DHCP4_CONFIG_RECEIVED ...
2021-02-06T18:39:01.658 a INFO kea-dhcp4.ha-hooks HA_LOCAL_DHCP_DISABLE local DHCP service is disabled while the a is in the WAITING state
2021-02-06T18:39:01.658 a INFO kea-dhcp4.ha-hooks HA_SERVICE_STARTED started high availability service in load-balancing mode as secondary server
...
2021-02-06T18:39:01.820 a INFO kea-dhcp4.commands COMMAND_RECEIVED Received command 'config-set'
2021-02-06T18:39:01.820 a DEBUG kea-dhcp4.dhcp4 DHCP4_CONFIG_RECEIVED ...
2021-02-06T18:39:01.839 a INFO kea-dhcp4.ha-hooks HA_DEINIT_OK unloading High Availability hooks library successful
...
2021-02-06T18:40:05.371 a DEBUG kea-dhcp4.packets DHCP4_BUFFER_RECEIVED received buffer from 0.0.0.0:68 to 255.255.255.255:67 over interface ens3
2021-02-06T18:40:05.371 a DEBUG kea-dhcp4.bad-packets DHCP4_PACKET_DROP_0008 [hwtype=1 ], cid=[no info], tid=0x0: DHCP service is globally disabled
```
Also, I've seen note on new dhcp-enable/dhcp-disable API commands in the recent ChangeLog entry:
```
1858. [bug] razvan
The DHCP service can be independently enabled or disabled by
the user command, by the database connection mechanics or
by the HA library. The DHCP service is disabled when any
of those originators disables the service, and it is enabled
when all those who previously disabled the service enable it.
```
But "when all those who previously disabled the service enable it" seem to imply that it won't be a good workaround for this bug if HA hook indeed does not re-enable the service when removed - it'll stay disabled regardless of API command, or require to masquerade that command as if it was from HA hook, which seem to be suboptimal in a number of ways.
**Extra Question**
Can someone knowledgeable with Kea internals think of a good workaround with a current stable Kea version?\
I.e. is there a good way to reliably disable HA hook at an arbitrary time without risk of leaving DHCP in a broken state?
I can think that maybe HA hook should be first transitioned into passive-backup or somesuch state, from which it explicitly enables DHCP on deinit (assuming that it does, didn't look at the code to confirm), but maybe there's a simplier hack/workaround?
Thanks in advance for any suggestions.
**Contacting you**
Will try to monitor replies here.kea1.9.6Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2478Consider making the build-time dependency on nghttp2 optional2021-07-14T18:34:16ZMichał KępieńConsider making the build-time dependency on nghttp2 optionalRight now, the `main` branch needs nghttp2 to be available in order for
BIND 9 to build at all. Since nghttp2 is only required for
DNS-over-HTTPS (DoH) support - which we promised to backport to BIND
9.16 at some point - it looks slight...Right now, the `main` branch needs nghttp2 to be available in order for
BIND 9 to build at all. Since nghttp2 is only required for
DNS-over-HTTPS (DoH) support - which we promised to backport to BIND
9.16 at some point - it looks slightly harsh to have a new, hard
requirement on another library (even if it is a rather ubiquitous and
not version-picky one), especially in light of a future BIND 9.16
backport.
We should probably discuss whether nghttp2 should be considered
mandatory for:
- BIND 9.17+
- ~~BIND 9.16~~[^1]
Any changes in this area should be "announced" in:
- `README.md`
- `PLATFORMS.md`
- release notes.
[^1]: Not a possibility any more as it has been decided that DoH support
will not be backported to BIND 9.16.August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)https://gitlab.isc.org/isc-projects/kea/-/issues/1690Congestion control: consider packet type as well as age2023-04-06T12:02:31ZVicky Riskvicky@isc.orgCongestion control: consider packet type as well as ageKea has congestion control, that addresses the issue that FIFO handling, when the queue grows too long, will result in replying only after the client has given up waiting and sent a new request. This feature request asks that we conside...Kea has congestion control, that addresses the issue that FIFO handling, when the queue grows too long, will result in replying only after the client has given up waiting and sent a new request. This feature request asks that we consider not only packet age, but also the request type when dealing with a temporary peak load.
When the DHCP service is under heavy load and internal queues are reaching a critical level, it may be desirable to prioritize DHCP-RENEW and DHCP-REBIND packets to ensure continuity of service to already active subscribers. DHCP-DISCOVERS must be handled differently, either by assigning a lower priority or by dropping those packets. In the latter case, clients will initialize their retry mechanism with backoff delay, however this may cause some unwanted effects on the DHCP service if the total number of clients increases.
For DHCP-DISCOVER packets prioritization is preferred over dropping.
(labelled docsis but this is not specific to cable operators.)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1688Auto-detect congestion (busy state thresholds)2022-11-02T15:10:18ZVicky Riskvicky@isc.orgAuto-detect congestion (busy state thresholds)This is a general requirement to adapt to improve performance under unusual load. The feature will require some further design thought.
**Congestion Handling**
Being able to handle peak loads is an important feature for service provider...This is a general requirement to adapt to improve performance under unusual load. The feature will require some further design thought.
**Congestion Handling**
Being able to handle peak loads is an important feature for service providers. Congestion handling features attempts to improve the DHCP performance when the service becomes busy and is not able to fulfill all incoming requests. In cable operators the following scenarios are usual:
- Massive firmware updates- causing cable modems to restart
- Power outages- affecting cable modems in a region or fiber node.
- A fiber node might serve up to ~2,000 subscribers
- CMTS reboots- due to scheduled maintenance or outages
- RF plant rearrangements- where fiber nodes are combined or splitted causing cable modems within the node to re register
- DDI infrastructure maintenance or outages.
- Business requirements- such as massive actions to customers, i.e. disabling customers with unpaid bills.
Suggestion
**Busy state threshold**
Defines a mechanism to allow Kea to evaluate whether it is operating in a normal or busy state. Kea could use the value of the “packet-queue-size” parameter in the multi-threaded configuration section to evaluate if the system should enter a busy state, for example when the queue capacity is 75% full the system transitions to a busy state and may take actions to improve DHCP performance, such as enabling one or more congestion handling features on the fly, like reducing logging, packet prioritization, and/or batch insertion. When the queue capacity is 25% full or less, the system should return from busy to normal state.
It is likely that customers would want to be able to adjust these high and low watermarks.
It should be possible to explicitly enable/disable this feature.
The various actions that Kea will take to handle the congestion should be determined based on some analysis of what will have the most impact in maintaining normal responsiveness to clients under peak loads.
```
# example suggested configuration section
"multi-threading": {
"enable-multi-threading": true,
"thread-pool-size": 4,
"packet-queue-size": 16
"busy-state-pct" : 75,
"normal-state-pct" : 25
}
```
The “capacity” value in the “dhcp-queue-control” configuration section might also be used to evaluate busy state.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1687Batch lease insertion for database lease backend2021-10-20T11:53:14ZVicky Riskvicky@isc.orgBatch lease insertion for database lease backendThe DHCP service might receive thousands of requests per second under peak loads. If each granted lease executes a COMMIT in the database, object contention may occur in rows, tables or indexes. A batch insert provides a mechanism where ...The DHCP service might receive thousands of requests per second under peak loads. If each granted lease executes a COMMIT in the database, object contention may occur in rows, tables or indexes. A batch insert provides a mechanism where the DHCP delays lease insertion for a configurable period of time (in seconds) and then inserts leases in batches using a single database transaction. To avoid data loss in case the DHCP service crashes all queued leases should be persisted to a local on-disk database for a configurable period of time, for example 5 seconds.
This feature should also support configuring the max number of database connections and the number of threads Kea should use to insert leases in the database.
```
# kea config batch lease insertion
batch-lease-insertion-interval-ms = 5000
# if database enabled
batch-lease-insertion-db-connections = 5
batch-lease-insertion-threads = 5
```outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1683kea is not accepting custom spaces in option definitions in class2023-04-04T09:50:34ZWlodzimierz Wencelkea is not accepting custom spaces in option definitions in classoptions in kea can be defined in kea standard space `dhcp4` and `dhcp6` or custom spaces e.g.:
```
"option-def": [
{
"array": false,
"code": 242,
"encapsulate": "",
"name": "dls",
"record-types": "",
"space": "X...options in kea can be defined in kea standard space `dhcp4` and `dhcp6` or custom spaces e.g.:
```
"option-def": [
{
"array": false,
"code": 242,
"encapsulate": "",
"name": "dls",
"record-types": "",
"space": "XYZ",
"type": "string"
}
],
```
But Kea accept custom spaces only on global level, returns error with this configuration:
```
client-classes": [
{
"option-def": [
{
"encapsulate": "339",
"code": 43,
"type": "empty",
"name": "vendor-encapsulated-options"
},
{
"code": 2,
"name": "vlanid",
"space": "339",
"type": "uint32",
"record-types": "",
"array": false,
"encapsulate": ""
},
{
"code": 3,
"name": "dls",
"space": "339",
"type": "string",
"record-types": "",
"array": false,
"encapsulate": ""
}
],
"name": "VENDOR_CLASS_339",
"option-data": [
{
"name": "vendor-encapsulated-options"
},
{
"always-send": true,
"data": "123",
"name": "vlanid",
"space": "339"
},
{
"always-send": true,
"data": "sdlp://192.0.2.11:18443",
"name": "dls",
"space": "339"
}
]
}
],
```
Error:
```
2021-01-28 07:16:28.281 INFO [kea-dhcp4.dhcp4/27394.140192072867456] DHCP4_STARTING Kea DHCPv4 server version 1.9.4-git (development) starting
2021-01-28 07:16:28.282 WARN [kea-dhcp4.dhcp4/27394.140192072867456] DHCP4_DEVELOPMENT_VERSION This software is a development branch of Kea. It is not recommended for production use.
2021-01-28 07:16:28.283 ERROR [kea-dhcp4.dhcp4/27394.140192072867456] DHCP4_CONFIG_LOAD_FAIL configuration error using file: /home/wlodek/installed/git/etc/kea/kea-dhcp4.conf, reason: Not allowed option definition for code '2' in space '339' at (/home/wlodek/installed/git/etc/kea/kea-dhcp4.conf:46:21)
2021-01-28 07:16:28.285 ERROR [kea-dhcp4.dhcp4/27394.140192072867456] DHCP4_INIT_FAIL failed to initialize Kea server: configuration error using file '/home/wlodek/installed/git/etc/kea/kea-dhcp4.conf': Not allowed option definition for code '2' in space '339' at (/home/wlodek/installed/git/etc/kea/kea-dhcp4.conf:46:21)
```
Making impossible to have multiple suboptions code `2` for different classes.
full config attached [kea-dhcp4.conf](/uploads/d68a9d83bf876bf2b8dd033f738424da/kea-dhcp4.conf)current-stable-2.4https://gitlab.isc.org/isc-projects/bind9/-/issues/2394dig +short for MX when the record is broken gives confusing answer2022-04-26T13:36:40ZPaul Hoffmandig +short for MX when the record is broken gives confusing answerA confused user said that dig +short for an MX record did not report the preference level. The example he gave was:
```
# dig +short cyclonit.com MX
HDRedirect-LB7-5a03e1c2772e1c9c.elb.us-east-1.amazonaws.com.
```
When given without +sho...A confused user said that dig +short for an MX record did not report the preference level. The example he gave was:
```
# dig +short cyclonit.com MX
HDRedirect-LB7-5a03e1c2772e1c9c.elb.us-east-1.amazonaws.com.
```
When given without +short, the reason becomes clear:
```
# dig cyclonit.com MX
; <<>> DiG 9.16.10 <<>> cyclonit.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65526
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: b0e8599a68ce3729dc85d51e6003a03d038d9864e7c2e63c (good)
;; QUESTION SECTION:
;cyclonit.com. IN MX
;; ANSWER SECTION:
cyclonit.com. 10544 IN CNAME HDRedirect-LB7-5a03e1c2772e1c9c.elb.us-east-1.amazonaws.com.
;; AUTHORITY SECTION:
elb.us-east-1.amazonaws.com. 53 IN SOA ns-1826.awsdns-36.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 60
```
Yep, it's the dreaded "CNAME and MX at the same level" issue. However, +short hides that in a confusing way.
Proposal: dig +short for broken names such as this should instead reply "CNAME target", or possibly "Bad CNAME target".Not plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/1643Missing foreign key for lease6.hwaddr_source2022-11-02T15:10:19ZSander SteffannMissing foreign key for lease6.hwaddr_source**Describe the bug**
When inspecting the database structure I noticed (using PostgreSQL) that `lease6.hwaddr_source` is not a foreign key to `lease_hwaddr_source.hwaddr_source`. This seems inconsistent as both `lease6.state` and `lease6...**Describe the bug**
When inspecting the database structure I noticed (using PostgreSQL) that `lease6.hwaddr_source` is not a foreign key to `lease_hwaddr_source.hwaddr_source`. This seems inconsistent as both `lease6.state` and `lease6.lease_type` are foreign keys.
**To Reproduce**
Steps to reproduce the behavior:
1. Run `kea-admin db-init pgsql`
2. Connect to the kea database using `psql`
3. Check the database schema with `\d lease6`
**Expected behavior**
I would expect `lease6.hwaddr_source` to be a foreign key as it references values in another table.
**Environment:**
- Kea version: isc-kea-admin, deb package 1.9.3-isc001302020121418142
- OS: Debian GNU/Linux 10 (buster)
**Additional Information**
None
**Contacting you**
sander@steffann.nl or +31-6-22660412backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1635V4 Setting lease time via client classification2021-05-24T16:26:37ZPeter DaviesV4 Setting lease time via client classificationSetting lease time via client classification:
In order to grant the same lease time to a group of clients it would be useful to be able to adjust the lease time via the client classification mechanism.
Either by allowing definition o...Setting lease time via client classification:
In order to grant the same lease time to a group of clients it would be useful to be able to adjust the lease time via the client classification mechanism.
Either by allowing definition of "valid-lifetime" parameter or allowing direct changes to option 51.
[RT #17519 ](https://support.isc.org/Ticket/Display.html?id=17519)kea1.9.5Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2377Allow A records below an '_spf' label as a check-names exception2021-02-04T11:43:35ZMark AndrewsAllow A records below an '_spf' label as a check-names exceptionSPF uses A records for existence testing (exists rule). When "_spf" is used as a separating label this results in A records with non LDH owners.SPF uses A records for existence testing (exists rule). When "_spf" is used as a separating label this results in A records with non LDH owners.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2375dnssec-policy key rollover bug when more than two keys are involved2023-07-06T09:26:15ZMatthijs Mekkingmatthijs@isc.orgdnssec-policy key rollover bug when more than two keys are involved### Summary
When using `dnssec-policy`, key rollovers are scheduled automatically. If a key rollover is halted (because for example the DS was never uploaded), and a new key is introduced to replace the previous successor, at some point...### Summary
When using `dnssec-policy`, key rollovers are scheduled automatically. If a key rollover is halted (because for example the DS was never uploaded), and a new key is introduced to replace the previous successor, at some point `dnssec-policy` decides that having only the new key is a valid state, removing the two previous keys. This moves the zone into a bogus state, where the DS
in the parent mismatches the DNSKEY RRset in the child zone.
### BIND version used
9.16.9
### Steps to reproduce
Create a `dnssec-policy` with quick rollovers, wait until the third key is introduced, and then some more. At some point the keymgr decides to remove the first two keys.
### What is the current *bug* behavior?
The first two keys are removed from the zone too soon.
### What is the expected *correct* behavior?
All three keys should stay in the zone, until a valid `rndc dnssec -checkds` command is issued.
### Relevant configuration files
```
///
/// 20201209 DST, BIND 9.16 dnssec policy test
///
dnssec-policy "test" {
// Keys
keys {
csk key-directory lifetime 7d algorithm 13;
};
// Key timings
dnskey-ttl 3600;
publish-safety 1h;
retire-safety 1h;
// Zone parameters
max-zone-ttl 3600;
zone-propagation-delay 300;
// Parent parameters
parent-ds-ttl 1h;
parent-propagation-delay 1h;
};
zone "badware.ch" {
type master;
dnssec-policy test;
key-directory "/etc/bind/inline-signing-keys";
file "dynamic/badware.ch";
};
```
### Relevant logs and/or screenshots
https://dnsviz.net/d/badware.ch/X-MRAg/dnssec/
### Possible fixesFebruary 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2360dnstap-read: please modify to print query/response timestamps with milliseconds2023-05-05T10:34:18Zssbertilsondnstap-read: please modify to print query/response timestamps with milliseconds### Description
Desire to be able to use dnstap-read to track latency - milliseconds not just by seconds. Simple function call change in print_yaml from using existing libisc function isc_time_formatISO8601 to existing isc_time_formatI...### Description
Desire to be able to use dnstap-read to track latency - milliseconds not just by seconds. Simple function call change in print_yaml from using existing libisc function isc_time_formatISO8601 to existing isc_time_formatISO8601ms in 2 places. Am using this in a version modified from 9.16.6.
### Request
```
diff --git a/bin/tools/dnstap-read.c b/bin/tools/dnstap-read.c
index 5b15fa8153..2663668c08 100644
--- a/bin/tools/dnstap-read.c
+++ b/bin/tools/dnstap-read.c
@@ -230,13 +230,13 @@ print_yaml(dns_dtdata_t *dt) {
if (!isc_time_isepoch(&dt->qtime)) {
char buf[100];
- isc_time_formatISO8601(&dt->qtime, buf, sizeof(buf));
+ isc_time_formatISO8601ms(&dt->qtime, buf, sizeof(buf));
printf(" query_time: !!timestamp %s\n", buf);
}
if (!isc_time_isepoch(&dt->rtime)) {
char buf[100];
- isc_time_formatISO8601(&dt->rtime, buf, sizeof(buf));
+ isc_time_formatISO8601ms(&dt->rtime, buf, sizeof(buf));
printf(" response_time: !!timestamp %s\n", buf);
}
```
### Links / referencesMay 2023 (9.16.41, 9.16.41-S1, 9.18.15, 9.18.15-S1, 9.19.13)https://gitlab.isc.org/isc-projects/dhcp/-/issues/152Support DHCP relay on interfaces with zero MAC address2022-03-09T19:06:03ZQingtao CaoSupport DHCP relay on interfaces with zero MAC addressThe dhcrelay daemon is designed to work on Ethernet-alike interfaces with MAC addresses. However, some interfaces on Linux don't use L2 header at all, such as cellmodem's wwanX interfaces, if the IPSec kernel driver doesn't forge a MAC a...The dhcrelay daemon is designed to work on Ethernet-alike interfaces with MAC addresses. However, some interfaces on Linux don't use L2 header at all, such as cellmodem's wwanX interfaces, if the IPSec kernel driver doesn't forge a MAC address, the ipsecX interfaces built upon such wwanX interfaces won't have L2 addresses, resulting in the dhcrelay daemon unable to use them.
I will try to propose a patchset to support such interfaces.Outstandinghttps://gitlab.isc.org/isc-projects/stork/-/issues/459Support for subnet 'names'2023-09-07T13:57:07ZVicky Riskvicky@isc.orgSupport for subnet 'names'several users have expressed an interest in having names for some subnets as well. These may be locations, building IDs, department codes or a combination.
They want this to come from Kea, from the configuration, so this requires a Kea c...several users have expressed an interest in having names for some subnets as well. These may be locations, building IDs, department codes or a combination.
They want this to come from Kea, from the configuration, so this requires a Kea change as well.
Users with a large number of subnets may also want to specify which subnets should be displayed on the dashboard, as there will be a few 'problem' subnets and those may not - probably will not be, the largest subnets.
This is the last remaining issue from GL #374, notes from the second user testbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1559doc: picking the right redundancy solution (HA vs shared database)2024-03-21T12:23:39ZTomek Mrugalskidoc: picking the right redundancy solution (HA vs shared database)Once the situation with MySQL group replication improves (see #1411, #593 and #980) and we get more experience with running Kea with a cluster, we should document this a possible alternative for HA.
Support and sales are vitally interes...Once the situation with MySQL group replication improves (see #1411, #593 and #980) and we get more experience with running Kea with a cluster, we should document this a possible alternative for HA.
Support and sales are vitally interested in this. Hence the customer label.
At various times it was commented that the decision tree for recently added in host reservation docs is very useful. Regardless if this ends up as a KB article or part of Kea ARM, there should be a decision tree helping the reader to navigate through available options.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/1547custom option examples2022-11-02T15:10:19ZTomek Mrugalskicustom option examplesWe should improve the custom option examples. Here are some requests:
1. [custom option 191](https://lists.isc.org/pipermail/kea-users/2019-November/002570.html)We should improve the custom option examples. Here are some requests:
1. [custom option 191](https://lists.isc.org/pipermail/kea-users/2019-November/002570.html)backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2268RFC 8914 - Extended error for No Reachable Authority2023-07-11T10:01:59ZVicky Riskvicky@isc.orgRFC 8914 - Extended error for No Reachable AuthorityAnother error message support would like to see sooner is
22 - No Reachable AuthorityAnother error message support would like to see sooner is
22 - No Reachable Authorityhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2254named.conf man page formatting2023-11-01T07:33:03ZTom Marcoennamed.conf man page formattingThe ''named.conf'' man page displays the comment styles in the DESCRIPTION as:
```
C style: /* */
C++ style: // to end of line
Unix style: # to end of line
```
is this weird spacing intentional? I would expect it to be:
```
C style...The ''named.conf'' man page displays the comment styles in the DESCRIPTION as:
```
C style: /* */
C++ style: // to end of line
Unix style: # to end of line
```
is this weird spacing intentional? I would expect it to be:
```
C style: /* */
C++ style: // to end of line
Unix style: # to end of line
```
The code in the man page is:
```
.sp
C style: /* */
.INDENT 0.0
.INDENT 3.5
C++ style: // to end of line
.UNINDENT
.UNINDENT
.sp
Unix style: # to end of line
```
Perhaps it can be changed to:
```
.sp
C style: /* */
.INDENT 0.0
C++ style: // to end of line
.UNINDENT
.INDENT 0.0
Unix style: # to end of line
.UNINDENT
```
PS: This man page appears to be missing from the appendix of the ARM (v9.16.8).