Day 2

We received a patch from ISC and rebuilt the resolvers. We have validated
that  the following delegations work:
  optin -> secure  (secure.optin)
  optin -> optin  (optin.optin)
  optin -> insecure (insecure.optin)

  secure -> optin (optin.secure)
  secure -> secure (secure.secure)
  secure -> insecure  (insecure.secure)

  test -> optin  (optin.test)
  test -> secure (secure.test)
  test -> insecure (insecure.test)

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

In debugging .test (the Verisignlabs opt-in server), the type bit map of the
NXT erroneously  includes a key but there is no key that made the 
validation fail using the ISC resolver for insecure.test.

If a zone has a NS RR that is in zone but no A RR exists for that label,
the validation proof fails even though it may not be necessary for it
to validate before going into a delegation.  The zone only has one NS RR 
and is the secure entry point.

In resolving the issue, we made the .test delegation reply with the
same dataset as the ISC optin zone. Issues arise in that optin.optin
works whereas optin.test does not work. Error turned out to be the
Verisignlabs server giving a referral on a DS query when it should
have returned a noerror. That was fixed and now resolves correctly.

Olaf reported that dnssec-signzone's -d option does not work. Joao 
confirmed that it does it not work. -t does not work either.

Test cases to run:
  wildcards with opt-in - could not test since it triggered a bug that
  trashed the recursive nameserver. A bug report was sent to ISC.
  We confirmed that this error is triggered in both opt-in as well
  full-on dnssec signed zones. In a insecure zone, wildcard processing
  works normally.
   
  running opt-in erronoeously on non-delegation points.
  The test worked as expected (SERVFAIL)

  having a insecure delegation in the nxt chain

  The java zone signer was modified to create this situation, and
  resolving this created a servfail.  Either the draft needs to
  disallow this situation, or the spec should explictly allow it and
  BIND should be fixed.


DA Signaling

Tested with 9.1.2, 9.1.3, and 9.2.1, resolvers against insecure.secure.
They failed.  Installed the DA signalling patch on the authoritative
server on for "secure" and the three resolvers answered correctly.
This worked on the unpatched snapshot resolver as well. However,
a patched resolver snapshot going against a unpatched-snapshot
authoritative server, it came back with an unsecured response when it
should be secured. This is expected behaviour.