1. Forum
  2. Newsgroups
  3. comp.protocols.dns.bind

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

    From vom513@vom513@gmail.com to bind-users on Sat May 30 15:27:45 2020
    From Newsgroup: comp.protocols.dns.bind

    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:
    vom@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
    vom@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...
    --- Synchronet 3.18a-Linux NewsLink 1.113
  • From vom513@vom513@gmail.com to bind-users on Sat May 30 23:58:12 2020
    From Newsgroup: comp.protocols.dns.bind

    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...--- Synchronet 3.18a-Linux NewsLink 1.113