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.thurs...@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.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
-- 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
