[dnssec-deployment] About "no validation" for DNS root signing strategy

[Thierry Moreau]

Peter Koch wrote:
> Thierry,
>
>   
>> The "proper key" for the signatures to be valid is not in the DNSKEY 
>> RRset at the zone apex. Thus, the signature verification, if done, 
>> results in a "bogus" indication. Is this understanding correct?
>>     
>
> RFC 4035 defines "bogus" only in connection with a trust anchor:
>
>    Bogus: An RRset for which the resolver believes that it ought to be
>       able to establish a chain of trust but for which it is unable to
>       do so, either due to signatures that for some reason fail to
>       validate or due to missing data that the relevant DNSSEC RRs
>       indicate should be present.  This case may indicate an attack but
>       may also indicate a configuration error or some form of data
>       corruption.
>
> Since with the DURZ (Deliberately Unvalidatable Root Zone) you are not
> supposed to configure a trust anchor for the root zone, there's little
> chance the status of "bogus" applies.
>
>   
Thanks for this precision.

However, the protocol provisions (RFC4035) include

5.1. Special Considerations for Islands of Security

Islands of security (see [RFC4033]) are signed zones for which it is
not possible to construct an authentication chain to the zone from
its parent. Validating signatures within an island of security
requires that the validator have some other means of obtaining an
initial authenticated zone key for the island. If a validator cannot
obtain such a key, it SHOULD switch to operating as if the zones in
the island of security are unsigned.

All the normal processes for validating responses apply to islands of
security. The only difference between normal validation and
validation within an island of security is in how the validator
obtains a trust anchor for the authentication chain.

What the contemplated root deployment strategy asks for is to replace 
theabove SHOULD by a MUST. Otherwise, the DNSSEC standard allows "bogus" 
returned by a resolver software implementation even in the absence of 
"other means of obtaining an initial authenticated key" .

Here is a tentative analogy: Do you really need an alarm system 
certified according to the local electrical code to pay attention to a 
fire alarm?

But I am done with this discussion. We'll see what kind of public 
announcement can be made to explain those bizarre signatures using those 
bizarre public keys. At one point, DNSSEC has to be understood outside 
of the inner circles of RFC authors and experts.

Regards,

- Thierry

> -Peter
>
>