BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-11-02T16:57:55Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1984"./configure --with-gperftools-profiler" can fail oddly with "error: libcap i...2023-11-02T16:57:55ZMichal Nowak"./configure --with-gperftools-profiler" can fail oddly with "error: libcap is required"On Fedora 32 when `gperftools-devel` and `gperftools-libs` packages are missing, `./configure --with-gperftools-profiler` fails oddly with `error: libcap is required`:
```
checking whether to use gperftools profiler... yes
...
checking f...On Fedora 32 when `gperftools-devel` and `gperftools-libs` packages are missing, `./configure --with-gperftools-profiler` fails oddly with `error: libcap is required`:
```
checking whether to use gperftools profiler... yes
...
checking for library containing cap_set_proc... no
configure: error: libcap is required for Linux capabilities support. Either install libcap or use --disable-linux-caps.
```
`config.log`:
```
| #ifdef __cplusplus
| extern "C"
| #endif
| char cap_set_proc ();
| int
| main ()
| {
| return cap_set_proc ();
| ;
| return 0;
| }
configure:18826: result: no
configure:18833: error: libcap is required for Linux capabilities support. Either install libcap or use --disable-linux-caps.
```September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)https://gitlab.isc.org/isc-projects/bind9/-/issues/1972named aborted in __GI_sigismember at sigismem.c when SoftHSM not setup2021-10-05T12:42:28ZMichal Nowaknamed aborted in __GI_sigismember at sigismem.c when SoftHSM not setupI work on adding [stress test](https://gitlab.isc.org/isc-private/bind-qa/-/tree/master/bind9/stress) to the CI and I forgot to add [`*setup_softhsm`](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/.gitlab-ci.yml#L247), which setu...I work on adding [stress test](https://gitlab.isc.org/isc-private/bind-qa/-/tree/master/bind9/stress) to the CI and I forgot to add [`*setup_softhsm`](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/.gitlab-ci.yml#L247), which setups SoftHSM slot in the job:
```
.setup_softhsm: &setup_softhsm |
export SLOT=$(sh -x bin/tests/prepare-softhsm2.sh)
test -n "${SLOT}" && test "${SLOT}" -gt 0
```
`named` (`1844b47eb37ea20dd6365db6f7f6e8e1ac7d32e7`) started [crashing](https://gitlab.isc.org/mnowak/bind9/-/jobs/975274) on Fedora 31 with `Aborted (core dumped) $NAMED $COMMAND_SWITCHES -f -c ./named.conf > ./named.run 2>&1` immediately after start, the backtrace is:
```
(gdb) bt
#0 0x00007faeb8f0a625 in __GI_sigismember (set=<optimized out>, set=<optimized out>, signo=-2143708960) at sigismem.c:32
#1 __GI_sigismember (set=0x2, signo=-2143708960) at sigismem.c:24
#2 0x0000000000004003 in ?? ()
#3 0x0000000000000000 in ?? ()
```
Full backtrace: [gdb-full.txt](/uploads/406b6749d970e9323cf3df6168843cf9/gdb-full.txt).
Core: [core.128.gz](/uploads/12ff887f8d33cb015462e3e892d5d121/core.128.gz).
named.conf: [named.conf](/uploads/cc100953547112b2360fa985ad929a56/named.conf)
When I added `*setup_softhsm` `named` stopped crashing.BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1963journal file corrupt: expected serial N, got M2021-03-16T23:18:39ZTony Finchjournal file corrupt: expected serial N, got MOn my R&D box, running latest main (9.17.2 plus patches) I'm seeing several cases of this error message, for a number of different kinds of zone:
```
2020-06-22.02:29:17.494 general: error: auth.mkeys.jnl: journal file corrupt: expected...On my R&D box, running latest main (9.17.2 plus patches) I'm seeing several cases of this error message, for a number of different kinds of zone:
```
2020-06-22.02:29:17.494 general: error: auth.mkeys.jnl: journal file corrupt: expected serial 859, got 860
2020-06-22.02:34:21.396 general: error: ../u/z/dotat.at.jnl: journal file corrupt: expected serial 26317, got 26318
2020-06-22.02:37:46.170 general: error: ../zone/__catz__auth_catz.arpa.cam.ac.uk_in-addr.arpa.cam.ac.uk.db.jnl: journal file corrupt: expected serial 1592610406, got 1592614189
```
i.e. for the trust anchors, for primary zones, and secondary zones (most secondaries on this box are configured with catz). Multiple primary and secondary zones are affected. This started after I (belatedly) upgraded from 9.17.0 to 9.17.2 yesterday.
The delta is 1 for all the mkeys and primary zones, usually (but not always) larger for secondary zones.
edited to add: also the primary zones have `auto-dnssec maintain` but are not inline-signed.https://gitlab.isc.org/isc-projects/bind9/-/issues/1962Integrate GitHub's super-linter image with CI2021-10-18T07:48:19ZMichal NowakIntegrate GitHub's super-linter image with CIRecently GitHub [introduced](https://github.blog/2020-06-18-introducing-github-super-linter-one-linter-to-rule-them-all/) [Super Linter](https://github.com/github/super-linter), a Docker image which provides an easy way to lint various s...Recently GitHub [introduced](https://github.blog/2020-06-18-introducing-github-super-linter-one-linter-to-rule-them-all/) [Super Linter](https://github.com/github/super-linter), a Docker image which provides an easy way to lint various source files.
`sudo docker run -e RUN_LOCAL=true -v $PWD:/tmp/lint github/super-linter`:
```
The script has completed
ERRORS FOUND in MARKDOWN:[16]
ERRORS FOUND in BASH:[373]
ERRORS FOUND in PERL:[44]
ERRORS FOUND in PYTHON:[12]
Exiting with errors found!
```
Given that how easy is to use it in GitHub Action it may become very popular for upstream projects and sideline linter versions distributed with the OS.
On the pro side it would help us not to care about updating our linters and go with whatever Super Linter provides.
On the con side it may not be ideal for outside GitHub use.BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1872Text edits in advanced.rst2020-06-08T10:15:58ZSuzanne GoldlustText edits in advanced.rstVarious content, clarity, and grammar edits neededVarious content, clarity, and grammar edits neededJune 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1868Clean up code determining advertised EDNS UDP buffer size2020-05-25T13:52:57ZMichał KępieńClean up code determining advertised EDNS UDP buffer sizeWhile looking at some packet captures, I noticed what looked like
oddities in how `named` sets the advertised UDP buffer size in the EDNS
queries it sends to servers which have intermittent network issues. In
the end, I did not find any...While looking at some packet captures, I noticed what looked like
oddities in how `named` sets the advertised UDP buffer size in the EDNS
queries it sends to servers which have intermittent network issues. In
the end, I did not find any obvious bugs, but I believe the
documentation does not match the code in a few places and it also
occurred to me that the [code][1] determining the advertised UDP buffer
size in outgoing queries is cryptic enough for me to be unable to
predict what the outcome will be in pretty much *any* scenario.
I think it would be nice to rip out the redundant bits, add comments,
and make sure the documentation matches the code (either by updating the
former or fixing the latter). Such changes would likely not need to be
backported to 9.16 (and beyond).
This is not particularly urgent, though it is slightly related to [DNS
Flag Day 2020][2].
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/6f576b2c184c3ffdae7ecbea5f7cb40e6d302b0d/lib/dns/resolver.c#L2648-2687
[2]: https://dnsflagday.net/2020/June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1866dumpdb take 12+ seconds to complete.2021-10-05T12:18:21ZMark Andrewsdumpdb take 12+ seconds to complete.Job [#896675](https://gitlab.isc.org/isc-projects/bind9/-/jobs/896675) failed for 4df013f0ea61d927abf4f67d5c6ab04478b53d28:
cacheclean system test failed because dumpdb took excessive time to complete.
```
I:cacheclean:check the number...Job [#896675](https://gitlab.isc.org/isc-projects/bind9/-/jobs/896675) failed for 4df013f0ea61d927abf4f67d5c6ab04478b53d28:
cacheclean system test failed because dumpdb took excessive time to complete.
```
I:cacheclean:check the number of cached records remaining (13)
I:cacheclean:timed out waiting for 'rndc dumpdb' to finish
Can't open ns2/named_dump.db.test13: No such file or directory.
I:cacheclean:found 0 records expected 1
I:cacheclean:failed
```
```
21-May-2020 04:21:38.807 received control channel command 'dumpdb -cache _default'
21-May-2020 04:21:38.807 dumpdb started: -cache
21-May-2020 04:21:38.807 delete_node(): 0x7febb871ad68 second1.top1.flushtest.example (bucket 94)
21-May-2020 04:21:38.807 delete_node(): 0x7febb871fc20 top2.flushtest.example (bucket 0)
21-May-2020 04:21:38.807 delete_node(): 0x7feb4fe51bd0 second1.top3.flushtest.example (bucket 36)
21-May-2020 04:21:38.807 delete_node(): 0x7febb871aa38 second2.top3.flushtest.example (bucket 0)
21-May-2020 04:21:48.887 socket 0x7febb8801600: internal_accept called, locked socket
21-May-2020 04:21:48.887 socket 0x7febb8801600 10.53.0.1#38867: accepted connection, new socket 0x7febb83e8310
21-May-2020 04:21:50.555 expiring v4 for name 0x7febb858f270
21-May-2020 04:21:50.675 killing name 0x7febb858f270
21-May-2020 04:21:50.675 ENTER clean_finds_at_name, name 0x7febb858f270, evtype 0004000d, addrs 00000003
21-May-2020 04:21:50.675 EXIT clean_finds_at_name, name 0x7febb858f270
21-May-2020 04:21:50.687 dumpdb complete
```https://gitlab.isc.org/isc-projects/bind9/-/issues/1864Commit 54fe75b9b76eba92efd0fc1cded4a0ac0adc0ba9 introduced a regression in 9.112021-10-05T12:17:40ZBrian ConryCommit 54fe75b9b76eba92efd0fc1cded4a0ac0adc0ba9 introduced a regression in 9.11This commit causes a problem in 9.11 when using `query-source` with `port 53`.
After a reconfig or reload the server will stop receiving data.
I've confirmed that 9.14 and later versions are not affected.
I've also confirmed that both ...This commit causes a problem in 9.11 when using `query-source` with `port 53`.
After a reconfig or reload the server will stop receiving data.
I've confirmed that 9.14 and later versions are not affected.
I've also confirmed that both 9.11 and 9.11-S are affected.
This was discovered from a customer ticket, though the customer has since removed the query source port configuration.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1863dnssec-verify specify a current time2024-02-14T14:44:27ZPeter Daviesdnssec-verify specify a current time### Description
dnssec-verify specify a current time:
If we generate a signed zone via dnssec-signzone with an inception time in the future, then we have a way to fully verify it (including signature validity time checks) with dnssec-ve...### Description
dnssec-verify specify a current time:
If we generate a signed zone via dnssec-signzone with an inception time in the future, then we have a way to fully verify it (including signature validity time checks) with dnssec-verify before hand.
### Request
A command line parameter that allowed you to specify a current time to be used by dnssec-verify.
### Links / references
[GL #743 ](https://gitlab.isc.org/isc-projects/bind9/-/issues/743)
[RT #16466](https://support.isc.org/Ticket/Display.html?id=16466)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1853Force promotion to unsigned int.2020-06-04T05:59:46ZMark AndrewsForce promotion to unsigned int.Job [#889498](https://gitlab.isc.org/isc-projects/bind9/-/jobs/889498) failed for 6ca026b31399e62dba5a6b3ca3d41c7a3dc5c730:
lwinetaton.c:188:20: runtime error: left shift of 213 by 24 places cannot be represented in type 'int'Job [#889498](https://gitlab.isc.org/isc-projects/bind9/-/jobs/889498) failed for 6ca026b31399e62dba5a6b3ca3d41c7a3dc5c730:
lwinetaton.c:188:20: runtime error: left shift of 213 by 24 places cannot be represented in type 'int'June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1851single-query trace logging2022-04-26T13:10:59ZEvan Huntsingle-query trace logging@wpk proposed a useful method of tracing the progress of a single query by turning up the debugging level to maximum on a per-thread level for the duration of a client if the query ID is set to a particular value.@wpk proposed a useful method of tracing the progress of a single query by turning up the debugging level to maximum on a per-thread level for the duration of a client if the query ID is set to a particular value.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1848The table in /doc/arm/logging-categories.rst is too wide2020-08-13T00:40:05ZSuzanne GoldlustThe table in /doc/arm/logging-categories.rst is too wideThe table in /doc/arm/logging-categories.rst appears to be formatted correctly, but it is way too wide for the RTD page. There is a horizontal scroll bar at the very bottom, but the table is long and there's no way to scroll when you're ...The table in /doc/arm/logging-categories.rst appears to be formatted correctly, but it is way too wide for the RTD page. There is a horizontal scroll bar at the very bottom, but the table is long and there's no way to scroll when you're in the middle.BIND 9.17 BackburnerOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1839Follow-up from "TCP accept refactoring" - clean up naming of isc__netievent etc.2021-10-05T12:16:35ZWitold KrecickiFollow-up from "TCP accept refactoring" - clean up naming of isc__netievent etc.The following discussion from !3320 should be addressed:
- [ ] @each started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3320#note_127617):
> It isn't urgent, or even new in this branch, but I just no...The following discussion from !3320 should be addressed:
- [ ] @each started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3320#note_127617):
> It isn't urgent, or even new in this branch, but I just noticed for the first time that in some of these names you have a double underscore after `netievent` as well as before, and I'm wondering what that signifies?BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1814isc_rwlocks tuning - get rid of {down,up}grades, adaptivity2021-10-05T12:13:21ZWitold Krecickiisc_rwlocks tuning - get rid of {down,up}grades, adaptivityOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1758Clean the duplicate and not-used code from libirs2020-04-29T12:16:17ZOndřej SurýClean the duplicate and not-used code from libirsThe libirs contains:
* reimplemenation of `getnameinfo()`, `getaddrinfo()`, `freeaddrinfo()`, and `gai_strerror()` - we can drop these
* the `irs_dnsconf` API which is experimental and not used anywhere
The leaves us with irs_resconf a...The libirs contains:
* reimplemenation of `getnameinfo()`, `getaddrinfo()`, `freeaddrinfo()`, and `gai_strerror()` - we can drop these
* the `irs_dnsconf` API which is experimental and not used anywhere
The leaves us with irs_resconf and irs_context APIs.May 2020 (9.11.19, 9.11.19-S1, 9.14.12, 9.16.3)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1755Tune the Windows build, so we can use /WX (equivalent of -Werror)2020-04-29T11:30:40ZOndřej SurýTune the Windows build, so we can use /WX (equivalent of -Werror)Currently, Windows build files have "Level3" set for the warning. We need to fix the Windows code and also fine-tune the warning level, so we can actually use `/WX` option that would break the build if there's a warning on Windows.Currently, Windows build files have "Level3" set for the warning. We need to fix the Windows code and also fine-tune the warning level, so we can actually use `/WX` option that would break the build if there's a warning on Windows.May 2020 (9.11.19, 9.11.19-S1, 9.14.12, 9.16.3)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1754edns-udp-size in server statement2021-06-23T15:48:52ZDavid Zychedns-udp-size in server statementhttps://ftp.isc.org/isc/bind9/9.16.1/doc/arm/Bv9ARM.ch05.html#server_statement_definition_and_usage points out that `edns-udp-size` in a server statement, which sets a single UDP size for all packets sent to the server, differs from the ...https://ftp.isc.org/isc/bind9/9.16.1/doc/arm/Bv9ARM.ch05.html#server_statement_definition_and_usage points out that `edns-udp-size` in a server statement, which sets a single UDP size for all packets sent to the server, differs from the behavior of `edns-udp-size` in options or view statements, where it specifies a *maximum* value. It goes on to warn that **"The server statement behavior may be brought into conformance with the options/view behavior in future releases."**
I'm writing to share what I believe to be a valid real-world use case for the current behavior, and therefore a reason to preserve it.
As of this writing, I have discovered that a certain set of authoritative nameservers neglects to set the TC flag when they truncate a response to the following query:
```
$ dig +norec +dnssec +bufsize=512 +ignore +qr @a.gov-servers.net rh202ns2.355.dhhs.gov a
; <<>> DiG 9.11.17 <<>> +norec +dnssec +bufsize=512 +ignore +qr @a.gov-servers.net rh202ns2.355.dhhs.gov a
; (2 servers found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30828
;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
; COOKIE: cd7bdc7c0652450f
;; QUESTION SECTION:
;rh202ns2.355.dhhs.gov. IN A
;; QUERY SIZE: 62
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30828
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;rh202ns2.355.dhhs.gov. IN A
;; AUTHORITY SECTION:
dhhs.gov. 86400 IN NS rh120ns2.368.dhhs.gov.
dhhs.gov. 86400 IN NS rh202ns2.355.dhhs.gov.
dhhs.gov. 86400 IN NS rh120ns1.368.dhhs.gov.
dhhs.gov. 86400 IN NS rh202ns1.355.dhhs.gov.
dhhs.gov. 3600 IN DS 51937 8 1 5B557959E1E4CB05FE667CD0EE98D0C5D243D71A
dhhs.gov. 3600 IN DS 635 8 2 3DA74CE6083E79B5FCA8BD5516CE7201774BAEBDE7D1314A32A113A7 74635410
dhhs.gov. 3600 IN DS 51937 8 2 8CDF39C362FD8A982E141B25DEBA8D6957419A7C025A40CC493255BD 6D5352D7
dhhs.gov. 3600 IN DS 635 8 1 CC30699D55C70F38F9653E71B6A8553803ED67D9
dhhs.gov. 3600 IN RRSIG DS 8 2 3600 20200421161007 20200414161007 36558 gov. m1OXbWkv/Rvkb+y6Ytnvtde6pdJXBVOYG6ha0llcV+43bf9o0pHVa7xX J23MSpLzBytY0m61XO8hVUPmln7Rkz+gX5HuIjweMiqoT2MbVC5LjMu7 Z38kG2cV3xkjMs2MCM3Cl5MdnLmt9swdhu+Weue5NsOixr0dTDmrhaXs 3jRDJk1Nd7Wav/MgYvz1/LyMT5AmDlSwQO+W+QQwBnbd+A==
;; Query time: 12 msec
;; SERVER: 69.36.157.30#53(69.36.157.30)
;; WHEN: Tue Apr 14 19:36:25 UTC 2020
;; MSG SIZE rcvd: 500
```
This is one of the authoritative nameservers for `gov.` providing a referral response for `dhhs.gov.`. Since the nameservers in the referral are themselves underneath `dhhs.gov.`, it is absolutely essential that this response include glue A records; without them, it is impossible for a recursive resolver to follow the delegation. But in this case the glue A records have been omitted in order for the response to fit within 512 bytes, and **no TC flag is set** to tell the resolver it should retry over TCP. Which is not our fault, of course, but that doesn't mean it's not our problem.
Now consider a freshly-initialized BIND recursive resolver. Because BIND always advertises a UDP buffer size of 512 the first time it queries any given remote server, if the first recursive query we attempt to handle after startup is for `rh202ns2.355.dhhs.gov a` then we will receive the above problematic answer (TC=0, no glue A records) from one of the gov servers, conclude that no glue records *exist* (i.e. the delegation is hopelessly broken), and return SERVFAIL to our recursive client.
Interestingly this SERVFAIL condition will not persist indefinitely; since our first query against 69.36.157.30 with buffer size 512 was "successful" (in the sense that we didn't get a timeout or a NOTIMPL / FORMERR / SERVFAIL), our next subsequent attempt to query 69.36.157.30 will advertise a larger buffer size which does in fact happen to be large enough to hold all the glue records, allowing us to follow the delegation and retrieve the desired answer. But each time we restart named (and maybe for other reasons too, I'm not sure) we'll try 512 again and end up back at SERVFAIL.
Which brings us to `edns-udp-size`: configuring
```
options {
edns-udp-size 1232;
};
```
is no help at all in this scenario because BIND will still try 512 first. But
```
# a.gov-servers.net
server 69.36.157.30 {
edns-udp-size 1232;
};
# b.gov-servers.net
server 209.112.123.30 {
edns-udp-size 1232;
};
# c.gov-servers.net
server 69.36.153.30 {
edns-udp-size 1232;
};
# d.gov-servers.net
server 81.19.194.30 {
edns-udp-size 1232;
};
```
is an effective workaround that we can implement on the BIND recursive resolver, until such time as we can convince someone to fix the authoritative nameservers (which are not under our control).
Of course we could also use `tcp-only yes;` as a workaround, but it's nice to have both alternatives available.
For the record:
* I did my proof-of-concept testing with BIND 9.11.17, but the ARM statement warning that this behavior might be removed someday is still present in 9.16.1.
* What matters to me is that the behavior still be available; I would be perfectly happy to configure it using a different option name in order to reduce confusion.
Thanks for reading!Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1683Check the question section when transferring zones.2020-12-09T16:30:40ZMark AndrewsCheck the question section when transferring zones.January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/1657allow per type record counts to be specified in update-policy2021-10-13T11:33:37ZMark Andrewsallow per type record counts to be specified in update-policyAllow per type limits to be specified as part of a update policy. This will allow ISP's to specify practical limits.
e.g. Clients could be allowed to add a single PTR record for their machine.
```
zone "in-addr.arpa" {
type master;
f...Allow per type limits to be specified as part of a update policy. This will allow ISP's to specify practical limits.
e.g. Clients could be allowed to add a single PTR record for their machine.
```
zone "in-addr.arpa" {
type master;
file "x";
update-policy {
grant * tcp-self . ptr(1);
};
};
```June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1654Integrate hongfuzz2020-09-02T12:12:44ZOndřej SurýIntegrate hongfuzzThere are instructions here: https://github.com/google/honggfuzz/blob/master/examples/bind/
We should integrate the patch they are using into our `fuzz/` directory and run the fuzzing on regular basis.There are instructions here: https://github.com/google/honggfuzz/blob/master/examples/bind/
We should integrate the patch they are using into our `fuzz/` directory and run the fuzzing on regular basis.BIND 9.17 BackburnerMichał KępieńMichał Kępień