mysterious failures/wrong-answers in reverse DNS lookup

Michael Richardson <[email protected]> Wed, 23 Jul 2025 15:19:58 +0200
Newsgroups	gmane.network.dns.bind9.user
Message-ID	<72623.1753276798__15435.6323227816$1753276845$gmane$org@dyas>
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.

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
signature.asc (application/pgp-signature, 487 B)