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.
signature.asc
Description: PGP signature
-- 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 bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
