Constant errors concerning in-addr.arpa SOA (insecure response)

[vom513]

Hello all,

I've searched the list - and there is a thread from 7 years ago that seems to match what I am seeing:

https://lists.isc.org/pipermail/bind-users/2013-March/090003.html

I am seeing this on a fresh Debian 10 install, using the Debian bind9 packages (specifically as of this moment I have: BIND 9.11.5-P4-5.1+deb10u1-Debian (Extended Support Version) <id:998753c>). I have stayed as close as possible to the vanilla shipped config. So to that point - DNSSEC validation works fine out of the box.

I am getting this frequently:

May 30 14:15:33 orbital named[10379]: validating in-addr.arpa/SOA: got insecure response; parent indicates it should be secure
May 30 14:19:47 orbital named[10379]: validating in-addr.arpa/SOA: got insecure response; parent indicates it should be secure
May 30 14:19:58 orbital named[10379]: validating in-addr.arpa/SOA: got insecure response; parent indicates it should be secure
May 30 14:23:12 orbital named[10379]: validating in-addr.arpa/SOA: got insecure response; parent indicates it should be secure

Absolutely maddening. This box is also my mail server, so it’s constantly doing reverse lookups, and hence frequently triggering this log...

I have two other boxes (one Debian 9, one Ubuntu (16.04 ?)). Both also run bind 9.x - distro packages. Neither of those boxes give me the frequent errors for in-addr.arpa.

I thought this was perhaps an MTU / frag (IPv6 ?) issue ? I can ping 1500 packets with DF from here to other places across the net.

I also ran a tcpdump filtering for the IP/IPv6 addresses of the [a-f].in-addr-servers.arpa… either I missed something or I’m not seeing it. Nothing stands out to me there.

No idea if this is red herring, or not, but I notice that b and c instances give back answers that are 200+ bytes larger than a,d,e,f:

***@orbital:~$ for i in a b c d e f; do echo -n "$i: "; dig -4 +norecurse +dnssec @$i.in-addr-servers.arpa in-addr.arpa soa | grep rcvd: ; done
a: ;; MSG SIZE rcvd: 309
b: ;; MSG SIZE rcvd: 547
c: ;; MSG SIZE rcvd: 547
d: ;; MSG SIZE rcvd: 309
e: ;; MSG SIZE rcvd: 313
f: ;; MSG SIZE rcvd: 281
***@orbital:~$ for i in a b c d e f; do echo -n "$i: "; dig -6 +norecurse +dnssec @$i.in-addr-servers.arpa in-addr.arpa soa | grep rcvd: ; done
a: ;; MSG SIZE rcvd: 309
b: ;; MSG SIZE rcvd: 547
c: ;; MSG SIZE rcvd: 547
d: ;; MSG SIZE rcvd: 309
e: ;; MSG SIZE rcvd: 313
f: ;; MSG SIZE rcvd: 281

Does anyone know what could be causing this ? I feel like I’m missing a troubleshooting step. I would love some clue on some specific dig commands I could run to recreate/diagnose this.

Thanks in advance - this is my “white whale” for this weekend...

[vom513]

Sorry to self reply - I *think* I figured this out. Looks like the messages I was seeing (at least to my eyes) make this seem like a true failure in the chain of recursion/validation. Looks like it’s more benign - misconfigured auth servers for various in-addr.arpa zones hading out information erroneously (i.e. NOT what they were asked / have been delegated).

I was able to do this on one of my “clean” servers that I hadn’t observed the log messages on:

while true; do nmap -n -iR 10 -sL | grep "^Nmap scan" | awk '{print $5}' | while read ip; do dig -x $ip; done; sleep 5; done

I’m just using nmap to generate 10 random IPs, I’m not “scanning” anything…

That command managed to trigger the log message on my “clean” machine. I think part of the issue is my mail server is simply much busier looking up rDNS as it gets SMTP connections, and is therefore more likely to trigger this log.

I don’t mean to pick on this network, but the following record/query seems to trigger this every time:

dig -x 106.62.177.136

And to see what caused it:

dig +trace -x 106.62.177.136

Notice the “IN-ADDR.ARPA” they give out (helpfully in all CAPS :)).

Sorry for the noise with this thread. If anyone has a more in-depth explanation of bind’s behavior in this scenario I’d love to hear it because I don’t feel like I 100% understand it...