. SOA: got insecure response

[Alexander Gall]

On Thu, 22 Jul 2010 07:15:25 +1000, Mark Andrews <marka at isc.org> said:

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

That doesn't sound plausible to me.  Wouldn't these messages refer to
those zones in that case?  Instead, they refer to the zones that are
covered by the trust anchors themselves (like the root or some TLD).

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

That's definitively a negative here.  Also, I can't see any EDNS
backoff or disable messages that I could link to these events.

-- 
Alex