. SOA: got insecure response

[Mark Andrews]

In message <19526.43429.234698.104548 at hadron.switch.ch>, Alexander Gall writes:
> On Wed, 21 Jul 2010 09:20:21 +0200, Gilles Massen <gilles.massen at 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 at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> 
> 
> _______________________________________________
> bind-users mailing list
> bind-users at 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: marka at isc.org