list.DNSEXT WG meeting, November 13, 2003.


Accompanying slide set is available in PDF at:

https://www.ietf.org/proceedings/03nov/slides/dnsext-1.pdf



Item 0: Agenda
         Administrivia                    5 min
         Working Group Docs               5 min
         Call for Interop Report          5 min
         Wild Card Clarify discussion    10 min
         DNSSECbis Doc discussion        90 min


Evidenced by the time allotted on the agenda, the predominate focus of the 
meeting is on the latest round of DNSSEC definition document, 
dnssec-intro, dnssec-records, and dnssec-protocol.  The other burning 
issue to be discussed lies in the wcard-clarify draft, which, although not 
discussing DNSSEC itself, has altered some of the work needed to finish off 
DNSSEC.

 Item 1: Administrivia

 (Note all agenda items are accompanied by a slide set.)

 Minutes from the Vienna meeting (July 2003) were posted 
http://ops.i
etf.org/lists/namedroppers/namedro
ppers.2003/msg01541.html

 An issue tracker has been introduced to manage comments and changes to 
working group documents.  The purpose is to make sure all changes 
corresponding to WG decisions are made and that all changes are because of WG 
decisions (consensus).

 One issue tracker instance is as 
https://roundup.machshav.com/dnsext/index document editors can choose to use 
others.

 Item 2: WG Documents

 All of this is in slides.

 Documents seeing recent activity (with the focus of the WG): 
wcard-clarify and the three DNSSECbis documents.

 Docs in final stages: mdns, tkey renewal, case insensitive 
clarifications Docs stalled: 2536bis and 2539bis, DSA and 
Diff-Hellman KEY RR algorithms At IESG: AXFR clarify, DS RR, type code 
roll, key signing bit, opt-in, dhc-id, dns threats, discovery, others?

 Item 3: Call for Interop Reports

 In the past decade, many documents have made it to Proposed Standard, but 
none have made it to Draft Standard.  An important ingredient for draft 
standard is a demonstration and documentation of 
interoperability.  The WG has many documents to promote from proposed to 
draft standards, and this is an open call for work in this area.

 One interoperability report is making it's way through the process.  I 
think this is TSIG, no progress has been made recently.

 Question from the floor: where should folks focus?

 Answer: Milestones on the charter page list what's needed, 
sequencing can be adjusted.

 Item 4: wcard-clarify Discussion

 This document was begun in January, became a WG item during the March 2003 
SF meetings, and made progress through the Vienna meeting in July.  A 
change in editor was requested by the first editor and a new one, Robert 
Elz, has been installed.

 Remaining issues include: 
  a) Cache use of unexpanded wild card records
  b) Use of the "*" label in the interior of a name
  c) Handling of a CNAME RR at a wild card name
  d) Handling of a NS RR at a wild card name
  e) Procedural question - split document between clarify an fix

 Discussion started with (e): room recommendation is to keep the 
document as one.  (Originally the document treated pre and post DNSSEC, now 
it treats only pre-DNSSEC.)  Even though it is 
"clarifications," adjustments to the original definition are to be 
considered and included.  The rationale for not splitting is that if it 
were done, we'd have too many documents in the process.

 Issue (4a): RFC 1034 says that a cache must not make use of a wild card 
record.  (As opposed to a wild card record in the authoritative date.) 
While it makes sense that a cache must not synthesize records from a 
cached wild card record (because the cache doesn't have enough 
information), there's little reason that a cache can't answer with the 
record if the QNAME is for the wild card exactly.  (I.e., *.example. IN A 
1.1.1.1 in cache could be used for a query of [*.example. IN A].)

 The room's proposal was to allow the cache to answer if the record was an 
exact match for the data, leaving the restriction of not allowing cache 
synthesis from the record.

 Issue (4b): Whether or not "*" can be in the middle of a name.  There was no 
discussion in the room on this one.  The basic issue is that the draft goes 
to great length to talk about how this is handled. Later on, someone 
noticed that 1034 discourages this.

 Although there is no sentiment to allow these names, nor is there any 
common use, if the names are barred as in 1034, then more rules are 
needed to specify what happens when they are (mistakenly?) seen.  If the 
rules aren't specified then behavior is unpredicatable - perhaps in ways 
that don't matter very much.

 An older mail list discussion leaned toward staying with 1034's 
definition.

 Issue (4c): Whether CNAME's are "chase" has been the most 
significant issue in this work.  As it stands now, a CNAME RR at a wild 
card means that the wild card only comes into play when the query is for the 
wild card name itself and for the type CNAME.  Implementers have 
suggested letting a CNAME at a wild card play the same role as a CNAME at an 
exact match, meaning that one step in the algorithm in 1034/4.3.2 would be 
altered. (Noting that the algorithm is a suggestion and not a 
specification.)

 This is the central issue on whether or not the document is merely a 
clarification or an adjustment to 1034.

 The sense seems to be to allow CNAMEs to be "chased" at a wild card, 
regardless of whether this is a clarification or an adjustment.

 One other suggestion was that DNAMEs ought to also be included in the 
discussion.  Originally they were, and there still may be a blurb in the 
draft, but the DNAME specification has been seen as too confusing to 
clarify at this point.

 Issue (4d): Whether a wild card NS is permitted.  For a while (since 
Vienna) it seemed that this would be viable.  However, no one has cited a 
concrete application for this.  In addition, there is a rule that only the 
authoritative source can synthesize an answer to a query, when issuing a 
referral, the answering party is inherently not authoritative.

 The sense of the room seemed to be for banning NS RR from wild cards.

 The downside to this is that enforcement should be defined.  E.g., what 
