Subject: Workshop @ ISC report

From: Olaf Kolkman <[email-masked]>
Date: Tue, 18 Mar 2003 02:49:50 +0100

[email-masked] Testing Workshop 
Executive Summary.

== Introduction

  ISC hosted a workshop to test new DNSSEC features between Wednesday
  March 12 and Friday March 14 2003. The workshop focused on issues
  that were currently added to the software and/or features that were
  not fully tested during previous workshops.

  One additional goal of this workshop was to record the complete
  testing infrastructure.

  Before the workshop a number of test issues were identified and test plans
  were written for these issues. During the first day of the workshop these
  test plans were finalized. 

  This text serves as a summary of tests, discussions and feedback to the
  DNSEXT working group.

  A complete journal will be published on the ISC website shortly. The
  link is forthcoming.

== Short description of tests and their results.

  What follows is a list of performed tests and their results and 
  some general comments that the workshop had towards some of the issues
  currently on the table in the DNSEXT working group. 
  
  Roughly following the agenda items on the DNSEXT agenda these are:

  * AD bit. 

    No specific tests but in the workshop the bit seemed useful for
    first order trouble shooting.

  * Unknown RR types

    The type code rollover proposal depends on certain expected
    behavior in the presence of unknown RR types.  Older resolvers
    should not choke on getting the new security records in any part
    of the answer.  The old validators should not interpret the new
    records as security data.

    No specific tests were performed to trigger potential
    problems. While running code with new type code and mnemonics for
    DNSSEC RRs, no problems were seen during the workshop even in the
    presence of older resolvers.

  * DS version 13 draft

    A number of recursive servers (all older versions of bind) were
    queried to assess if problems occur when DS is returned in the
    additional section. No problems were found.
    
    Other corner cases that were identified and fixed in the
    specification were tested. No protocol specification bugs were
    found.

  * DNSSEC OPT-IN  

    We tested OPT-IN.  Some initial testing was done in Amsterdam in
    late January, so we revisited some of those tests and added some
    new ones.  There is one issue with compliance of the current
    resolver with respect to the specs.  It's noted that secure
    dynamic update and OPT-IN are not allowed but it was not tested if
    a dynamic server enforces this.

    One issue not covered in the previous version was implemented and
    tested. The issue is about an insecure delegation with an opt-in
    NXT at the same name.

    We configured for combinations - signed and unsigned zones in the
    OPT-IN span and in the signed span. No problems were found.
    Currently DS RRs are not allowed in OPT-IN (unsigned) spans, and
    this is probably a good thing.

  * KSK (Key Signing Key) Flag 

    We came to the conclusion that for easier management we need more
    bits.  A Signer (stand-alone and in a dynamically updated
    nameserver) needs to know more about the intended use of the keys,
    either 2 or 3 flags are needed.

  * Wildcard behavior.

    The BIND 9.3 private snapshot was tested for the behavior as
    specified in the clarification draft.

    - The server returned correct matches
    - The server returned correct denial of existence RRs
    - The verifier does not yet validate fully; it cannot tell if the 
      correct wildcard match was applied by a server.
    - The behavior of wildcards in combination with CNAMEs needs more
      clarification.

  Additional items discussed during the workshop that are not part of
  the DNSEXT wg meeting but the group wanted to give feedback on.

  * IPv6 transport and DNSSEC 

    Tests of DNSSEC over IPv4 and IPv6 transport (including mixed
    IPv4/IPv6 and IPv6 only at delegations) were concluded
    successfully.

    The group did not address the potential response packet size
    issues raised by IPv6 in combination with DNSSEC data and
    encourages considerations of the Paul Vixie/Akira Kato draft
    submitted to DNSOP on this subject.

  * Discussion of the Type code roll

    Type code rollover of the SIG, KEY and NEXT DNSSEC RRs was been
    tested during the workshop. It works as was expected. The workshop
    saw this is a workable solution and supports the proposal as a
    simple, direct path to production DNSSEC deployment.

  * Inclusion of KEYs in the additional section

    The code we ran during the workshop did not add the KEY RR set to
    the additional section. We experienced no operational problems but
    we noticed additional latency during first lookup per zone.

  * Key management 'BCP'

    With respect to operations we came up with a procedure to roll the
    ZSK (Zone Signing Key). We concluded that a key management BCP
    document is needed.  A long-lived evolving draft is The Way(TM) to
    proceed.

  The workshop did not discuss, test or comment on the following
  DNSSEC related issues.
      + DNSSEC roadmap document
      + The GSS-TSIG proposal
      + DNS Thread document
      + The DNSSEC 2535bis document set

= The Whole Setup

  Configuration, zone and log files are stored in a CVS repository,
  for which a link is forthcoming.  It can be used to bootstrap the
  setup in future workshops.

  Finally the workshop found some minor bugs in the implementation. They
  were not due to problems with the protocol specs. The bugs were reported.

The workshop participants:

 Ed Lewis                        
 Michael Graff                   
 David Blacka                    
 Mans Nilsson                    
 Michael Richardson              
 Sam Weiler                      
 Mark Andrews                    
 Olaf Kolkman                    
 Kazuhori Fujiwara               
 Tomohiro "Sho" Ishihara         
 Yashuhiro "Orange" Morishita    
 Dave Perodin                    
 Rob Payne                       
 David Lawrence                  

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Kazunori Fujiwara <[email-masked]>
Date: Tue, 18 Mar 2003 17:58:58 +0900

Hi, 
nice summary.

> From: Olaf Kolkman <[email-masked]>

snip

> The workshop participants:

s/h/n/  please.

--  
Fujiwra, Kazunori	JPRS