Perhaps a full rebuild of that package is required?

It may be reasonable to consider :

    https://downloads.isc.org/isc/bind9/cur/9.21/

However dns/bind921 does not exist. At the moment.

Thus patch update breaks name services and also this means
internal email is not working and no user/system has access
to the local DNS server. Clearly.

The patch process results in a boot environment snapshot and thus
the required libs should exist inside the snapshot.

However clearly something is amiss : 

p# pwd
/.zfs/snapshot/2026-08-02-18:32:38-0
p# ls -lad usr/local/lib/liblmdb*
-rw-r--r--  1 root wheel 137904 Jul 11 02:09 usr/local/lib/liblmdb.a
lrwxr-xr-x  1 root wheel     14 Jul 11 02:09 usr/local/lib/liblmdb.so -> liblmdb.so.1.0
lrwxr-xr-x  1 root wheel     14 Jul 11 02:09 usr/local/lib/liblmdb.so.1 -> liblmdb.so.1.0
-rw-r--r--  1 root wheel 113960 Jul 11 02:09 usr/local/lib/liblmdb.so.1.0
p# 

However the libs have not changed :

p# 
p# openssl dgst -sha256 -r usr/local/lib/liblmdb.so.1.0 /usr/local/lib/liblmdb.so.1.0
db48f2bb8d6fe77b1beb2185b4fb80d6f5e20257f3db161e01eb3372824ad189 *usr/local/lib/liblmdb.so.1.0
db48f2bb8d6fe77b1beb2185b4fb80d6f5e20257f3db161e01eb3372824ad189 */usr/local/lib/liblmdb.so.1.0
p# 

p# LD_LIBRARY_PATH=/usr/local/lib ldd /usr/local/bin/named-checkconf
/usr/local/bin/named-checkconf:
        libisc-9.20.23.so => /usr/local/lib/libisc-9.20.23.so (0x15512337b000)
        libdns-9.20.23.so => /usr/local/lib/libdns-9.20.23.so (0x1551234aa000)
        libns-9.20.23.so => /usr/local/lib/libns-9.20.23.so (0x155124698000)
        libisccfg-9.20.23.so => /usr/local/lib/libisccfg-9.20.23.so (0x155124e14000)
        libk5crypto.so.122 => /usr/lib/libk5crypto.so.122 (0x155122cc6000)
        libcom_err.so.122 => /usr/lib/libcom_err.so.122 (0x1551253d6000)
        libfstrm.so.0 => /usr/local/lib/libfstrm.so.0 (0x1551269f1000)
        libprotobuf-c.so.1 => /usr/local/lib/libprotobuf-c.so.1 (0x15512797e000)
        liblmdb.so.0 => not found (0)
        libuv.so.1 => /usr/local/lib/libuv.so.1 (0x1551285fc000)
        libssl.so.35 => /usr/lib/libssl.so.35 (0x155128ad3000)
        libcrypto.so.35 => /lib/libcrypto.so.35 (0x155129800000)
        libz.so.6 => /lib/libz.so.6 (0x155125a4b000)
        libjson-c.so.5 => /usr/local/lib/libjson-c.so.5 (0x15512b4b1000)
        libnghttp2.so.14 => /usr/local/lib/libnghttp2.so.14 (0x15512baaa000)
        libxml2.so.16 => /usr/local/lib/libxml2.so.16 (0x15512cad8000)
        libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x15512d3b0000)
        libthr.so.3 => /lib/libthr.so.3 (0x15512ad44000)
        libm.so.5 => /lib/libm.so.5 (0x15512ef79000)
        libkrb5.so.122 => /usr/lib/libkrb5.so.122 (0x15512da55000)
        libgssapi_krb5.so.122 => /usr/lib/libgssapi_krb5.so.122 (0x15512e695000)
        liburcu.so.8 => /usr/local/lib/liburcu.so.8 (0x15512f871000)
        liburcu-common.so.8 => /usr/local/lib/liburcu-common.so.8 (0x1551305aa000)
        liburcu-cds.so.8 => /usr/local/lib/liburcu-cds.so.8 (0x155130865000)
        libc.so.7 => /lib/libc.so.7 (0x155131a09000)
        liblmdb.so.0 => not found (0)
        liblmdb.so.0 => not found (0)
        liblmdb.so.0 => not found (0)
        libkrb5support.so.122 => /usr/lib/libkrb5support.so.122 (0x155131f99000)
        libelf.so.2 => /lib/libelf.so.2 (0x155132551000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x155132e73000)
        libsys.so.7 => /lib/libsys.so.7 (0x15513363a000)
        libkrb5profile.so.122 => /usr/lib/libkrb5profile.so.122 (0x15513395b000)
        [vdso] (0x155122099000)
