In message <19526.43429.234698.104...@hadron.switch.ch>, Alexander Gall writes: > On Wed, 21 Jul 2010 09:20:21 +0200, Gilles Massen <gilles.mas...@restena.lu> > said: > > > Hello, > > Since enabling the root TA in my resolver, I keep seeing from time to time: > > > 21-Jul-2010 08:52:27.929 dnssec: debug 3: validating @0x134fe7e8: . > > SOA: attempting insecurity proof > > 21-Jul-2010 08:52:27.929 dnssec: debug 3: validating @0x134fe7e8: . > > SOA: insecurity proof failed > > 21-Jul-2010 08:52:27.929 dnssec: info: validating @0x134fe7e8: . SOA: > > got insecure response; parent indicates it should be secure > > I've seen this for various top-level domains for which I have trust > anchors configure as well. I could never track this down either, but I > suspect it has nothing to do with the authoritative servers. > > -- > Alex
Named has to deal with multually incompatible senarios. DNSSEC which requires EDNS and nameservers and firewalls which drop EDNS requests so named has to turn off EDNS to get answers back. Occasionally a set of answers will take too long to get back to named or are lost due to network problems and named will fallback to issuing plain DNS queries which will of course fail validation if the zone is secure and you have a trusted path from a trust anchor to that zone. Named will normally re-issue the queries and get a answer that can be validated as it tries again to use EDNS. This will happen more often if you have network equipment that is blocking large DNS responses (>512 or network MTU) but still lets through EDNS responses. If you see this you should also look for congested network paths and paths with long delays. Mark > > Otherwise validation just works fine and mostly I see these: > > validating @0x134fe7e8: . SOA: marking as secure, noqname proof not needed > > > Following an earlier comment on this list by Mark Andrews ( > > http://www.mail-archive.com/bind-users@lists.isc.org/msg04276.html ) > > I've checked the answers given by the 13 root instances (ipv4 and 6), > > and all answer to "dig . soa +dnssec" just fine. > > > Trying to capture . SOA queries from the resolver (by a crude > > tcpdump/grep) failed to show something useful. > > > Any idea what could be the reason for these messages, and how to > > confirm/retrace the events that lead to such messages? Could it be that > > lame auth server with a local (unsigned) copy of the root zone triggers > > this? > > > best regards, > > Gilles > > > -- > > Fondation RESTENA - DNS-LU > > 6, rue Coudenhove-Kalergi > > L-1359 Luxembourg > > tel: (+352) 424409 > > fax: (+352) 422473 > > _______________________________________________ > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > > > _______________________________________________ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
