IETF-58 DNSEXT minutes

[Ólafur Gudmundsson/DNSEXT co-chair <ogud@ogud.com>]

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.ietf.org/lists/namedroppers/namedroppers.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
admosphere during the meeting.

Olafur and Olaf. 


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