Re: Transition from 2535 to opt-in

[Brian Wellington <Brian.Wellington@nominum.com>]

On Wed, 28 Nov 2001, Olaf Kolkman wrote:

> Hi Roy, Mark & David
> 
> I think that the transition issues need some attention in
> draft-ietf-dnsext-dnssec-opt-in.
> 
> I am afraid that an RFC2535 verifiers (not opt-in aware) will not be
> able to see the non secured part of an opt-in zone.
> 
> 
> An example of that:
> 
> Assume my RFC 2535 verifier is configured to use "example." as a root
> of security (Trusted-key in named.conf speak) or more general the zone
> is marked secure by it's parent.
> 
> If I do a query for QNAME=unsigned.example QTYPE=mx I will get an answer
> as in your's example A.1:
> 
>          RCODE=NOERROR
> 
>          Answer Section:
>          UNSECURE.EXAMPLE.      MX    ...
> 
>          Authority Section:
>          SECOND-SECURE.EXAMPLE. NXT   EXAMPLE. NS SIG KEY
>          SECOND-SECURE.EXAMPLE. SIG   NXT ...
> 
>          Additional Section:
>          EXAMPLE.               KEY   ...
>          EXAMPLE.               SIG   KEY ...
> 
> Since there is no SIG on unsecure.example I must mark this RR as BAD
> and discard it. Hence all unsecured records are not visible to an
> RFC2535 verifier.
> 
> As for possible transition scenarios I am afraid that there is no
> smooth transition possible; it seems to be a 'flag-date' thing. 

I don't think that this is a problem.  If a TLD is opt-in and a resolver
is not opt-in capable, it shouldn't contain a trusted-key for that TLD.

Trusted keys (in BIND, at least) need to be explicitly configured, and 
there's no reason to configure a trusted key for an opt-in zone if the 
resolver doesn't support opt-in.

Brian



to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.