p#

Not sure how to proceed here to fix this.

I will rip out all packages and start over with dns/bind9-devel wherein
I see this : 

--
+------------------------------------------------------------+
|THIS IS A DEVELOPMENT VERSION OF BIND, IT WILL EAT YOUR DATA|
+------------------------------------------------------------+
p# 


However if it works then it is better than dns/bind920.

p# 
p# /usr/local/etc/rc.d/named start
Starting named.
p# 

Yup .... that works.

Still baffled by this.

Today I see :

    $ pkg query %n\ %v\ %o\ %R\ %a | grep -i 'lmdb'
    lmdb0 0.9.35 databases/lmdb0 FreeBSD-ports 1

So that is a dependency dragged in by something else. Likely dns/bind-devel ?

Line 41 of the Makefile seems to point to it :

    https://cgit.freebsd.org/ports/tree/dns/bind9-devel/Makefile#n41

However looking at https://cgit.freebsd.org/ports/tree/dns/bind920/Makefile#n36
it seems to be missing. Or not needed at all. However it is needed.

I see there are two flavours/versions of that OpenLDAP thing :

$ pkg provides liblmdb.so.
Name    : lmdb0-0.9.35
Comment : OpenLDAP Lightning Memory-Mapped Database (legacy)
Repo    : FreeBSD-ports
Filename: usr/local/lib/liblmdb.so.0

Name    : lmdb-1.0.0,1
Comment : OpenLDAP Lightning Memory-Mapped Database
Repo    : FreeBSD-ports
Filename: usr/local/lib/liblmdb.so.1.0
          usr/local/lib/liblmdb.so.1
$ 

Where dns/bind920 wants one of them and not the other. Then
we have dns/bind-devel on the other side of that coin.

So it was not the freebsd-update the borked DNS services but
rather likely is some weird dependency mess up.

Would dns/bind920 still work ? Just off the shelf pkg install?

Comment 6 Mathieu Arnold 2026-08-06 19:18:38 UTC

I don't quite understand, dns/bind9* don't depend on databases/lmdb, but on databases/lmdb0. Where is lmdb 1 coming from?

Comment 7 Mathieu Arnold 2026-08-06 19:21:28 UTC

You probably need to `pkg install lmdb0`, though dns/bind9* should bring it.

