u/Hungry-Extension2013

I have a DNSSEC-signed zone (example.com, served by my own authoritative BIND9 server) and I'm trying to validate it locally using delv with a manually-supplied trust anchor, without relying on the real DNS root or any parent-zone DS record.
What I've confirmed works

The zone is genuinely DNSSEC-signed — dig DNSKEY example.com u/127.0.0.1 returns a valid DNSKEY record, and zone transfers (AXFR) include correct RRSIG/NSEC records.
The DNSKEY value in my trust-anchor file matches the live server's DNSKEY byte-for-byte (verified via diff and a hex dump, just to rule out transcription errors).

What I'm trying to do
Build a standalone trust-anchor file:
trust-anchors {
example.com. static-key 257 3 13 "";
};
And validate against it:
delv u/127.0.0.1 -a /path/to/anchor.trust +root=example.com SOA example.com
Expected result
; fully validated
Actual result
;; validating example.com/DNSKEY: no valid signature found (DS)
;; no valid RRSIG resolving 'example.com/DNSKEY/IN': 127.0.0.1#53
;; broken trust chain resolving 'example.com/SOA/IN': 127.0.0.1#53
;; resolution failed: broken trust chain
What I think is happening
Using +rtrace, I can see delv is specifically trying to validate the zone's own DNSKEY record by looking for a DS record — but no DS record exists anywhere (no parent-zone delegation, this is an isolated/private zone not chained to any real parent).
From man delv:

"-a anchor-file: This option specifies a file from which to read DNSSEC trust anchors... Keys that do not match the root zone name are ignored. An alternate key name can be specified using the +root option."

I interpreted this to mean +root=example.com should let delv treat my anchor as the top-level trust point for that name — essentially "trust this key directly, don't require a DS chain above it." But in practice, delv still attempts DS validation regardless of +root.
My question
Is it actually possible to get delv -a + static-key to fully validate a zone with no DS record anywhere in the chain (i.e., a deliberately "island" zone with no real parent delegation)? Or does +root= not do what I think it does, and is there a different flag/anchor-type combination needed to bypass the DS requirement entirely for a self-contained, locally-trusted zone?
Environment

BIND 9.18.39 (Ubuntu 24.04 LTS, Extended Support)
delv from the bind9-dnsutils package

I'm running a containerized DNS server (BIND9 inside a Podman container) with rootless Podman, and I can't get host-to-container connectivity to work over loopback for a published port, even though everything else about the setup checks out.
Setup
bashpodman run -d --name bind-sec
-p 30053:53/tcp -p 30053:53/udp
-v /var/cache/bind-sec:/var/cache/bind
my-bind-image:latest
podman ps shows the port mapping correctly:
PORTS
0.0.0.0:30053->53/tcp, 0.0.0.0:30053->53/udp
What works

The container itself is healthy — podman logs shows BIND fully started, zones loaded, listening on port 53 internally.
Querying the container's own internal IP directly from inside the container's network namespace works fine.
ss -tlnp on the host shows something listening on 0.0.0.0:30053 (confirmed via lsof -i :30053 that it's the container's conmon/proxy process, not a stray process).
Other containers I run with the same -p pattern (e.g., a basic httpd container on port 8080) do work correctly over loopback — curl http://127.0.0.1:8080/ succeeds normally for those.

What fails
bashdig u/127.0.0.1 -p 30053 example.com
;; communications error to 127.0.0.1#30053: timed out
This fails consistently, both from the host itself and (with appropriate firewall rules in place) from other hosts on the same subnet querying :30053.
What I've tried

Confirmed firewall (nftables) rules explicitly allow the port on both iif "lo" and the regular network interface — ruled out as the cause since the same symptom persists with or without those rules.
Tried both default bridge networking and --network=slirp4netns:allow_host_loopback=true — same timeout in both modes.
Tried running the same container with sudo (rootful) instead of rootless — same timeout persists.
Confirmed no orphaned/leftover container processes are holding the port from a previous run.

My question
Why would a UDP/TCP port published via -p work fine for an HTTP container (httpd on 8080) but consistently time out for a DNS container on a different port, using the identical -p host:container syntax and the same Podman version/host? Is there something DNS/UDP-specific about rootless Podman's port-forwarding (rootlessport) that behaves differently from a simple TCP HTTP service, even when both are nominally "just a published port"?
Environment

Ubuntu 24.04 LTS
Podman (rootless, default config)
nftables firewall (rules confirmed not to be the blocker)