happens on zone load, dynamic update addition, or records seen in an 
answer. (Also, when it comes to DNSSEC, how the signer treats this.)

 Other issues - one person asked about a restriction on SOA (a counter to 
the NS record).  SOA's are already barred from being anywhere other than the 
apex.

 Item #5: The DNSSECbis documents

 The discussion centered around the dnssec-editor's list of 
'official' questions.  For convienence, the questions will be listed by 
number here and not by content.  (Content is available in the slides.)

 The discussion began by listing the following questions as haven been 
recently settled: Q6, Q11, Q16, and Q17.  In addition, Q15 was moved from 
open to settled during the week.

 The rest of the dicussion was organized by the open questions, 
followed by an issue concerning compression of names and the encoding of the 
NSEC RR.

 The current list of open questions are Q18, Q19, Q20, and Q21.

 Q18: conflicting rules between TTL settings on the RRSIG RR

 According to RFC 2181 the RRSIG's at a name comprise a set, ergo all 
should have the same TTL.  According to RFC 2535 the (RR)SIG's ought to 
have the same TTL as their covering set.

 The discussion came down to a choice between making signature records a 
special case (RRSIG, SIG, or both) or adopting a means to make the 
dilemma disappear.  E.g., adopting a bit in the RR type field to signify 
that the record was a signature.

 While there was a sentiment to "not break DNS to secure it" there was a 
stronger opinion to just recognize that the signature was an 
infrastructure record and therefore treat it as special. Hence it should 
take up the TTL from the RRset it signes and it is allowed for 
individual RRs in a SIG RRset to have different TTLs.

 Q19: suppression of duplicates

 The original specification leans toward but does not explicitly forbid the 
transmission of duplicate RR's (same envelope and RDATA).  DNSSEC needs to 
define a canonical form so that the signer and verifier can work 
together.  If not, there would be crypto-level errors which are hard to 
detect and isolate.

 There wasn't a clear mandate to alter the base DNS state on this.  
However, it was clear that there needs to be a canonical form between 
signer and verifier.  Besides suppression of duplicates, sequencing and 
downcasing also have to be preserved.  This isn't necesarily an 
on-the-wire issue, as both ends of the crypto process can repeat the same 
canonicalization process.

 Q20: expansion of wild card in authority section

 A wild card record would be appear in the authority section in a few 
cases. One might be the expansion of an NS RR - but wild card NS RR's seem to 
be on the road to elimination.  (See the discussion on them in the wcard 
doc.)

 In the case of an NXDOMAIN, there would be a NSEC for the exact match and 
for the wild card, and with allowing CNAME's at a wild card to have the 
effect of continuing the lookup, possibly more.  But none of these would 
involve expansion.

 The remaining case is the inclusion of a wild card NSEC record in a "no 
data" situation.  The query name does not have an answer, but a wild card 
synthesis rule is in effect.  However, the desired type is not 
represented.

 The sense of the room was to leave this name in the wild card form. Using 
the record for synthesis would appear to be confusing - first an NSEC 
claims the name does not exist and then there's an NSEC 
(synthesized) for the name. In either case, a resolver could figure this out 
given the label count, but the expansion serves no purpose.

 One other comment was that the result of this ought to be included in the 
wcard clarify draft - cleansing the issue of DNSSEC.  IOW, under what 
conditions are sythesized records places in the authority section.

 Q21: (re)use of NSEC in cache

 According to NCACHE (RFC 2038), a cached negative answer can only be used by 
a cache to answer a newer query if the QNAME, QCLASS, and QTYPE match. With 
the NSEC RR, it is possible to reuse the negative answer for a match 
involving just the QNAME and QCLASS, if the QTYPE is absent from the bit 
field.

 The debate centered around if such a discussion was appropriate here or in 
an update to NCACHE (RFC 2308).  On the other hand, the words in the 
proposed text used MAY - as in the cache MAY take advantage of this.  As 
opposed to a MUST or SHOULD which actively promote the adoption of this 
"shortcut", MAY is neutral, encouraging experimentation.  MUST NOT or 
SHOULD NOT are too strong in the other direction.

 Compression Guidelines:

 New DNS records are not supposed to be compressed.  A discussion along the 
lines of "conservative on send, liberal on receive" ensued. Servers ought 
not compress, resolvers ought not have a fit over compressed data.

 The conversation was to be moved to the list over the wording of 
enforcement. 




NSEC encoding:


The NXT record defines the encoding of types 1-127 and leave the rest open to 
future definition.  This needed to be solved for NSEC. Working group 
chairs announced an appointment of a Document Editor for an Internet Draft 
processing this change: Jakob Schlyter.


Five proposals were listed and briefly described.
a) Extend bitmap for all types (0-127 are coverd by a simple bitmap)
b) List types in sorted order
c) Approach optimized for the first 256 types
d) Approach optimized for the size of the record (skiplist of blocks)
e) Approach close to d, using bitmap within blocks


Comments:
b & c don't allow a name to have 64K types simultaneously, max around half 
that.  'Course, a name with this is unlikely.


The goal was to decide on one approach to seek a further definition.


What followed was a beauty contest.  In the first round, approaches b,c and e 
were chosen (people humming for more than one).


In the second round, approach e was selected for further work.


Wrap-up


The three DNSSECbis documents are planned to be in WG last call by the end of 
the year.  Following soon will be two authoritative 
implementations - BIND 9 and NSD.  Two recursive servers will also be 
available - BIND 9 and IDsA (http://www.idsa.prd.fr).


Acknowledgements


These minutes are based on the notes made by Ed Lewis and Jaap 
Akkerhuis and the Jabber log by Andrew Newton. We would like to thank them 
for their quick submission and precise record of the meeting.


Thanks to those who contributed to the constructive and productive 
atmosphere during the meeting.


Olafur and Olaf.