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