Re: dnssec: resolver - application communication

[Mike StJohns <Mike.StJohns@nominum.com>]

>
>I also think the app should know the difference between:
>
>   - signed, signature is good.
>   - signed, but the signature expired.
>   - signed, but the signature did not validate.
>   - unsigned
>   - unsigned, but should be signed
>
>Am I missing cases here?


signed, but expired, signed but not validated, and unsigned but should be 
signed are all variations of "bogus" - I should have been able to validate 
it, but for some reason I wasn't able to.  Not clear whether the app can do 
anything with the variants here given that an attacker can use replay to 
duplicate all of these. (signed but expired is replay the old data, signed 
but not validated is replay but twiddle the bits, and unsigned but should 
be signed is delete the rsig info).

The four I've got are (these are all at the recursive/caching resolver, not 
the stub)"

secure - signed, validated and there was a trust anchor that rooted the 
signature chain.

unsecure - the unsecured delegation of a zone was signed and validated back 
to a trust anchor (e.g. foo.com is unsecure when .com is secure iff there 
is provably no DS record at foo.com.  Everything at foo.com and below is 
unsecure)

bogus - the resolver had a trust anchor superior to the name but was unable 
to either a) form a valid signature chain, b) get the rrsig data, c) or 
validate the signatures (there's more cases but...)

indeterminate - the resolver has no trust anchor superior to the name.  The 
zone owner may consider it secure, but the resolver can't do anything with 
the information.  The security information is extraneous to the resolver.

There may be a fifth one - error.  SERVFAIL is a valid error message, but 
gives the querier no security information.  The resolver can neither 
confirm nor deny whether or not any information exists or does not 
exist.  (Hmm... let's call that the CIA answer)