mysterious failures/wrong-answers in reverse DNS lookup

[Michael Richardson]

Sometimes, when I do reverse lookups on my own /56, I get weird responses.
I saw this in ... April too... and maybe it went away, not sure how.
Today, it's back.  I tend to notice this while ping6'ing stuff...

Hosts:
1. obiwan is desktop in Ottawa.
2. tilapia is authoritative DNS server (in Ottawa)
3. dyas is laptop at IETF123
4. storm.ca is upstream ISP.


obiwan-[~](3.3.8) mcr 10027 %dig @nic.sandelman.ca -x 2607:f0b0:f::babe:f00d ptr
;; ANSWER SECTION:
d.0.0.f.e.b.a.b.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. 600 IN CNAME 13.240.190.186.in-addr.arpa.
13.240.190.186.in-addr.arpa. 86315 IN	PTR	186-190-240-13.e-commercepark.com.

Where did that *CNAME* even come from?
Same wrong thing when I ask from the DNS server itself (named "tilapia").
So I think this is not some on-path attacker.

tilapia-[~] mcr 10002 %dig @nic.sandelman.ca -x 2607:f0b0:f::babe:f00d ptr
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 0de55c77c2a73b29010000006880e09438d5655b1e4d15da (good)
;; QUESTION SECTION:
;d.0.0.f.e.b.a.b.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. IN PTR

;; ANSWER SECTION:
d.0.0.f.e.b.a.b.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. 600 IN CNAME 13.240.190.186.in-addr.arpa.
13.240.190.186.in-addr.arpa. 86400 IN	PTR	186-190-240-13.e-commercepark.com.

---

When I ask from the IETF123 network:

;; SERVER: 31.130.231.0#53(31.130.231.0) (UDP)
;; ANSWER SECTION:
d.0.0.f.e.b.a.b.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. 7200 IN PTR nic.sandelman.ca.

which is entirely correct.

And my secondary is correct:
dyas-[~](3.3.8) mcr 8134 %dig @sns.cooperix.net -x 2607:f0b0:f::babe:f00d ptr
;; ANSWER SECTION:
d.0.0.f.e.b.a.b.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. 7200 IN PTR nic.sandelman.ca.

My nic.sandelman.ca is supposed to be authoriative for this reverse.
At first, I thought my upstream ISP had made a mistake (some typo) in config,
but it's correct:

dyas-[~](3.3.8) mcr 8139 %dig @pns.storm.ca -x 2607:f0b0:f::babe:f00d ptr
...
;d.0.0.f.e.b.a.b.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. IN PTR

;; AUTHORITY SECTION:
0.0.f.0.0.0.0.b.0.f.7.0.6.2.ip6.arpa. 86400 IN NS nic.sandelman.ca.
0.0.f.0.0.0.0.b.0.f.7.0.6.2.ip6.arpa. 86400 IN NS sns.cooperix.net.

This zone is signed "manually" (by cronjob+makefile) via dnssec-signzone.
[Slowly, I'm migrating to inline signing, using two bind views]

%/usr/sbin/named -V
BIND 9.21.9-1+0~20250620.139+debian12~1.gbpa83878-Debian (Development Release) <id:>
I'm running from:
  deb [signed-by=/usr/share/keyrings/deb.sury.org-bind-dev.gpg] https://packages.sury.org/bind-dev/ bookworm main

This persists even when I updated SOA/resign/rndc reload.
And after that reload, the secondary (sns.cooperix.net) definitely picked up
the zone, and the reply is completely correct.
It also persists when I restart named entirely!
I could run a different version if someone is concerned about this being some
bleeding edge problem.

At this point, I begin to suspect the machine is compromised in some very
sophisticated way... But I have no evidence, and why do this.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20250723/3f79b397/attachment.sig>