mysterious failures/wrong-answers in reverse DNS lookup

[Jeremy C. Reed]

On Thu, 24 Jul 2025, Michael Richardson wrote:

>    > nic.sandelman.ca.  is also authoritatively serving:
>
>    > 0.0.0.0.0.0.0.0.0.0.0.0.f.0.0.0.0.b.0.f.7.0.6.2.ip6.arpa. 86400 IN SOA
>    > . . 0 28800 7200 604800 86400
>    > 0.0.0.0.0.0.0.0.0.0.0.0.f.0.0.0.0.b.0.f.7.0.6.2.ip6.arpa. 0 IN NS .
>
>    > That may give you a clue.
>
>    > You may have two zones serving the same.
>
> Are you saying I might have two copies of the zone loaded?
> Or are you saying that I might have a data from this zone in another file,
> perhaps by copy and paste error?

Or generated (see below).

> I'm not seeing either of this via grep and the like and reviewing my
> named.conf files, but I'll look looking.
>
> You are showing me a SOA record at the very bottom of the tree (the /128)
> Removing one 0. shows me the SOA record at the /64 cut point.
> (I see the same thing locally)!
>
> Looking at the signed copy, the string "SOA" occurs three times:
>        In the SOA record itself, in the RRSIG, and the NSEC.

See the RDATA of
. . 0 28800 7200 604800 86400

and the SOA TTL is 864000 and the NS TTL is 0.

See add_soa() in bin/named/server.c used by create_empty_zone() has same 
hardcoded TTL (86400) and hardcoded SOA SERIAL (0), REFRESH (7200), 
RETRY (7200), EXPIRE (604800), and MINTTL (86400).

         CHECK(dns_soa_buildrdata(origin, contact, dns_db_class(db), 0, 28800,
                                  7200, 604800, 86400, buf, &rdata));
...
         rdatalist.ttl = 86400;

But it also has 86400 for the add_ns() but yours is 0. I don't know.

Also empty-contact defaults to "." which you have above SOA RNAME (.). 
But the SOA MNAME doesn't have the "." default.

Maybe check your "empty" zone configurations?
See empty-zones-enable and disable-empty-zone and empty-server

Maybe check if using dyndb?