[dns-operations] [DNSSEC] Resolver behavior with broken DS records

[Edward Lewis]

At 10:18 +0200 5/6/11, Stephane Bortzmeyer wrote:
>In an (involuntary) experiment under .FR, I discovered that the rule
>"at least one DS must match for a child zone to be authenticated" is
>wrong if a broken DS is present. In our case, the field Algorithm in
>the DS did not match the one in the DNSKEY. While there was another
>correct DS for the child zone, both BIND and Unbound servfailed. So,
>the incorrect DS made the child zone bogus.
>
>Is it normal and expected behavior or a bug common to these two name
>servers?

"Bug" is a strong word.  It generally means that there is clear 
expected behavior that has failed to materialized.  I'm not saying 
you are wrong to call this a bug, but first let's be clear here 
because in the history of DNSSEC, many alleged bugs turned out to be 
something else.

First, the specifications say that "local policy rules/governs." 
Given that, perhaps the choices made by BIND and Unbound disagree 
with what you expect, but it doesn't classify this as a bug.

Second, speaking from the philosophy behind DNSSEC, if there is one 
thread of evidence the data is secure, that should be accepted - 
unless of course your local policy is to be very, very paranoid.

IMHO, a general purpose implementation should be liberal in what it 
accepts.  Because the downside to being conservative is that you cut 
off the user from the affected parts of the DNS if there's ambiguity. 
DNSSEC is just a preliminary defense.

One reason I'd also suggest that general purpose implementations to 
be liberal in finding a validated chain is that it is fairly easy to 
forge bad data and slip that into the DNS messages.  Essentially 
there are lots of "packets of death" or "poison packets" that can 
result in a denial of service and only a few that will validate data.

I wouldn't call this a bug, but I would say the implementations lack 
ruggedness and are open to a remote chance of a DoS.  A validator 
should try hard to find a reason to accept data because only the 
authority can arrange that.  Any one can create reasons to not accept 
it.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?