BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-01-19T09:14:46Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/67cacheclean system test fails intermittently2021-01-19T09:14:46ZMichał Kępieńcacheclean system test fails intermittentlySame failure mode has been observed in multiple jobs:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/988
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/993
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/1028
* https://gitlab...Same failure mode has been observed in multiple jobs:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/988
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/993
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/1028
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/1153
```
S:cacheclean:Fri Feb 16 09:03:14 UTC 2018
T:cacheclean:1:A
A:System test cacheclean
I:check correctness of routine cache cleaning
I:only one tcp socket was used
I:reset and check that records are correctly cached initially
I:check flushing of the full cache
I:check flushing of individual nodes (interior node)
I:check flushing of individual nodes (leaf node, under the interior node)
I:check flushing of individual nodes (another leaf node, with both positive and negative cache entries)
I:check flushing a nonexistent name
I:check flushing of namespaces
I:check flushing a nonexistent namespace
I:check the number of cached records remaining
I:check the check that flushname of a partial match works.
I:check the number of cached records remaining
I:check flushtree clears adb correctly
I:failed
I:check expire option returned from master zone
I:check expire option returned from slave zone
I:exit status: 1
R:FAIL
E:cacheclean:Fri Feb 16 09:03:37 UTC 2018
```BIND-9.13.0Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2380Documentation update - use of "-E pkcs11"2021-01-19T09:10:34ZPeter DaviesDocumentation update - use of "-E pkcs11"
The "named" man page but could be updated to specify that the engine-name is mandatory when using Bind not build with pkcs11 support.
-E engine-name
When applicable, specifies the hardware to use for cryptographic operations, suc...
The "named" man page but could be updated to specify that the engine-name is mandatory when using Bind not build with pkcs11 support.
-E engine-name
When applicable, specifies the hardware to use for cryptographic operations, such as a secure key store
used for signing. When BIND is built with OpenSSL PKCS#11 support, this defaults to the string “pkcs11”, which identifies an OpenSSL engine that can drive a cryptographic accelerator or hardware service module. When BIND is built with
native PKCS#11 cryptography (–enable-native-pkcs11), it defaults to the path of the PKCS#11 provider library
specified via “–with-pkcs11”.
ARM:
5.11 PKCS#11 (Cryptoki) support
This text could be updated: to refer to or include : https://gitlab.isc.org/isc-projects/bind9/-/wikis/BIND-9-PKCS11
[RT #17522 ](https://support.isc.org/Ticket/Display.html?id=17522)February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2323Add non-threaded build to 9.11 CI2021-01-19T06:18:32ZMark AndrewsAdd non-threaded build to 9.11 CIFebruary 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2364CID 314969: Control flow issues (DEADCODE) in zoneconf.c2021-01-18T12:35:31ZMichal NowakCID 314969: Control flow issues (DEADCODE) in zoneconf.cCoverity Scan identified the following issue in `bin/named/zoneconf.c` on Sunday December 27 on `v9_16` and `main`:
```
*** CID 314969: Control flow issues (DEADCODE)
/bin/named/zoneconf.c: 2212 in named_zone_inlinesigning()
2206 ...Coverity Scan identified the following issue in `bin/named/zoneconf.c` on Sunday December 27 on `v9_16` and `main`:
```
*** CID 314969: Control flow issues (DEADCODE)
/bin/named/zoneconf.c: 2212 in named_zone_inlinesigning()
2206 if (!inline_signing && !zone_is_dynamic &&
2207 cfg_map_get(zoptions, "dnssec-policy", &signing) == ISC_R_SUCCESS &&
2208 signing != NULL)
2209 {
2210 if (strcmp(cfg_obj_asstring(signing), "none") != 0) {
2211 inline_signing = true;
>>> CID 314969: Control flow issues (DEADCODE)
>>> Execution cannot reach the expression ""no"" inside this statement: "dns_zone_log(zone, 1, "inli...".
2212 dns_zone_log(
2213 zone, ISC_LOG_DEBUG(1), "inline-signing: %s",
2214 inline_signing
2215 ? "implicitly through dnssec-policy"
2216 : "no");
2217 } else {
```
The culprit likely lies in cf420b2af0d45693d0f5f34d9113ea411b5f2225 as it's the only change in that file between last two Coverity Scan runs.
Coverity Scan link: https://scan8.coverity.com/reports.htm#v38342/p12579/fileInstanceId=38520332&defectInstanceId=11383777&mergedDefectId=314969.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2141asynchrony support for BIND 9 query plugins2021-01-15T22:48:55ZJinmei Tatuyaasynchrony support for BIND 9 query plugins### Description
Currently, BIND 9's query plugin framework requires any hook works synchronously. But sometimes a hook action can be time consuming. Consider, for example, a hook that needs to send some kind of query (like a DB lookup...### Description
Currently, BIND 9's query plugin framework requires any hook works synchronously. But sometimes a hook action can be time consuming. Consider, for example, a hook that needs to send some kind of query (like a DB lookup) to an external backend server and waits for the response to complete the hook's action. Right now this has to be synchronous, blocking the BIND 9 worker thread handling the query, which also blocks subsequent DNS queries. It would be much better if it could be asynchronous, similar to the way BIND 9 handles recursive resolution from the query module.
### Request
Based on some experiments it doesn't seem to be difficult to extend it to support asynchronous hook actions. I plan to write a complete patch to implement the idea. This issue is a placeholder for that patch.
### Links / referencesDecember 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Jinmei TatuyaJinmei Tatuyahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2390Nsupdate.exe on windows server 2019 fails2021-01-14T07:00:41ZLaurent “Lox” DinclauxNsupdate.exe on windows server 2019 fails### Summary
Nsupdate.exe on windows server 2019 fails with `dns_request_getresponse: expected a TSIG or SIG(0)`
### BIND version used
Tried both Bind 9.16.10 and Bind 9.11.26 x64
### Steps to reproduce
```
"C:\Program Files\BIND9.16...### Summary
Nsupdate.exe on windows server 2019 fails with `dns_request_getresponse: expected a TSIG or SIG(0)`
### BIND version used
Tried both Bind 9.16.10 and Bind 9.11.26 x64
### Steps to reproduce
```
"C:\Program Files\BIND9.16.10.x64\nsupdate.exe" -v -y hmac-sha512:mydomain.com:[redacted TSIG key]
> server ns.server.com
> update add test.mydomain.com 86400 A 10.10.10.10
> send
dns_request_getresponse: expected a TSIG or SIG(0)
```
### What is the current *bug* behavior?
It give an error: `dns_request_getresponse: expected a TSIG or SIG(0)` whereas the exact same commands succeed in Linux
### What is the expected *correct* behavior?
It should work and add the requested record.https://gitlab.isc.org/isc-projects/bind9/-/issues/2381Use of literal "MDASH" instead of hyphen in pdf versions of the ARM2021-01-12T14:49:08ZPeter DaviesUse of literal "MDASH" instead of hyphen in pdf versions of the ARMIn the pdf version of the Bind ARM the literal "MDASH" is generated instead of a hyphen in a number of instancesIn the pdf version of the Bind ARM the literal "MDASH" is generated instead of a hyphen in a number of instancesJanuary 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1925Additional text edits to BIND ARM2021-01-12T14:46:44ZSuzanne GoldlustAdditional text edits to BIND ARMCleaning up various anomalies in formatting, contentCleaning up various anomalies in formatting, contentJuly 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1883Text edits in pkcs11.rst2021-01-12T14:43:59ZSuzanne GoldlustText edits in pkcs11.rstVarious text edits in the pkcs11.rst section of the BIND ARMVarious text edits in the pkcs11.rst section of the BIND ARMJuly 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1915Edits to man pages for BIND ARM2021-01-12T14:39:10ZSuzanne GoldlustEdits to man pages for BIND ARMText and formatting edits for the man pages in the BIND ARMText and formatting edits for the man pages in the BIND ARMJuly 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1940Removing more references to "master" and "slave" in BIND ARM2021-01-12T14:33:07ZSuzanne GoldlustRemoving more references to "master" and "slave" in BIND ARMContinued cleanup of ARM files to remove offensive terminology where possible.Continued cleanup of ARM files to remove offensive terminology where possible.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1948add synonym for "masters"2021-01-12T14:24:13ZEvan Huntadd synonym for "masters"When I made `primary` and `secondary` valid zone types, I didn't add `primaries` as a synonym for `masters` because I didn't want to deal with the added complexity of both terms being used in the same context. Time to finish it though.When I made `primary` and `secondary` valid zone types, I didn't add `primaries` as a synonym for `masters` because I didn't want to deal with the added complexity of both terms being used in the same context. Time to finish it though.July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2137SO_REUSEPORT doesn't distribute queries to multiple netmgr workers on MacOS2021-01-11T12:12:08ZMichael McNallySO_REUSEPORT doesn't distribute queries to multiple netmgr workers on MacOSJinmei informs us, via [Support #17085](https://support.isc.org/Ticket/Display.html?id=17085):
```
I've recently noticed that, on MacOS 10.15.6, only one netmgr
worker handles incoming queries even if multiple workers are
configured on...Jinmei informs us, via [Support #17085](https://support.isc.org/Ticket/Display.html?id=17085):
```
I've recently noticed that, on MacOS 10.15.6, only one netmgr
worker handles incoming queries even if multiple workers are
configured on multiple threads on multiple CPU cores. That's the
case even if I send queries from different addresses or from different
ports to the same listen-on port. It looks like lib/isc/netmgr/udp.c
assumes that SO_REUSEPORT (when available) reasonably distributes
incoming packets to the multiple sockets bound to the same port
with this socket option, but it doesn't work that way at least on
MacOS 10.15 (it's not surprising based on the very original purpose
of SO_REUSEPORT).
I've tested it on MacOS 10.15.6, but I guess it can be common for
other BSD variants that don't have SO_REUSEPORT_LB or other non-Linux,
non-BSD OSes.
```
He'd like to know whether this is accidental or intended and provides a suggested patch diff if it is not.
[udp.c.diff](/uploads/4f151a318d7b4cd5e54c80abeb3abbfa/udp.c.diff)
Ondrej: (I've edited the issue to remove "UDP" as the tcp and tcpdns layers have been rewritten to use `SO_REUSEPORT_LB` too.)December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/606Improve ARM DNSSEC Documentation - add DNSSEC GUIDE to appendix2021-01-11T07:32:20ZVicky Riskvicky@isc.orgImprove ARM DNSSEC Documentation - add DNSSEC GUIDE to appendixAnand B did a presentation on his assessment of signing systems for the RIPE 77 mtg n Amsterdam, and he reported that the DNSSEC section of the BIND ARM is out of date, and in particular, it does not mention the DNSSEC-keymgr utility. (t...Anand B did a presentation on his assessment of signing systems for the RIPE 77 mtg n Amsterdam, and he reported that the DNSSEC section of the BIND ARM is out of date, and in particular, it does not mention the DNSSEC-keymgr utility. (that utility is covered in a manpage though).
We should review and spiff up the DNSSEC section.
Anand also commented that the documentation on DNSSEC on the ISC web site was out of date - that is probably the DNSSEC Guide, that we outsourced and haven't been updating. We should discuss whether it would be better to remove it or just mark it as 'somewhat out of date'.
ref: https://ripe77.ripe.net/archives/video/2290/January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2355Incorrect increment of inactive in rbtdb.c:maybe_free_rbtdb()2021-01-08T13:29:07ZMark AndrewsIncorrect increment of inactive in rbtdb.c:maybe_free_rbtdb()It is possible to have two threads destroying an rbtdb at the same time when detachnode() executes and removes the last reference to a node between exiting being set to true for the node and testing if the references are zero in maybe_fr...It is possible to have two threads destroying an rbtdb at the same time when detachnode() executes and removes the last reference to a node between exiting being set to true for the node and testing if the references are zero in maybe_free_rbtdb().
```
Thread 18 (Thread 80113ef00 (LWP 100776/<unknown>)):
#0 0x0000000800d5843a in _umtx_op () from /home/support/XXXXXXX/lib/libc.so.7
#1 0x0000000800c7e9dd in pthread_mutex_unlock () from /home/support/XXXXXXX/lib/libthr.so.3
#2 0x00000000006c31ba in task_ready (task=0x805272c80) at task.c:424
#3 0x00000000006c3412 in isc_task_sendto (task0=0x805272c80, eventp=0x7fffdfdfc208, c=1) at task.c:570
#4 0x00000000006c3232 in isc_task_send (task0=0x805272c80, eventp=0x7fffdfdfc208) at task.c:517
#5 0x0000000000491e72 in free_rbtdb (rbtdb=0x827229aa0, log=true, event=0x0) at rbtdb.c:1122
#6 0x000000000049760f in detachnode (db=0x827229aa0, targetp=0x7fffdfdfcaa0) at rbtdb.c:5477
#7 0x00000000004a0cdf in rdataset_disassociate (rdataset=0x82f4d2f48) at rbtdb.c:8816
#8 0x00000000005452bd in dns_rdataset_disassociate (rdataset=0x82f4d2f48) at rdataset.c:111
#9 0x0000000000441c40 in msgresetnames (msg=0x82f4c74a0, first_section=0) at message.c:465
#10 0x000000000043b95d in msgreset (msg=0x82f4c74a0, everything=false) at message.c:551
#11 0x000000000043b907 in dns_message_reset (msg=0x82f4c74a0, intent=1) at message.c:779
#12 0x000000000036a02d in ns_client_endrequest (client=0x82ecd8b60) at client.c:229
#13 0x0000000000369a2c in ns__client_reset_cb (client0=0x82ecd8b60) at client.c:1536
#14 0x00000000006a67a6 in isc_nmhandle_detach (handlep=0x7fffdfdfcc58) at netmgr.c:1261
#15 0x00000000006a7552 in isc__nm_uvreq_put (req0=0x7fffdfdfcc98, sock=0x83b1e1a00) at netmgr.c:1393
#16 0x00000000006b073f in tcpdnssend_cb (handle=0x83b98aa00, result=54, cbarg=0x83e174800) at tcpdns.c:539
#17 0x00000000006adbc9 in tcp_send_cb (req=0x82fbaf278, status=-32) at tcp.c:1024
#18 0x0000000800c3edcc in uv__stream_destroy () from /home/support/XXXXXXX/usr/local/lib/libuv.so.1
#19 0x0000000800c3e717 in uv__stream_init () from /home/support/XXXXXXX/usr/local/lib/libuv.so.1
#20 0x0000000800c341eb in uv_run () from /home/support/XXXXXXX/usr/local/lib/libuv.so.1
#21 0x00000000006a28df in nm_thread (worker0=0x8011e93a8) at netmgr.c:488
#22 0x0000000800c76736 in pthread_create () from /home/support/XXXXXXX/lib/libthr.so.3
#23 0x0000000000000000 in ?? ()
Thread 12 (Thread 801140d00 (LWP 100782/<unknown>)):
#0 0x0000000800e4f1ba in thr_kill () from /home/support/XXXXXXX/lib/libc.so.7
#1 0x0000000800e4d5e4 in raise () from /home/support/XXXXXXX/lib/libc.so.7
#2 0x0000000800dc17e9 in abort () from /home/support/XXXXXXX/lib/libc.so.7
#3 0x0000000000300f21 in assertion_failed (file=0x252469 "rbtdb.c", line=1146, type=isc_assertiontype_require, cond=0x28ef26 "isc_refcount_current(&rbtdb->node_locks[i].references) == 0") at main.c:261
#4 0x000000000067dd18 in isc_assertion_failed (file=0x252469 "rbtdb.c", line=1146, type=isc_assertiontype_require, cond=0x28ef26 "isc_refcount_current(&rbtdb->node_locks[i].references) == 0") at assertions.c:46
#5 0x000000000049207c in free_rbtdb (rbtdb=0x827229aa0, log=true, event=0x0) at rbtdb.c:1146
#6 0x00000000004b16de in free_rbtdb_callback (task=0x805272c80, event=0x836d08768) at rbtdb.c:843
#7 0x00000000006ca483 in dispatch (manager=0x801d5c780, threadid=1) at task.c:1152
#8 0x00000000006c5ed1 in run (queuep=0x801d5d7c8) at task.c:1344
#9 0x0000000800c76736 in pthread_create () from /home/support/XXXXXXX/lib/libthr.so.3
#10 0x0000000000000000 in ?? ()
```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/2366BIND 9.16.10 build fails with libmaxminddb-1.4.32021-01-08T11:54:20ZGreg RabilBIND 9.16.10 build fails with libmaxminddb-1.4.3Having compile problems when building BIND 9.16.10 on CentOS 7 with support for GeoIP using MaxMindDB 1.4.3:
```
./configure --with-openssl=/opt/bind916/openssl --with-maxminddb=/opt/bind916/maxminddb
make
<...snip...>
gcc -std=gnu99 -g...Having compile problems when building BIND 9.16.10 on CentOS 7 with support for GeoIP using MaxMindDB 1.4.3:
```
./configure --with-openssl=/opt/bind916/openssl --with-maxminddb=/opt/bind916/maxminddb
make
<...snip...>
gcc -std=gnu99 -g -O2 -pthread -fPIC -Wl,--export-dynamic -o resolve \
resolve.o ../irs/libirs.a ../dns/libdns.a -L/opt/bind916/maxminddb/lib ../isccfg/libisccfg.a ../isc/libisc.a -L/opt/bind916/openssl/lib -lcrypto -lxml2 -lz -L/opt/bind916/libuv/lib -luv -ldl -ldl
../dns/libdns.a(geoip2.o): In function `get_entry_for':
/opt/work3/bind-9.16.10/lib/dns/geoip2.c:96: undefined reference to `MMDB_lookup_sockaddr'
../dns/libdns.a(geoip2.o): In function `dns_geoip_match':
/opt/work3/bind-9.16.10/lib/dns/geoip2.c:368: undefined reference to `MMDB_get_value'
/opt/work3/bind-9.16.10/lib/dns/geoip2.c:345: undefined reference to `MMDB_get_value'
/opt/work3/bind-9.16.10/lib/dns/geoip2.c:328: undefined reference to `MMDB_get_value'
/opt/work3/bind-9.16.10/lib/dns/geoip2.c:304: undefined reference to `MMDB_get_value'
/opt/work3/bind-9.16.10/lib/dns/geoip2.c:296: undefined reference to `MMDB_get_value'
collect2: error: ld returned 1 exit status
make[2]: *** [resolve] Error 1
make[2]: Leaving directory `/opt/work3/bind-9.16.10/lib/samples'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/opt/work3/bind-9.16.10/lib'
make: *** [subdirs] Error 1
```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/2359missing newlines in log messages dnssec-signzone/dnssec-verify2021-01-08T11:40:29ZMark Andrewsmissing newlines in log messages dnssec-signzone/dnssec-verifyChange 664b8f04f5f2322086138f5eda5899a62bcc019b needs to be reimplemented. The newlines need to be added by report not the caller to ensure that named's logs don't have spurious new lines. Perhaps use flockfile/funlockfile to prevent l...Change 664b8f04f5f2322086138f5eda5899a62bcc019b needs to be reimplemented. The newlines need to be added by report not the caller to ensure that named's logs don't have spurious new lines. Perhaps use flockfile/funlockfile to prevent log messages being mangled.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/182Update GeoIP support to new API (GeoLite2 from Maxmind)2021-01-08T09:46:56ZVicky Riskvicky@isc.orgUpdate GeoIP support to new API (GeoLite2 from Maxmind)### Description
Maxmind is discontinuing support for the version of their GeoIP db that is supported currently by BIND.
'At the beginning of April, 2018, we will cease updating the GeoLite Legacy downloadable databases. We will also ...### Description
Maxmind is discontinuing support for the version of their GeoIP db that is supported currently by BIND.
'At the beginning of April, 2018, we will cease updating the GeoLite Legacy downloadable databases. We will also disable free downloads of GeoLite Legacy databases from the geoipupdate program on that date.'
### Request
Please update the GeoIP support in BIND to work with the new API/schema. I did check their website and they are still providing a free community edition of the db, but the schema is new. (https://dev.maxmind.com/geoip/geoip2/geolite2/)
Excerpt from an email from a user:
Simple example for Australia and New Zealand that we use:
```
acl "ANZ" {
geoip country NZ;
geoip country AU;
};
view "ANZ" {
match-clients { key anzkey; !all_keys; ANZ; };
allow-notify { key anzkey; };
allow-transfer { key anzkey; };
server 192.999.888.77 { keys anzkey; };
zone "geo.xxx.com" {
type slave;
notify no;
file "/usr/local/etc/namedb/geo/ANZ.xxx";
masters { 127.0.0.1; };
};
zone "geo.yyy.com" {
type slave;
notify no;
file "/usr/local/etc/namedb/geo/ANZ.yyy";
masters { 127.0.0.1; };
};
};
```
We use GeoIP commercial database, so we rely on it, and it realy works. :)
It has the same schema but more data than free. The point is that MaxMind changed the schema and API for GeoIP2/GeoLite2,
so old function calls will not work with new shared libraries, so developers have to change headers and function calls.
Bind911 uses headers at lib/dns/geoip.c:
```
#include <GeoIP.h>
#include <GeoIPCity.h>
```
and calls like:
```
GeoIP_country_code_by*
GeoIP_country_name_by*
```
New maxmind libraries called "libmaxminddb" is replacement of old "GeoIP" shared libraries with new API:
headers:
```
#include <maxminddb.h>
```
Functions and data structures begin from MMDB_*.
Examples:
```
MMDB_lookup_string(&mmdb, ip_address, &gai_error, &mmdb_error);
MMDB_get_entry_data_list(&result.entry, &entry_data_list);
MMDB_dump_entry_data_list(stdout, entry_data_list, 2);
```
So, the API has changed dramaticaly.
### Links / references
MaxMind supported APIS: https://dev.maxmind.com/geoip/geoip2/downloadable/
## Notes
This new feature will be backported as to old release and the old GeoIP support will have to stay (`--with-geoip`). The two options will be mutually exclusive though. In the development branch, we will remove support for old GeoIP and only the new one will stay. Internally, the configuration should stay the same (even though this will require changes from the administrator anyway to put the new databases into their respective places).BIND 9.15.2Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2379asynchronous hooks could assert2021-01-08T09:32:43ZEvan Huntasynchronous hooks could assert@jtatuya submitted an MR (!4491) correcting a possible assertion failure in asynchronous hooks due the fetchhandle being detached at the wrong time.@jtatuya submitted an MR (!4491) correcting a possible assertion failure in asynchronous hooks due the fetchhandle being detached at the wrong time.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/2341Removing 'auto-dnssec' does not turn off DNSSEC maintenance2021-01-07T21:37:35ZMatthijs Mekkingmatthijs@isc.orgRemoving 'auto-dnssec' does not turn off DNSSEC maintenanceIf you reconfigure a zone and remove the `auto-dnssec` option, the zone is actually still DNSSEC maintained. This is because in `zoneconf.c` there is no call to `dns_zone_setkeyopt()` to turn off the flags. If the configuration option is...If you reconfigure a zone and remove the `auto-dnssec` option, the zone is actually still DNSSEC maintained. This is because in `zoneconf.c` there is no call to `dns_zone_setkeyopt()` to turn off the flags. If the configuration option is not used `cfg_map_get(zoptions, "auto-dnssec", &obj)` will return an error.
(this is fixed in d72ad7c530bb3f0860bc0d47c075368cbd3fcc44 as part of #1750)January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.org