BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-11-20T10:39:24Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4426Feature request - client.bind chaos class queries2023-11-20T10:39:24ZRay BellisFeature request - client.bind chaos class queriesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4423named starts up slow when many zones reference the same dnssec-policy2024-02-24T07:54:22ZMatthijs Mekkingmatthijs@isc.orgnamed starts up slow when many zones reference the same dnssec-policyWhile rolling out KASP to many zones, it is more efficient to use more DNSSEC policies in order to improve
reload/reconfig times.
When all zones or referenced by the same `dnssec-policy`, it takes quite some time to process all zones af...While rolling out KASP to many zones, it is more efficient to use more DNSSEC policies in order to improve
reload/reconfig times.
When all zones or referenced by the same `dnssec-policy`, it takes quite some time to process all zones after reload/reconfig and CPU usage of the named process remains at 100% and it takes quite a few minutes for named to start responding to queries after such a reload/reconfig request.
When spreading my zones to 10 identical policies, cpu usage goes well above 100% (using more threads I assume) and this is speeding
things up really nice.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4422No supported algorithms on platform2024-02-29T15:26:01ZMark AndrewsNo supported algorithms on platformJob [#3783240](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3783240) failed for 5d20a7ce254dabe1d4a99f7bd0fd1cfa6309124b:
```
$ PYTHON="$(source bin/tests/system/conf.sh; echo $PYTHON)"
Traceback (most recent call last):
File "/bu...Job [#3783240](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3783240) failed for 5d20a7ce254dabe1d4a99f7bd0fd1cfa6309124b:
```
$ PYTHON="$(source bin/tests/system/conf.sh; echo $PYTHON)"
Traceback (most recent call last):
File "/builds/isc-projects/bind9/bin/tests/system/get_algorithms.py", line 241, in <module>
main()
File "/builds/isc-projects/bind9/bin/tests/system/get_algorithms.py", line 227, in main
algs = filter_supported(algs)
^^^^^^^^^^^^^^^^^^^^^^
File "/builds/isc-projects/bind9/bin/tests/system/get_algorithms.py", line 138, in filter_supported
raise RuntimeError(
RuntimeError: no DEFAULT algorithm from "stable" set supported on this platform
$
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4416ccmsg doesn't support multiple message read in the single TCP read2023-11-09T09:35:42ZDominik Thalhammerccmsg doesn't support multiple message read in the single TCP read### Summary
Sending multiple messages (without waiting for the previous responses to arrive) to bind via rndc causes messages to get lost/bind to loose sync on the stream.
### BIND version used
Docker image `ubuntu/bind9:9.18-22.04_be...### Summary
Sending multiple messages (without waiting for the previous responses to arrive) to bind via rndc causes messages to get lost/bind to loose sync on the stream.
### BIND version used
Docker image `ubuntu/bind9:9.18-22.04_beta`
```
BIND 9.18.12-0ubuntu0.22.04.3-Ubuntu (Extended Support Version) <id:>
running on Linux x86_64 6.2.0-36-generic #37~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct 9 15:34:04 UTC 2
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/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' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--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' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-B5s8Yi/bind9-9.18.12=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 11.4.0
compiled with OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
linked to OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
compiled with libuv version: 1.43.0
linked to libuv version: 1.43.0
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
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
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
```
### Steps to reproduce
Send multiple requests via rndc in rapid succession. The particular program used to initially observe the issue is closed source and tightly integrated, however the following script using `bind9-rndc-node` experiences the same behaviour.
```js
var RNDC = require('bind9-rndc');
var key = 'BzDBJ1B/JbQg9iXJYAGZLQ==';
var session = RNDC.connect('172.17.0.2', 953, key, 'md5');
var test_count = 10;
var recv_count = 0;
session.on('ready', () => {
for(var i = 0; i < test_count; i++)
session.send('status');
});
session.on('data', (obj) => {
recv_count++;
console.log("Got " + recv_count);
console.log(obj);
});
session.on('error', console.log);
```
### What is the current *bug* behavior?
Bind correctly handles some of the requests but drops others. Depending on the message size and timing the indices of the recognized messages vary and sometimes bind looses track entirely until it drops the connection with a timeout.
### What is the expected *correct* behavior?
The number of responses is equal to the number of requests (the order can vary, thats what `_ser` is for) and the stream stays in sync, regardless of the timing when sending messages. If bind can not keep up with the client it should use the tcp blocking to signal this instead of dropping data.
### Relevant configuration files
named.conf
```
key "rndc-key" {
algorithm hmac-md5;
secret "BzDBJ1B/JbQg9iXJYAGZLQ==";
};
controls {
inet 0.0.0.0 allow { any; } keys { "rndc-key"; };
};
options {
directory "/var/cache/bind";
version none;
allow-query { any; };
allow-recursion { any; };
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { };
listen-on { any; };
};
```
### Relevant logs and/or screenshots
Sample output of script (note theres a rather long pause before `warning: unread...`):
```
(node:10142) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Got 1
Map(0) {
type: 'status',
result: '0',
text: 'version: BIND 9.18.12-0ubuntu0.22.04.3-Ubuntu (Extended Support Version) <id:> (version.bind/txt/ch disabled)\n' +
'running on 54d01852d58b: Linux x86_64 6.2.0-36-generic #37~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct 9 15:34:04 UTC 2\n' +
'boot time: Sat, 04 Nov 2023 14:45:41 GMT\n' +
'last configured: Sat, 04 Nov 2023 14:45:41 GMT\n' +
'configuration file: /etc/bind/named.conf\n' +
'CPUs found: 16\n' +
'worker threads: 16\n' +
'UDP listeners per interface: 16\n' +
'number of zones: 101 (99 automatic)\n' +
'debug level: 0\n' +
'xfers running: 0\n' +
'xfers deferred: 0\n' +
'soa queries in progress: 0\n' +
'query logging is OFF\n' +
'recursive clients: 0/900/1000\n' +
'tcp clients: 0/150\n' +
'TCP high-water: 0\n' +
'server is up and running'
}
warning: unread data left over
```
Relevant log output for this transaction:
`04-Nov-2023 15:12:17.519 invalid command from 172.17.0.1#40764: timed out`
### Possible fixes
I am not familiar with the bind9 source code, but I will take a look if I can find something (along with retesting on the master branch).
A fix for clients is to ensure that there is never more than one message in flight. This fixes the issue, but vastly degrades performance if the latency between server and client is huge.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4403Resolve spike in memory when named starts2023-12-05T15:58:58ZMatthijs Mekkingmatthijs@isc.orgResolve spike in memory when named starts9.19 resolver does better parallelization of work with cold cache, and thus consumes a more memory and CPU resources right after startup.
We should investigate if it works fine in face of limited resources, e.g. when the initial memory ...9.19 resolver does better parallelization of work with cold cache, and thus consumes a more memory and CPU resources right after startup.
We should investigate if it works fine in face of limited resources, e.g. when the initial memory spike exceeds available memory.
![all-groups-resmon.memory.current-docker](/uploads/b5fa63c677bb0c903ffca45b994375ac/all-groups-resmon.memory.current-docker.png)
![all-groups-resmon.cpu.usage_percent.cg-docker](/uploads/314f7c9f1c396f303bdd6397dd2dc73a/all-groups-resmon.cpu.usage_percent.cg-docker.png)
![all-groups-latency-since_0-until_150](/uploads/3ba559d2fd3a18335eaf45796874482c/all-groups-latency-since_0-until_150.png)BIND 9.19.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4400CID 467118: Control flow issue in lib/dns/message.c2024-02-24T07:55:29ZMichal NowakCID 467118: Control flow issue in lib/dns/message.cCoverity Scan claims control flow issue in `lib/dns/message.c` (suspect: !8400).
```
*** CID 467118: Control flow issues (DEADCODE)
/lib/dns/message.c: 1076 in getquestions()
1070 return (DNS_R_RECOVERABLE);
1071 }
1072 ...Coverity Scan claims control flow issue in `lib/dns/message.c` (suspect: !8400).
```
*** CID 467118: Control flow issues (DEADCODE)
/lib/dns/message.c: 1076 in getquestions()
1070 return (DNS_R_RECOVERABLE);
1071 }
1072 return (ISC_R_SUCCESS);
1073
1074 cleanup:
1075 if (rdataset != NULL) {
>>> CID 467118: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "dns_message_puttemprdataset...".
1076 dns_message_puttemprdataset(msg, &rdataset);
1077 }
1078 if (free_name) {
1079 dns_message_puttempname(msg, &name);
1080 }
1081
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4374modernize systemd.service file2023-10-24T08:33:22ZPetr Špačekpspacek@isc.orgmodernize systemd.service fileTurns out that our systemd.service file is from the age of dinosaurs.
Looking at https://gitlab.isc.org/isc-private/rpms/bind/-/blob/5b649ff34e7047ac4be6c82993c6f9784958533c/named.service.in ([named.service.in](/uploads/5dd91c2fc03c7620...Turns out that our systemd.service file is from the age of dinosaurs.
Looking at https://gitlab.isc.org/isc-private/rpms/bind/-/blob/5b649ff34e7047ac4be6c82993c6f9784958533c/named.service.in ([named.service.in](/uploads/5dd91c2fc03c762068b98741f3e1e358/named.service.in)):
- type should be `notify-reload`
- `ExecReload`, `ExecStop`, `PIDFile` commands should go away
Pros:
This will provide sensible integration and detection when BIND is ready (including reload) - at least for the simple cases where no catalog zones or RPZ is involved.
It might also make debugging a bit easier as tighter integration should avoid corner cases around `kill` invocation.
Edit: fixed the link.https://gitlab.isc.org/isc-projects/bind9/-/issues/4371All the things that need to be fixed before 9.202024-03-27T14:02:04ZMatthijs Mekkingmatthijs@isc.orgAll the things that need to be fixed before 9.20This is an overarching issue for keeping track on all the things that need to be completed before the 9.20.0 release.
### Features
- [ ] #1128 Offline KSK (:gear: @matthijs)
- [x] #1129 HSM support via pkcs11-provider
- [x] #4363 Enfor...This is an overarching issue for keeping track on all the things that need to be completed before the 9.20.0 release.
### Features
- [ ] #1128 Offline KSK (:gear: @matthijs)
- [x] #1129 HSM support via pkcs11-provider
- [x] #4363 Enforce stricter NSEC3 parameter limits
- [x] #4388 Accepting PROXYv2
- [x] #4241 Expose data about 'first time' zone maintenance in-progress
- [ ] #2099 Implement ZoneMD signature generation and verification. (:gear: !5217 @marka, @each)
### Config incompatibilities
- [x] #4364 named-compilezone defaults
- [x] #4373 safer "dnssec-validation yes"
- [x] #4447 "stale-answer-client-timeout" must be zero (:gear: !8699 @aram)
### Refactoring
- [x] #4411 QPDB lite (:gear: !8726 @matthijs, @each)
- [x] #4251 system test runner
### Bugs
- [x] #4340 "max-cache-size" is a no-op since BIND 9.19.16
- [x] #4213 BIND shutdown hang in checkds/ns9/ in cross-version-config-tests job
- [x] #4060 named doesn't shut down after receiving rndc stop command
- [x] #4211 AssertionError: named crashed, shutdown crash
- [ ] #4403 Resolve spike in memory at start of named (:gear: @ondrej)
- [ ] #4481 TCP issue (:gear: isc-private/bind9!639 @ondrej)
- [ ] #4475 Data races in isc_buffer_peekuint8, rdataset_settrust, and memmove (:gear: !8645 @marka)
- [x] #4625 DNSSEC validation incompatibility
- [ ] #4652 Server crash caused by external UDP queriesBIND 9.19.x2024-05-02https://gitlab.isc.org/isc-projects/bind9/-/issues/4370Check that a zone is served by IPv6 servers if it has AAAA records2023-12-05T09:04:32ZMark AndrewsCheck that a zone is served by IPv6 servers if it has AAAA recordsOne thing that is often forgotten when turning on an IPv6 service is to ensure that the zone holding the AAAA records for that service is also served over IPv6. This can be relatively easy be checked for by named-checkzone by looking fo...One thing that is often forgotten when turning on an IPv6 service is to ensure that the zone holding the AAAA records for that service is also served over IPv6. This can be relatively easy be checked for by named-checkzone by looking for AAAA records in the zone contents, including glue AAAA records, and then checking that there are AAAA records published for some of the nameservers if any are found (in zone or elsewhere). This can also sometimes be determined by named without needing to look beyond the zone's contents, but cannot be guaranteed.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4358Randomize client address to improve security against cache poisoning2023-10-10T12:46:26ZKasper DupontRandomize client address to improve security against cache poisoning### Description
Existing solutions to increase request entropy only provide a few extra bits. Port number randomization provide at most 16 bits of entropy and randomizing casing of the name will often provide less than that. Moreover fo...### Description
Existing solutions to increase request entropy only provide a few extra bits. Port number randomization provide at most 16 bits of entropy and randomizing casing of the name will often provide less than that. Moreover for responses spanning multiple packets that extra entropy may only protect the first packet of the response.
### Request
Take advantage of the larger address space provided by IPv6 to randomize both client IP address and port. Using a /72 prefix would leave 56 bits for randomization which is more than request ID, port number, and name randomization combined. The IP address is part of each packet and will thus protect all packets of the response. It does not require the other methods of adding entropy to be disabled, combined the entropy can be even higher.
Ideally the prefix length used will be configurable. Supporting only multiples of 8 will keep the implementation simpler. A /72 prefix length will be preferred in at least some deployments. It avoids randomizing the multicast and globally unique bits of the address. Additionally it's usable with providers who only route a /64 to customers. (Use cases exist for /48, /56, /64, /72, and /104 with /72 being the best compromise if only a single prefix length is supported.)
To use this feature the server administrator would need to:
- Ensure a prefix is routed to the host
- Choose a sub-prefix of that to use for source IP randomization (could be the entire range if the routed prefix is used for nothing else)
- Add a local route for the chosen sub-prefix (this functionality exists on Linux, I don't know which other OS supports this functionality.)
- Configure the chosen sub-prefix for address randomization in the BIND configuration.
The BIND recursion code will need to do the following:
- Before calling bind on a newly created socket set the IP_FREEBIND option.
- In the arguments for bind provide not just a port number but also a local IP address constructed by combining the configured prefix with a random bitstring to produce a total of 128 bits.
- Ensure that any replies not sent to the correct local IP address are ignored either by the kernel or by BIND itself.
When using TCP IP randomization should also be used, but it should not change how long the TCP connections are kept alive. So multiple queries could be sent over a TCP connection where IP randomization was applied only once.
### Links / references
The security feature requested here already exists in Unbound and can be configured using outgoing-interface: https://nlnetlabs.nl/documentation/unbound/unbound.conf/Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4352inline-signing breaks nsdiff2024-02-24T07:55:39ZBjörn Perssoninline-signing breaks nsdiff### Summary
When both inline-signing and update-policy are in use, I can't detect race conditions with the method described in RFC 2136 section 5.7, which nsdiff uses.
In a zone that uses dnssec-policy and relies on the default value o...### Summary
When both inline-signing and update-policy are in use, I can't detect race conditions with the method described in RFC 2136 section 5.7, which nsdiff uses.
In a zone that uses dnssec-policy and relies on the default value of inline-signing, the method in RFC 2136 section 5.7 will stop working on upgrade to BIND 9.20, as inline-signing will then be switched on by default, if I understand correctly.
### BIND version used
```
$ named -V
BIND 9.18.19-1~deb12u1-Debian (Extended Support Version) <id:>
running on Linux x86_64 5.10.0-25-amd64 #1 SMP Debian 5.10.191-1 (2023-08-16)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/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' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--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.18.19=. -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 12.2.0
compiled with OpenSSL version: OpenSSL 3.0.10 1 Aug 2023
linked to OpenSSL version: OpenSSL 3.0.9 30 May 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.52.0
linked to libnghttp2 version: 1.52.0
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
linked to maxminddb version: 1.7.1
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.1
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
```
### Steps to reproduce
Here I start from a working state with serial number 2023091800. The prerequisite matches the reply to the SOA query, and the update is answered with NOERROR. This is correct as far as I understand:
```
$ (echo 'prereq yxrrset xn--rombobjrn-67a.se. IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400' ; echo send) | nsupdate -k internal -d
Creating key...
Creating key...
namefromtext
keycreate
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23595
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; ANSWER SECTION:
xn--rombobjrn-67a.se. 86400 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400
Found zone name: xn--rombobjrn-67a.se
The primary is: ns1.xn--rombobjrn-67a.se
Sending update to 192.168.72.1#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 44980
;; flags:; ZONE: 1, PREREQ: 1, UPDATE: 0, ADDITIONAL: 1
;; PREREQUISITE SECTION:
xn--rombobjrn-67a.se. 0 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695171088 300 64 [...] 44980 NOERROR 0
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 44980
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695171088 300 64 [...] 44980 NOERROR 0
```
Later, the server has automatically increased the serial number to 2023091802. I use the new serial number in the prerequisite, so it looks identical to the new SOA value, but this time the update is rejected with NXRRSET:
```
$ (echo 'prereq yxrrset xn--rombobjrn-67a.se. IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091802 14400 3600 3024000 86400' ; echo send) | nsupdate -k internal -d
Creating key...
Creating key...
namefromtext
keycreate
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65052
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; ANSWER SECTION:
xn--rombobjrn-67a.se. 86400 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091802 14400 3600 3024000 86400
Found zone name: xn--rombobjrn-67a.se
The primary is: ns1.xn--rombobjrn-67a.se
Sending update to 192.168.72.1#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 52912
;; flags:; ZONE: 1, PREREQ: 1, UPDATE: 0, ADDITIONAL: 1
;; PREREQUISITE SECTION:
xn--rombobjrn-67a.se. 0 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091802 14400 3600 3024000 86400
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695259647 300 64 [...] 52912 NOERROR 0
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NXRRSET, id: 52912
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695259647 300 64 [...] 52912 NOERROR 0
```
Now I change the prerequisite back to 2023091800. The SOA hasn't changed again. The serial number is still 2023091802. This update should be rejected as the prerequisite contains an outdated serial number, but is in fact answered with NOERROR:
```
$ (echo 'prereq yxrrset xn--rombobjrn-67a.se. IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400' ; echo send) | nsupdate -k internal -d
Creating key...
Creating key...
namefromtext
keycreate
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6226
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; ANSWER SECTION:
xn--rombobjrn-67a.se. 86400 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091802 14400 3600 3024000 86400
Found zone name: xn--rombobjrn-67a.se
The primary is: ns1.xn--rombobjrn-67a.se
Sending update to 192.168.72.1#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 49961
;; flags:; ZONE: 1, PREREQ: 1, UPDATE: 0, ADDITIONAL: 1
;; PREREQUISITE SECTION:
xn--rombobjrn-67a.se. 0 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695263626 300 64 [...] 49961 NOERROR 0
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 49961
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695263626 300 64 [...] 49961 NOERROR 0
```
### What is the current *bug* behavior?
It seems that a serial number specified in a prerequisite of an update is compared to the unsigned version of the zone, but the serial number retrieved with a SOA or AXFR query is from the signed version. As far as I know a client can't look up the unsigned serial number, and thus can't specify it in the prerequisite. Thus the update fails when the two serial numbers differ.
### What is the expected *correct* behavior?
It seems to me that a prerequisite that specifies a SOA record should be checked against the same record that a client gets in response to a SOA or AXFR query. I don't know what other usecases that might break though.
### Relevant excerpts from the configuration file
```
dnssec-policy "some_name" {
keys {
ksk lifetime unlimited algorithm rsasha256 2048;
zsk lifetime unlimited algorithm rsasha256 2048;
};
dnskey-ttl P1D;
purge-keys 0;
};
view "internal" {
allow-transfer { key internal.beorn.tag.xn--rombobjrn-67a.se.; };
zone "xn--rombobjrn-67a.se" {
type master;
file "/var/lib/bind/db.xn--rombobjrn-67a.se.internal";
dnssec-policy some_name;
parental-agents { ::1; };
inline-signing yes;
update-policy {
grant internal.beorn.tag.xn--rombobjrn-67a.se. zonesub ANY;
};
};
};May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://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/4345Debug messages logging network traffic only include the address of one peer2024-02-24T08:19:42ZMichał KępieńDebug messages logging network traffic only include the address of one peerEven with `-d 99` used on the command line, `named` only logs lines
like:
28-Sep-2023 14:31:23.212 sending packet to 2001:503:ba3e::2:30#53
or:
28-Sep-2023 14:31:23.232 received packet from 2001:503:ba3e::2:30#53
However, net...Even with `-d 99` used on the command line, `named` only logs lines
like:
28-Sep-2023 14:31:23.212 sending packet to 2001:503:ba3e::2:30#53
or:
28-Sep-2023 14:31:23.232 received packet from 2001:503:ba3e::2:30#53
However, network traffic is always sent **from** one socket **to**
another. The currently available debug messages do not include the
sender's address (first example) or the receiver's address (second
example). As a result, just bumping up the log level is often not
enough to diagnose certain issues and a network traffic sniffer has to
be used in order to learn the details of the packets being exchanged.
This lack of detail sometimes also makes debugging system test issues
harder than it has to be. With multiple tests being run in parallel,
knowing the exact addresses and ports that were used by each running
`named` instance is crucial for determining whether a test failure was
caused by an unexpected interaction between tests or not. (Such issues
happened more than once in the past, particularly when network code
and/or the system test framework were being worked on.)
Debug messages logging network traffic should be extended to include
information about both sides of each communication channel.
While this issue is technically only tangential to #4344, having
detailed network-level information available would greatly improve the
benefits of the feature proposed here.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4344Enable extraction of exact local socket addresses2024-02-24T08:19:47ZMichał KępieńEnable extraction of exact local socket addressesThe Network Manager API is currently unable to expose the exact
address/port that a local wildcard/TCP socket is bound to. This limits
the level of detail available to all sorts of traffic-logging code
(debug messages, dnstap, etc.)
Th...The Network Manager API is currently unable to expose the exact
address/port that a local wildcard/TCP socket is bound to. This limits
the level of detail available to all sorts of traffic-logging code
(debug messages, dnstap, etc.)
This has been previously discussed (in dnstap context) in #3143. Back
then, it quickly [emerged][1] that extracting the exact address that a
local wildcard/TCP socket is bound to requires issuing a system call.
Unfortunately, the function that would be responsible for doing this is
[called on a hot path][2]. After running some performance tests, it
[became obvious][3] that doing that unconditionally is a non-starter
performance-wise. The proposal was scrapped and replaced with a [note
in documentation](!6472).
However, the problem persists and limits the capabilities of not just
dnstap, but also logging code. In some cases, more detailed logging is
preferred over raw performance and there should be some way for the user
to express their preference in that regard.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5816#note_272336
[2]: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5816#note_272404
[3]: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5816#note_272407May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4333catz: assertion failure in dns_view_attach() during shutdown2024-02-24T07:55:32ZArаm Sаrgsyаncatz: assertion failure in dns_view_attach() during shutdownSee https://gitlab.isc.org/isc-projects/bind9/-/jobs/3673976
This has happened on a branch based on `main`, so for now only ~"Affects v9.19" is set, but the other branches are probably affected too. The labels will updated when there is...See https://gitlab.isc.org/isc-projects/bind9/-/jobs/3673976
This has happened on a branch based on `main`, so for now only ~"Affects v9.19" is set, but the other branches are probably affected too. The labels will updated when there is more information.
```
[New LWP 55771]
[New LWP 55766]
[New LWP 55752]
[New LWP 55767]
[New LWP 55772]
[New LWP 55770]
[New LWP 55773]
[New LWP 55769]
[New LWP 55768]
[New LWP 55774]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/lt-named -D catz_tmp_b13wq61e-ns4 -X'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f0c573e0b8f in raise () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x7f0c3c87e700 (LWP 55771))]
Thread 10 (Thread 0x7f0c3b07b700 (LWP 55774)):
#0 0x00007f0c573cb9bd in syscall () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f0c57b68c76 in synchronize_rcu_memb () from /lib64/liburcu.so.6
No symbol table info available.
#2 0x00007f0c57b6975d in call_rcu_thread () from /lib64/liburcu.so.6
No symbol table info available.
#3 0x00007f0c580f81da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00007f0c573cbe73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 9 (Thread 0x7f0c5247d700 (LWP 55768)):
#0 0x00007f0c580ff60e in pthread_barrier_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f0c5b8416f9 in resume_loop (loop=0x7f0c53e93180) at loop.c:114
loopmgr = <optimized out>
loopmgr = <optimized out>
#2 pauseresume_cb (handle=<optimized out>) at loop.c:114
loop = 0x7f0c53e93180
#3 0x00007f0c5922a2f1 in uv.async_io.part () from /lib64/libuv.so.1
No symbol table info available.
#4 0x00007f0c5923bd15 in uv.io_poll () from /lib64/libuv.so.1
No symbol table info available.
#5 0x00007f0c5922aa74 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#6 0x00007f0c5b841792 in loop_thread (arg=arg@entry=0x7f0c53e93180) at loop.c:282
loop = 0x7f0c53e93180
r = <optimized out>
__func__ = "loop_thread"
ret = <optimized out>
#7 0x00007f0c5b850469 in thread_body (wrap=wrap@entry=0xf19630) at thread.c:85
func = 0x7f0c5b841707 <loop_thread>
arg = 0x7f0c53e93180
ret = 0x0
jemalloc_enforce_init = 0x7f0c48000b60
#8 0x00007f0c5b850492 in thread_run (wrap=0xf19630) at thread.c:100
ret = <optimized out>
#9 0x00007f0c580f81da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#10 0x00007f0c573cbe73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 8 (Thread 0x7f0c51c7c700 (LWP 55769)):
#0 0x00007f0c573cb9bd in syscall () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f0c5795e96d in futex_wait.part () from /lib64/liburcu-cds.so.6
No symbol table info available.
#2 0x00007f0c5795ee10 in workqueue_thread () from /lib64/liburcu-cds.so.6
No symbol table info available.
#3 0x00007f0c580f81da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00007f0c573cbe73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 7 (Thread 0x7f0c3b87c700 (LWP 55773)):
#0 0x00007f0c5810187d in __lll_lock_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f0c580fab29 in pthread_mutex_lock () from /lib64/libpthread.so.0
No symbol table info available.
#2 0x00007f0c57b681c9 in mutex_lock () from /lib64/liburcu.so.6
No symbol table info available.
#3 0x00007f0c57b69498 in rcu_register_thread_memb () from /lib64/liburcu.so.6
No symbol table info available.
#4 0x00007f0c5b856969 in isc__work_cb (req=<optimized out>) at work.c:28
work = 0x7f0c406203c0
#5 0x00007f0c592254ee in worker () from /lib64/libuv.so.1
No symbol table info available.
#6 0x00007f0c580f81da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#7 0x00007f0c573cbe73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 6 (Thread 0x7f0c3d07f700 (LWP 55770)):
#0 0x00007f0c580fe4ac in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f0c5923821d in uv_cond_wait () from /lib64/libuv.so.1
No symbol table info available.
#2 0x00007f0c5922558d in worker () from /lib64/libuv.so.1
No symbol table info available.
#3 0x00007f0c580f81da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00007f0c573cbe73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 5 (Thread 0x7f0c3c07d700 (LWP 55772)):
#0 0x00007f0c580fe4ac in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f0c5923821d in uv_cond_wait () from /lib64/libuv.so.1
No symbol table info available.
#2 0x00007f0c5922558d in worker () from /lib64/libuv.so.1
No symbol table info available.
#3 0x00007f0c580f81da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00007f0c573cbe73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 4 (Thread 0x7f0c52c7e700 (LWP 55767)):
#0 0x00007f0c580ff60e in pthread_barrier_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f0c5b8416f9 in resume_loop (loop=0x7f0c53e92900) at loop.c:114
loopmgr = <optimized out>
loopmgr = <optimized out>
#2 pauseresume_cb (handle=<optimized out>) at loop.c:114
loop = 0x7f0c53e92900
#3 0x00007f0c5922a2f1 in uv.async_io.part () from /lib64/libuv.so.1
No symbol table info available.
#4 0x00007f0c5923bd15 in uv.io_poll () from /lib64/libuv.so.1
No symbol table info available.
#5 0x00007f0c5922aa74 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#6 0x00007f0c5b841792 in loop_thread (arg=arg@entry=0x7f0c53e92900) at loop.c:282
loop = 0x7f0c53e92900
r = <optimized out>
__func__ = "loop_thread"
ret = <optimized out>
#7 0x00007f0c5b850469 in thread_body (wrap=wrap@entry=0xf19660) at thread.c:85
func = 0x7f0c5b841707 <loop_thread>
arg = 0x7f0c53e92900
ret = 0x0
jemalloc_enforce_init = 0x7f0c44000b60
#8 0x00007f0c5b850492 in thread_run (wrap=0xf19660) at thread.c:100
ret = <optimized out>
#9 0x00007f0c580f81da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#10 0x00007f0c573cbe73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 3 (Thread 0x7f0c5bd5e480 (LWP 55752)):
#0 0x00007f0c5810187d in __lll_lock_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f0c580fab29 in pthread_mutex_lock () from /lib64/libpthread.so.0
No symbol table info available.
#2 0x00007f0c57b681c9 in mutex_lock () from /lib64/liburcu.so.6
No symbol table info available.
#3 0x00007f0c57b68c44 in synchronize_rcu_memb () from /lib64/liburcu.so.6
No symbol table info available.
#4 0x00007f0c5b36f3ca in dns_view_detach (viewp=viewp@entry=0x7ffddd6d9348) at view.c:519
mkzone = 0x0
rdzone = 0x0
resolver = 0x0
adb = 0x7f0c40625600
zonetable = 0x7f0c5395d0a0
requestmgr = 0x7f0c4061b1e0
dispatchmgr = 0x7f0c53e7a9a0
view = 0x7f0c538cfc00
__func__ = "dns_view_detach"
#5 0x00000000004457e1 in shutdown_server (arg=0x7f0c53e881c0) at server.c:10025
server = 0x7f0c53e881c0
view = 0x0
view_next = 0x7f0c538cf600
kasp = 0x0
kasp_next = <optimized out>
flush = false
nsc = 0x0
#6 0x00007f0c5b82e23a in isc__async_cb (handle=<optimized out>) at async.c:111
job = 0x7f0c53e673c0
loop = 0x7f0c53e91800
jobs = {head = {node = {next = 0x7f0c53e63cd0}}, tail = {p = 0x7f0c53e673d0}}
ret = <optimized out>
node = 0x7f0c53e673d0
next = 0x0
#7 0x00007f0c5922a2f1 in uv.async_io.part () from /lib64/libuv.so.1
No symbol table info available.
#8 0x00007f0c5923bd15 in uv.io_poll () from /lib64/libuv.so.1
No symbol table info available.
#9 0x00007f0c5922aa74 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#10 0x00007f0c5b841792 in loop_thread (arg=arg@entry=0x7f0c53e91800) at loop.c:282
loop = 0x7f0c53e91800
r = <optimized out>
__func__ = "loop_thread"
ret = <optimized out>
#11 0x00007f0c5b850469 in thread_body (wrap=0xf1a3e0) at thread.c:85
func = 0x7f0c5b841707 <loop_thread>
arg = 0x7f0c53e91800
ret = 0x0
jemalloc_enforce_init = 0xf1a410
#12 0x00007f0c5b8504e3 in isc_thread_main (func=func@entry=0x7f0c5b841707 <loop_thread>, arg=0x7f0c53e91800) at thread.c:116
No locals.
#13 0x00007f0c5b84271a in isc_loopmgr_run (loopmgr=0x7f0c53e11540) at loop.c:454
__func__ = "isc_loopmgr_run"
#14 0x0000000000425995 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1580
result = <optimized out>
Thread 2 (Thread 0x7f0c5347f700 (LWP 55766)):
#0 0x00007f0c580ff60e in pthread_barrier_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f0c5b8416f9 in resume_loop (loop=0x7f0c53e92080) at loop.c:114
loopmgr = <optimized out>
loopmgr = <optimized out>
#2 pauseresume_cb (handle=<optimized out>) at loop.c:114
loop = 0x7f0c53e92080
#3 0x00007f0c5922a2f1 in uv.async_io.part () from /lib64/libuv.so.1
No symbol table info available.
#4 0x00007f0c5923bd15 in uv.io_poll () from /lib64/libuv.so.1
No symbol table info available.
#5 0x00007f0c5922aa74 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#6 0x00007f0c5b841792 in loop_thread (arg=arg@entry=0x7f0c53e92080) at loop.c:282
loop = 0x7f0c53e92080
r = <optimized out>
__func__ = "loop_thread"
ret = <optimized out>
#7 0x00007f0c5b850469 in thread_body (wrap=wrap@entry=0xf19710) at thread.c:85
func = 0x7f0c5b841707 <loop_thread>
arg = 0x7f0c53e92080
ret = 0x0
jemalloc_enforce_init = 0x7f0c4c000b60
#8 0x00007f0c5b850492 in thread_run (wrap=0xf19710) at thread.c:100
ret = <optimized out>
#9 0x00007f0c580f81da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#10 0x00007f0c573cbe73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 1 (Thread 0x7f0c3c87e700 (LWP 55771)):
#0 0x00007f0c573e0b8f in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f0c573b3ea5 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x0000000000422efd in assertion_failed (file=0x7f0c5b3eb932 "view.c", line=429, type=isc_assertiontype_insist, cond=0x7f0c5b3c1f70 "__v > 0 && __v < (4294967295U)") at main.c:234
No locals.
#3 0x00007f0c5b82df3b in isc_assertion_failed (file=file@entry=0x7f0c5b3eb932 "view.c", line=line@entry=429, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7f0c5b3c1f70 "__v > 0 && __v < (4294967295U)") at assertions.c:48
No locals.
#4 0x00007f0c5b36c3f1 in dns_view_attach (source=source@entry=0x7f0c538cfc00, targetp=targetp@entry=0x7f0c3a20e4c8) at view.c:431
__v = <optimized out>
#5 0x000000000042ba15 in catz_run (entry=0x7f0c39e25000, origin=origin@entry=0x7f0c53e88540, view=0x7f0c538cfc00, udata=0x680670 <ns_catz_cbdata>, type=type@entry=CATZ_DELZONE) at server.c:2956
cz = 0x7f0c3a20e4b0
action = 0x42baf4 <catz_delzone_cb>
#6 0x000000000042ba6e in catz_delzone (entry=<optimized out>, origin=origin@entry=0x7f0c53e88540, view=<optimized out>, udata=<optimized out>) at server.c:2972
No locals.
#7 0x00007f0c5b244c2b in dns__catz_zones_merge (catz=0x7f0c53e88540, newcatz=0x7f0c3a211000) at catz.c:696
entry = 0x7f0c39e25000
result = ISC_R_SUCCESS
iter1 = 0x0
iter2 = 0x7f0c3a21e060
iteradd = 0x7f0c3a21e040
itermod = 0x7f0c3a21e020
toadd = 0x7f0c53e6aa30
tomod = 0x7f0c53e6a9e0
delcur = <optimized out>
czname = "catalog-tls.example\000\f\177\000\000\240\340tW\f\177\000\000\000\000\000\000\000\000\000\000\212\067HW\f\177\000\000@\000\000\000\000\000\000\000\000\006\"s\223>Z\177 \260\207<\f\177\000\000\034\024\205[\f\177\000\000\067\000\000\000\037\000\000\000\016\000\000\000\026\000\000\000\b\000\000\000{\000\000\000\001\000\000\000\000\000\000\000P\262\207<\f\177\000\000\365\016\204[\f\177\000\000{e\206[\f\177\000\000\000&uW\f\177\000\000\240\343tW\f\177\000\000Pl\205[\f\177\000\000{e\206[\f\177\000\000\000\000\000\000\000\000\000\000P\262\207<\f\177\000\000\300\b\204[\f\177\000\000H\361\350S\f\177\000\000"...
zname = "tls1.example\000\177\000\000\377", '\000' <repeats 23 times>, '\377' <repeats 16 times>, '\000' <repeats 24 times>, "`\330tW\f\177\000\000\000\006\"s\223>Z\177\000&uW\f\177\000\000\207(\255\373\000\000\000\000\360\200\346S\f\177\000\000\060\264\207<\f\177\000\000!fuB\000\000\000\000\240\253\207<\f\177\000\000\377", '\000' <repeats 23 times>, '\377' <repeats 16 times>, "\000\006\"s\223>Z\177\340\253\207<\f\177\000\000\000"...
addzone = 0x42ba81 <catz_addzone>
modzone = 0x42ba70 <catz_modzone>
delzone = 0x42ba5f <catz_delzone>
__func__ = "dns__catz_zones_merge"
#8 0x00007f0c5b248106 in dns__catz_update_cb (data=<optimized out>) at catz.c:2467
catz = <optimized out>
updb = <optimized out>
catzs = <optimized out>
oldcatz = 0x7f0c53e88540
newcatz = 0x7f0c3a211000
result = ISC_R_SHUTTINGDOWN
r = <optimized out>
node = 0x0
vers_node = 0x0
updbit = 0x0
fixname = {name = {magic = 1145983854, ndata = 0x0, length = 0, labels = 0, attributes = {absolute = false, readonly = false, dynamic = false, dynoffsets = false, nocompress = false, cache = false, answer = false, ncache = false, chaining = false, chase = false, wildcard = false, prerequisite = false, update = false, hasupdaterec = false}, offsets = 0x7f0c3c87bf40 "", buffer = 0x7f0c3c87bfc0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0, tail = 0x0}}, offsets = "\000\b\024\034", '\000' <repeats 123 times>, buffer = {magic = 1114990113, base = 0x7f0c3c87c000, length = 255, used = 0, current = 0, active = 0, extra = 0, dynamic = false, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0}, data = "\aversion\vcatalog-tls\aexample", '\000' <repeats 36 times>, "!fuB\000\000\000\000@y\":\f\177\000\000\000\000\002\000\016", '\000' <repeats 19 times>, '\377' <repeats 16 times>, "\000\000\000\000\000\000\000\000!fuB", '\000' <repeats 20 times>, ")\253\017X\f\177\000\000\000\000\000\000\000\000\000\000\n\000\000\000\000\000\000\000\200\322\326W\f\177\000\000\000\000\000\000\000\000\000\000\066\303\017X\f\177\000\000\000"...}
name = 0x7f0c3c87bef0
rdsiter = 0x0
rdataset = {magic = 1145983826, methods = 0x0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, rdclass = 0, type = 0, ttl = 0, trust = 0, covers = 0, attributes = 0, count = 4294967295, resign = 0, {keytable = {node = 0x0, iter = 0x0}, ncache = {raw = 0x0, iter_pos = 0x0, iter_count = 0}, slab = {db = 0x0, node = 0x0, raw = 0x0, iter_pos = 0x0, iter_count = 0, noqname = 0x0, closest = 0x0}, rdlist = {list = 0x0, iter = 0x0, noqname = 0x0, closest = 0x0, node = 0x0}, rps = {db = 0x0, iter_pos = 0x0, iter_count = 0}}}
bname = "catalog-tls.example", '\000' <repeats 413 times>...
cname = "\000\274\207<\f\177\000\000\001\000\000\000\001\000\000\000@y\":\f\177", '\000' <repeats 19 times>, "\204$:\f\177\000\000\000\340$:\f\177", '\000' <repeats 11 times>, "~`@\f\177", '\000' <repeats 18 times>, "\340\300\207<\f\177\000\000\200\250\340S\f\177\000\000\000\000\000\000\000\000\000\000 \200d@\f\177\000\000\020", '\000' <repeats 311 times>...
is_vers_processed = <optimized out>
is_active = true
vers = 2
catz_vers = <optimized out>
__func__ = "dns__catz_update_cb"
#9 0x00007f0c5b856976 in isc__work_cb (req=<optimized out>) at work.c:30
work = 0x7f0c53e6dbe0
#10 0x00007f0c592254ee in worker () from /lib64/libuv.so.1
No symbol table info available.
#11 0x00007f0c580f81da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#12 0x00007f0c573cbe73 in clone () from /lib64/libc.so.6
No symbol table info available.
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Ondřej SurýOndřej Surýhttps://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/4320allow shorter resolver-query-timeout configuration2023-09-15T14:18:22ZPetr Špačekpspacek@isc.orgallow shorter resolver-query-timeout configuration### Use-case
Weird network setup:
* Load balancer is listed in NS RR set like this:`example.com NS load-balancer.example.com`
* The load balancer sets RD=1 and forwards query to a BIND **resolver**
* The BIND **resolver** is then configu...### Use-case
Weird network setup:
* Load balancer is listed in NS RR set like this:`example.com NS load-balancer.example.com`
* The load balancer sets RD=1 and forwards query to a BIND **resolver**
* The BIND **resolver** is then configured to talk to backend servers which are not visible in the public NS set
### Description
If/when the auths don't keep up with load from the BIND resolver "frontend", the resolver will retry several times during [resolver-query-timeout](https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-resolver-query-timeout) interval, which currently has minimum value of 10 s.
At the same time, the client which sent the original query will timeout because it is not expecting any auth to take 10 seconds to respond. This means the frontend BIND will be doing mostly pointless work, and that the client will penalize BIND-frontend in client's ADB (address database) because it will believe the BIND frontend just times out, while it will give back SERVFAIL, but only after 10 seconds.
See https://indico.dns-oarc.net/event/47/contributions/1018/ for more details.
### Request
When BIND is used in this weird scenario it's pointless to have `resolver-query-timeout` set to 10 s. It should allow configuration to be something like 0.5 seconds because communication with backends should be really fast. With such configuration BIND-frontend can give back SERVFAIL early when backends are not available and the ultimate client will not penalize the BIND-frontend for non-response.
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4318Check the size of the structure passed to dns_rdata_*struct methods2024-01-03T13:35:03ZMark AndrewsCheck the size of the structure passed to dns_rdata_*struct methods#4314 made me think we should check the size of the structure being passed to dns_rdata_tostruct, dns_rdata_fromstruct, and dns_rdata_freestruct as we don't have the compiler doing type checks for us. It there is a mismatch badness coul...#4314 made me think we should check the size of the structure being passed to dns_rdata_tostruct, dns_rdata_fromstruct, and dns_rdata_freestruct as we don't have the compiler doing type checks for us. It there is a mismatch badness could happen.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4315CID 465566-465575: Passing tainted expression "*name.ndata" to "name_prefix"2023-11-02T09:19:55ZMichal NowakCID 465566-465575: Passing tainted expression "*name.ndata" to "name_prefix"Coverity Scan claims several `TAINTED_SCALAR` CIDs on `main` in `lib/dns/rdata/`.
```
** CID 465575: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID ...Coverity Scan claims several `TAINTED_SCALAR` CIDs on `main` in `lib/dns/rdata/`.
```
** CID 465575: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465575: (TAINTED_SCALAR)
/lib/dns/rdata/generic/afsdb_18.c: 88 in totext_afsdb()
82 dns_rdata_toregion(rdata, ®ion);
83 num = uint16_fromregion(®ion);
84 isc_region_consume(®ion, 2);
85 snprintf(buf, sizeof(buf), "%u ", num);
86 RETERR(str_totext(buf, target));
87 dns_name_fromregion(&name, ®ion);
>>> CID 465575: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
88 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
89 : 0;
90 return (dns_name_totext(&prefix, opts, target));
91 }
92
93 static isc_result_t
/lib/dns/rdata/generic/afsdb_18.c: 88 in totext_afsdb()
82 dns_rdata_toregion(rdata, ®ion);
83 num = uint16_fromregion(®ion);
84 isc_region_consume(®ion, 2);
85 snprintf(buf, sizeof(buf), "%u ", num);
86 RETERR(str_totext(buf, target));
87 dns_name_fromregion(&name, ®ion);
>>> CID 465575: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
88 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
89 : 0;
90 return (dns_name_totext(&prefix, opts, target));
91 }
92
93 static isc_result_t
** CID 465574: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465574: (TAINTED_SCALAR)
/lib/dns/rdata/in_1/svcb_64.c: 689 in generic_totext_in_svcb()
683
684 /*
685 * TargetName.
686 */
687 dns_name_fromregion(&name, ®ion);
688 isc_region_consume(®ion, name_length(&name));
>>> CID 465574: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
689 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
690 : 0;
691 RETERR(dns_name_totext(&prefix, opts, target));
692
693 while (region.length > 0) {
694 isc_region_t r;
/lib/dns/rdata/in_1/svcb_64.c: 689 in generic_totext_in_svcb()
683
684 /*
685 * TargetName.
686 */
687 dns_name_fromregion(&name, ®ion);
688 isc_region_consume(®ion, name_length(&name));
>>> CID 465574: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
689 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
690 : 0;
691 RETERR(dns_name_totext(&prefix, opts, target));
692
693 while (region.length > 0) {
694 isc_region_t r;
** CID 465573: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465573: (TAINTED_SCALAR)
/lib/dns/rdata/in_1/kx_36.c: 77 in totext_in_kx()
71 snprintf(buf, sizeof(buf), "%u", num);
72 RETERR(str_totext(buf, target));
73
74 RETERR(str_totext(" ", target));
75
76 dns_name_fromregion(&name, ®ion);
>>> CID 465573: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
77 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
78 : 0;
79 return (dns_name_totext(&prefix, opts, target));
80 }
81
82 static isc_result_t
/lib/dns/rdata/in_1/kx_36.c: 77 in totext_in_kx()
71 snprintf(buf, sizeof(buf), "%u", num);
72 RETERR(str_totext(buf, target));
73
74 RETERR(str_totext(" ", target));
75
76 dns_name_fromregion(&name, ®ion);
>>> CID 465573: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
77 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
78 : 0;
79 return (dns_name_totext(&prefix, opts, target));
80 }
81
82 static isc_result_t
** CID 465572: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465572: (TAINTED_SCALAR)
/lib/dns/rdata/generic/mx_15.c: 123 in totext_mx()
117 snprintf(buf, sizeof(buf), "%u", num);
118 RETERR(str_totext(buf, target));
119
120 RETERR(str_totext(" ", target));
121
122 dns_name_fromregion(&name, ®ion);
>>> CID 465572: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
123 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
124 : 0;
125 return (dns_name_totext(&prefix, opts, target));
126 }
127
128 static isc_result_t
/lib/dns/rdata/generic/mx_15.c: 123 in totext_mx()
117 snprintf(buf, sizeof(buf), "%u", num);
118 RETERR(str_totext(buf, target));
119
120 RETERR(str_totext(" ", target));
121
122 dns_name_fromregion(&name, ®ion);
>>> CID 465572: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
123 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
124 : 0;
125 return (dns_name_totext(&prefix, opts, target));
126 }
127
128 static isc_result_t
** CID 465571: Insecure data handling (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465571: Insecure data handling (TAINTED_SCALAR)
/lib/dns/rdata/any_255/tsig_250.c: 525 in tostruct_any_tsig()
519 isc_region_consume(&sr, 2);
520
521 /*
522 * Other.
523 */
524 INSIST(sr.length == tsig->otherlen);
>>> CID 465571: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted expression "tsig->otherlen" to "mem_maybedup", which uses it as an offset.
525 tsig->other = mem_maybedup(mctx, sr.base, tsig->otherlen);
526
527 tsig->mctx = mctx;
528 return (ISC_R_SUCCESS);
529 }
530
** CID 465570: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465570: (TAINTED_SCALAR)
/lib/dns/rdata/generic/lp_107.c: 77 in totext_lp()
71 snprintf(buf, sizeof(buf), "%u", num);
72 RETERR(str_totext(buf, target));
73
74 RETERR(str_totext(" ", target));
75
76 dns_name_fromregion(&name, ®ion);
>>> CID 465570: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
77 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
78 : 0;
79 return (dns_name_totext(&prefix, opts, target));
80 }
81
82 static isc_result_t
/lib/dns/rdata/generic/lp_107.c: 77 in totext_lp()
71 snprintf(buf, sizeof(buf), "%u", num);
72 RETERR(str_totext(buf, target));
73
74 RETERR(str_totext(" ", target));
75
76 dns_name_fromregion(&name, ®ion);
>>> CID 465570: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
77 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
78 : 0;
79 return (dns_name_totext(&prefix, opts, target));
80 }
81
82 static isc_result_t
** CID 465569: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465569: (TAINTED_SCALAR)
/lib/dns/rdata/in_1/px_26.c: 98 in totext_in_px()
92 RETERR(str_totext(" ", target));
93
94 /*
95 * MAP822.
96 */
97 dns_name_fromregion(&name, ®ion);
>>> CID 465569: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
98 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
99 : 0;
100 isc_region_consume(®ion, name_length(&name));
101 RETERR(dns_name_totext(&prefix, opts, target));
102 RETERR(str_totext(" ", target));
103
/lib/dns/rdata/in_1/px_26.c: 98 in totext_in_px()
92 RETERR(str_totext(" ", target));
93
94 /*
95 * MAP822.
96 */
97 dns_name_fromregion(&name, ®ion);
>>> CID 465569: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
98 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
99 : 0;
100 isc_region_consume(®ion, name_length(&name));
101 RETERR(dns_name_totext(&prefix, opts, target));
102 RETERR(str_totext(" ", target));
103
** CID 465568: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465568: (TAINTED_SCALAR)
/lib/dns/rdata/generic/rt_21.c: 85 in totext_rt()
79 num = uint16_fromregion(®ion);
80 isc_region_consume(®ion, 2);
81 snprintf(buf, sizeof(buf), "%u", num);
82 RETERR(str_totext(buf, target));
83 RETERR(str_totext(" ", target));
84 dns_name_fromregion(&name, ®ion);
>>> CID 465568: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
85 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
86 : 0;
87 return (dns_name_totext(&prefix, opts, target));
88 }
89
90 static isc_result_t
/lib/dns/rdata/generic/rt_21.c: 85 in totext_rt()
79 num = uint16_fromregion(®ion);
80 isc_region_consume(®ion, 2);
81 snprintf(buf, sizeof(buf), "%u", num);
82 RETERR(str_totext(buf, target));
83 RETERR(str_totext(" ", target));
84 dns_name_fromregion(&name, ®ion);
>>> CID 465568: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
85 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
86 : 0;
87 return (dns_name_totext(&prefix, opts, target));
88 }
89
90 static isc_result_t
** CID 465567: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465567: (TAINTED_SCALAR)
/lib/dns/rdata/in_1/srv_33.c: 137 in totext_in_srv()
131 RETERR(str_totext(" ", target));
132
133 /*
134 * Target.
135 */
136 dns_name_fromregion(&name, ®ion);
>>> CID 465567: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
137 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
138 : 0;
139 return (dns_name_totext(&prefix, opts, target));
140 }
141
142 static isc_result_t
/lib/dns/rdata/in_1/srv_33.c: 137 in totext_in_srv()
131 RETERR(str_totext(" ", target));
132
133 /*
134 * Target.
135 */
136 dns_name_fromregion(&name, ®ion);
>>> CID 465567: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
137 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
138 : 0;
139 return (dns_name_totext(&prefix, opts, target));
140 }
141
142 static isc_result_t
** CID 465566: (TAINTED_SCALAR)
________________________________________________________________________________________________________
*** CID 465566: (TAINTED_SCALAR)
/lib/dns/rdata/generic/naptr_35.c: 299 in totext_naptr()
293 RETERR(str_totext(" ", target));
294
295 /*
296 * Replacement.
297 */
298 dns_name_fromregion(&name, ®ion);
>>> CID 465566: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
299 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
300 : 0;
301 return (dns_name_totext(&prefix, opts, target));
302 }
303
304 static isc_result_t
/lib/dns/rdata/generic/naptr_35.c: 299 in totext_naptr()
293 RETERR(str_totext(" ", target));
294
295 /*
296 * Replacement.
297 */
298 dns_name_fromregion(&name, ®ion);
>>> CID 465566: (TAINTED_SCALAR)
>>> Passing tainted expression "*name.ndata" to "name_prefix", which uses it as a loop boundary.
299 opts = name_prefix(&name, tctx->origin, &prefix) ? DNS_NAME_OMITFINALDOT
300 : 0;
301 return (dns_name_totext(&prefix, opts, target));
302 }
303
304 static isc_result_t
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4313automate root.hints up-to-date check2023-09-12T13:12:02ZPetr Špačekpspacek@isc.orgautomate root.hints up-to-date check### Problem
Right now root.hints file content is hardcoded into lib/dns/rootns.c, and not checked in any automated way I know of.
### Request
Use some automated process to check content of the file. E.g. a new job in the scheduled pip...### Problem
Right now root.hints file content is hardcoded into lib/dns/rootns.c, and not checked in any automated way I know of.
### Request
Use some automated process to check content of the file. E.g. a new job in the scheduled pipeline which would check content of the file against https://www.internic.net/domain/db.cache or something like that.
### Links / references