BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-11-02T16:51:54Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1642lib/dns/zone.c refactoring2023-11-02T16:51:54ZOndřej Surýlib/dns/zone.c refactoringWhile reviewing a MR that touches `lib/dns/zone.c`, I have notice several things:
- [ ] `zone_postload()` needs to be refactored, the functions spans from line 4696 to to line 5290 (e.g. 400 lines)
- [ ] `zone_rekey()` also need to be re...While reviewing a MR that touches `lib/dns/zone.c`, I have notice several things:
- [ ] `zone_postload()` needs to be refactored, the functions spans from line 4696 to to line 5290 (e.g. 400 lines)
- [ ] `zone_rekey()` also need to be refactored as it spans from line 19317 to line 19734
- [ ] `keyfetch_done()` spans from line 9993 to line 10647 (600 lines)
- [ ] `zone_nsec3chain()` ~900 lines
- [ ] The locked parameter in `zone_locked()` should be removed in favor of just locking the zone prior to the call
- [ ] There's probably a missing lock in `dns_zone_catz_enable_db()`
- [ ] There's probably a missing lock around `dns_zone_rpz_disable_db()` and `dns_zone_catz_disable_db()` call
- [ ] There's lot of unlocked access to dns_zone_t members in `zone_nsec3chain()` and `zone_sign()` at the top of the function
- [ ] There's unlocked access to dns_zone_t members in `zone_maintenance()` (`zone->view`, `zone->type`, `zone->masters`, ...)
- [ ] There's unlocked access to `zone->maxrecords` in `dns_zone_getmaxrecords()` and `dns_zone_setmaxrecords()`
- [ ] There's unlocked access to `zone->origin`, `zone->flags`, `zone->dblock`, and other members of dns_zone_t in `zone_notify()`
- [ ] `zone_rekey()` contains unlocked access to `zone->mctx`, `zone->origin`, `zone->rdclass` and other members
The list here is neither complete or necessarily correct. Some of the struct members might be read-only (e.g. protected by reference counting), but the struct comment is saying "/* Locked */", so if they are truly read-only, perhaps casting them to `const` would be a right thing to do. Also I mostly checked only static functions and looked only at `dns_zone_t *` accesses.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1633Can query flags in +yaml be made a list?2022-04-26T13:36:36ZJP MensCan query flags in +yaml be made a list?### Description
In `dig`'s new YAML output (`+yaml`), the query flags are reported as a string (e.g. `flags: qr rd ra ad`)
```json
"flags": "qr rd ra ad"
```
### Request
I think it'd be more natural to have them returned as a list (e...### Description
In `dig`'s new YAML output (`+yaml`), the query flags are reported as a string (e.g. `flags: qr rd ra ad`)
```json
"flags": "qr rd ra ad"
```
### Request
I think it'd be more natural to have them returned as a list (e.g. `flags: [ qr, rd, ra, ad ]`) which would result in
```json
"flags": [ "qr", "rd", "ra", "ad" ]
```
The benefit I see is that this change would make it easier to find out programatically whether a specific flag is set.
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1630Requested feature: Label construct for configuration file.2021-10-15T22:01:56ZPeter DaviesRequested feature: Label construct for configuration file.The other day while test different configurations, I came upon an old idea that it might be useful if one could define a label in the configuration file.
This would give a simple method to track configuration versions and to verify the r...The other day while test different configurations, I came upon an old idea that it might be useful if one could define a label in the configuration file.
This would give a simple method to track configuration versions and to verify the running config.
This either by consulting the startup messages and/or by using the "rndc status" command.
I realise it is not foolproof and is entirely dependent on the creator updating the label.
Neither would this be usable on included files labels, although using other structures than string may.
Related to :
GL #421 "Add support-status command to rndc"
GL #993 "Provide a way to print out whole configuration as it would be used on startup"
GL #1075 "Print entire running configuration to a file for troubleshooting, diagnostics, updating"
/Peterhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1615nslookup manual page does not clearly state what can be used as command-line ...2021-10-05T10:59:39ZGhost Usernslookup manual page does not clearly state what can be used as command-line options### Summary
The nslookup manual page says that "options" can be specified on the command line, but doesn't make it clear that these options correspond to the keywords for the interactive `set` command.
### BIND version used
9.11.3. Al...### Summary
The nslookup manual page says that "options" can be specified on the command line, but doesn't make it clear that these options correspond to the keywords for the interactive `set` command.
### BIND version used
9.11.3. Also [confirmed in current latest release](https://downloads.isc.org/isc/bind9/9.15.8/doc/arm/man.nslookup.html) (9.15.8).
### Steps to reproduce
```
man nslookup
```
### What is the current *bug* behavior?
nslookup manual page says, in the ARGUMENTS section:
> Options can also be specified on the command line if they precede the arguments and are prefixed with a hyphen.
Firstly, since options are not arguments, that text (and the following text) should be in a separate section called OPTIONS, not in the ARGUMENTS section.
Secondly, it's not clear what options are available (apart from the `--version` option mentioned later, and the options used in the example query). After some investigation, it seems that all of the `keyword[=value]` entries under the `set` entry in INTERACTIVE COMMANDS are available as command-line options, but that is not stated in the man page.
The example query (`nslookup -query=hinfo -timeout=10`) also uses an undocumented abbreviation (`query`) for the `querytype`/`type` keyword. This potentially increases confusion if the reader tries to search the man page for a "query" option.
### What is the expected *correct* behavior?
It should be clear to the reader what command-line options are available.
### Possible fixes
Ideally, split the second half of the ARGUMENTS section (everything from "Options can also be specified..." onwards) out into a new OPTIONS section. Then move all of the keyword entries from under the `set` command entry to the OPTIONS section, and rewrite the description of the `set` command to refer to the options listed in the OPTIONS section.https://gitlab.isc.org/isc-projects/bind9/-/issues/1614IDN and dig2021-10-15T21:46:56ZMark AndrewsIDN and digExtend dig to selectively validate input against
* IDNA2008 `IDN2_NO_TR46`
* TR46 `IDN2_TRANSITIONAL`
* NON-TR46 `IDN2_NONTRANSITIONAL` [current behaviour, default]
`+idnin=<rule>` may be one way to signal thisExtend dig to selectively validate input against
* IDNA2008 `IDN2_NO_TR46`
* TR46 `IDN2_TRANSITIONAL`
* NON-TR46 `IDN2_NONTRANSITIONAL` [current behaviour, default]
`+idnin=<rule>` may be one way to signal thishttps://gitlab.isc.org/isc-projects/bind9/-/issues/1586BIND hook module for dynamically-created reverse PTR records for IPv4, IPv6 [...2023-11-02T16:51:52ZVicky Riskvicky@isc.orgBIND hook module for dynamically-created reverse PTR records for IPv4, IPv6 [ISC-support #15935]We have had requests in the past for some mechanism for creating reverse PTR records on the fly for IPv6 addresses. The reason for needing to create these dynamically is, of course, the address space is so vast, it is just unfeasible or ...We have had requests in the past for some mechanism for creating reverse PTR records on the fly for IPv6 addresses. The reason for needing to create these dynamically is, of course, the address space is so vast, it is just unfeasible or at least inefficient to create PTR records in advance for all possible needs.
This is a somewhat controversial feature, because a lot of ppl now think that reverse PTR records are unnecessary, so it is an example of a feature some users might think would be more clutter and unnecessary code risk in BIND. Therefore, can we consider using the new BIND Hooks interface to create an optional module for dynamic creation of reverse PTR records?
* [ ] Ideally this would only come into play after checking for the presence of an actual reverse PRT record, and then create on on the fly if there isn't one.
* [ ] It would be ideal if it is possible to also sign this record on the fly, but the feature will still be usable to many people even if it is not possible to sign it.
* [ ] There is no real reason to restrict this to IPv6 addresses. We may as well also support IPv4 addresses too, particularly if we will only synthesize a record if there is none already configured.
We do have an existing support customer request for this.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1517Local IPv6 address for UDP sockets not recognized properly2023-11-02T16:25:43ZWitold KrecickiLocal IPv6 address for UDP sockets not recognized properlyNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1516Option on secondary servers to apply inbound IXFR to a temporary version of t...2023-12-06T16:51:50ZCathy AlmondOption on secondary servers to apply inbound IXFR to a temporary version of the zone being updated instead of incrementally to the live zoneThis maybe needs to be an option that can be set globally, per view, by zone, and perhaps also per server.
Background: [Support ticket #15857](https://support.isc.org/Ticket/Display.html?id=15857) and [Support ticket #15075](https://sup...This maybe needs to be an option that can be set globally, per view, by zone, and perhaps also per server.
Background: [Support ticket #15857](https://support.isc.org/Ticket/Display.html?id=15857) and [Support ticket #15075](https://support.isc.org/Ticket/Display.html?id=15075)
Large inbound IXFRs can seriously degrade a BIND secondary nameserver's performance when serving clients (not necessarily from the same zones being transferred) at the same time. This is most likely because the updates are being applied directly to the active zone (unlike an inbound AXFR that creates a copy version of the zone and then swaps them when the inbound transfer is complete).
The overhead of maintaining state/status does not scale well with large incremental updates. IXFR was written many moons ago when memory was expensive and large incremental updates were uncommon. System memory is now easy to upgrade and in the interests of performance, it would be helpful to be able to choose the mode of IXFR update.
Servers hosting large numbers of authoritative zones would benefit particularly from a feature like this.Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1506cacheclean system test fails intermittently and does not preserve forensic data2023-11-02T16:44:00ZMichał Kępieńcacheclean system test fails intermittently and does not preserve forensic data - https://gitlab.isc.org/isc-private/bind9/-/jobs/474768:
```
S:cacheclean:Thu Dec 12 10:24:18 UTC 2019
T:cacheclean:1:A
A:cacheclean:System test cacheclean
I:cacheclean:PORTRANGE:5900 - 5999
I:cacheclean:check correctness of routine ... - https://gitlab.isc.org/isc-private/bind9/-/jobs/474768:
```
S:cacheclean:Thu Dec 12 10:24:18 UTC 2019
T:cacheclean:1:A
A:cacheclean:System test cacheclean
I:cacheclean:PORTRANGE:5900 - 5999
I:cacheclean:check correctness of routine cache cleaning (1)
I:cacheclean:only one tcp socket was used (2)
I:cacheclean:reset and check that records are correctly cached initially (3)
I:cacheclean:check flushing of the full cache (4)
I:cacheclean:check flushing of individual nodes (interior node) (5)
I:cacheclean:check flushing of individual nodes (leaf node, under the interior node) (6)
I:cacheclean:check flushing of individual nodes (another leaf node, with both positive and negative cache entries) (7)
I:cacheclean:failed
I:cacheclean:check flushing a nonexistent name (8)
I:cacheclean:check flushing of namespaces (9)
I:cacheclean:check flushing a nonexistent namespace (10)
I:cacheclean:check the number of cached records remaining (11)
I:cacheclean:check the check that flushname of a partial match works (12)
I:cacheclean:check the number of cached records remaining (13)
I:cacheclean:check flushtree clears adb correctly (14)
I:cacheclean:check expire option returned from master zone (15)
I:cacheclean:check expire option returned from slave zone (16)
I:cacheclean:exit status: 1
R:cacheclean:FAIL
E:cacheclean:Thu Dec 12 10:28:25 UTC 2019
```
This failure was *probably* caused by an almost two-second stall in execution (`ns2/named.run`) between querying for `third1.second1.top1.flushtest.example/A` and then requerying for it with `+noanswer +auth`[^1]:
```
12-Dec-2019 10:27:53.849 dns_adb_destroyfind on find 0x42a37f84d20
12-Dec-2019 10:27:53.849 client @0x42a5c0351c0 (no-peer): free
12-Dec-2019 10:27:53.849 sockmgr 0x42a43959010: watcher got message -2 for socket -1
12-Dec-2019 10:27:53.849 fctx 0x42aae098010(third1.second1.top1.flushtest.example/A): unlink
12-Dec-2019 10:27:53.849 fctx 0x42aae098010(third1.second1.top1.flushtest.example/A): destroy
12-Dec-2019 10:27:55.400 socket 0x42a439712e0: dispatch_recv: event 0x42abf336200 -> task 0x42a4396ee70
12-Dec-2019 10:27:55.401 socket 0x42a43971880: dispatch_recv: event 0x42ac4225200 -> task 0x42a4396ef28
12-Dec-2019 10:27:55.402 socket 0x42a439712e0: internal_recv: task 0x42a4396ee70 got event 0x42a43971388
```
This *probably* caused the second query to yield a 3598 negative TTL, which led the test code to believe that the answer had come from cache even though it had not.
The "*probably*" bits above stem from the fact that proving this theory is impossible because the `cacheclean` system test preserves almost no forensic information, making intermittent failure diagnosis mostly an exercise in tasseography.
[^1]: Let's ignore for a while the fact that the test could easily do away with grabbing that record just once, but it nevertheless issues two queries for it because the first `dig` invocation uses flags which prevent a negative answer TTL to be extracted from `dig` output...Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1405Additional RRs for ILNP RR queries.2019-11-26T18:08:57ZFrancis DupontAdditional RRs for ILNP RR queries.RFC 6742 has some requirements like this one:
> To improve performance, ILNP-aware DNS servers and DNS resolvers MAY
attempt to return all L32, L64, and LP records for the same owner
name of the NID RRset in the Additional sectio...RFC 6742 has some requirements like this one:
> To improve performance, ILNP-aware DNS servers and DNS resolvers MAY
attempt to return all L32, L64, and LP records for the same owner
name of the NID RRset in the Additional section of the response, if
space permits.
(in fact one per new RR)
bind implements the ILNP MRs but not these "Additional Section Processing" requirements.
BTW if it is enough to put some code into additionaldata_xxx() functions in function in the corresponding lib/dns/rdata/generic/foo_yyy.c files I can provide the patch in a MR.https://gitlab.isc.org/isc-projects/bind9/-/issues/1400Follow-up from "Tune the performance of the autosign test" - the sig-validity...2019-11-27T07:50:58ZOndřej SurýFollow-up from "Tune the performance of the autosign test" - the sig-validity-intervalThe following discussion from !2601 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/2601#note_92489): (+9 comments)
> I think you might be mistaken here. Accordin...The following discussion from !2601 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/2601#note_92489): (+9 comments)
> I think you might be mistaken here. According to the [ARM][1] (and this is what I seem to be observing in practice) `sig-validity-interval 10 2` means resigning will start in 10 days - 2 *hours*. I think this affects your reasoning?
>
> [1]: https://gitlab.isc.org/isc-projects/bind9/blob/eb21ecf55c12b6682ee47a03112c9c8a92a31ed7/doc/arm/Bv9ARM-book.xml#L8859-8861https://gitlab.isc.org/isc-projects/bind9/-/issues/1326named-checkconf option to include defaults in output2023-11-02T16:43:59ZBrian Conrynamed-checkconf option to include defaults in outputA customer has requested an option for `named-checkconf` to integrate the full set of defaults into the output.
One of the purpose of this is to make it easier to document (e.g. for an external operations team) all of the configuration ...A customer has requested an option for `named-checkconf` to integrate the full set of defaults into the output.
One of the purpose of this is to make it easier to document (e.g. for an external operations team) all of the configuration options values that are being used by BIND without having to consult the ARM (and make sure that you're looking at the version of the ARM that matches the version of BIND that you're running).
*See also:*
* #2798;Not plannedArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1292Rethink default values for interface-interval and automatic-interface-scan2023-11-02T16:43:59ZOndřej SurýRethink default values for interface-interval and automatic-interface-scanThe following discussion from !2483 should be addressed:
- [ ] @matthijs started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/2483#note_85228): (+1 comment)
> I think if this is set to `yes` there is no ...The following discussion from !2483 should be addressed:
- [ ] @matthijs started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/2483#note_85228): (+1 comment)
> I think if this is set to `yes` there is no need to set a positive `interface-interval` right? If so, perhaps say that it is advised to set `interface-interval` to zero.
>
> Currently `interface-interval` is set to 60 minutes. So IIUC `named` will scan the interfaces when addresses are added or removed *and* every hour. Seems like overkill and perhaps we want to rethink the default value for `interface-interval` or `automatic-interface-scan`.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1263segfault in free_rdataset()2022-03-01T09:46:28ZCathy Almondsegfault in free_rdataset()As reported in [Support ticket #15331](https://support.isc.org/Ticket/Display.html?id=15331)
```
> Program terminated with signal 11, Segmentation fault.
> #0 0x000000000052f983 in free_rdataset (rbtdb=0x7f8d15579b20, mctx=0x7f8d15541b...As reported in [Support ticket #15331](https://support.isc.org/Ticket/Display.html?id=15331)
```
> Program terminated with signal 11, Segmentation fault.
> #0 0x000000000052f983 in free_rdataset (rbtdb=0x7f8d15579b20, mctx=0x7f8d15541b10, rdataset=0x7f8d0a7efff8) at rbtdb.c:1903
> 1903 idx = rdataset->node->locknum;
>
> (gdb) bt
> #0 0x000000000052f983 in free_rdataset (rbtdb=0x7f8d15579b20, mctx=0x7f8d15541b10, rdataset=0x7f8d0a7efff8) at rbtdb.c:1903
> #1 0x00000000005301e9 in clean_stale_headers (rbtdb=0x7f8d15579b20, mctx=0x7f8d15541b10, top=0x7f8d0a816e30) at rbtdb.c:2200
> #2 0x0000000000530240 in clean_headerlist (header_head=0x7f8cfed71c60, rbtdb=0x7f8d15579b20) at rbtdb.c:2215
> #3 0x00000000005307d2 in clean_cache_node (rbtdb=0x7f8d15579b20, node=0x7f8cfed7db78, least_serial=0, nlock=<value optimized out>, tlock=57054,
> pruning=1048576) at rbtdb.c:2252
> #4 decrement_reference (rbtdb=0x7f8d15579b20, node=0x7f8cfed7db78, least_serial=0, nlock=<value optimized out>, tlock=57054, pruning=1048576) at rbtdb.c:2704
> #5 0x0000000000531122 in detachnode (db=<value optimized out>, targetp=0x7f8d1c1bffa8) at rbtdb.c:6278
> #6 0x00000000005312bf in rdataset_disassociate (rdataset=<value optimized out>) at rbtdb.c:10473
> #7 0x00000000005a2502 in dns_rdataset_disassociate (rdataset=0x7f8d132ac068) at rdataset.c:134
> #8 0x000000000050e7fe in msgresetnames (msg=0x7f8d1159c010, everything=<value optimized out>) at message.c:467
> #9 msgreset (msg=0x7f8d1159c010, everything=<value optimized out>) at message.c:551
> #10 0x000000000050f522 in dns_message_reset (msg=0x7f8d132ac068, intent=1) at message.c:818
> #11 0x0000000000421014 in ns_client_endrequest (client=0x7f8cfc0b7410) at client.c:1124
> #12 exit_check (client=0x7f8cfc0b7410) at client.c:650
> #13 0x0000000000422133 in ns_client_detach (clientp=<value optimized out>) at client.c:4929
> #14 0x000000000044fe89 in query_find (client=0x0, event=0x0, qtype=1) at query.c:13266
> #15 0x0000000000450d36 in query_resume (task=<value optimized out>, event=0x7f8d1627fd48) at query.c:5503
> #16 0x0000000000750003 in dispatch (uap=<value optimized out>) at task.c:1180
> #17 run (uap=<value optimized out>) at task.c:1352
> #18 0x00007f8dc3963fc9 in ?? ()
> #19 0x0000000000000000 in ?? ()
```
(Info requested by Evan - there's also a full backtrace attached to the Support ticket)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1259resolv.conf search parsing has artificial limit2022-04-26T13:37:46ZPetr Menšíkresolv.conf search parsing has artificial limit### Summary
libirs support only 8 search domains
### BIND version used
master branch
### Steps to reproduce
1. sed -i 's/^search .*/search non-existent1.very-long-domain.fedoraproject.org non-existent2.very-long-domain.fedoraproject...### Summary
libirs support only 8 search domains
### BIND version used
master branch
### Steps to reproduce
1. sed -i 's/^search .*/search non-existent1.very-long-domain.fedoraproject.org non-existent2.very-long-domain.fedoraproject.org non-existent3.very-long-domain.fedoraproject.org non-existent4.very-long-domain.fedoraproject.org non-existent5.very-long-domain.fedoraproject.org non-existent6.very-long-domain.fedoraproject.org openstacklocal redhat.com/' /etc/resolv.conf
2. [ "$(host access)" == "$(getent host access.redhat.com.)" ] && echo matches
3. sed -i 's/^search .*/search non-existent1.very-long-domain.fedoraproject.org non-existent2.very-long-domain.fedoraproject.org non-existent3.very-long-domain.fedoraproject.org non-existent4.very-long-domain.fedoraproject.org non-existent5.very-long-domain.fedoraproject.org non-existent6.very-long-domain.fedoraproject.org non-existent7.very-long-domain.fedoraproject.org non-existent8.very-long-domain.fedoraproject.org openstacklocal redhat.com/' /etc/resolv.conf
4. [ "$(host access)" == "$(getent host access.redhat.com.)" ] && echo still matches
### What is the current *bug* behavior?
4. does not match
### What is the expected *correct* behavior?
4. does match
### Relevant configuration files
```
# resolv.conf
search non-existent1.very-long-domain.fedoraproject.org non-existent2.very-long-domain.fedoraproject.org non-existent3.very-long-domain.fedoraproject.org non-existent4.very-long-domain.fedoraproject.org non-existent5.very-long-domain.fedoraproject.org non-existent6.very-long-domain.fedoraproject.org non-existent7.very-long-domain.fedoraproject.org non-existent8.very-long-domain.fedoraproject.org openstacklocal redhat.com
nameserver 9.9.9.9
```
### Relevant logs and/or screenshots
(none.)
### Possible fixes
I *know* using such high number domains would cause too many queries to resolve. I *know it is a bad idea*. But I think there should not be such hard limit preventing this. It was updated in glibc to accept unlimited domains. It is not good idea, but I think it is better than simply ignoring what user wishes. We have some customers hitting limits on it.
I think it should be discouraged but possible.
[RH Bug for glibc](https://bugzilla.redhat.com/show_bug.cgi?id=677316), [RH Bug of nslookup](https://bugzilla.redhat.com/show_bug.cgi?id=1758317)https://gitlab.isc.org/isc-projects/bind9/-/issues/1255Accept gc._msdcs.<forest> as a reverse PTR target.2019-10-29T05:26:08ZMark AndrewsAccept gc._msdcs.<forest> as a reverse PTR target.We already accept gc._msdcs.<forest> for A and AAAA. The reverse should also be done.
See https://support.isc.org/Ticket/Display.html?id=15205We already accept gc._msdcs.<forest> for A and AAAA. The reverse should also be done.
See https://support.isc.org/Ticket/Display.html?id=15205Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1254Follow-up from "silence clang warning by using local variable."2019-10-02T08:05:26ZOndřej SurýFollow-up from "silence clang warning by using local variable."The following discussion from !2419 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/2419#note_80780): (+1 comment)
> There's more usage of `isc_commandline_index` ...The following discussion from !2419 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/2419#note_80780): (+1 comment)
> There's more usage of `isc_commandline_index` (and other global variables from `lib/isc/commandline.c`) scattered over BIND 9 source code.
>
> I would rather see a refactoring of the API that would not use global variables and would better cover common usage patterns than selectively applying ducktape to silence one specific compiler. The whole isc_commandline API is not thread-safe and it should be.
>
> The `isc_commandline_index`, `isc_commandline_option`, `isc_commandline_argument` should be moved to `isc_commandline_parse()` as arguments, `isc_commandline_reset` should be a function, and `isc_commandline_errprint` should be argument to new `isc_commandline_init()` function. `isc_commandline_progname` is used only internally.
>
> As a side note - the whole usage of non-const `LIBISC_EXTERNAL_DATA` variables should be eradicated.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1249add build of lib/dns/dnsrps.c to CI2021-10-05T09:21:07ZMark Andrewsadd build of lib/dns/dnsrps.c to CIA recent freebsd build failed in lib/dns/dnsrps.c because a recent change left a variable unused and this was only detected on Jenkins after the merge, not in the CI.A recent freebsd build failed in lib/dns/dnsrps.c because a recent change left a variable unused and this was only detected on Jenkins after the merge, not in the CI.https://gitlab.isc.org/isc-projects/bind9/-/issues/1167Add SRP update policy rule.2019-09-06T02:47:55ZMark AndrewsAdd SRP update policy rule.See also #1166 See also #1166 https://gitlab.isc.org/isc-projects/bind9/-/issues/1166Add code to identify SRP messages and potential extract the KEY RRset from th...2019-09-06T02:48:19ZMark AndrewsAdd code to identify SRP messages and potential extract the KEY RRset from the message.For background see [draft-ietf-dnssd-srp](https://tools.ietf.org/html/draft-ietf-dnssd-srp).
See also #1167For background see [draft-ietf-dnssd-srp](https://tools.ietf.org/html/draft-ietf-dnssd-srp).
See also #1167