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

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

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

Back to article view | Back to comp.protocols.dns.bind

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

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

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

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

[toc] | [standalone]

Back to top | Article view | comp.protocols.dns.bind

csiph-web