Finding dnssec validation failures in the logs

[John Thurston]

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.Thurston at alaska.gov
Department of Administration
State of Alaska

On 1/24/2023 5:26 AM, Michael Richardson wrote:
> John Thurston<john.thurston at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230124/f4baf144/attachment.htm>