Re: OPT-IN and response synthesis clarification needed

[Miek Gieben <miek@atoom.net>]

[On 03 Apr, 2002, Olaf M. Kolkman wrote in "OPT-IN and response synthesis clari ..."]
> 
> Suppose we have the following zone file (you'll understand the
> shorthand I'm sure):
> 
> $ORIGIN greek
> @	SOA
> 	SIG(SOA) greek 1
> 	KEY 1
> 	NXT alpha
> 
> alpha   A 10.0.0.1
> 	SIG(A) greek 1
> 	NXT-OPT zeta                  (opt in style)	
               ^^^^^^^
shouldn't that be omega?

> 	SIG (NXT) greek 1
> 
> lambda  A 10.0.0.4
> 	SIG(A) greek 1
> 
> omega   A 10.0.0.5
> 	SIG(A) greek 1
> 	NXT greek.
> 
> 
> Should the answer for a query for QNAME=lambda.greek QTYPE=A with the
> DO bit generate an aswer with the SIG included in the answer section?
> 
> The reason for inclussion is to allow resolvers that explicitly trust
> the greek key 1 to verify the data. On the other hand the zone owner
> states explicitly that lambda.greek is not secured.
> 
> I would say that you should include the SIG and leave it to the
> resolvers policy to either trust the OPT-IN NXT and ignore the SIG or
> to ignore the OPT-IN NXT and trust the SIG. 
> 
> Is this the proper approach?
I think yes, if there is a signature it should be returned. Otherwise
the resolver will ask for the signature. If there is no signature
a NXT will be returned and from that the resolver can see if it deals
with a OPT-IN zone or a 2535 zone. 

So in the above example the resolver asks for lambda.greek and gets an
answer with a signature (no NXT record). So it will assume 2535/DS style
signing of this zone. If the signature doesn't check out, it will mark
lambda.greek as bad. 

In other words:
if there is a sig, return it, if it checks out, you're okay, if not
the data is bad no matter is the zone is OPT-IN or not.

grtz
  Miek

--
            miek.nl  __
 __       atoom.net |  | 
|__|.--.--.--.-----.|  |
 __ |  |  |  |  _  ||__|
|__||________|__   ||__|
                |__|