ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2019-02-07T17:00:17Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/445add support for mongo db2019-02-07T17:00:17ZGhost Useradd support for mongo db---
name: mongodb
about: add mongodb support to kea dhcp server
---
**Some initial questions**
- could not find this request anywhere in issues or on the web
- sure, there are other databases support; but that's not the point
**Is you...---
name: mongodb
about: add mongodb support to kea dhcp server
---
**Some initial questions**
- could not find this request anywhere in issues or on the web
- sure, there are other databases support; but that's not the point
**Is your feature request related to a problem? Please describe.**
- Reduction of the numbers of databases on the client's systems
**Describe the solution you'd like**
- allow kea administrators to configure mongodb in kea
**Describe alternatives you've considered**
- Not really.
**Additional context**
- No.
**Funding its development**
- Sure to some very small degree.
**Participating in development**
- design discussions and testing
**Contacting you**
- Private messages to my gitlab.isc.org registered email address are fine.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/449Create AuditRevision object to carry supplementary information for audit entries2020-09-10T15:49:35ZMarcin SiodelskiCreate AuditRevision object to carry supplementary information for audit entriesThe CB database includes `dhcp4_audit_revision` table which holds general information about the changes applied in the database. Currently it holds a timestamp and the log message. The timestamp is and will remain being generated automat...The CB database includes `dhcp4_audit_revision` table which holds general information about the changes applied in the database. Currently it holds a timestamp and the log message. The timestamp is and will remain being generated automatically. The log message is also generated automatically at the moment but the idea is to be able to specify the log message in the command. Some examples can be found here:
https://gitlab.isc.org/isc-projects/kea/wikis/designs/configuration-in-db-design#configuration-management
In the future we may store more information in the revision table. For example: name of the user who applied a change, IP address from which the command has been sent etc. This information must be encapsulated in a new object, e.g. AuditRevision and passed via the CB API to the commands that modify the information in the database, i.e. set and del commands.
Even though we could postpone this change to later Kea release, it may be actually better to add it now to keep the API stable in next releases.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/450Populate log messages from the cb_cmds to the database2020-09-10T15:50:03ZMarcin SiodelskiPopulate log messages from the cb_cmds to the databaseAssuming that we do #449, we then have to extend the cb_cmds hooks library to actually use the log messages conveyed in the control commands to the database through the AuditRevision objects.Assuming that we do #449, we then have to extend the cb_cmds hooks library to actually use the log messages conveyed in the control commands to the database through the AuditRevision objects.outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/455lazy catalog zone configuration makes a server lame2021-10-04T13:05:00ZTony Finchlazy catalog zone configuration makes a server lameI restarted my test server while another task was frequently repeating several queries; the server got stuck in a funny state where it would SERVFAIL these queries persistently.
tl;dr: I think this problem might affect normal authoritat...I restarted my test server while another task was frequently repeating several queries; the server got stuck in a funny state where it would SERVFAIL these queries persistently.
tl;dr: I think this problem might affect normal authoritative servers that use catalog zones: there's a chance that lazy zone configuration might cause the server to return referrals rather than proper answers during startup, leading it to being unfairly marked lame by recursive servers for 10 minutes.
I reproduced this with vanilla 9.12.2 and a simplified configuration. The setup is:
* an auth view, containing:
* a catalog zone listing all our local zones
* a local root zone
* a rec view, containing:
* static-stub zone configurations for all the auth zones pointing at the auth view
If I make frequent queries for `cam.ac.uk` while the server starts, it usually gets into this SERVFAIL state.
When a cam.ac.uk query happens while the server is starting (before catz configuration is complete), the rec view gets a referral from the root in the auth view. It then decides to mark the auth view as lame for cam.ac.uk, so everything is broken for 10 minutes (the `lame-ttl`).
If there's no root zone, the rec view gets REFUSED; it SERVFAILs a few queries while the server is starting but it doesn't mark the auth view as lame - surprisingly, REFUSED is treated a lot more gently than an unexpected referral.
I can trigger the same problem with *only* the catalog zone, with no root zone, but in this case it is harder to lose the race. If I repeatedly query for www.cl.cam.ac.uk, and the server loads `cam.ac.uk` before `cl.cam.ac.uk`, then it can get a referral instead of the expected answer.
```
while sleep 0.05; do dig +tries=1 +timeout=1 @::1 www.cl.cam.ac.uk | grep status & done
```
I can't trigger the same effect with explicitly configured zones, i.e. if I replace the auth view configuration with `include "../etc/named.slave"`.
These attachments have the relevant config; I can provide access to a VM if you want to try this config out for yourselves.
[named.conf](/uploads/9e077f0e27f49446462fc93010243728/named.conf)
[make-static-stub](/uploads/08300990a5b352629e8cc2efa57e9c2a/make-static-stub)https://gitlab.isc.org/isc-projects/bind9/-/issues/459[RT 39964] logging of NXDOMAIN query-responses (response source and type)2024-03-13T13:46:50ZVicky Riskvicky@isc.org[RT 39964] logging of NXDOMAIN query-responses (response source and type)Edited/compressed from the original in classic bugs-RT
for analyzing queries resulting in NXDOMAIN responses...
Please add the following to normal query log:
a) what kind of answer was given (nxrrset, rrset (how many) or servfail)
b) w...Edited/compressed from the original in classic bugs-RT
for analyzing queries resulting in NXDOMAIN responses...
Please add the following to normal query log:
a) what kind of answer was given (nxrrset, rrset (how many) or servfail)
b) where did the answer came from (authorative, from cache or was it the result of a recursive search)
The actual content of the answer is not needed outside some very special debug-cases and for these cases you have to do a complete network trace anyway.
spawned from #39253: dnstap wish-list: Query log limited by zone/domain & Answer logging
Reference to https://support.isc.org/Ticket/Display.html?id=8385 added
----
* This is response, not query information
<from Ray>
NB: recording these either means two separate log entries (one for query, one for response) or if they're merged that the query log will now be in response order rather than request order.
------
This request is for 'normal' query logging, but many have asked for this via **dnstap** as well. We would love to get this in dnstap if that is possible, realizing there is a standards/schema issue with dnstap.
------
Tagging with 9.13.3 because we would really like to try for this in 9.14.0. This is a fairly long standing and frequently-heard request.Not plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/472Documentation about congestion recovery2020-09-10T15:52:00ZFrancis DupontDocumentation about congestion recoveryTwo points:
- make clearer that the congestion recovery is not congestion avoidance (or any variant in terms which can suggest it) in the documentation
- findings about the impact on performance of the congestion recovery.Two points:
- make clearer that the congestion recovery is not congestion avoidance (or any variant in terms which can suggest it) in the documentation
- findings about the impact on performance of the congestion recovery.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/475extend kea-admin with option to install/update yang models2021-06-18T09:35:04ZWlodzimierz Wencelextend kea-admin with option to install/update yang modelskea-admin is capable to handle mysql/pgsql/cql when it comes to leases and HR. And right now work on config backend will extend it for configuration storage. We should also extend it to handle yang models.kea-admin is capable to handle mysql/pgsql/cql when it comes to leases and HR. And right now work on config backend will extend it for configuration storage. We should also extend it to handle yang models.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/479HA peer should drop leases not present on the partner during sync2022-11-02T15:10:19ZMarcin SiodelskiHA peer should drop leases not present on the partner during syncLet's suppose there are two HA peers A and B. The peer B dies. While the peer B is offline, the admin sends `lease4-del` command to the A. The peer B starts up and synchronizes its lease database with A. It correctly adds new leases and ...Let's suppose there are two HA peers A and B. The peer B dies. While the peer B is offline, the admin sends `lease4-del` command to the A. The peer B starts up and synchronizes its lease database with A. It correctly adds new leases and updates existing leases based on the list received from A. However, it doesn't remove the lease deleted on A while it was offline. The server admin would need to send `lease4-del` command to B to remove the lease.
In order to address this problem we have to fetch all leases from the B's backend and iterate over them to see if they are also present on A. In order to do so, we will have to keep the local copy of leases received from A. For Memfile, MySQL and Postgres we could do it more efficiently by comparing ranges of leases as they are ordered by IP addresses. After comparing a range of leases we could simply drop the local copy of the lease ranges. However, this won't work for Cassandra which returns leases out of order. In the Cassandra case we will have to collect all leases returned by the peer.backlogMarcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/482perfdhcp avalanche: more research needed for selecting proper periods for che...2022-11-02T15:10:19ZMichal Nowikowskiperfdhcp avalanche: more research needed for selecting proper periods for checking resending packetsCurrently this is 200ms. It was choosen based on experiments.
The whole scenario times were more less the lowest between 50ms and 200ms.
This issue reflects review comment: https://gitlab.isc.org/isc-projects/kea/merge_requests/237#note...Currently this is 200ms. It was choosen based on experiments.
The whole scenario times were more less the lowest between 50ms and 200ms.
This issue reflects review comment: https://gitlab.isc.org/isc-projects/kea/merge_requests/237#note_45247
This time is located in avalanche_scen.cc file, in run() method.backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/497[ISC-support #13383] Add RRset size-limiting option to protect masters from r...2024-02-20T10:59:13ZCathy Almond[ISC-support #13383] Add RRset size-limiting option to protect masters from rogue dynamic updates and slaves from damaging IXFR/AXFRsBased on https://support.isc.org/Ticket/Display.html?id=13383
The issue is that although the DNS protocol does not restrict how many RRs can exist in a single RRset, once the number of RRs becomes significantly large, both dynamic updat...Based on https://support.isc.org/Ticket/Display.html?id=13383
The issue is that although the DNS protocol does not restrict how many RRs can exist in a single RRset, once the number of RRs becomes significantly large, both dynamic updates and inbound IXFRs become highly CPU-intensive and performance degrading. Encountering oversized RRsets in a production environment is almost certainly the result of a rogue client or poorly-considered configuration/design, but the outcome for any DNS servers having to maintain oversized RRsets can be a significantly degraded performance.
(This scenario is similar to the one that led to the introduction of BIND option max-rrset which protects servers that are hosting zones provided by 3rd parties from being overwhelmed unexpectedly by a zone that unexpectedly becomes of significant size - more than the hosting server can handle).
---
Some more background information to the case leading to this request is that it was observed in a zone that has an RRset consisting of 4K RRs of type A for the same hostname, that adding a new RR with a different TTL can take in excess of several seconds and the task performing the update consumes a significant amount of CPU doing so.
The reason why adding an additional RR causes so much internal zone maintenance activity is complex, but it is directly due to the TTL change and what this implies for maintenance of the .jnl file (used both to satisfy outbound IXFR requests, and for rolling forward/loading the zone locally, in case of an unexpected interrupt of named (a normal rndc stop will write the current version of the zone to disk, but a sigterm or crash won't - although see option flush-zones-on-shutdown which defaults to "no" that can influence this).
When the TTL of one of the RRset changes, it results in all of the other RRs in the set having to be updated to adopt the new TTL at the same time (a difference in TTL between the members of the same RRset is not permitted). Although the TTL is stored on a per-RRset basis internal to BIND, this is, unfortunately, not the end of the story. When the RRset is being updated, named has to generate the set of zone content changes for the .jnl file - and it's here that this becomes, not a single RR add, but the deletion of 4K RRs and the addition of 4K+1 RRs. And this is what drives named doing exactly this when it adds this new RRset itself to its zone.
However, this gets worse (and this next part explains why the maintenance of large RRsets increases exponentially rather than linearly). When you add a RR to a pre-existing RRset, in order to prevent duplicates, for each 'add' named has to check the new candidate against all of the other RRs already in the set. So, when adding the 200th, we have to check it against 199 others, but for the 4001th, it's checking against 4000 others.
Yes, potentially we could optimise this internally for the single case where we know we've checked the one RR that we're adding, on the basis that we know the only reason we're doing 4K deletes and adds is to change the TTL on the whole lot, but that really we're just adding one new RR. But that is not going to help a slave server receiving an IXFR of the same update, and it's not going to help this server if it needs to reload/replay the zone update from the .jnl file if it gets interrupted.
So similarly, just accepting an IXFR for a zone with 4K+ new RRs to be added to a single RRset is also going to impact named, irrespective of the TTLs on those RRs. (Basically, oversized RRsets are bad news for a server that is properly checking the contents of zones that it is loading/updating).
---
Therefore, going back to the request for a new option... it's clearly bordering on insane to have RRsets of this size - DNS certainly wasn't designed to handle them (think of the query responses and the clients!) and BIND certainly wasn't optimised internally for this extreme scenario. Therefore, please could we have a new option (with sane defaults on a per-RTYPE basis) to prevent accidental craziness that degrades performance.
Something like:
max-rrset [rrtype] integer;
(Defaults to be discussed... but they're potentially going to be different for PTR vs other RTYPEs).Not plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/501remote-option4-global-set accepts option with empty data2022-10-24T08:02:55ZWlodzimierz Wencelremote-option4-global-set accepts option with empty data```
{
"arguments": {
"options": [
{
"code": 6
}
],
"remote": {
"type": "mysql"
},
"server-tags": [
"abc"
]
},
"command": "remote-option4-global-set"
}
```
Response:
```
{
"a...```
{
"arguments": {
"options": [
{
"code": 6
}
],
"remote": {
"type": "mysql"
},
"server-tags": [
"abc"
]
},
"command": "remote-option4-global-set"
}
```
Response:
```
{
"arguments": {
"options": [
{
"code": 6,
"space": "dhcp4"
}
]
},
"result": 0,
"text": "DHCPv4 option successfully set."
}
```
Kea should not be configured with empty option. Possible that it's not yet implemented.outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/505experimental implementation of draft-ietf-dnsop-update-timeout2020-07-29T10:33:06ZMark Andrewsexperimental implementation of draft-ietf-dnsop-update-timeouthttps://tools.ietf.org/html/draft-ietf-dnsop-update-timeouthttps://tools.ietf.org/html/draft-ietf-dnsop-update-timeoutMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/kea/-/issues/513Verify that subnets in a shared network sanity checks are performed for confi...2020-06-04T15:44:52ZFrancis DupontVerify that subnets in a shared network sanity checks are performed for config updates outside the JSON config file.Reference https://gitlab.isc.org/isc-projects/kea/merge_requests/242#note_46769
Note this should be addressed only when the CB train will be merged.Reference https://gitlab.isc.org/isc-projects/kea/merge_requests/242#note_46769
Note this should be addressed only when the CB train will be merged.outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/534Allow only DNS64 reverse zone to be configured independently of the DNS64 clause2023-10-08T12:48:08ZMark AndrewsAllow only DNS64 reverse zone to be configured independently of the DNS64 clausedns64 currently configures both the DNS64 synthesis and a DNS64 reverse zone.
If a customer is using RFC 7050 (IPV4ONLY.ARPA) or some other mechanism to publish the NAT64 prefix but not DNS64 the reverse zone synthesis is still needed.dns64 currently configures both the DNS64 synthesis and a DNS64 reverse zone.
If a customer is using RFC 7050 (IPV4ONLY.ARPA) or some other mechanism to publish the NAT64 prefix but not DNS64 the reverse zone synthesis is still needed.https://gitlab.isc.org/isc-projects/bind9/-/issues/536Add a MacOS instance to CI2021-10-15T12:32:03ZMark AndrewsAdd a MacOS instance to CIWe had a build failure on MacOS committed due to MacOS not being part of CI.We had a build failure on MacOS committed due to MacOS not being part of CI.https://gitlab.isc.org/isc-projects/kea/-/issues/541auto-generated config parsing tests are currently limited to "Dhcp4Parser*.*"2019-08-08T16:20:44ZThomas Markwalderauto-generated config parsing tests are currently limited to "Dhcp4Parser*.*"The following discussion from !254 should be addressed:
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/254#note_48600): (+4 comments)
> Now that you trained me how to re-generate the un...The following discussion from !254 should be addressed:
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/254#note_48600): (+4 comments)
> Now that you trained me how to re-generate the unit tests in get_config_unittests.cc I wonder if enabling this test that calls `extractConfig` should result in re-generating the tests?outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/542add support for ccache in Hammer for virtualbox provider2022-12-28T11:23:06ZMichal Nowikowskiadd support for ccache in Hammer for virtualbox providerbecause for now it only works for LXCbecause for now it only works for LXCoutstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/554RFC 7901 CHAIN Query Requests in DNS2018-09-24T15:42:30ZVicky Riskvicky@isc.orgRFC 7901 CHAIN Query Requests in DNS### Description
APNIC would like to see us support RFC 7901. Specifically, the desired application is for using DANE for pinning the CA certificate.
### Request
Implement RFC 7901 in BIND, for TCP or UDP connections with valid cookies...### Description
APNIC would like to see us support RFC 7901. Specifically, the desired application is for using DANE for pinning the CA certificate.
### Request
Implement RFC 7901 in BIND, for TCP or UDP connections with valid cookies only. Note that this is experimental, although it is an RFC.
### Links / references
https://tools.ietf.org/html/rfc7901https://gitlab.isc.org/isc-projects/kea/-/issues/554Speedup subnet selection2022-11-02T15:10:18ZFrancis DupontSpeedup subnet selectionFirst we use a selector structure where all possible keys are (so not the query itself), second the most interesting key is the source address of the query (interesting here means mainly the key which should not change between two querie...First we use a selector structure where all possible keys are (so not the query itself), second the most interesting key is the source address of the query (interesting here means mainly the key which should not change between two queries from the same or similar clients.
So I propose to cache selector => subnet selection results in a hash table (unordered multi map) keyed by the source address.
Note as this can slow down things where there are a few subnets conditions of use, cache sizing, etc, should be analyzed (so it is an **idea**).
Changed for a more global research of subnet selection speedup.backlogFrancis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea-quick-config/-/issues/10remove PHP from the project2023-07-12T20:08:35ZDarren Ankneyremove PHP from the projectre-implement the validation of the steps (and associated helper functions) in javascript so that PHP will not be required for the project. As a side effect, a web server would no longer be required for the project to work.re-implement the validation of the steps (and associated helper functions) in javascript so that PHP will not be required for the project. As a side effect, a web server would no longer be required for the project to work.future