ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-03-14T14:36:20Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3273Upgrade schema on startup2024-03-14T14:36:20ZAndrei Pavelandrei@isc.orgUpgrade schema on startupKea could have a boolean database-level configuration knob with a default of false that, when enabled, makes the schema be upgraded on startup.
Should be straightforward to do following the work on automatic database init in issue 3025.Kea could have a boolean database-level configuration knob with a default of false that, when enabled, makes the schema be upgraded on startup.
Should be straightforward to do following the work on automatic database init in issue 3025.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3272Refactor ProcessSpawn2024-03-14T14:34:16ZAndrei Pavelandrei@isc.orgRefactor ProcessSpawnThere are a few things that could be improved in the ProcessSpawn implementation. They become more apparent now that the synchronous functionality has been added to it, but the issues were present before too.
- The asynchronous implemen...There are a few things that could be improved in the ProcessSpawn implementation. They become more apparent now that the synchronous functionality has been added to it, but the issues were present before too.
- The asynchronous implementation of ProcessSpawn relies on having a global IO signal set and on having the IO service being periodically polled in order to wait for child processes which is why it uses the main IO service. For this reason:
- There needs to be a dedicated AsyncProcessSpawn class that should be a singleton to signal to the developer that it has global dependency objects.
- There needs to be a method in AsyncProcessSpawn that sets the IO service. It needs to be callable only once and called as close as possible to the creation of the main IO service. Spawning would throw if the IO service is not initialized. This is to avoid the current behavior which sets the IO service on the first ProcessSpawn creation which could be on a null IOServicePtr. See `src/hooks/dhcp/run_script/run_script.cc` or `src/hooks/dhcp/forensic_log/rotating_file.cc`.
- There should be a new class encapsulating the synchronous implementation, say `SyncProcessSpawn`. It does not have to be a singleton since waiting for the child process is done in the scope it was declared, and the object can be safely deleted afterwards.
- It is worth considering to change the sync variant to use an IO signal set and an IO service like the async variant, but these should not be global, but declarable by the developer, or even better, hidden by the implementation.
- The dismiss feature in spawn is not used in code. I suggest removing it.
- The async process spawn is currently fire-and-forget. It would be nice for the async process spawn to have the ability to be notified that the process has finished and that its status is available. Maybe with the help of a condition variable?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3220Debian apt repository setup installs `apt-transport-https` dummy package2024-03-14T14:31:13ZDirk HeinrichsDebian apt repository setup installs `apt-transport-https` dummy packagePlease stop installing that package. It's a dummy since Debian Buster/Ubuntu 18.04.Please stop installing that package. It's a dummy since Debian Buster/Ubuntu 18.04.outstandingTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/4636rndc.py got 'NotImplementedError: Wrong message version'2024-03-14T12:25:47Zbino oetomorndc.py got 'NotImplementedError: Wrong message version'dear All.
I'm trying to delete a zone in catalog zone using python.
the script is adopted (to Python 3.9.2) from catz-del.py of https://kb.isc.org/docs/aa-01401
here is the script.
```
import sys
import os
import isc
import dns.query
i...dear All.
I'm trying to delete a zone in catalog zone using python.
the script is adopted (to Python 3.9.2) from catz-del.py of https://kb.isc.org/docs/aa-01401
here is the script.
```
import sys
import os
import isc
import dns.query
import dns.update
import dns.name
import hashlib
ZONEPATH='/var/cache/bind/'
MASTERS=['192.168.1.101']
SERVER = '192.168.8.78'
DNSPORT=53
RNDCPORT=9953
RNDCALGO='sha256'
RNDCKEY='1234abcd8765'
CATZONE='catalog.example'
PTR_EXPIRE = 31622400
PRIMARIES = ';'.join(MASTERS)
def hashzones(domain):
hash = hashlib.sha1(dns.name.from_text(domain).to_wire()).hexdigest()
return f'{hash}.zones'
def del_zone(name):
# Update catalog zone
update = dns.update.Update(CATZONE)
update.delete(f'{hashzones(name)}','ptr')
response = dns.query.tcp(update, SERVER, port=DNSPORT)
if response.rcode() != 0:
raise Exception(f"Error updating catalog zone: {response.rcode()}" )
# Delete zone from primary using RNDC
r = isc.rndc((SERVER, DNSPORT), RNDCALGO, RNDCKEY)
response = r.call(f'delzone {name}')
if response['result'] != b'0':
raise Exception(f"Error deleting zone from primary: {response['err']}" )
del_zone(sys.argv[1])
```
I Got error when try to run it
```
(venv) debian@risetdns01:~/catzman$ python ./delzone.py domain20.bino
Traceback (most recent call last):
File "/home/debian/catzman/./delzone.py", line 40, in <module>
del_zone(sys.argv[1])
File "/home/debian/catzman/./delzone.py", line 35, in del_zone
r = isc.rndc((SERVER, DNSPORT), RNDCALGO, RNDCKEY)
File "/home/debian/catzman/isc/rndc.py", line 54, in __init__
self.__connect_login()
File "/home/debian/catzman/isc/rndc.py", line 158, in __connect_login
msg = self.__command(type="null")
File "/home/debian/catzman/isc/rndc.py", line 139, in __command
raise NotImplementedError("Wrong message version %d" % version)
NotImplementedError: Wrong message version 2147549184
```
while from my bind9 log file, I got
```
13-Mar-2024 22:35:29.991 update: info: client @0x7ff0a4030080 192.168.8.78#33920: updating zone 'catalog.example/IN': deleting rrset at '5858ea66ec75231963ecb03723e1ce3295e23349.zones.catalog.example' PTR
13-Mar-2024 22:35:29.991 client: debug 1: client @0x7ff0a40322c0 192.168.8.78#33926: message parsing failed: bad label type
```
my isc python module version '9.16.48-Debian'
Its /usr/lib/python3/dist-packages/isc/__init__.py since it cannot accessed directly when I use venv
My named details :
```
root@risetdns01:~# named -V
BIND 9.16.48-Debian (Extended Support Version) <id:0dab57e>
running on Linux x86_64 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/reproducible-path/bind9-9.16.48=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 10.2.1 20210110
compiled with OpenSSL version: OpenSSL 1.1.1w 11 Sep 2023
linked to OpenSSL version: OpenSSL 1.1.1w 11 Sep 2023
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
Problem is not occur with 'add zone'
Kindly please tell me what to check or do to fix this problem.
sincerely
-bino-https://gitlab.isc.org/isc-projects/stork/-/issues/1333Incorrect error handing of the bind9 app state causes no transition to the in...2024-03-14T12:23:22ZMarcin SiodelskiIncorrect error handing of the bind9 app state causes no transition to the inactive stateThe `GetAppState()` logic returns early when communication with named fails. As a result, the info about the app is not updated in the database. So, for example, the active flag remains true, while it should be put to false. The daemon a...The `GetAppState()` logic returns early when communication with named fails. As a result, the info about the app is not updated in the database. So, for example, the active flag remains true, while it should be put to false. The daemon appears to be online in the UI even though there is no connection to it.https://gitlab.isc.org/isc-projects/kea/-/issues/1738Improve VLAN filtering for raw sockets2024-03-14T10:45:38ZTomek MrugalskiImprove VLAN filtering for raw socketsThere were several reports of users struggling with mixed VLAN setups: some interfaces are physical and some are tagged:
* https://lists.isc.org/pipermail/kea-users/2020-February/002619.html (the discussion is long)
The goal of this ti...There were several reports of users struggling with mixed VLAN setups: some interfaces are physical and some are tagged:
* https://lists.isc.org/pipermail/kea-users/2020-February/002619.html (the discussion is long)
The goal of this ticket is to extend the LPF/BPF code to better handle tagged packets.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1117Mix of physical and virtual interfaces (VLAN) does not work2024-03-14T10:45:38ZTalkaboutMix of physical and virtual interfaces (VLAN) does not work**Describe the bug**
Setting up KEA DHCP server on a system to listen to a physical interface and one or multiple virtual interfaces causes wrong IP pools to be assigned.
**To Reproduce**
Steps to reproduce the behavior:
1. Set up a vir...**Describe the bug**
Setting up KEA DHCP server on a system to listen to a physical interface and one or multiple virtual interfaces causes wrong IP pools to be assigned.
**To Reproduce**
Steps to reproduce the behavior:
1. Set up a virtual interface as VLAN interface connected to a physical interface
2. Configure KEA DHCP server to listen to physical interface and virtual interface in "raw" mode
3. Try to request an IP from the pool assigned to the VLAN
4. KEA DHCP server gets confused and handles the request on both devices advertising different ips
**Expected behavior**
Proper IP pools should be assigned. VLAN requests must not be handled on physical device.
**Environment:**
- Kea version: 1.6.1
- OS: Debian 10
- Which features were compiled in (in particular which backends): mysql
- If/which hooks where loaded in: libdhcp_stat_cmds.so, libdhcp_ha.so, libdhcp_lease_cmds.so
**Additional Information**
Config file:
```
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth0", "eth0.30", "eth0.50", "eth0.100" ],
"dhcp-socket-type": "raw"
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea4-ctrl-socket"
},
"lease-database": {
…
},
"hosts-database": {
…
},
"sanity-checks": {
"lease-checks": "fix-del"
},
"valid-lifetime": 28800,
"rebind-timer": 21600,
"subnet4": [
{
"pools": [
{
"pool": "192.168.20.100-192.168.20.200"
}
],
"id": 1,
"subnet": "192.168.20.0/24",
"interface": "eth0",
"option-data": [
…
]
},
{
"pools": [
{
"pool": "192.168.30.100-192.168.30.200"
}
],
"id": 30,
"subnet": "192.168.30.0/24",
"interface": "eth0.30",
"option-data": [
…
]
},
{
"pools": [
{
"pool": "192.168.50.100-192.168.50.200"
}
],
"id": 50,
"interface" : "eth0.50",
"subnet": "192.168.50.0/24",
"option-data": [
…
]
},
{
"pools": [
{
"pool": "192.168.100.100-192.168.100.200"
}
],
"id": 100,
"subnet": "192.168.100.0/24",
"interface": "eth0.100",
"option-data": [
…
]
}
],
"hooks-libraries": [
…
],
"loggers": [
…
]
}
}
```
Currently I have a temporary solution in place by creating a "macvlan" device (also virtual) to handle traffic from the physical device. But this is not an optimal solution.
**Contacting you**
talk.about@gmx.deoutstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1550[ISC-support #15905] rndc stop issued after server (or single zone) rndc relo...2024-03-13T21:08:58ZCathy Almond[ISC-support #15905] rndc stop issued after server (or single zone) rndc reload and during ixfr-from-differences processing leaves the .jnl file corruptedFrom Support ticket [#15905](https://support.isc.org/Ticket/Display.html?id=15905)
9.11.x (but I don't anticipate that the BIND version makes any difference)
This problem is readily reproducible (and, I suspect, occurs because "rndc st...From Support ticket [#15905](https://support.isc.org/Ticket/Display.html?id=15905)
9.11.x (but I don't anticipate that the BIND version makes any difference)
This problem is readily reproducible (and, I suspect, occurs because "rndc stop" doesn't recognise that the zone is effectively 'dynamic' because it has been reloaded with 'ixfr-from-differences yes;').
Here's what is being done, per the server logs. First the reload (the outcome is also the same with 'reload zone'):
```
09-Jan-2020 14:50:29.157 general: info: received control channel command 'reload' ============>>> RELOAD COMMAND
09-Jan-2020 14:50:29.179 general: info: loading configuration from '/etc/named.conf'
... etcetera
09-Jan-2020 14:50:29.202 general: info: reloading configuration succeeded
09-Jan-2020 14:50:29.202 general: info: reloading zones succeeded
09-Jan-2020 14:50:29.202 general: notice: all zones loaded
09-Jan-2020 14:50:29.202 general: notice: running
```
Note that the reload has completed, as far as the logging is concerned, but, it would appear that the regeneration of the .jnl files via 'ixfr-from-differences yes;' has not (high CPU use by named - suggests that it is busy doing this).
Then the 'rndc stop' is issued - and it completes almost immediately (no evidence that it is waiting for the processing to complete), in fact, it seems to log that it has aborted a zone reload, even though the previous logging said that the reload *had* completed:
```
09-Jan-2020 14:50:33.211 general: info: received control channel command 'stop -p'
09-Jan-2020 14:50:33.212 general: info: shutting down: flushing changes
.. etcetera (just the logs of the various sockets being closed here)
09-Jan-2020 14:50:33.216 general: error: zone test.com/IN: loading from master file dynamic/test.com.zone failed: operation canceled
09-Jan-2020 14:50:33.216 general: error: zone test.com/IN: not loaded due to errors.
09-Jan-2020 14:50:34.265 general: notice: exiting
```
And then after this, restarting named - the zone can no longer be loaded - the journal file does not tally with the zone itself:
```
...
09-Jan-2020 14:51:28.141 general: error: zone test.com/IN: journal rollforward failed: journal out of sync with zone
09-Jan-2020 14:51:28.141 general: error: zone test.com/IN: not loaded due to errors.
09-Jan-2020 14:51:28.142 general: notice: all zones loaded
09-Jan-2020 14:51:28.142 general: notice: running
```
======
Something has gone badly wrong during the 'rndc stop' - which is supposed to be a graceful shutdown of named. I'm assuming that the problem is that the .jnl file itself is corrupt, rather than that something has happened to the zone file on disk - but will ask for more data to confirm this.
```
stop [-p]
Stop the server, making sure any recent changes made through dynamic update
or IXFR are first saved to the master files of the updated zones. If -p is
specified named’s process id is returned. This allows an external process
to determine when named had completed stopping.
```
Now, since ixfr-from-differences processing could take an age to complete, I don't think it's reasonable to wait forever on the rndc stop. Possibly one solution would be have a (configurable?) timeout, after which any pending ixfr-from-differences .jnl file generation is terminated and the incomplete .jnl file discarded/removed. After all, the administrator in this scenario has just presented named with a new zone file that it asked named to load - so we know that the full copy of the zone on disk should be good and valid - we just loaded from it.
====
The workaround if this happens, is presumably to manually discard the corrupted .jnl file and restart named.Not plannedhttps://gitlab.isc.org/isc-projects/stork/-/issues/1261The list tab link doesn't include the already specified filter2024-03-13T18:41:07ZSlawek FigielThe list tab link doesn't include the already specified filterThe list tab link doesn't include the already specified filter.
![image](/uploads/975779709fab2fb25c2959373d7d2081/image.png)
After clicking on it, the list presents non-filtered results, although the filter is still specified.
![imag...The list tab link doesn't include the already specified filter.
![image](/uploads/975779709fab2fb25c2959373d7d2081/image.png)
After clicking on it, the list presents non-filtered results, although the filter is still specified.
![image](/uploads/946de8fa616032c96e97f1157e526afa/image.png)1.16https://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/bind9/-/issues/826EDNS tag for triggering forwarding2024-03-13T13:33:46ZVicky Riskvicky@isc.orgEDNS tag for triggering forwarding### Description
Some BIND users, specifically enterprise users, want to forward a subset of their queries to a specialized resolver. The primary purpose is to enable some additional proprietary filtering policy that is enforced on the s...### Description
Some BIND users, specifically enterprise users, want to forward a subset of their queries to a specialized resolver. The primary purpose is to enable some additional proprietary filtering policy that is enforced on the specialized resolver. This policy may be updated frequently, and therefore it is preferable that the BIND server not cache these responses, but always forward queries that have this tag.
Requests that we have seen include forwarding queries from users in specific departments that may have different security requirements.
Currently, you can configure BIND to either forward globally or you create "forward zones" (which aren't really zones at all but only look that way in the configuration) to forward specific domains - and all subdomains that don't have local configuration overriding the forwarding. What we would like is to add a DNS extension (EDNS additional information) on individual queries to direct the BIND resolver to forward those queries. This would have to work along side the existing more general forward zones.
### Request
* Design some additional EDNS option (does not need to be standardized)
* Add a configuration option to BIND to set up a list of EDNS options with associated forwarding instructions. (tags A, B & C -> forward to server 23, tags D & E, forward to server 24)
* When BIND receives a query with this EDNS option, check for the presence of a forwarding rule associated with that option. If there isn't one, ignore the option.
* Ideally, we would like the BIND resolver that gets the query with the EDNS option to forward the query and *not* cache the response.
* Of course, the EDNS option should be backwards compatible, so a BIND server that isn't configured for or doesn't support this option should be unaffected.
### Questions
* As Brian has added below, DNSMASQ already is adding some EDNS options to identify CPE, subnets, or MAC addresses. In an enterprise use case, can't rely on DNSMASQ to be present, so .... we need to also add the corresponding feature to BIND to ADD this EDNS option on some queries. **We need more user feedback about how to do this markup** - does an individual BIND server just put the same tag on every query it is resolving?
* Assuming it would be a big project to forward without also caching the responses, we need to consider the issues and effort in creating and maintaining such a 'simple forwarder' feature.
### Links / references
Related feature request for using EDNS option for selecting a filtering policy: https://gitlab.isc.org/isc-projects/bind9/issues/825https://gitlab.isc.org/isc-projects/bind9/-/issues/1916Check ECS response in DiG for RFC compliance2024-03-13T13:11:50ZMark AndrewsCheck ECS response in DiG for RFC complianceWe have seen servers that return ECS responses that don't meet this requirement.
```
RFC 7871, 7.2.1. Authoritative Nameserver
FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS in the response MUST match
those in the query. Echoing back ...We have seen servers that return ECS responses that don't meet this requirement.
```
RFC 7871, 7.2.1. Authoritative Nameserver
FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS in the response MUST match
those in the query. Echoing back these values helps to mitigate
certain attack vectors, as described in Section 11.
```
Add a warning when the ECS response fails to meet this requirement.Not plannedhttps://gitlab.isc.org/isc-projects/stork/-/issues/1010Hide "Authorize" button for non-super-admin users2024-03-13T10:34:59ZSlawek FigielHide "Authorize" button for non-super-admin usersThe issue was found by @slawek during 1.10 sanity checks. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/1009#note_364510).
The users in an `admin` role are not permitted to authorize machines, but the "Authorize" button is...The issue was found by @slawek during 1.10 sanity checks. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/1009#note_364510).
The users in an `admin` role are not permitted to authorize machines, but the "Authorize" button is presented for them. After clicking the button, the ugly error page is presented. The "Authorize" button should be hidden for users with the `admin` role.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/1318Change database for migrating hosts2024-03-12T08:19:13ZSlawek FigielChange database for migrating hostsBelow is our current database schema:
![image](/uploads/6ff3034985b96c7a7c984478bb4ff11d/image.png)
In this structure, it is impossible to recognize which Kea daemon holds a specific IP or hostname reservation.
So, we don't know on whi...Below is our current database schema:
![image](/uploads/6ff3034985b96c7a7c984478bb4ff11d/image.png)
In this structure, it is impossible to recognize which Kea daemon holds a specific IP or hostname reservation.
So, we don't know on which Kea daemon perform the migration.
I want to make the below changes:
- Replace the `ip_reservation` table's reference to `host` table with reference to `local_host`.
- Move the `hostname` column from `host` to `local_host` table
- (Optionally) Add a single-column primary key to the `local_host` table and add a unique index on the `host_id`, `data_source`, and `daemon_id` to preserve the existing constraints.1.16Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4348implement QPDB databases2024-03-08T23:38:09ZEvan Huntimplement QPDB databasesCreate QP-trie based databases to take the place of RBTDB, for use as a:
- [ ] zone database
- [ ] cacheCreate QP-trie based databases to take the place of RBTDB, for use as a:
- [ ] zone database
- [ ] cacheBIND 9.21.xEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/4626Repatedly hitting max-cache-size leads to all-SERVFAIL answers2024-03-08T17:59:30ZPetr Špačekpspacek@isc.orgRepatedly hitting max-cache-size leads to all-SERVFAIL answers### Summary
This needs proper investigation.
### BIND version affected
- v9.16.49-to-be
- v9.16.45 - even worse, response rate goes down
**Other versions were not tested** but I assume the same problem in other branches, too.
### Ste...### Summary
This needs proper investigation.
### BIND version affected
- v9.16.49-to-be
- v9.16.45 - even worse, response rate goes down
**Other versions were not tested** but I assume the same problem in other branches, too.
### Steps to reproduce
Run [resolver test pipeline](https://gitlab.isc.org/isc-projects/bind9-shotgun-ci/-/pipelines/new) with these settings:
1. SHOTGUN_SCENARIO = udp
2. SHOTGUN_TRAFFIC_MULTIPLIER = 10
3. SHOTGUN_DURATION = 600
4. CACHE_SIZE_MB = 64
This ridiculously overloads resolver with 64 MB cache and floods it with 100 k QPS.
### What is the current *bug* behavior?
Initially SERVFAIL rate spikes - that's okay, probably recursive clients limit - and then goes down - also expected. But then it goes up again to the point where the resolver only SERVFAILs (by the end of tenth minute).
![response-rate-rcodes.svg](/uploads/0f6cec19b3c2eba1d343803e1f1e4c23/response-rate-rcodes.svg)
Second problem is that response rate goes down from time to time. It should not drop answers. But that might be an artifact of the measurement - it uses 2 second timeout.
### What is the expected *correct* behavior?
Well, I would expect very roughly constant SERVFAIL rate.
### Relevant configuration files
Auto-generated by the pipeline. Recursive-clients = probably 10 000.
### Relevant logs
https://gitlab.isc.org/isc-projects/bind9-shotgun-ci/-/pipelines/166603 (artifacts retained for a while)
Have a look at charts v9.1*/results-shotgun/charts/response-rate-rcodes.svg in individual jobs.https://gitlab.isc.org/isc-projects/bind9/-/issues/4523dnstap support for new transport protocols2024-03-08T09:03:02ZPeter Daviesdnstap support for new transport protocols### Description
Feature Request: dnstap support for new transport protocols
### Request
Currently, BIND's dnstap implementation distinguishes between UDP and TCP based
dns traffic.
With BIND's support for DNS over TLS ...### Description
Feature Request: dnstap support for new transport protocols
### Request
Currently, BIND's dnstap implementation distinguishes between UDP and TCP based
dns traffic.
With BIND's support for DNS over TLS and DNS over HTTPS, users may wish to
differentiate between these transports in dnstap output.
### Links / references
The current dnstap protobuf lists support for DoT, DoH:
see https://github.com/dnstap/dnstap.pb/blob/master/dnstap.protoAydın MercanAydın Mercanhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4446deprecate --enable-fixed-rrset / rrset-order fixed2024-03-07T19:20:29ZPetr Špačekpspacek@isc.orgdeprecate --enable-fixed-rrset / rrset-order fixed### Discussion
I wonder if we should deprecate `configure --enable-fixed-rrset`? It seems that it might create trouble down the road when we try to improve database/node structure...
We don't have to touch it for QPDB in 9.20, but I th...### Discussion
I wonder if we should deprecate `configure --enable-fixed-rrset`? It seems that it might create trouble down the road when we try to improve database/node structure...
We don't have to touch it for QPDB in 9.20, but I think it will get in our way when we fix #3405.
### Proposal
Deprecate deprecate `configure --enable-fixed-rrset` / `rrset-order fixed` statement in 9.20, remove in 9.21.
### Links / referencesBIND 9.19.xhttps://gitlab.isc.org/isc-projects/kea/-/issues/3251Fix drop statistics in subnet6_select and RADIUS hook2024-03-07T14:55:13ZFrancis DupontFix drop statistics in subnet6_select and RADIUS hookThe pkt6-receive-drop is not correctly handled in the subnet6_select callout and the RADIUS hook adds another way to mess it.The pkt6-receive-drop is not correctly handled in the subnet6_select callout and the RADIUS hook adds another way to mess it.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3241Failed to start kea-dhcp if the interface defined in the interface-config lis...2024-03-07T14:54:35ZPranathi NandhigamFailed to start kea-dhcp if the interface defined in the interface-config list is unavailable even though some of the interfaces are upI have observed kea-dhcp failed to start when one of the interface defined in the "interface-config" list does not exist even though other defined interfaces are up and has usable IP address configured. May be dhcp server can be started ...I have observed kea-dhcp failed to start when one of the interface defined in the "interface-config" list does not exist even though other defined interfaces are up and has usable IP address configured. May be dhcp server can be started with the interfaces which are up instead of refusing to start until all interfaces defined in the list comes up.
From code snippet below
void IfacesConfigParser::parseInterfacesList(const CfgIfacePtr& cfg_iface, ConstElementPtr ifaces_list) {
for (auto const& iface : ifaces_list->listValue()) {
std::string iface_name = iface->stringValue();
try {
cfg_iface->use(protocol_, iface_name);
} catch (const std::exception& ex) {
isc_throw(DhcpConfigError, "Failed to select interface: "
<< ex.what() << " (" << iface->getPosition() << ")");
}
}
}
Here if interface is not found instead of raising an exception, it can be a warning and can be proceeded with other interfaces in the list. I am not sure how feasible it is and its side effect.next-stable-3.0