2.3.1 DNS Extensions (dnsext)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-29

Olafur Gudmundsson <ogud@ogud.com>
Olaf Kolkman <okolkman@ripe.net>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret.wasserman@nokia.com>
Internet Area Advisor:
Thomas Narten <narten@us.ibm.com>
Mailing Lists:
General Discussion: namedroppers@ops.ietf.org
To Subscribe: namedroppers-request@ops.ietf.org
Archive: http://ops.ietf.org/lists/namedroppers/
Description of Working Group:
DNS was originally specified in RFC's 1034 and 1035, with subsequent updates. Within the scope of this WG are DNS protocol issues, including the specification of message formats, message handling, and data formats used for DNS client-server and server-server communication.

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.

Goals and Milestones:
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
  • - draft-ietf-dnsext-axfr-clarify-05.txt
  • - draft-ietf-dnsext-dhcid-rr-07.txt
  • - draft-ietf-dnsext-dnssec-roadmap-07.txt
  • - draft-ietf-dnsext-mdns-24.txt
  • - draft-ietf-dnsext-delegation-signer-15.txt
  • - draft-ietf-dnsext-dnssec-intro-07.txt
  • - draft-ietf-dnsext-ecc-key-04.txt
  • - draft-ietf-dnsext-dns-threats-04.txt
  • - draft-ietf-dnsext-dnssec-records-05.txt
  • - draft-dnsext-opcode-discover-02.txt
  • - draft-ietf-dnsext-keyrr-key-signing-flag-11.txt
  • - draft-ietf-dnsext-dnssec-protocol-03.txt
  • - draft-ietf-dnsext-ipv6-name-auto-reg-01.txt
  • - draft-ietf-dnsext-dnssec-2535typecode-change-05.txt
  • - draft-ietf-dnsext-wcard-clarify-02.txt
  • Request For Comments:
    RFC2782 PS A DNS RR for specifying the location of services (DNS SRV)
    RFC2845StandardSecret Key Transaction Authentication for DNS (TSIG)
    RFC2929BCPDomain 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
    RFC3425 PS Obsoleting IQUERY
    RFC3445 PS Limiting the Scope of the KEY Resource Record out
    RFC3597 PS Handling of Unknown DNS Resource Record (RR) Types
    RFC3596StandardDNS Extensions to support IP version 6
    RFC3645StandardGSS Algorithm for TSIG (GSS-TSIG)
    RFC3655StandardRedefinition of DNS AD bit

    Current Meeting Report

    list.DNSEXT WG meeting, November 13, 2003.
    Accompanying slide set is available in PDF at:
    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 
     Item 1: Administrivia
     (Note all agenda items are accompanied by a slide set.)
     Minutes from the Vienna meeting (July 2003) were posted 
     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 
     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 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 
     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 
     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 
     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 
     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 
     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 
     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 
    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
    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.
    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).
    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. 


    DNSEXT Working Group