BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-02-14T17:13:53Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4505Implement kTLS support in BIND2024-02-14T17:13:53ZArtem BoldarievImplement kTLS support in BIND
Recent versions of Linux and FreeBSD support TLS encryption by kernel (kTLS). One of the benefits of it is that when TLS encryption is performed by kernel, it might use additional hardware features otherwise not available in the user sp...
Recent versions of Linux and FreeBSD support TLS encryption by kernel (kTLS). One of the benefits of it is that when TLS encryption is performed by kernel, it might use additional hardware features otherwise not available in the user space, including offloading TLS encryption to the NICs that support that (e.g. [NVIDIA Mellanox ConnectX-6 Dx](https://www.nvidia.com/en-us/networking/ethernet/connectx-6-dx/)), almost completely freeing the CPU from this task, because even in the case of hardware acceleration of encryption within the CPU, it still requires some cycles from it. Also, using it might reduce memory copying in some cases.
Of course, kernel space encryption is more limited compared to the one provided by OpenSSL and its derivatives in the user space: these limitations are imposed by hardware - e.g. NICs might not support anything but AES 128 (aka `TLS_AES_128_GCM_SHA256`), as it is the only cipher mandatory for TLS v1.3). If it is good enough for WEB servers, it should be good enough for DNS, too.
Even when kTLS is used, the handshake itself happens in the user space (e.g. using OpenSSL) with negotiated parameters passed to the kernel using `setsockopt()` calls on a TCP socket descriptor.
OpenSSL provides support for kTLS encryption natively since version 3.X (see `SSL_OP_ENABLE_KTLS` [option](https://www.openssl.org/docs/manmaster/man3/SSL_set_options.html)) but, as far as I understand it, it does so only when OpenSSL manages the underlying TCP socket file descriptor natively: not our case, as we are using LibUV for that. However, considering that the idea of kTLS is that with it enabled, we are supposed to pass unencrypted data to `send()` and `recv()`, that is kTLS-enabled socket from the higher level perspective works (mostly) as a TCP socket, we might try the following approach to implement kTLS, that *might* work:
1. We use our existing code (`tlsstream.c`) to handle handshake, just like we do now;
2. After completing the handshake, we pass the negotiated information to the kernel. OpenSSL might have some interfaces for that. In the worst case, we might need to do that by hand using. `setsockopt()`;
3. Then, we add new code paths to `tlsstream.c` to bypass TLS connection objects (`isc_tls_t`) and use the underlying TCP connection directly, which, by now, works in "kTLS-mode", providing transparent TLS encryption;
4. Control messages, like TLS shutdown, will require additional care.
That is how I see the initial plan that might or might not work. There can (and, likely, will) be unforeseen obstacles that might turn out to overcomplicate the code base so much that it might make it unfeasible to implement, like adding a kTLS-only transport. Furthermore, that might require some assistance from LibUV. That will require some trial and error.
That is mostly written with Linux in mind. If the kTLS interface in FreeBSD is similar enough (it seems so at the first glance), we should support both platforms.
The issue is created mostly to dump the information from my mind and keep kTLS under our radar: we might want to do that, as at least `dnsdist` has experimental support for it. It will be even more important in the future, as it seems now that encrypted DNS transport will be even more important to the point of replacing the good ol' Do53 at some point.
For sure, it is not a 9.20 material - rather 9.21-9.22 if we are lucky, as it is a big feature. Also, I foresee a similar concept eventually appearing for QUIC, too (kQUIC?). Also, I am aquiet certain that we *will* need #3504 for this (implemented here: !8576).
See also:
1. https://docs.kernel.org/networking/tls.html
2. https://man.freebsd.org/cgi/man.cgi?query=ktls&apropos=0&sektion=0&manpath=FreeBSD+13.0-RELEASE+and+Ports&arch=default&format=html
3. https://delthas.fr/blog/2023/kernel-tls/ - mostly discusses it in the context of HTTP and `sendfile()` acceleration, but contains many references on the topic.
4. https://docs.nvidia.com/networking/display/ofedv512580/kernel+transport+layer+security+(ktls)+offloadsLong-termArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4544"primaries" block documentation issues2024-01-23T15:27:16ZRay Bellis"primaries" block documentation issuesI'm finding the documentation of the "primaries" block confusing.
The ARM claims a `primaries` zone setting is only permissible within mirror, redirect, secondary and stub zones. However I've been using them at least a couple of years ...I'm finding the documentation of the "primaries" block confusing.
The ARM claims a `primaries` zone setting is only permissible within mirror, redirect, secondary and stub zones. However I've been using them at least a couple of years within the `also-notify` section of primary zones.
There's no direct mention of `primaries` in the grammar of an `also-notify` block. I _suspect_ that it's covered by `<remote-servers>` but the only link between `primaries` and `remote-servers` is this text in the glossary:
> remote-servers: A named list of one or more ip_addresses with optional tls_id, server_key, and/or port. A remote-servers list may include other remote-servers lists. See primaries block.
If in fact a `<remote-servers>` reference _is_ a (named) `primaries` list, then that ought to be spelled out more explicitly, and the documentation updated to reflect that this can be used in *any* `allow-notify` block in any applicable zone type.
I'd also suggest that the top level grammar ought to actually be called `xfer-servers` instead of `masters` and then that term used in place of `remote-servers` in the ARM. In the NOTIFY case the listed servers are secondaries, not primaries, and it makes no sense to call them primaries.
[`remote-servers` also causes confusion with `server <prefix> { }` used to specify per-server EDNS overrides, etc]Long-termMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4542XoT: Primaries should be able to have different allow-transfer acls per trans...2024-01-22T13:10:56ZDave KnightXoT: Primaries should be able to have different allow-transfer acls per transport or ACLs should be extended with port and transport options### Description
We can restrict a primary to ONLY allow-transfer on a specific transport, e.g.
allow-transfer port 853 transport tls { acl_for_xot_clients; };
Unless I'm missing something, there's no way to have different rules per tr...### Description
We can restrict a primary to ONLY allow-transfer on a specific transport, e.g.
allow-transfer port 853 transport tls { acl_for_xot_clients; };
Unless I'm missing something, there's no way to have different rules per transport.
I want to require XoT for transfers over the Internet, but allow insecure AXFR to localnets.
It's not possible to have multiple allow-transfer definitions, i.e. this
allow-transfer port 53 transport tcp { acl_for_nonxot_clients; };
allow-transfer port 853 transport tls { acl_for_xot_clients; };
results in
'allow-transfer' redefined near 'allow-transfer'
And my understanding is that we can't refer to ports or transport in an acl.
### Request
Either allow multiple allow-transfer clauses, treating "allow transfer transport tcp" and "allow transfer transport tls" as different things, which can have their own acl specification, or add port and transport to the acl so that this can be controlled there.
### Links / referencesLong-termArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4503Possible pytest RNDC interface improvements2023-12-21T18:03:30ZŠtěpán BalážikPossible pytest RNDC interface improvementsReview of !8357, which provides a first cut of the pytest RNDC interface, shown multiple suggestion for possible improvements.
I am now dumping them here in a form of checklist so they don't get buried in the now resolved MR comments:
...Review of !8357, which provides a first cut of the pytest RNDC interface, shown multiple suggestion for possible improvements.
I am now dumping them here in a form of checklist so they don't get buried in the now resolved MR comments:
- [ ] Find a way to the the `*.in` files templating in pure Python. This is needed for the elimination of the `setup.sh` scripts. This will probably require depending on `jinja` explicitly.
- [ ] Add an "rndc null" before every reconfiguration to show which file is used (NamedInstance.add_mark_to_log() as it may be generically useful?)
- [ ] Extend `NamedInstance` with some kind of `query` method. This is needed as a replacement for the calls to `dig` which are common in system tests.
- [ ] There are now two objects representing the ports used in tests: dictionary returned by the `ports` fixture and the new `NamedPorts` class. Unify them. Discussed [here](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8357#note_411674).
- [ ] Consider switch from `NamedTuple` to `dataclass` (Python 3.7 feature, requires a external dependency on some distros we run) as discussed [here](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8357#note_411004).
- [ ] `NamedInstance.rndc(…)` method probably ought to be `async`. Discussed [here](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8357#note_411007)
Feel free to add others!Long-termŠtěpán BalážikŠtěpán Balážikhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4330Add support to parse and display DSO (opcode 6) messages2023-11-01T14:43:41ZMark AndrewsAdd support to parse and display DSO (opcode 6) messagesSee [RFC 8490](https://www.rfc-editor.org/rfc/rfc8490.txt). These contain 1 or more TLVs immediately after the DNS messages header.
Add support to dig to be able to send arbitrary DSO messages.See [RFC 8490](https://www.rfc-editor.org/rfc/rfc8490.txt). These contain 1 or more TLVs immediately after the DNS messages header.
Add support to dig to be able to send arbitrary DSO messages.Long-termMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3228Reduce and then remove task exclusive mode2023-11-01T07:55:11ZOndřej SurýReduce and then remove task exclusive modeThis is (umbrella) issue to track the removal of task exclusive mode which (with proper design) should not be necessary. The exclusive mode is used in:
* [ ] named itself when:
* [ ] [(re-)loading configuration](issue TBD)
* [ ] [lo...This is (umbrella) issue to track the removal of task exclusive mode which (with proper design) should not be necessary. The exclusive mode is used in:
* [ ] named itself when:
* [ ] [(re-)loading configuration](issue TBD)
* [ ] [loading zones](issue TBD)
* [ ] [shutting down](issue TBD)
* [ ] [enabling/disabling DNSSEC validation](issue TBD) via rndc
* [ ] [flushing cache](issue TBD)
* [x] [deleting TSIG?](issue TBD)
* [ ] [dumping changes to dynamic zones](issue TBD) via rndc
* [ ] [freezing/thawing zone](issue TBD)
* [ ] [something with adding/removing zones](issue TBD) via rndc
* [ ] [destroying managed-keys database](issue TBD)
* [ ] [setting TCP timeouts](issue TBD) #WTF?
* [ ] [configuring serve-stale](issue TBD) via rndc
* [x] [dns_adb](issue TBD)
* [ ] [dns_catz](issue TBD) via `catz_addmodzone_taskaction()`, `catz_delzone_taskaction()`
* [ ] [dns_dt](issue TBD)
* [x] [ns_clientmgr](https://gitlab.isc.org/isc-projects/bind9/-/issues/3230)
* [x] [ns_interfacemgr](https://gitlab.isc.org/isc-projects/bind9/-/issues/3229)Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4297Follow-up from "Resolve "UAF in validator logging""2023-09-06T01:05:12ZMark AndrewsFollow-up from "Resolve "UAF in validator logging""The following discussion from !8269 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8269#note_399683): (+2 comments)
> Wouldn't it be better if `val->name` would...The following discussion from !8269 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8269#note_399683): (+2 comments)
> Wouldn't it be better if `val->name` would be attached to the `dns_name_t` instead of just assigned to prevent this reordering issues? What would be the performance impact of such change?Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4268There is a performance waste in the rpz check2023-08-22T07:06:22ZMr BenThere is a performance waste in the rpz check
### Summary
This is not a strict bug, it should belong to performance optimization.
When using rpz, if a domain name contains a cname domain name, the domain name will go through multiple rpz checks.
### BIND version used
```
BIND 9....
### Summary
This is not a strict bug, it should belong to performance optimization.
When using rpz, if a domain name contains a cname domain name, the domain name will go through multiple rpz checks.
### BIND version used
```
BIND 9.16.11 (Stable Release) <id:5218cdf>
running on Linux x86_64 3.10.0-1160.45.1.el7.x86_64 #1 SMP Wed Oct 13 17:20:51 UTC 2021
built by make with '--enable-dnstap' '--enable-epoll' '--with-dlz-filesystem' '--with-libjson' '--with-libtool' '--enable-dnsdrps' '--prefix=/data/named/' 'CFLAGS= -O0 -g -DDEBUG' 'PKG_CONFIG_PATH=/usr/local/lib/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
compiled with OpenSSL version: OpenSSL 1.1.1p 21 Jun 2022
linked to OpenSSL version: OpenSSL 1.1.1k FIPS 25 Mar 2021
compiled with libuv version: 1.43.0
linked to libuv version: 1.43.0
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
compiled with protobuf-c version: 1.3.0
linked to protobuf-c version: 1.3.0
threads support is enabled
default paths:
named configuration: /data/named/etc/named.conf
rndc configuration: /data/named/etc/rndc.conf
DNSSEC root key: /data/named/etc/bind.keys
nsupdate session key: /data/named/var/run/named/session.key
named PID file: /data/named/var/run/named/named.pid
named lock file: /data/named/var/run/named/named.lock
```
### Steps to reproduce
```
options {
response-policy {
zone "in-addr.arpa.";
};
};
zone "in-addr.arpa." {
type primary;
file "badlist.zone";
allow-query {none;};
};
```
### What is the current *bug* behavior?
It is not reflected in the function, but it is reflected in the code logic.
```
eg:
dig @127.0.0.1 www.microsoft.com
;; ANSWER SECTION:
www.microsoft.com. 1496 IN CNAME www.microsoft.com-c-3.edgekey.net.
www.microsoft.com-c-3.edgekey.net. 247 IN CNAME www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net.
www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net. 203 IN CNAME e13678.ca2.s.tl88.net.
e13678.ca2.s.tl88.net. 158 IN A 218.58.101.49
```
The rpz module checks the following domain names twice, which is a huge waste of performance:
www.microsoft.com, www.microsoft.com-c-3.edgekey.net, www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net
### What is the expected *correct* behavior?
Each domain name is checked only once。
### Relevant configuration files
```
Configure the rpz module normally:
options {
response-policy {
zone "in-addr.arpa.";
};
};
zone "in-addr.arpa." {
type primary;
file "badlist.zone";
allow-query {none;};
};
and the file of badlist.zone is:
$TTL 1H
@ SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d 2h)
NS LOCALHOST.
nxdomain.domain.com CNAME . ; NXDOMAIN policy
```
### Relevant logs and/or screenshots
none.
### Possible fixes
The call of the rpz module should be migrated from query_gotanswer to before query_gotanswer:
```
if (!RECURSING(qctx->client) &&
!dns_name_equal(qctx->client->query.qname, dns_rootname))
{
result = query_checkrpz(qctx, result);
if (result == ISC_R_COMPLETE) {
return (ns_query_done(qctx));
}
}
```
After the query resume function is triggered, it will execute to ns_query_start. It is not necessary to call rpz in query_gotanswer after query_resume, but call rpz in ns_query_start, which reduces the number of rpz calls.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4158investigate performance impact of huge pages2023-06-27T07:27:35ZPetr Špačekpspacek@isc.orginvestigate performance impact of huge pages- We do lots and lots of allocation.
- jemalloc supports huge pages to limit metadata overhead and TLB misses
- that together with tuning sysctl `vm.nr_hugepages` can be interesting.
Reading:
https://access.redhat.com/documentation/en-u...- We do lots and lots of allocation.
- jemalloc supports huge pages to limit metadata overhead and TLB misses
- that together with tuning sysctl `vm.nr_hugepages` can be interesting.
Reading:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/monitoring_and_managing_system_status_and_performance/configuring-huge-pages_monitoring-and-managing-system-status-and-performanceLong-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4161Support quantum safe DNSSEC algorithms2023-06-27T07:27:28ZPetr Špačekpspacek@isc.orgSupport quantum safe DNSSEC algorithms### Description
Reportedly US government is going to mandate post-quantum algorithm support from 2026 onward, with no legacy algorithms allowed after 2033.
### Request
Explore how we can integrate quantum safe algorithms for early exp...### Description
Reportedly US government is going to mandate post-quantum algorithm support from 2026 onward, with no legacy algorithms allowed after 2033.
### Request
Explore how we can integrate quantum safe algorithms for early experimentation.
Many algorithms are already available as OpenSSL provider here: https://github.com/open-quantum-safe/oqs-provider
### Additional details
* [FALCON implementation in PowerDNS](https://indico.dns-oarc.net/event/42/contributions/902/attachments/871/1601/Post-Quantum%20DNSSEC%20with%20FALCON-512%20and%20PowerDNS(2).pdf)
* [Verisign's presentation](https://indico.dns-oarc.net/event/46/contributions/985/attachments/938/1728/OARC40-ResearchAgendaForAPQCDNSSEC-Final.pdf)
Word of mouth from Red Hat crypto people I talked to:
Right now it seems that NIST might standardize 5 algorithms, with several variants for each algorithm with intent to provide 128/256 bit-equivalent of security.
Rambling about candidate algorithms for DNSSEC:
- HSS/LMS & XMSS^MT algorithms are extremely susceptible to key reuse. One key reuse ruins the whole thing. Don't use it.
- Falcon-512 has smallest signatures by large margin (around 666 bytes). CRYSTALS-Dillithium are built on the same principle but have larger signatures (about 2420 bytes). The problem is, both are reportedly built on shaky grounds because we as humankind don't fully understand the math behind them, so chances for breaking these algorithms in couple years are non-negligible.
- The remaining candidate algorithm is SPHINCS+-128. That one is most solid because it's based on ordinary hashes, which are well understood. The catch is that one signature is about 7856 bytes :exploding_head:
Consequently, this sounds like we need very good very solid TCP/TLS/QUIC support in client and server, so we are not limited to UDP packet sizes. That's IMHO the only way to go without significantly changing the protocol.
(Or we can go and engineer DNS 2.0 :grinning:)
### Links / referencesLong-term2026-01-01https://gitlab.isc.org/isc-projects/bind9/-/issues/4162SHA-1 removal2023-06-27T07:27:14ZPetr Špačekpspacek@isc.orgSHA-1 removal### Description
From [NIST announcement](https://csrc.nist.gov/news/2022/nist-transitioning-away-from-sha-1-for-all-apps):
> As a result, NIST will transition away from the use of SHA-1 for applying cryptographic protection to **all app...### Description
From [NIST announcement](https://csrc.nist.gov/news/2022/nist-transitioning-away-from-sha-1-for-all-apps):
> As a result, NIST will transition away from the use of SHA-1 for applying cryptographic protection to **all applications** by December 31, 2030
### Request
Don't get caught asleep at the wheel.
### Links / references
Send questions about the transition in an email to sha-1-transition@nist.gov. Visit the [Policy on Hash Functions](https://csrc.nist.gov/projects/hash-functions/nist-policy-on-hash-functions) page to learn more.Long-term2030-12-31https://gitlab.isc.org/isc-projects/bind9/-/issues/4164Investigate performance impact of UDP_GRO2023-06-27T07:06:24ZPetr Špačekpspacek@isc.orgInvestigate performance impact of UDP_GRO### Description
Mention of UDP_GRO in [Linux udp man page](https://man.archlinux.org/man/udp.7) sounds worth investigating:
> #### UDP_GRO (since Linux 5.0)
> Enables UDP receive offload. If enabled, the socket may receive multiple dat...### Description
Mention of UDP_GRO in [Linux udp man page](https://man.archlinux.org/man/udp.7) sounds worth investigating:
> #### UDP_GRO (since Linux 5.0)
> Enables UDP receive offload. If enabled, the socket may receive multiple datagrams worth of data as a single large buffer, together with a cmsg(3) that holds the segment size. This option is the inverse of segmentation offload. It reduces receive cost by handling multiple datagrams worth of data as a single large packet in the kernel receive path, even when that exceeds MTU. This option should not be used in code intended to be portable.
More reading:
https://developers.redhat.com/articles/2021/11/05/improve-udp-performance-rhel-85
### Request
- Investigate if UDP receipt is even a bottleneck.
- Investigate if UDP_GRO makes a difference and is worth messing with (I supposed in libuv).
### Links / referencesLong-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2547Resolver benchmarking testing - corralling the generic plus the important edg...2022-06-03T10:15:14ZCathy AlmondResolver benchmarking testing - corralling the generic plus the important edge cases to include when testingOpening this issue to capture discussions on what we need to include in BIND resolver performance benchmark tests, beyond the generic case.Opening this issue to capture discussions on what we need to include in BIND resolver performance benchmark tests, beyond the generic case.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2549Create a BIND benchmarking package for users to download and use in their own...2022-06-03T10:15:14ZCathy AlmondCreate a BIND benchmarking package for users to download and use in their own environmentsThis feature issue ticket is to track discussions on a potential downloadable benchmark testing framework for users (performance testing is hard...)This feature issue ticket is to track discussions on a potential downloadable benchmark testing framework for users (performance testing is hard...)Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2548Resolver testing - building an Internet Simulator device2022-06-03T10:15:14ZCathy AlmondResolver testing - building an Internet Simulator deviceThis ticket is being opened to capture discussions on how to create a device to take the place of 'The Internet' for benchmarking resolver performance more realisticallyThis ticket is being opened to capture discussions on how to create a device to take the place of 'The Internet' for benchmarking resolver performance more realisticallyLong-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2800Docker image for AArch64 - Raspberry Pi2022-02-01T11:18:07ZVicky Riskvicky@isc.orgDocker image for AArch64 - Raspberry PiI received a request via email for a Docker image that will run on a stack of Raspberry Pi 4Bs. I have only ever seen the one request, so I will put it here and see if it gets a lot of upvotes...
"ISC's official Docker image is not supp...I received a request via email for a Docker image that will run on a stack of Raspberry Pi 4Bs. I have only ever seen the one request, so I will put it here and see if it gets a lot of upvotes...
"ISC's official Docker image is not supported for the AArch64 architecture."Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2999remove duplicate code between DLZ example & dlzexternal test2022-01-07T09:40:28ZPetr Špačekpspacek@isc.orgremove duplicate code between DLZ example & dlzexternal testVersion: main branch, 4bebcd45033400a6b1a3057c60c3a2cfd5fd4029
These two files are substantially the same:
- contrib/dlz/example/dlz_example.c
- bin/tests/system/dlzexternal/driver/driver.c
I think we should remove one of them and use ...Version: main branch, 4bebcd45033400a6b1a3057c60c3a2cfd5fd4029
These two files are substantially the same:
- contrib/dlz/example/dlz_example.c
- bin/tests/system/dlzexternal/driver/driver.c
I think we should remove one of them and use symlink instead of copy. Updating two files is ... suboptimal.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1573Rewrite qmin ans.py services2021-10-05T07:43:44ZWitold KrecickiRewrite qmin ans.py servicesLong-termWitold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/352Refactored RPZ has a scalability design problem2021-10-04T12:50:35ZGhost UserRefactored RPZ has a scalability design problem(Don't let that title sound discouraging - IMO it is still better than the old RPZ code, but more work is necessary.)
Last week I heard from a provider of feed data that they need resolvers to react quickly and the current 60s default u...(Don't let that title sound discouraging - IMO it is still better than the old RPZ code, but more work is necessary.)
Last week I heard from a provider of feed data that they need resolvers to react quickly and the current 60s default update rate plus the fact that RPZ does a full iteration of the DB will not work for them as their data is not latency tolerant and their policy zones are large.
There was a separate bug ticket by a popular reporter from another ISC customer in the last 1-2 months that asked whether this 60s update time could be improved to match the old RPZ behavior.
I feel this can be addressed. BIND RPZ would need to hook not just into `dns_db_updatenotify_register()`, but also into a `newdbversion` signal and every `add` and `del` update to the DB. Note that the RPZ view summary datastructure is still not versioned, so RPZ code would have to separately batch and keep aside a copy of the update diffs until the DB version commit passes, and then apply just the diffs to the RPZ view summary data structure instead of iterating the zone. I think versioning the view summary datastructure would be too much work and complicate the structure.. as long as the diff is applied to it after the DB version commit passes, there should be no problem of inconsistent data.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/303Improve const correctness2021-10-04T12:47:58ZOndřej SurýImprove const correctness@bind-team, this is 3 years old review of BIND code by Errata Security: https://blog.erratasec.com/2015/07/a-quick-review-of-bind9-code.html and he is right.
We need to start using `const` more extensively _and_ internalise it when writ...@bind-team, this is 3 years old review of BIND code by Errata Security: https://blog.erratasec.com/2015/07/a-quick-review-of-bind9-code.html and he is right.
We need to start using `const` more extensively _and_ internalise it when writing new code and doing reviews.
It is a long term goals, so we will just keep this open, and I'll list major components that should be reviewed:
* [ ] libisc
* [ ] libdns
* [ ] libns
* [ ] libisccfg
* [ ] libiscccc
* [ ] bin/namedLong-term