Path: csiph.com!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!feeder.usenetexpress.com!tr2.eu1.usenetexpress.com!news.uzoreto.com!news.etla.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!usenet-its.stanford.edu!usenet.stanford.edu!not-for-mail
From: vom513 <vom513@gmail.com>
Newsgroups: comp.protocols.dns.bind
Subject: Re: Constant errors concerning in-addr.arpa SOA (insecure response)
Date: Sat, 30 May 2020 23:58:12 -0400
Lines: 36
Approved: bind-users@lists.isc.org
Message-ID: <mailman.463.1590897482.942.bind-users@lists.isc.org>
References: <854199C1-8834-482D-9E9A-CF09A20C4BC9@gmail.com> <05FF1329-0454-4EBC-876B-C5F0847F8119@gmail.com>
NNTP-Posting-Host: lists.isc.org
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: bind-users@lists.isc.org
In-Reply-To: <854199C1-8834-482D-9E9A-CF09A20C4BC9@gmail.com>
Precedence: list
Xref: csiph.com comp.protocols.dns.bind:15796

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=E2=80=99s =
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 =E2=80=9Cclean=E2=80=9D servers that =
I hadn=E2=80=99t 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=E2=80=99m just using nmap to generate 10 random IPs, I=E2=80=99m not =
=E2=80=9Cscanning=E2=80=9D anything=E2=80=A6

That command managed to trigger the log message on my =E2=80=9Cclean=E2=80=
=9D 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=E2=80=99t 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 =E2=80=9CIN-ADDR.ARPA=E2=80=9D they give out (helpfully in =
all CAPS :)).

Sorry for the noise with this thread.  If anyone has a more in-depth =
explanation of bind=E2=80=99s behavior in this scenario I=E2=80=99d love =
to hear it because I don=E2=80=99t feel like I 100% understand it...=