[Opendnssec-develop] KASP Auditor Requirements

[Stephen.Morris at nominet.org.uk]

John Dickinson <jadsab at googlemail.com> wrote on 12/05/2009 14:20:36:

> On 23 Apr 2009, at 12:38, Stephen.Morris at nominet.org.uk wrote:
> 
> > I've placed the first draft of (what I consider to be) the 
> > requirements
> > for the KASP Auditor on the wiki:
> >
> >      http://www.opendnssec.se/wiki/Signer/AuditorRequirements
> 
> 
> Some notes:
> 3.1 item 1: the signer should be able to change the TTL,  minimum  and 
> serial numbers for the SOA. This is important so that the signer can 
> "fix" a unsigned zone that does not contain values which are not 
> consistent with the values specified in kasp.

This raises an interesting question: ignoring the serial number, should 
the SOA values in the input zone file or in KASP be considered the 
definitive ones?  If the former, then either the values in KASP _must_ 
match the values in the zone file, or else KASP needs to read the zone 
file to determine them.  If the latter, this raises the possibility of 
what is set in the zone file is ignored by the signer, which could lead to 
confusion on the part of some users.



> 3.1 item 2: using serial number arithmetic, of course.

Good point.  But I think that the auditor should issue a warning message 
(as opposed to an error message) for this.



> 3.2: item 2: the protocol field must equal 3
> 3.2: I don't agree the last two checks. Either the sep bit should be 
> being used in a way consistent with RFC5011 or in a way consistent 
> with the policy. It may be that the policy should be consistent with a 
> BCP RFC like 4641bis.

Perhaps these checks should be optional then?



> 3.3 s/domain/zone/

"domain name" would be more accurate.  The idea is that if you have 
several million records, you may only decide to validate the records for a 
subset of all the names in the zone.



> 3.4 item 1: what if you are switching from nsec to nsec3? This does 
> not have to be done in a single step.

Good point.  Again, perhaps this should be configurable; most of the time 
you will use either NSEC or NSEC3 and you would want to ensure that only 
those type of next-secure records were in the zone, but during a 
transition you would want to ignore the check.



> 3.4 item 4: should read: the nsec records form a single closed loop 
> linking each owner name in canonical order.
> 3.4 item 5: should read: each nsec correctly identifies the set of RR 
> types present at the  owner name.

Accepted.



> 3.5 item 1: what if you are switching from nsec3 to nsec? This does 
> not have to be done in a single step.

Accepted, see above.



> 3.5 item 2: if you are doing nsec3 then there must be a nsec3param.
> 3.5 item 2c:  there must be at least one complete chain of nsec3 
> records present with the same set of nsec3 parameters.
> 3.5 item 3: should read: each nsec3  record has bits set to indicate 
> the types of rr's  present at the owner name.
> 3.5 item 4: should read: the next hashed owner name field contains 
> the next hashed owner name in hash order.

Accepted.



> 3.5: I think we should also say that all nsec3 records must either be 
> opt in or opt out.

Probably a good idea, but is this a requirement of the protocol?



I'll update both the requirements and auditor requirements documents after 
the teleconference next week.

Stephen