(In reply to Mathieu Arnold from comment #7)

I report it as I see it. Did the usual freebsd-update stuff and reboot
which results in dead name services. No dns/bind920 did not work. Full
removal of ALL packages and then reinstall. Still dead. It is as I tell
it and saw it. The only way forward was to remove everything again and
then re-install pkgs with dns/bind9-devel which worked. Strange but true.

(In reply to Mathieu Arnold from comment #6)

LMDB Usage in BIND 9
In BIND 9, LMDB (Lightning Memory-Mapped Database) serves as a high-performance, embedded key-value storage backend primarily used for:
⚬	New Zone Database (NZD / .nzd / .nzf files):
When zones are added, deleted, or reconfigured dynamically at runtime using rndc addzone or rndc delzone (instead of manually editing named.conf), BIND stores these zone configurations and state inside an LMDB database.
⚬	DNSSEC Key and Zone State (KASP / Key Automated State Maintenance):
BIND uses LMDB to store state information and key metadata when using dynamic DNSSEC management and Automated Key Signing Policy (KASP).
⚬	DNS Response Policy Service (DNS-RPS):
When configured to use response policy databases, LMDB provides fast, low-latency lookups for policy enforcement.
Key Technical Takeaways for System Administrators
⚬	Data Scope: LMDB stores dynamic state and zone metadata. It is not used for static text-based zone files defined directly in named.conf.
⚬	Incompatibility Handling: Upgrading from LMDB 0.x to 1.x changes the on-disk binary format. Because existing .nzd and .mdb state files cannot be parsed by LMDB 1.x, they must be cleared prior to restarting named, which will then automatically recreate clean 1.x-compatible database files.


Furthermore, upgrading to LMDB 1.x is completely safe and non-disruptive. Because LMDB in BIND 9 is strictly used for dynamic runtime data (such as NZD/NZF dynamic zones, DNSSEC key state, and DNS-RPS lookups) rather than static configuration or standard zone files, flushing the legacy database files cleanly resolves the format transition without risking core service integrity or zone configuration loss.

Created attachment 273584 [details]
dns/bind920 update for lmdb 1.x support

Description:
This PR updates dns/bind920 to build against databases/lmdb (1.x) instead of the legacy databases/lmdb0 port.

Summary of changes:
- Makefile: Switch LMDB_LIB_DEPENDS from databases/lmdb0 to databases/lmdb.
- Makefile: Bump PORTREVISION (dns/bind920 only).
- files/pkg-message.in: Add an upgrade instruction block warning administrators about the on-disk format incompatibility introduced in LMDB 1.x. Existing .nzd/.mdb files must be removed prior to restarting named to avoid startup failures ('operational/LMDB error').

QA / Testing performed:
- Successfully built and tested on FreeBSD via portmaster.
- Verified pkg-message rendering for both fresh install and upgrade contexts.
- Confirmed that bind-tools slave port is unaffected (LMDB option remains excluded).

I see the following procedure :

    Before restarting named after this upgrade:
        1. Sync dynamic updates to disk:
           # rndc sync -clean
        2. Stop the daemon:
           # service named stop
        3. Remove old LMDB working files:
           # rm -f %%PREFIX%%/etc/namedb/working/*.nzd
           # rm -f %%PREFIX%%/etc/namedb/working/*.mdb
        4. Start named (it will recreate clean 1.x files automatically):
           # service named start


I will be very surprised if users/sysadmins will see that and know
what to do. It may be better is the pkg install process deletes the
existing stuff in %%PREFIX%%/etc/namedb/working/*.nzd and *.mdb given
that ( most likely? ) a pkg upgrade/update would be preceded by the
"service named stop".

Or change nothing. At this point the freebsd-update procedure is now
something I called "mostly harmless". Mostly.

(In reply to Dennis Clarke from comment #12)
Hi Dennis,
Thank you for the feedback!
Automating the deletion of these files during the package upgrade phase (pkg install / pkg upgrade) is unfortunately not safe for a couple of reasons:
	1.	Risk of Data Loss: If a sysadmin hasn't run rndc sync -clean before the package manager stops the service and deletes the files, any dynamic updates currently sitting in the journal (.jnl) that haven't been flushed to the LMDB zones will be permanently lost. BIND needs to shut down gracefully first to commit data.
	2.	Permissions and Environment: pkg executes tasks in a staging environment where it shouldn't blindly wipe out working directory states, especially since the path can be customized or chrooted.
Displaying these instructions via pkg-message (specifically under the type: upgrade trigger) is the standard FreeBSD Ports mechanism for handling backward-incompatible database upgrades (similar to how major PostgreSQL or BerkeleyDB upgrades are handled).
Furthermore, it's worth noting that for the vast majority of standard setups using classic text-based zone files, these LMDB files (.nzd/.mdb) don't even exist. The issue only impacts environments utilizing runtime dynamic zone additions (rndc addzone) or automated KASP DNSSEC policies. For everyone else, this upgrade will be completely transparent and "mostly harmless" indeed.

Comment 14 Mathieu Arnold 2026-08-11 17:23:17 UTC

Comment on attachment 273584 [details]
dns/bind920 update for lmdb 1.x support

This is a bad idea.

Comment 15 Mathieu Arnold 2026-08-11 17:25:55 UTC

both lmdb0 and lmdb install files in the same place, so you can't have both installed at the same time, and most of the tree depends on lmdb0.