Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.protocols.dns.bind > #15796

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

Show key headers only | View raw

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...

Back to comp.protocols.dns.bind | Previous | Next | Find similar | Unroll thread

Thread

Re: Constant errors concerning in-addr.arpa SOA (insecure response) vom513 <vom513@gmail.com> - 2020-05-30 23:58 -0400

csiph-web