Finding dnssec validation failures in the logs

Mark Andrews marka at isc.org
Tue Jan 24 20:47:26 UTC 2023


I would be looking for packet loss and / or a bad firewall that is dropping fragmented packets which is triggering fallback to non EDNS requests  If you are forwarding ensure that the entire forwarding chain is validating. 

-- 
Mark Andrews

> On 25 Jan 2023, at 04:53, John Thurston <john.thurston at alaska.gov> wrote:
> 
> 
> 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.
> -- 
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230125/51ea2662/attachment.htm>


More information about the bind-users mailing list