Day 3

 Opt-in testing

 And we did one chain going from 
 optin->secure->optin->secure->optin->insecure
   insecure.optin.secure.optin.secure.optin
   insecure.optin.insecure.optin.secure.optin

 This worked as expected when using RSASHA1. However, validation failed
 unexpectedly when using a RSAMD5 key for optin.secure.optin.secure.optin.
 It is likely to be a bug in the java signer as validation failed on the
 perl resolver as well.

 We tested an unsigned A record that was within an opt-in span that created a
 servfail. This is expected since opt-in should work with delegations only.

 Wildcard Testing

 Wildcards worked as expected in full-on dnssec as well as opt-in. One 
 point to note, when querying a optin zone without a wildcard, bind returns the
 negative wildcard proof (that is, an additional NXT record covering the
 non-existant wildcard).  The current opt-in draft actually forbids this,
 although perhaps it shouldn't.

 DA Signaling

 When 9.1.3 and 9.2.1 used as forwarders for a DA patched box, the DA
 was dropped and replaced with the D0 bit in the opt RR (expected).


 We formed the following tests:

 An authoritative entry-point server that was not DA aware and delegations that
 were DA aware:
    With a DA aware resolver - failed (expected)
    With a DO aware resolver - failed (expected) this may be a point of
      confusion since it did resolve off the first delegation correctly but
      servfailed on subseqent referrals. It failed since the DO aware server
      expected secure responses on the secure delegations but did not receive
      them.

 An authoritative entry-point server that was DA and delegations that
 were DA aware:
    With a DA aware resolver - succeeded
    With a DO aware resolver - failed (expected) 

 Grandfather problem with DS

 Snapshot did not work with the DS grandfather problem. The result was
 a timeout on the recursive resolver.  Using the patched version using DA,
 resolution worked.

 New typcode patch

 When applied to software with optin and the wildcard patch:

 - Signer is looking for KEY not DNSKEY record in the zonefile.
 - If KEY is included, signer aborts. 

 This appeared to be at least partly an integration problem between
 the opt-in code and the typecode change code. A previous version
 supporting the typecode changes only was applied to the servers, and
 we found that tests done with bind 9.2 and 9.1.2 and bind 8.3
 resolvers work as expected (no crashes). We can draw no conclusion
 about compatibility between opt-in and new typecodes per se and can't
 think of a protocol reason why there should be a compatibility problem.


 Grandparent problems: this test was not completed succesfully because
 the infrastructure was inconsistent with respect both DA and DO
 signalling.