It sounds like I'm correct that lines of the sort:
validating com/SOA: got insecure response; parent indicates it should be
secure
are my indication that dnssec is doing its job. (Whether I should be
reacting to messages like the above remains to be seen.)
Let me rephrase my original question (which remains unanswered): Are
there other strings in the log which similarly indicate dnssec is doing
its job and logging responses which can not be validated?
Of the lines like the above (for a sample day), 92% of them indicate
failure to validate SOA-records. Only 4% are for A-records. Of those
same lines, the most prevalent entris are the SOA-records for:
2% io
2% us
2% ip6.arpa
2% pure.cloud
2% org
4% impervadns.net
6% net
7% cloudflare.net
9% .
33% com
It concerns me the SOA records I'm requesting are so often being
rejected as invalid.
I have my suspicions of what's happening, but not enough information to
form a solid hypothesis or perform tests. I want higher confidence that
I'm recognizing the important lines in the logs before I start casting
stones.
--
Do things because you should, not just because you can.
John Thurston 907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
On 1/24/2023 5:26 AM, Michael Richardson wrote:
John Thurston<john.thurs...@alaska.gov> wrote:
> On a resolver running ISC BIND 9.16.36 with "dnssec-validation auto;" I
am
> writing "category dnssec" to a log file at "severity info;" When I
look in
> the resulting log file, I'm guessing that lines like this:
> validating com/SOA: got insecure response; parent indicates it should be
> secure
> Are an indication I have a problem I should investigate.
Maybe.
It could be that DNSSEC is simply defending you against attackers who are
trying to race insecure answers to your queries in the belief that "nobody
validates"
If it were systematic (every query, every query to some servers...) then you
should suspect that there is a on-path attacker modifying the responses.
That's unlikely in general, but it's why we have DNSSEC.
It could also be the result of corrupted packets that survive the UDP
checksum, or which go through a middle box that "fixes" that. Some satellite
systems do that. I imagine that Alaska might have at least one satellite link.
It doesn't sound like it's systematic, so I think they are off-path
attackers, and it looks like it's queries on .com?
Most likely, there is little you can do.
--
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
