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