WikiStart: nsec3-workshop-agenda.txt

Line 
1 Workshop Agenda
2
3 Most of the tests for authoritative servers were completed during the first workshop. This workshop will concentrate on a few key issues that came up from that workshop and followup discussions. Most of the focus will be on the resolver side.
4
5 The identified issues are
6 (1) signalling NSEC3 and traversing through various combinations.
7 (2) rolling from NSEC to NSEC3 and vice versa
8 (3) zone signing, loading and transfer
9 (4) handling brokeness
10
11 We'd like to propose the following schedule for the three days:
12
13         Monday morning
14         1. Welcome
15         2. Introduction
16         3. Network, Resolver and Tools setup
17         4. Agenda Bashing
18         5. Group Management
19
20         Monday morning, afternoon
21         6. Signalling and Traversing
22
23         monday afternoon
24         7. Rolling from NSEC to NSEC3 and vice versa
25
26         Tuesday morning
27         8. Zone signing, loading and transfer
28
29         tuesday afternoon, wednesday morning
30         9. handling brokeness
31
32         Wednesday afternoon
33         10. wrap-up and documentation
34
35
36
37 1. Welcome.
38
39 We have a few newcomers to this workshop. We'd like them to share their specific interest and expectation of this workshop, and get a good overall sense of understanding the protocol.
40
41 2. Introduction.
42
43 An outline of the 4 main items (point 6-9) we'd like to test, the basic setup of the tests, the expected documentation, and a small open discussion of other interesting test scenarios that we might have overlooked.
44
45 3. Network and Tools setup
46
47 We have a set of authoritative servers, serving a set of zones, available from a server outside the network. In contrast with the last workshop, this will not be a backup, but will be the default. We need to test the network in order to reach those servers.
48
49 We have two implementations of a resolver. Some of us will be asked to run an instance of the resolver. We need six instances, which are explained below (point 6).
50
51 We will also have a set of tools to make life easier. These include a whole range of items, and we will ask the developers of the tools to give a quick outline.
52
53 4. Agenda bashing.
54
55 Since we're on a fairly tight schedule, we'd like to hash out anything left untouched, and ask for input on other material to test.
56
57 5. Group management.
58
59 Since we will have 6 instances of a resolver, we'd like to have 6 groups of participants testing each instance of the resolver. We'd like to have a fair distribution of experience and knowledge. If you don't know how to use the tools, sit with someone who does. If you haven't grasped the details of NSEC3 yet, sit with someone who does.
60
61 6. Signalling and Traversing
62
63 There are 3 authoritative servers. The 'trust-anchored zone' (ws.nsec3.org) resides on one server. The second level zones reside on another server, and the third level zones reside on yet another server. The ws.nsec3.org zone is DNSSEC-NSEC signed and contains delegations to signed zones and one unsigned zone. The delegations are to zone with the following format.
64
65         n0      unsigned zone
66         n1u     signed zone with unsigned delegations, using NSEC
67         n1s     signed zone with signed delegations, using NSEC
68         n3o     signed zone with opted out, unsigned delegations, using NSEC3
69         n3u     signed zone with unsigned delegations, using NSEC3
70         n3s     signed zone with signed delegations, using NSEC3
71
72 The zones with unsigned delegations (n0,n1u,n3o,n3u) will have a delegation to n0.(n0,n1u,n3o,n3u)
73 The zones with signed delegations (n1s,n3s) will have delegations to n1.n3s and n3.(n1s,n3s)
74
75 We will have two independent resolver implementations. One is BIND, the other UNDBOUND. Each implementations will be configured in three modes: NSEC3 capable, NSEC only, and one with no trust anchor. Three modes times two implementations gives us 6 instances.
76
77 Each group sends the following list of requests to their assigned resolver instance, and notes the results (ad bit status, response type). We will hand out the list with requests, so they can easily be ticked off.
78
79  1. www.n0.n0.ws.nsec3.org IN A
80  2. www.n0.n1u.ws.nsec3.org IN A
81  3. www.n0.n3o.ws.nsec3.org IN A
82  4. www.n1.n1s.ws.nsec3.org IN A
83  5. www.n3.n1s.ws.nsec3.org IN A
84  6. www.n1.n3s.ws.nsec3.org IN A
85  7. www.n3.n3s.ws.nsec3.org IN A
86
87 Note we do only care about the delegation logic here. To be complete, we will have a test zone from the previous workshop available so all response types can be checked again.
88
89 Following the tests, discussion about any odd behavior, failed tests, etc.  The
90 product of these tests will be a matrix of the compiled results. 
91
92 7. Rolling from NSEC to NSEC3 and vice versa.
93
94 This is somewhat trickier to automate, though we will have 3 sets of files ready for an intermediate (delegating) zone, and 3 for an 'end' zone before-hand.
95 The 3 zones files are basically: NSEC-known-alg, NSEC-unknown-alg, NSEC3-unknown-alg. To be efficient, these second and third level zones will be delegated to local servers at the workshop. (Two individual laptops). We might use three to avoid the DS roll in the trust-anchored server (ws.nsec3.org).
96
97 We use the combination of resolvers mentioned above (BIND-NODNSSEC, etc,etc), effectively the same teams who did the previous testing, and have one or two individuals doing the rolling.  To avoid TTL issues, we'll keep'em short.
98
99 Each group sends a list of requests similarly to the previous test (but a shorte list). This list will be done 5 times, according to the following states, combining the beforementioned states as follows: (1)NSEC-KNOWN-ALG (2)NSEC-UNKNOWN-ALG (3)NSEC3-UNKNOWN-ALG (4)NSEC-UNKNOWN-ALG (5)NSEC-KNOWN-ALG
100
101 Only the intermediate zone 'roll' is going to be rolled, thus, given the following zones:
102
103 n0.roll.ws.nsec3.org
104 n1.roll.ws.nsec3.org
105 n3.roll.ws.nsec3.org
106
107 Each group will query their respective resolver, for a record in n0, n1, n3 and nx. The 'nx' zone does not exist and is in order to trigger a negative response from the server responsible for 'roll'.
108
109 8. Zone signing, loading and transfer
110
111 We believe that zone signing mostly works, since we have previously compared the output of several signed zones using several signers. We'd like to test zonetransfers for serveral signed zones.
112         - from bind to nsd
113         - from nsd to bind
114
115 using several NSEC3 signed zones with different parameters.
116
117 These tests will be fairly simple. We'll take two groups, one group transferring all the zones to their hosts from the BIND server, another group from the NSD server. We have a zonecompare tool to compare what has been transferred to what is on disk.
118
119 9. handling brokeness
120
121 This test is an iteration of the same test in the previous workshop. We will again use two groups. One using the bind-resolver, another using the unbound resolver, using a list of requests to perform.
122
123 10. wrap-up and documentation.
124
125 During wrap-up we will address the issues evolving from all the previous tests, and possibly perform other tests. We need to writeup 5 documents, where 4 documents match the results of the 4 previous tests, and one document handling the open issues, and possible future work.
126
127