Last Modified: 2003-10-29
This WG is focused on advancing the zone transfer, update and notify documents to Draft standard and on the rewrite of the DNSSEC proposed standard.
Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of scope for this Working Group. These issues are considered in other venues, such as the DNS Operations Working Group.
Specific work items are:
o Protocol clarifications and corrections for DNSSEC, initially these clarifications will be done as separate RFCs that will later be folded into a document that we refer to as the RFC 2535bis document standard. These include changes that simplify the operation of DNSSEC.
o Generate new specification documents of DNSSEC (the RFC 2535bis document set) that includes all changes to RFC2535. This includes the following RFCs 2931, 3007, 3008, 3090 and 3226 and a number of Internet Drafts including DS, AD-is-secure, Key Signing Flag, etc. Advance this document set through the standards process.
o Clarification of RFC1034/1035 relating to DNSEXT ongoing work. + Clarification of wildcard processing rules. + Case Insensitivity Clarification.
o After the work items above have been completed the working group will continue on reviewing the following existing proposed standard and examine if there is a possibility to progress them on the standards track. + RFC1995 (IXFR) to Draft standard. + RFC1996 (Notify) to Draft standard. + RFC2136bis (Dynamic Update) to Draft Standard. + RFC2181 (Clarify) to IESG for advancement to Draft Standard. + RFC2308 (Neg Caching) to Draft Standard. + RFC2671 (EDNS0) to Draft Standard. + RFC2845 (TSIG)to Draft standard. + RFC2930 (TKEY) to Draft standard. + RFC3007 (Secure Update) to Draft standard. + RFC3??? AXFR clarify to Draft Standard. + RFC3??? GSS/TSIG to Draft Standard
o Foster the development of Link Local Multicast Name Resolution (LLMNR) standard. The WG has taken up this work since LLMNR it is very similar to the DNS protocol. LLMNR is targeted as proposed standard.
The lifetime of the group is set by the work items above but while these are ongoing the working group has additional tasks:
o Reviewing and providing recommendations about the specification, by other working groups, of RR types that do not require any special processing and that do not require any special naming conventions.
|Sep 03||Update boilerplate text on OPT-IN|
|Oct 03||Forward RFC2535-bis to IESG for proposed standard|
|Oct 03||Forward Wildcard clarification to IESG for proposed standard|
|Oct 03||WG last call on the DNSSEC document set(RFC2535-bis)|
|Oct 03||Forward LLMNR to IESG for Proposed Standard|
|Nov 03||Start of process of reviewing the following RFCs and to move them to PS status|
|Nov 03||Submit KEY algorithm documents RFC253[69d] and RFC3110 to IESG for proposed standard|
|Feb 04||RFC1982 (Serial Number Arithmetic)|
|Feb 04||Submit to IESG RFC2930 (TKEY) to Draft standard|
|Feb 04||Submit to IESG RFC2845 (TSIG)to Draft standard|
|Feb 04||RFC2782 (SRV RR) to Draft Standard|
|Feb 04||RFC2538 (CERT RR) to Draft Standard|
|May 04||RFC1995 (IXFR) to Draft standard|
|May 04||RFC1996 (Notify) to Draft Standard|
|May 04||RFC2136 (Dynamic Update) to Draft Standard|
|May 04||RFC3007 (Secure Update) to Draft standard|
|Aug 04||RFC2181 (Clarify) to Draft Standard|
|Aug 04||RFC2671 (EDNS0) to Draft Standard|
|Aug 04||RFC2308 (Neg Caching) to Draft Standard|
|Nov 04||RFC3090 (TKEY) to Draft Standard|
|Nov 04||FRC2539 (DH Key RR) to Draft Standard|
|Nov 04||RFC3226 (Message Size) to Draft Standard|
|RFC2782||PS||A DNS RR for specifying the location of services (DNS SRV)|
|RFC2845||Standard||Secret Key Transaction Authentication for DNS (TSIG)|
|RFC2929||BCP||Domain Name System (DNS) IANA Considerations|
|RFC2930||PS||Secret Key Establishment for DNS (TKEY RR)|
|RFC2931||PS||DNS Request and Transaction Signatures ( SIG(0)s )|
|RFC3007||PS||Secure Domain Name System (DNS) Dynamic Update|
|RFC3008||PS||Domain Name System Security (DNSSEC) Signing Authority|
|RFC3090||PS||DNS Security Extension Clarification on Zone Status|
|RFC3110||PS||RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)|
|RFC3123||E||A DNS RR Type for Lists of Address Prefixes (APL RR)|
|RFC3197||I||Applicability Statement for DNS MIB Extensions|
|RFC3225||PS||Indicating Resolver Support of DNSSEC|
|RFC3226||PS||DNSSEC and IPv6 A6 aware server/resolver message size requirements|
|RFC3363||I||Representing IPv6 addresses in DNS|
|RFC3364||I||Tradeoffs in DNS support for IPv6|
|RFC3445||PS||Limiting the Scope of the KEY Resource Record out|
|RFC3597||PS||Handling of Unknown DNS Resource Record (RR) Types|
|RFC3596||Standard||DNS Extensions to support IP version 6|
|RFC3645||Standard||GSS Algorithm for TSIG (GSS-TSIG)|
|RFC3655||Standard||Redefinition of DNS AD bit|
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 220.127.116.11 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.