BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-03-25T13:45:40Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4649All TSAN-enabled builds fail in AWS-based GitLab CI jobs2024-03-25T13:45:40ZMichał KępieńAll TSAN-enabled builds fail in AWS-based GitLab CI jobs[Yesterday's mass-rebuild of Docker images][1] caused some update to be
pulled into `tsan-fedora-39-amd64` that does not play nicely with AWS
hosts because all TSAN-enabled builds now fail with an error message
like:
FATAL: ThreadSa...[Yesterday's mass-rebuild of Docker images][1] caused some update to be
pulled into `tsan-fedora-39-amd64` that does not play nicely with AWS
hosts because all TSAN-enabled builds now fail with an error message
like:
FATAL: ThreadSanitizer: unexpected memory mapping 0x7d00e0772000-0x7d00e0c00000
While it is not clear what exactly happened, here are two jobs that were
run in CI for the same commit:
- [2024-03-20 14:24, passed][2]
- [2024-03-20 16:41, failed][3]
The refreshed TSAN image was pushed to the container registry at 15:13.
The TSAN builds seemingly still work fine with the refreshed TSAN image
on our bare metal runners, which use older kernels. This is consistent
with similar reports found online:
https://stackoverflow.com/questions/77850769/fatal-threadsanitizer-unexpected-memory-mapping-when-running-on-linux-kernels
The simplest course of action is to apply the workaround mentioned in
the StackOverflow post above (`sysctl vm.mmap_rnd_bits=28`) and remove
it once the issue resolves itself as kernels and packages get updated
over time.
[1]: https://gitlab.isc.org/isc-projects/images/-/pipelines/168133
[2]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/4142725
[3]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/4143237April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4641dig +ednsflags does not re-enable EDNS2024-03-17T03:12:44ZMark Andrewsdig +ednsflags does not re-enable EDNS+dnssec, +nsid re-enable EDNS if currently disabled. +ednsflags should do the same+dnssec, +nsid re-enable EDNS if currently disabled. +ednsflags should do the sameApril 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4640Checkzone in system test leaks queries2024-03-21T02:40:22ZMark AndrewsCheckzone in system test leaks queriesThe checkzone "checking with max ttl (text)" test leaks queries.The checkzone "checking with max ttl (text)" test leaks queries.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4633Undefined behaviour in rdataslab.c2024-03-21T12:20:05ZMark AndrewsUndefined behaviour in rdataslab.cmemmove can be called with a NULL source pointer if the rdata length is zero. This is triggers undefined behaviour.memmove can be called with a NULL source pointer if the rdata length is zero. This is triggers undefined behaviour.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4624Invalid durations in configuration files do not cause a syntax error2024-03-14T12:54:59ZMatthijs Mekkingmatthijs@isc.orgInvalid durations in configuration files do not cause a syntax errorFor example: `signatures-refresh P7.5D;` is accepted but treated as `P7D`.For example: `signatures-refresh P7.5D;` is accepted but treated as `P7D`.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4621rndc flush make cache pruning no-op2024-03-08T11:44:42ZOndřej Surýrndc flush make cache pruning no-opWhen `rndc flush` (e.g. `dns_cache_flush()`) is called, the task is not set for the rbtdb which makes the cache pruning basically no-op, piling up the parent nodes that could not be sweeped together with the child nodes.When `rndc flush` (e.g. `dns_cache_flush()`) is called, the task is not set for the rbtdb which makes the cache pruning basically no-op, piling up the parent nodes that could not be sweeped together with the child nodes.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4608Ensure static stub NS records are not returned2024-03-14T04:33:38ZMark AndrewsEnsure static stub NS records are not returnedstatic-stub synthesises NS record which shouldn't be returned to clients. Normally the NS records from the actual zone will be returned but not always.
- Setup a static-stub for "com" and disable minimal responses.
- query for foo.com ...static-stub synthesises NS record which shouldn't be returned to clients. Normally the NS records from the actual zone will be returned but not always.
- Setup a static-stub for "com" and disable minimal responses.
- query for foo.com NS (TTL is 600)
- wait 120 seconds
- query for foo.com A (TTL is 600)
- wait 500 seconds
- query for foo.com A
```
; <<>> DiG 9.19.20-dev <<>> foo.com -p 5555
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18858
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: dddb220761d487fa0100000065dec10ee6a221e99d9baa11 (good)
;; QUESTION SECTION:
;foo.com. IN A
;; ANSWER SECTION:
foo.com. 100 IN A 34.206.39.153
;; AUTHORITY SECTION:
com. 86400 IN NS com.
;; Query time: 2 msec
;; SERVER: ::1#5555(::1) (UDP)
;; WHEN: Wed Feb 28 16:13:50 AEDT 2024
;; MSG SIZE rcvd: 94
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4604Fix initial tests in masterfile system test2024-03-08T11:12:54ZMark AndrewsFix initial tests in masterfile system testAll three of the initial tests should have a known good output to test against.
The BIND 8 tests should be testing against ttl1.
There should be independent failure reporting for the first three tests.All three of the initial tests should have a known good output to test against.
The BIND 8 tests should be testing against ttl1.
There should be independent failure reporting for the first three tests.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4596Regression in cache cleaning2024-03-08T11:20:36ZOndřej SurýRegression in cache cleaningThere's an regression introduced in the fix to #4383 that causes the cache memory to clean too slow, so busy resolvers can run out of configured cache memory by not cleaning expired (TTL-expired) records to be not cleaned from the memory...There's an regression introduced in the fix to #4383 that causes the cache memory to clean too slow, so busy resolvers can run out of configured cache memory by not cleaning expired (TTL-expired) records to be not cleaned from the memory fast enough.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4595Regression in change for CVE-2023-5680 that can cause named to crash2024-03-08T11:03:30ZCathy AlmondRegression in change for CVE-2023-5680 that can cause named to crashReported to us by an OEM customer who integrates BIND into their own appliance and redistributes:
> NOTE: you might find this as a security issue.
>
> We believe we've identified the likely cause of the crash. It's a regression due to ...Reported to us by an OEM customer who integrates BIND into their own appliance and redistributes:
> NOTE: you might find this as a security issue.
>
> We believe we've identified the likely cause of the crash. It's a regression due to the change for CVE-2023-5680. I've added a patch to a unit test for BIND 9.18.24-S1 that can reproduce the crash. I confirmed the crash happened for 9.18.24-S1 and 9.16.48-S1. One straightforward fix is the other patch I've attached to this ticket.
>
> I believe an engineer familiar with the code base can understand how it happens by reading the patch (it has a lot of comments explaining it), so I won't repeat it here. But I'd note one thing: the introduction of the "old IP tree" breaks one critical assumption: when a node's last reference is released, the cleanup makes sure that there is no rdatasetheader that would still have to be cleaned up (such as an expired cache entry). With this, and the fact that whenerver an rdatasetheader makes a node dirty either a node (read or rw) lock is acquired or a node's reference is increased from 0, it was previously guaranteed that overmem purge never frees other entries that the purge code may reference later. Now that the basic assumption is broken, we now have this crash, and there might be other such cases.
>
> I've not tried to reproduce a crash using a `named` executable, but the unit test indicates it's probably possible to trigger the crash by an external attacker, albeit with some high barriers such as being listed as an "ecs-zone" in the named's configuration. You may want to deal with this case as such.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4591TTL-based cache cleaning in rbtdb ineffective (M/N problem)2024-03-20T13:50:45ZOndřej SurýTTL-based cache cleaning in rbtdb ineffective (M/N problem)Copying stuff from MatterMost for permanent record:
How it started?
> @ondrej: But I don't know actually - if there's something blocking the top of the heap to be cleaned up (dunno why yet), it could block cleaning everything else behin...Copying stuff from MatterMost for permanent record:
How it started?
> @ondrej: But I don't know actually - if there's something blocking the top of the heap to be cleaned up (dunno why yet), it could block cleaning everything else behind it
So, here's a summary of our finding
The TTL based cleaning is opportunistic. When we are inserting a new node, we look at the top of the heap ("list sorted by TTL-value") and if TTL of the top of the heap is expired, we try to eradicate the data it stores from the cache. The code that decides whether we will do the TTL-based cleaning looks like this:
```c
header = isc_heap_element(rbtdb->heaps[rbtnode->locknum], 1);
if (header != NULL) {
dns_ttl_t rdh_ttl = header->rdh_ttl;
/* Only account for stale TTL if cache is not overmem */
if (!cache_is_overmem) {
rdh_ttl += STALE_TTL(header, rbtdb);
}
if (rdh_ttl < now - RBTDB_VIRTUAL) {
expire_header(rbtdb, header, tree_locked,
expire_ttl);
}
}
```
Now, the RBTDB_VIRTUAL is this:
```
/*
* Allow clients with a virtual time of up to 5 minutes in the past to see
* records that would have otherwise have expired.
*/
#define RBTDB_VIRTUAL 300
```
Which means that even with 0 TTL records, the TTL-based cleaning will not kick-in until 5 minutes has passed.
Now what happens if you insert N records (where N could be large) within the first 5 minutes (cold bootstrap)?
After 5 minutes the TTL based cleaning should kick-in, but that's only if everything in the cache has expired, but even with that.
If we insert M records in the next minute, only M records will gets cleaned at maximum.
But anything that has longer TTL will just add to N, so the backlog of the records that are not subject to the TTL-based cleaning will build up over time until we are overmem and LRU based cleaning kicks in.
Additionally, @ondrej found out that there are records with `rdh_ttl` set to `0` if you just run `dnsperf` on a cold cache resolver, which made us puzzled - shouldn't we be cleaning records only after 5 minutes?
@michal did some excellent work and found out following:
so, i looked at those "zero TTL" frees that happen very shortly into the start of regular resolver operation
turns out that these are "superseded" headers
now, i don't understand why RBTDB does that. but it's this branch in add32() that expires these headers: https://gitlab.isc.org/isc-projects/bind9/-/blob/8fb49c5a8acdb37d4f4be0c5f5b19645d0103f48/lib/dns/rbtdb.c#L6677-6714
basically, AFAICT, what happens here is:
resolver: hey, RBTDB, add this shiny new SOA rdataset header to the cache
RBTDB: oh okay, let me see if i have a SOA header on that node already...
RBTDB: yup, got one. i'll just expire the one i had in there before (topheader) and insert the new one you gave me (newheader).
what i don't understand is why it just doesn't leave that old (identical, AFAICT) rdataset intact. but i'll move on with the reasoning for now.
so, the "previously-topmost" SOA header has its TTL set to zero, so it lands on the top of one of the TTL heaps
once we add a new rdataset, it should be cleaned up. but, as we already established yesterday, that only happens if the reference count of its node is zero.
meanwhile, in my very basic test (literally seconds into firing up dnsperf with the query set we use for respdiff tests, at some 1 kQPS), those rdatasets at the top of the heap are for nodes like net. or com. whose reference counts are around 60, or maybe 80 references. and until that count goes to zero, the first rdataset on the TTL heap will not disappear from there, blocking any rdataset headers on the same TTL heap from being cleaned up as well (backlog)
so, i thought "how bad is it and can we measure it?" and oh, boy, he could:
```
20-Feb-2024 10:46:29.561 connection refused resolving 'geo.fortinet.net/NS/IN': 104.198.248.186#53
20-Feb-2024 10:46:29.564 DNS format error from 203.205.195.75#53 resolving ns3.qq.com/AAAA for <unknown>: Name qq.com (SOA) not subdomain of zone ns3.qq.com -- invalid response
20-Feb-2024 10:46:29.564 FORMERR resolving 'ns3.qq.com/AAAA/IN': 203.205.195.75#53
20-Feb-2024 10:46:29.564 DNS format error from 108.136.87.44#53 resolving api.cloud.huawei.com/AAAA for 127.0.0.1#34840: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
20-Feb-2024 10:46:29.564 FORMERR resolving 'api.cloud.huawei.com/AAAA/IN': 108.136.87.44#53
-- 0 msecs since expiry
-- 0 msecs since expiry
-- 106 msecs since expiry
-- 106 msecs since expiry
-- 29 msecs since expiry
-- 29 msecs since expiry
20-Feb-2024 10:46:29.574 success resolving 'a.karma.sc2.fsapi.com/A' after disabling qname minimization due to 'ncache nxdomain'
-- 243 msecs since expiry
-- 246 msecs since expiry
-- 249 msecs since expiry
-- 433 msecs since expiry
-- 806 msecs since expiry
-- 813 msecs since expiry
-- 243 msecs since expiry
-- 246 msecs since expiry
-- 249 msecs since expiry
-- 433 msecs since expiry
-- 806 msecs since expiry
-- 0 msecs since expiry
-- 816 msecs since expiry
-- 816 msecs since expiry
-- 123 msecs since expiry
-- 323 msecs since expiry
-- 123 msecs since expiry
-- 323 msecs since expiry
20-Feb-2024 10:46:29.601 success resolving 'F00DCFRIBM41.zf.if.atcsg.net/A' after disabling qname minimization due to 'ncache nxdomain'
20-Feb-2024 10:46:29.624 REFUSED unexpected RCODE resolving 'cloud.Jensen.com.cn/NS/IN': 47.118.199.194#53
-- 0 msecs since expiry
-- 0 msecs since expiry
20-Feb-2024 10:46:29.677 DNS format error from 3.97.163.50#53 resolving api.cloud.huawei.com/AAAA for 127.0.0.1#34840: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
20-Feb-2024 10:46:29.677 FORMERR resolving 'api.cloud.huawei.com/AAAA/IN': 3.97.163.50#53
-- 6 msecs since expiry
-- 3 msecs since expiry
-- 9 msecs since expiry
-- 0 msecs since expiry
20-Feb-2024 10:46:29.801 REFUSED unexpected RCODE resolving 'cloud.Jensen.com.cn/NS/IN': 39.96.153.33#53
-- 3 msecs since expiry
-- 3 msecs since expiry
-- 46 msecs since expiry
-- 19 msecs since expiry
-- 0 msecs since expiry
-- 39 msecs since expiry
-- 0 msecs since expiry
-- 0 msecs since expiry
-- 3 msecs since expiry
-- 3 msecs since expiry
-- 126 msecs since expiry
-- 0 msecs since expiry
-- 0 msecs since expiry
-- 0 msecs since expiry
20-Feb-2024 10:46:30.104 REFUSED unexpected RCODE resolving 'cloud.Jensen.com.cn/NS/IN': 139.224.142.104#53
-- 286 msecs since expiry
-- 0 msecs since expiry
-- 69 msecs since expiry
-- 13 msecs since expiry
20-Feb-2024 10:46:30.307 success resolving 'hcdnd.csfw.c.cdnhwc6.com/AAAA' after disabling qname minimization due to 'ncache nxdomain'
-- 0 msecs since expiry
-- 199 msecs since expiry
-- 269 msecs since expiry
-- 656 msecs since expiry
-- 689 msecs since expiry
-- 746 msecs since expiry
-- 789 msecs since expiry
-- 816 msecs since expiry
-- 819 msecs since expiry
-- 819 msecs since expiry
-- 839 msecs since expiry
-- 853 msecs since expiry
-- 873 msecs since expiry
-- 876 msecs since expiry
-- 889 msecs since expiry
-- 896 msecs since expiry
-- 896 msecs since expiry
-- 916 msecs since expiry
-- 936 msecs since expiry
-- 956 msecs since expiry
-- 969 msecs since expiry
-- 979 msecs since expiry
-- 983 msecs since expiry
-- 999 msecs since expiry
-- 999 msecs since expiry
-- 1006 msecs since expiry
-- 1006 msecs since expiry
-- 1053 msecs since expiry
-- 1053 msecs since expiry
-- 1063 msecs since expiry
-- 1066 msecs since expiry
-- 1073 msecs since expiry
-- 1079 msecs since expiry
-- 1083 msecs since expiry
-- 1089 msecs since expiry
-- 1096 msecs since expiry
-- 1133 msecs since expiry
-- 1139 msecs since expiry
-- 1156 msecs since expiry
-- 1163 msecs since expiry
-- 1166 msecs since expiry
-- 1179 msecs since expiry
-- 1183 msecs since expiry
-- 1189 msecs since expiry
-- 1193 msecs since expiry
-- 1196 msecs since expiry
-- 1199 msecs since expiry
-- 1223 msecs since expiry
-- 1223 msecs since expiry
-- 1249 msecs since expiry
-- 1259 msecs since expiry
-- 1276 msecs since expiry
-- 1293 msecs since expiry
-- 1336 msecs since expiry
-- 1363 msecs since expiry
-- 1369 msecs since expiry
-- 1379 msecs since expiry
-- 1393 msecs since expiry
-- 1396 msecs since expiry
-- 1399 msecs since expiry
-- 1403 msecs since expiry
-- 1423 msecs since expiry
-- 1429 msecs since expiry
-- 1436 msecs since expiry
-- 1436 msecs since expiry
-- 1439 msecs since expiry
-- 1446 msecs since expiry
-- 1446 msecs since expiry
-- 1466 msecs since expiry
-- 1466 msecs since expiry
-- 1469 msecs since expiry
-- 1473 msecs since expiry
-- 1486 msecs since expiry
-- 1503 msecs since expiry
-- 1506 msecs since expiry
-- 1516 msecs since expiry
-- 1539 msecs since expiry
-- 1539 msecs since expiry
-- 1556 msecs since expiry
-- 1566 msecs since expiry
-- 1569 msecs since expiry
-- 1589 msecs since expiry
-- 1623 msecs since expiry
-- 1623 msecs since expiry
-- 1629 msecs since expiry
-- 1636 msecs since expiry
-- 1636 msecs since expiry
-- 1649 msecs since expiry
-- 1679 msecs since expiry
-- 1686 msecs since expiry
-- 1703 msecs since expiry
-- 1703 msecs since expiry
-- 1716 msecs since expiry
-- 1726 msecs since expiry
-- 1736 msecs since expiry
-- 1773 msecs since expiry
-- 1796 msecs since expiry
-- 1796 msecs since expiry
-- 1799 msecs since expiry
-- 1803 msecs since expiry
-- 1829 msecs since expiry
-- 1839 msecs since expiry
-- 1876 msecs since expiry
-- 1879 msecs since expiry
-- 1883 msecs since expiry
-- 1889 msecs since expiry
-- 1889 msecs since expiry
-- 1889 msecs since expiry
-- 1899 msecs since expiry
-- 1946 msecs since expiry
-- 1956 msecs since expiry
-- 1983 msecs since expiry
-- 2013 msecs since expiry
-- 2013 msecs since expiry
-- 2023 msecs since expiry
-- 2049 msecs since expiry
-- 2059 msecs since expiry
-- 2063 msecs since expiry
-- 2079 msecs since expiry
-- 2106 msecs since expiry
-- 2109 msecs since expiry
-- 2119 msecs since expiry
-- 2136 msecs since expiry
-- 2156 msecs since expiry
-- 2183 msecs since expiry
-- 2199 msecs since expiry
-- 2203 msecs since expiry
-- 2219 msecs since expiry
-- 2223 msecs since expiry
-- 2229 msecs since expiry
-- 2243 msecs since expiry
-- 2253 msecs since expiry
-- 2263 msecs since expiry
-- 2286 msecs since expiry
-- 2303 msecs since expiry
-- 2343 msecs since expiry
-- 2356 msecs since expiry
-- 2376 msecs since expiry
-- 2376 msecs since expiry
-- 2379 msecs since expiry
-- 2386 msecs since expiry
-- 2416 msecs since expiry
-- 2426 msecs since expiry
-- 2433 msecs since expiry
-- 2449 msecs since expiry
-- 2466 msecs since expiry
-- 2479 msecs since expiry
-- 2509 msecs since expiry
-- 2516 msecs since expiry
-- 2523 msecs since expiry
-- 2529 msecs since expiry
-- 2536 msecs since expiry
-- 2539 msecs since expiry
-- 2539 msecs since expiry
-- 2543 msecs since expiry
-- 2553 msecs since expiry
-- 2559 msecs since expiry
-- 2569 msecs since expiry
-- 2593 msecs since expiry
-- 2609 msecs since expiry
-- 2616 msecs since expiry
-- 2623 msecs since expiry
-- 2629 msecs since expiry
-- 2656 msecs since expiry
-- 2659 msecs since expiry
-- 2673 msecs since expiry
-- 2716 msecs since expiry
-- 2766 msecs since expiry
-- 2773 msecs since expiry
-- 2773 msecs since expiry
-- 2776 msecs since expiry
-- 2783 msecs since expiry
-- 2789 msecs since expiry
-- 2823 msecs since expiry
-- 2843 msecs since expiry
-- 2879 msecs since expiry
-- 2879 msecs since expiry
-- 2886 msecs since expiry
-- 2899 msecs since expiry
-- 2919 msecs since expiry
-- 2926 msecs since expiry
-- 2949 msecs since expiry
-- 2956 msecs since expiry
-- 2956 msecs since expiry
-- 2956 msecs since expiry
-- 2979 msecs since expiry
-- 2983 msecs since expiry
-- 2983 msecs since expiry
-- 2986 msecs since expiry
-- 3033 msecs since expiry
-- 3039 msecs since expiry
-- 3049 msecs since expiry
-- 3066 msecs since expiry
-- 3086 msecs since expiry
-- 3126 msecs since expiry
-- 3129 msecs since expiry
-- 3156 msecs since expiry
-- 3169 msecs since expiry
-- 3173 msecs since expiry
-- 3176 msecs since expiry
-- 3226 msecs since expiry
-- 3253 msecs since expiry
-- 3266 msecs since expiry
-- 3269 msecs since expiry
-- 3279 msecs since expiry
-- 3279 msecs since expiry
-- 3299 msecs since expiry
-- 3323 msecs since expiry
-- 3323 msecs since expiry
-- 3336 msecs since expiry
-- 3336 msecs since expiry
-- 3363 msecs since expiry
-- 3366 msecs since expiry
-- 3396 msecs since expiry
-- 3399 msecs since expiry
-- 3409 msecs since expiry
-- 3449 msecs since expiry
-- 3463 msecs since expiry
-- 3466 msecs since expiry
-- 3499 msecs since expiry
-- 0 msecs since expiry
-- 199 msecs since expiry
-- 269 msecs since expiry
-- 656 msecs since expiry
-- 689 msecs since expiry
-- 746 msecs since expiry
-- 789 msecs since expiry
-- 816 msecs since expiry
-- 819 msecs since expiry
-- 819 msecs since expiry
-- 839 msecs since expiry
-- 853 msecs since expiry
-- 873 msecs since expiry
-- 876 msecs since expiry
-- 889 msecs since expiry
-- 896 msecs since expiry
-- 896 msecs since expiry
-- 916 msecs since expiry
-- 936 msecs since expiry
-- 956 msecs since expiry
-- 969 msecs since expiry
-- 979 msecs since expiry
-- 983 msecs since expiry
-- 999 msecs since expiry
-- 999 msecs since expiry
-- 1006 msecs since expiry
-- 1006 msecs since expiry
-- 1053 msecs since expiry
-- 1053 msecs since expiry
-- 1063 msecs since expiry
-- 1066 msecs since expiry
-- 1073 msecs since expiry
-- 1079 msecs since expiry
-- 1083 msecs since expiry
-- 1089 msecs since expiry
-- 1096 msecs since expiry
-- 1133 msecs since expiry
-- 1139 msecs since expiry
-- 1156 msecs since expiry
-- 1163 msecs since expiry
-- 1166 msecs since expiry
-- 1179 msecs since expiry
-- 1183 msecs since expiry
-- 1189 msecs since expiry
-- 1196 msecs since expiry
-- 1199 msecs since expiry
-- 1203 msecs since expiry
-- 1226 msecs since expiry
-- 1226 msecs since expiry
-- 1253 msecs since expiry
-- 1263 msecs since expiry
-- 1279 msecs since expiry
-- 1296 msecs since expiry
-- 1339 msecs since expiry
-- 1366 msecs since expiry
-- 1373 msecs since expiry
-- 1383 msecs since expiry
-- 1396 msecs since expiry
-- 1399 msecs since expiry
-- 1403 msecs since expiry
-- 1406 msecs since expiry
-- 1426 msecs since expiry
-- 1433 msecs since expiry
-- 1439 msecs since expiry
-- 1439 msecs since expiry
-- 1443 msecs since expiry
-- 1449 msecs since expiry
-- 1449 msecs since expiry
-- 1469 msecs since expiry
-- 1469 msecs since expiry
-- 1473 msecs since expiry
-- 1476 msecs since expiry
-- 1489 msecs since expiry
-- 1506 msecs since expiry
-- 1509 msecs since expiry
-- 1519 msecs since expiry
-- 1543 msecs since expiry
-- 1543 msecs since expiry
-- 1559 msecs since expiry
-- 1569 msecs since expiry
-- 1573 msecs since expiry
-- 1593 msecs since expiry
-- 1626 msecs since expiry
-- 1626 msecs since expiry
-- 1633 msecs since expiry
-- 1639 msecs since expiry
-- 1639 msecs since expiry
-- 1653 msecs since expiry
-- 1683 msecs since expiry
-- 1689 msecs since expiry
-- 1706 msecs since expiry
-- 1706 msecs since expiry
-- 1719 msecs since expiry
-- 1729 msecs since expiry
-- 1739 msecs since expiry
-- 1776 msecs since expiry
-- 1799 msecs since expiry
-- 1799 msecs since expiry
-- 1803 msecs since expiry
-- 1806 msecs since expiry
-- 1833 msecs since expiry
-- 1843 msecs since expiry
-- 1879 msecs since expiry
-- 1883 msecs since expiry
-- 1886 msecs since expiry
-- 1893 msecs since expiry
-- 1893 msecs since expiry
-- 1893 msecs since expiry
-- 1903 msecs since expiry
-- 1949 msecs since expiry
-- 1959 msecs since expiry
-- 1986 msecs since expiry
-- 2016 msecs since expiry
-- 2016 msecs since expiry
-- 2026 msecs since expiry
-- 2053 msecs since expiry
-- 2063 msecs since expiry
-- 2066 msecs since expiry
-- 2083 msecs since expiry
-- 2109 msecs since expiry
-- 2113 msecs since expiry
-- 2123 msecs since expiry
-- 2139 msecs since expiry
-- 2159 msecs since expiry
-- 2186 msecs since expiry
-- 2203 msecs since expiry
-- 2206 msecs since expiry
-- 2223 msecs since expiry
-- 2226 msecs since expiry
-- 2233 msecs since expiry
-- 2246 msecs since expiry
-- 2256 msecs since expiry
-- 2266 msecs since expiry
-- 2289 msecs since expiry
-- 2306 msecs since expiry
-- 2346 msecs since expiry
-- 2359 msecs since expiry
-- 2379 msecs since expiry
-- 2379 msecs since expiry
-- 2383 msecs since expiry
-- 2389 msecs since expiry
-- 2419 msecs since expiry
-- 2429 msecs since expiry
-- 2436 msecs since expiry
-- 2453 msecs since expiry
-- 2469 msecs since expiry
-- 2483 msecs since expiry
-- 2513 msecs since expiry
-- 2519 msecs since expiry
-- 2526 msecs since expiry
-- 2533 msecs since expiry
-- 2539 msecs since expiry
-- 2543 msecs since expiry
-- 2543 msecs since expiry
-- 2546 msecs since expiry
-- 2556 msecs since expiry
-- 2563 msecs since expiry
-- 2573 msecs since expiry
-- 2596 msecs since expiry
-- 2613 msecs since expiry
-- 2619 msecs since expiry
-- 2626 msecs since expiry
-- 2633 msecs since expiry
-- 2659 msecs since expiry
-- 2663 msecs since expiry
-- 2676 msecs since expiry
-- 2719 msecs since expiry
-- 2769 msecs since expiry
-- 2776 msecs since expiry
-- 2776 msecs since expiry
-- 2779 msecs since expiry
-- 2786 msecs since expiry
-- 2793 msecs since expiry
-- 2826 msecs since expiry
-- 2846 msecs since expiry
-- 2883 msecs since expiry
-- 2883 msecs since expiry
-- 2889 msecs since expiry
-- 2903 msecs since expiry
-- 2923 msecs since expiry
-- 2929 msecs since expiry
-- 2956 msecs since expiry
-- 2959 msecs since expiry
-- 2959 msecs since expiry
-- 2959 msecs since expiry
-- 2983 msecs since expiry
-- 2986 msecs since expiry
-- 2986 msecs since expiry
-- 2989 msecs since expiry
-- 3036 msecs since expiry
-- 3043 msecs since expiry
-- 3053 msecs since expiry
-- 3069 msecs since expiry
-- 3089 msecs since expiry
-- 3129 msecs since expiry
-- 3133 msecs since expiry
-- 3159 msecs since expiry
-- 3173 msecs since expiry
-- 3176 msecs since expiry
-- 3179 msecs since expiry
-- 3229 msecs since expiry
-- 3256 msecs since expiry
-- 3269 msecs since expiry
-- 3273 msecs since expiry
-- 3283 msecs since expiry
-- 3283 msecs since expiry
-- 3303 msecs since expiry
-- 3326 msecs since expiry
-- 3326 msecs since expiry
-- 3339 msecs since expiry
-- 3339 msecs since expiry
-- 3366 msecs since expiry
-- 3369 msecs since expiry
-- 3399 msecs since expiry
-- 3403 msecs since expiry
-- 3413 msecs since expiry
-- 3453 msecs since expiry
-- 3466 msecs since expiry
-- 3469 msecs since expiry
-- 3 msecs since expiry
20-Feb-2024 10:46:30.324 REFUSED unexpected RCODE resolving 'cloud.Jensen.com.cn/NS/IN': 39.96.153.53#53
-- 0 msecs since expiry
-- 0 msecs since expiry
20-Feb-2024 10:46:30.524 REFUSED unexpected RCODE resolving 'cloud.Jensen.com.cn/NS/IN': 39.96.153.32#53
-- 0 msecs since expiry
```
So, there are multiple issues circling around the TTL-based cleaning.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4580Add resolver.arpa to the built in empty zones2024-03-21T00:23:52ZMark AndrewsAdd resolver.arpa to the built in empty zonesRFC 9462 adds resolver.arpa to the lists of empty zones.
```
6.4. Handling Non-DDR Queries for resolver.arpa
DNS resolvers that support DDR by responding to queries for _dns.resolver.arpa. MUST treat resolver.arpa as a
locally served z...RFC 9462 adds resolver.arpa to the lists of empty zones.
```
6.4. Handling Non-DDR Queries for resolver.arpa
DNS resolvers that support DDR by responding to queries for _dns.resolver.arpa. MUST treat resolver.arpa as a
locally served zone per [RFC6303]. In practice, this means that resolvers SHOULD respond to queries of any
type other than SVCB for _dns.resolver.arpa. with NODATA and queries of any type for any domain name under
resolver.arpa with NODATA.
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4571findnsec3proofs failed to disassociate all rdatasets returned by dns_ncache_c...2024-03-08T08:24:37ZMark Andrewsfindnsec3proofs failed to disassociate all rdatasets returned by dns_ncache_currentThese are not currently reference counted by if they where it would introduce a memory/reference leak.These are not currently reference counted by if they where it would introduce a memory/reference leak.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4568isc_ht case insensitive matching is broken2024-03-07T21:26:35ZOndřej Surýisc_ht case insensitive matching is brokenThe `isc__ht_node_match()` ignores the case_sensitivity setting and always uses `memcmp()` that is case sensitive.The `isc__ht_node_match()` ignores the case_sensitivity setting and always uses `memcmp()` that is case sensitive.February 2024 (9.16.47/9.16.48, 9.16.47/9.16.48-S1, 9.18.23/9.18.24, 9.18.23/9.18.24-S1, 9.19.21)https://gitlab.isc.org/isc-projects/bind9/-/issues/4562dispatch test needs to ignore unexpected sources2024-03-07T22:42:57ZMark Andrewsdispatch test needs to ignore unexpected sourcesJob [#3999076](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3999076) failed for 30026fb052bbbefdb2416e4538c9dc973b000541:
```
FAILED dispatch/tests_connreset.py::test_connreset - dns.query.UnexpectedSource: got a response from ('10....Job [#3999076](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3999076) failed for 30026fb052bbbefdb2416e4538c9dc973b000541:
```
FAILED dispatch/tests_connreset.py::test_connreset - dns.query.UnexpectedSource: got a response from ('10.53.0.3', 25547) instead of ('10.53.0.2', 25227)
```
dnspython supports ignoring unexpected responses
```
*ignore_unexpected*, a ``bool``. If ``True``, ignore responses from unexpected sources.
```
This will most probably need to be applied to most dns.query.udp calls.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4561Shutdown test doesn't log everything to named.run2024-03-07T22:43:03ZMark AndrewsShutdown test doesn't log everything to named.runThe rest of the system tests log everything to stderr using `-d 99 -g`. The named instances started by the shutdown test do not do this which causes logging to be lost at the start and at the end after logging has been shutdown, i.e. me...The rest of the system tests log everything to stderr using `-d 99 -g`. The named instances started by the shutdown test do not do this which causes logging to be lost at the start and at the end after logging has been shutdown, i.e. memory issues being reported. They use the logging clause.
This will also cause the system's log to be spammed with messages from the test system.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4560All tests for "make test" returning "ERROR" even though logs show most tests ...2024-03-26T10:30:37ZEric SchultzAll tests for "make test" returning "ERROR" even though logs show most tests passed### Summary
When I run "make test" after a successful configure/make, all of the tests throw "ERROR", but if you look at the log for each test or the xml output, it will show as passed.
### BIND version affected
bind-9.18.21
### St...### Summary
When I run "make test" after a successful configure/make, all of the tests throw "ERROR", but if you look at the log for each test or the xml output, it will show as passed.
### BIND version affected
bind-9.18.21
### Steps to reproduce
```
% cat /etc/redhat-release
Red Hat Enterprise Linux release 8.9 (Ootpa)
% cat /etc/oracle-release
Oracle Linux Server release 8.9
# Install required packages (though many of these are not listed as required on the BIND site! Namely the python RPMs.)
sudo yum install automake autoconf libtool libcap-devel python3-pytest python3 perl-Net-DNS python3-dns
# Download and install jemalloc RPMs from EPEL:
wget https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/j/jemalloc-5.2.1-2.el8.x86_64.rpm
wget https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/j/jemalloc-devel-5.2.1-2.el8.x86_64.rpm
sudo yum install jemalloc-5.2.1-2.el8.x86_64.rpm jemalloc-devel-5.2.1-2.el8.x86_64.rpm
```
Build accessory software as needed:
```
wget https://www.zlib.net/zlib-1.3.1.tar.gz
tar xzf zlib-1.3.1.tar.gz
cd zlib-1.3.1
./configure --prefix=/usr/local/zlib-1.3.1
make
make test
sudo make install
cd ../
sudo vi /etc/ld.so.conf.d/bind-libs.conf
# add /usr/local/zlib-1.3.1/lib
sudo ldconfig
wget https://www.openssl.org/source/openssl-3.0.13.tar.gz
tar xzf openssl-3.0.13.tar.gz
cd openssl-3.0.13
./config --prefix=/usr/local/openssl-3.0.13 --with-zlib-lib=/usr/local/zlib-1.3.1/lib
make
make test
sudo make install
cd ../
sudo vi /etc/ld.so.conf.d/bind-libs.conf
# update to /usr/local/openssl-3.0.13/lib64
sudo ldconfig
# Probably could use libuv RPM here but chose to get newest source
wget --no-check-certificate https://dist.libuv.org/dist/v1.47.0/libuv-v1.47.0.tar.gz
tar xzf libuv-v1.47.0.tar.gz
cd libuv-v1.47.0
sh autogen.sh
./configure --prefix=/usr/local/libuv-1.47.0
make
make check
sudo make install
cd ../
sudo vi /etc/ld.so.conf.d/bind-libs.conf
# add: /usr/local/libuv-1.47.0/lib
sudo ldconfig
# Now build BIND itself
wget https://downloads.isc.org/isc/bind9/9.18.21/bind-9.18.21.tar.xz
tar xJf bind-9.18.21.tar.xz
cd bind-9.18.21
export PKG_CONFIG_PATH=/usr/local/openssl-3.0.13/lib64/pkgconfig:/usr/local/zlib-1.3.1/lib/pkgconfig:/usr/local/libuv-1.47.0/lib/pkgconfig
./configure --prefix=/usr/local/bind-9.18.21 --mandir=/usr/local/bind-9.18.21/man --with-openssl=/usr/local/openssl-3.0.13 --with-jemalloc --with-gnu-ld --with-libxml2=no --with-gssapi=no --disable-auto-validation --disable-doh
make
sudo bin/tests/system/ifconfig.sh up
make test
```
### What is the current *bug* behavior?
"make test" will start generating ERROR for each test:
<snip>
make check-TESTS
make[6]: Entering directory '/tmp_mnt/homefs/mnt/eschultz/projects/bind-9.18.21-rhe8/bind-9.18.21/bin/tests/system'
make[7]: Entering directory '/tmp_mnt/homefs/mnt/eschultz/projects/bind-9.18.21-rhe8/bind-9.18.21/bin/tests/system'
ERROR: rpz
ERROR: rpzrecurse
ERROR: serve-stale
ERROR: timeouts
ERROR: upforwd
<snip>
But the log itself (and .xml) shows 100% PASSED:
```
% tail bin/tests/system/rpz.log
2024-02-05 08:11:28 INFO:rpz I:rpz_tmp_mrhdwc8_:checking that rewriting CD=1 queries handles pending data correctly (29)
2024-02-05 08:11:28 INFO:rpz I:rpz_tmp_mrhdwc8_:status (native RPZ sub-test): 0 (pass)
2024-02-05 08:11:28 INFO:rpz I:rpz_tmp_mrhdwc8_:attempting to configure servers with DNSRPS...
2024-02-05 08:11:32 INFO:rpz I:rpz_tmp_mrhdwc8_:DNSRPS disabled at compile time
2024-02-05 08:11:32 INFO:rpz I:rpz_tmp_mrhdwc8_:DNSRPS sub-test skipped
PASSED [100%]
generated xml file: /home/eschultz/projects/bind-9.18.21-rhe8/bind-9.18.21/bin/tests/system/rpz.xml
========================== 1 passed in 98.66 seconds ===========================
ERROR rpz (exit status: 99)
```
Every single test has exit status 99.
### What is the expected *correct* behavior?
These tests should almost all have result PASS, when checking the logs (except for two that show 50% PASSED):
```
% grep PASSED bin/tests/system/test-suite.log
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [ 50%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [ 50%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
```
### Relevant configuration files
I don't believe there is anything relevant for the build.
### Relevant logs
```
% cat bin/tests/system/rpz.log
============================= test session starts ==============================
platform linux -- Python 3.6.8, pytest-3.4.2, py-1.5.3, pluggy-0.6.0 -- /bin/python3
cachedir: ../.pytest_cache
rootdir: /tmp_mnt/homefs/mnt/eschultz/projects/bind-9.18.21-rhe8/bind-9.18.21/bin/tests/system, inifile: pytest.ini
collecting ... collected 1 item
tests_sh_rpz.py::test_rpz
-------------------------------- live log setup --------------------------------
2024-02-05 09:23:29 INFO:rpz test started: rpz/tests_sh_rpz.py
2024-02-05 09:23:29 INFO:rpz using port range: <25322, 25341>
-------------------------------- live log call ---------------------------------
2024-02-05 09:23:35 INFO:rpz I:rpz_tmp_zaujh5m9:running native RPZ sub-test
2024-02-05 09:23:35 INFO:rpz I:rpz_tmp_zaujh5m9:checking QNAME rewrites (1)
2024-02-05 09:23:42 INFO:rpz I:rpz_tmp_zaujh5m9:checking NXDOMAIN/NODATA action on QNAME trigger (2)
2024-02-05 09:23:46 INFO:rpz I:rpz_tmp_zaujh5m9:checking IP rewrites (3)
2024-02-05 09:23:48 INFO:rpz I:rpz_tmp_zaujh5m9:ns2 zone reload queued
2024-02-05 09:23:49 INFO:rpz I:rpz_tmp_zaujh5m9:ns2 zone reload queued
2024-02-05 09:23:50 INFO:rpz I:rpz_tmp_zaujh5m9:checking radix tree deletions (4)
2024-02-05 09:23:52 INFO:rpz I:rpz_tmp_zaujh5m9:checking NSDNAME rewrites (5)
2024-02-05 09:23:54 INFO:rpz I:rpz_tmp_zaujh5m9:checking NSIP rewrites (6)
2024-02-05 09:23:55 INFO:rpz I:rpz_tmp_zaujh5m9:checking walled garden NSIP rewrites (7)
2024-02-05 09:23:56 INFO:rpz I:rpz_tmp_zaujh5m9:checking policy overrides (8)
2024-02-05 09:24:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking crashes (9)
2024-02-05 09:24:04 INFO:rpz I:rpz_tmp_zaujh5m9:performance not checked; queryperf not available
2024-02-05 09:24:06 INFO:rpz I:rpz_tmp_zaujh5m9:checking that ns3 with broken rpz does not crash (10)
2024-02-05 09:24:11 INFO:rpz I:rpz_tmp_zaujh5m9:checking if rpz survives a certain class of failed reconfiguration attempts (11)
2024-02-05 09:24:12 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz failed update will keep previous rpz rules (12)
2024-02-05 09:24:13 INFO:rpz I:rpz_tmp_zaujh5m9:ns3 zone reload queued
2024-02-05 09:24:14 INFO:rpz I:rpz_tmp_zaujh5m9:checking reload of a mixed-case RPZ zone (13)
2024-02-05 09:24:14 INFO:rpz I:rpz_tmp_zaujh5m9:ns3 zone reload queued
2024-02-05 09:24:14 INFO:rpz I:rpz_tmp_zaujh5m9:checking that ttl values are not zeroed when qtype is '*' (14)
2024-02-05 09:24:14 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz updates/transfers with parent nodes added after children (15)
2024-02-05 09:24:56 INFO:rpz I:rpz_tmp_zaujh5m9:checking that going from an empty policy zone works (16)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:ns7 zone refresh queued
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:checking that add-soa no at rpz zone level works (17)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:checking that add-soa yes at response-policy level works (18)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:reconfiguring server with 'add-soa no' (19)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:checking that 'add-soa no' at response-policy level works (19)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:checking that 'add-soa unset' works (20)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz with delegation fails correctly (21)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:checking policies from expired zone are no longer in effect (22)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz 'CNAME *.' (NODATA) with dns64, AAAA lookup with A-only (23)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz 'CNAME *.' (NODATA) with dns64, A lookup with A-only (24)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz 'CNAME *.' (NODATA) with dns64, AAAA lookup with no A or AAAA (25)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz 'CNAME *.' (NODATA) with dns64, A lookup with no A or AAAA (26)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz 'CNAME *.' (NODATA) with dns64, AAAA lookup with A and AAAA (27)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz 'CNAME *.' (NODATA) with dns64, A lookup with A and AAAA (28)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking that rewriting CD=1 queries handles pending data correctly (29)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:status (native RPZ sub-test): 0 (pass)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:attempting to configure servers with DNSRPS...
2024-02-05 09:25:04 INFO:rpz I:rpz_tmp_zaujh5m9:DNSRPS disabled at compile time
2024-02-05 09:25:04 INFO:rpz I:rpz_tmp_zaujh5m9:DNSRPS sub-test skipped
PASSED [100%]
generated xml file: /home/eschultz/projects/bind-9.18.21-rhe8/bind-9.18.21/bin/tests/system/rpz.xml
========================== 1 passed in 97.72 seconds ===========================
ERROR rpz (exit status: 99)
```
```
% cat bin/tests/system/rpz.xml
<?xml version="1.0" encoding="utf-8"?><testsuite errors="0" failures="0" name="pytest" skips="0" tests="1" time="97.721"><testcase classname="rpz.tests_sh_rpz" file="rpz/tests_sh_rpz.py" line="12" name="test_rpz" time="97.68873071670532"></testcase></testsuite>
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4553return value for check DS shadows value for running keymgr2024-03-07T22:43:18ZMatthijs Mekkingmatthijs@isc.orgreturn value for check DS shadows value for running keymgrChecking the DS at the parent only happens if `dns_zone_getdnsseckeys()` returns success. However, if this function somehow fails, it can also prevent the keymgr from running.Checking the DS at the parent only happens if `dns_zone_getdnsseckeys()` returns success. However, if this function somehow fails, it can also prevent the keymgr from running.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4552keymgr: bug in Depends function2024-03-13T10:53:30ZMatthijs Mekkingmatthijs@isc.orgkeymgr: bug in Depends functionWhile working on the `dnssec` system test I noticed a bug in the `keymgr` code. The function `keymgr_dep` implements the `Depends` function, described as follows:
---
The `Depends` relation refers to types of rollovers in which a certa...While working on the `dnssec` system test I noticed a bug in the `keymgr` code. The function `keymgr_dep` implements the `Depends` function, described as follows:
---
The `Depends` relation refers to types of rollovers in which a certain record type is going to be swapped. For example, with the ZSK Pre-Publish rollover method the signatures created by the successor key `z` are being propagated first, so that the zone signatures for `x` and `z` can be swapped (smooth rollover). In this case, we say that `z` is the successor of `x` for the `ZRRSIG` record type. Here, `x` is the predecessor key that is going to be withdrawn from the zone. The set `Dep(x, T)` is a separately administrated set of keys that have a dependency on `x` for record type `T`.
For example, with the ZSK Pre-Publish method, the `ZRRSIG` records of key `x` can be withdrawn if there is a succeeding `ZRRSIG` of key `z` introduced in the zone. Key `x` now depends on key `z`, therefore `z` will be in the set `Dep(x, ZRRSIG)`. The successor relation requires that the predecessor key must not have any other keys relying on it. In other words, the set `Dep(x, T)` must be empty.
---
But if the key is phased out (all its states are in `HIDDEN`), there is no longer a dependency. Since the relationship is still maintained (`Predecessor` and `Successor` metadata), the `keymgr_dep` function still returned `true`. In other words, the set `Dep(x, T)` is not considered empty.
This slows down key rollovers, only retiring keys when the successor key has been fully propagated.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4551dnssec-keygen man page contradictory on whether TSIG keys can be generated2024-03-08T05:39:15ZChristopher Headdnssec-keygen man page contradictory on whether TSIG keys can be generated### Summary
At the top of the `dnssec-keygen` man page appears this text:
> It can also generate keys for use with TSIG (Transaction Signatures) as defined in RFC 2845, or TKEY (Transaction Key) as defined in RFC 2930.
Under the secti...### Summary
At the top of the `dnssec-keygen` man page appears this text:
> It can also generate keys for use with TSIG (Transaction Signatures) as defined in RFC 2845, or TKEY (Transaction Key) as defined in RFC 2930.
Under the section for the `-a` option:
> In prior releases, HMAC algorithms could be generated for use as TSIG keys, but that feature was removed in BIND 9.13.0. Use tsig-keygen to generate TSIG keys.
It looks like the top matter probably wasn’t updated when TSIG was spun out into `tsig-keygen`.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.org