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