2.3.4 DNS Extensions (dnsext)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-10-04


Olafur Gudmundsson <ogud@ogud.com>
Olaf Kolkman <okolkman@ripe.net>

Internet Area Director(s):

Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.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

This WG is focused on advancing the zone transfer, update and notify
documents to Draft standard and on the rewrite of the DNSSEC proposed

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

The DNSEXT Working Group actually uses an additional mailing list for
discussion of DNS Security related issues. This list is open to

      Discussion: dnssec@cafax.se
      To Subscribe: dnssec-request@cafax.se
      Archive: http://www.cafax.se/dnssec/ and

The RFC2535bis document set is edited by a team that can be reached
through dnssec-editors@east.isi.edu. This team is chartered with
making editorial changes only, with all substantative changes
discussed on the WG list. Only the document editors and working group
chairs are on this list, an archive of the mailing list is available
      Archive: http://www.east.isi.edu/projects/DNSSEC

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, NSEC RDATA 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 rules 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
              + RFC2308 (Neg Caching) to Draft Standard.
              + RFC2671 (EDNS0) to Draft Standard.
              + RFC2672 (DNAME) to Draft Standard, or revision.
              + RFC2845 (TSIG)to Draft standard.
              + RFC2930 (TKEY) to Draft standard.
              + RFC3007 (Secure Update) to Draft standard.
              + RFC3645 GSS/TSIG to Draft Standard
              + RFC3??? AXFR clarify 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
          special naming conventions.

Goals and Milestones:

Done  Forward NSEC rdata to IESG for Proposed Standard
Done  Forward RFC2535-bis to IESG for proposed standard
Feb 04  Forward Case Insensitive to IESG for Proposed Standard
Done  Forward LLMNR to IESG for Proposed Standard
Mar 04  Forward Wildcard clarification to IESG for proposed standard
Mar 04  Submit KEY algorithm documents RFC253[69]bis and RFC3110 to IESG for proposed standard
Mar 04  Start of process of reviewing the following RFCs and to move them to Draft Standard status
Apr 04  Update boilerplate text on OPT-IN
Apr 04  Submit to IESG RFC2845 (TSIG)to Draft standard
May 04  RFC1982 (Serial Number Arithmetic)
May 04  RFC2782 (SRV RR) to Draft Standard
May 04  RFC2538 (CERT RR) to Draft Standard
Jun 04  RFC1995 (IXFR) to Draft standard
Jun 04  RFC1996 (Notify) to Draft Standard
Jun 04  RFC2136 (Dynamic Update) to Draft Standard
Jul 04  RFC3007 (Secure Update) to Draft Standard
Jul 04  Submit to IESG RFC2930 (TKEY) to Draft standard
Jul 04  RFC2672 (DNAME) to Draft Standard or revision
Sep 04  RFC2181 (Clarify) to Draft Standard
Sep 04  RFC2671 (EDNS0) to Draft Standard
Sep 04  RFC2308 (Neg Caching) to Draft Standard
Nov 04  RFC3090 (DNSSEC zones tatus) to Draft Standard
Nov 04  FRC2539 (DH Key RR) to Draft Standard
Nov 04  RFC3226 (Message Size) to Draft Standard


  • draft-ietf-dnsext-dhcid-rr-08.txt
  • draft-ietf-dnsext-mdns-37.txt
  • draft-ietf-dnsext-rfc2536bis-dsa-04.txt
  • draft-ietf-dnsext-rfc2539bis-dhk-04.txt
  • draft-ietf-dnsext-dnssec-intro-13.txt
  • draft-ietf-dnsext-ecc-key-05.txt
  • draft-ietf-dnsext-tkey-renewal-mode-05.txt
  • draft-ietf-dnsext-dnssec-records-11.txt
  • draft-ietf-dnsext-dnssec-protocol-09.txt
  • draft-ietf-dnsext-insensitive-04.txt
  • draft-ietf-dnsext-wcard-clarify-03.txt
  • draft-ietf-dnsext-dnssec-trans-01.txt
  • draft-ietf-dnsext-tsig-sha-00.txt
  • draft-ietf-dnsext-interop3597-01.txt
  • draft-ietf-dnsext-signed-nonexistence-requirements-01.txt
  • draft-ietf-dnsext-trustupdate-threshold-00.txt
  • draft-ietf-dnsext-trustupdate-timers-00.txt

    Request For Comments:

    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
    RFC3425 PS Obsoleting IQUERY
    RFC3445 PS Limiting the Scope of the KEY Resource Record out
    RFC3596 Standard DNS Extensions to support IP version 6
    RFC3597 PS Handling of Unknown DNS Resource Record (RR) Types
    RFC3645 Standard GSS Algorithm for TSIG (GSS-TSIG)
    RFC3655 Standard Redefinition of DNS AD bit
    RFC3658 Standard Delegation Signer Resource Record
    RFC3755 Standard Legacy Resolver Compatibility for Delegation Signer
    RFC3757 Standard KEY RR Secure Entry Point Flag
    RFC3833 I Threat Analysis Of The Domain Name System
    RFC3845 Standard DNSSEC NSEC RDATA Format

    Current Meeting Report

    DNSEXT WG notes 11/10/04 @ 13:00
    Washington DC, IETF 61
    Scribe: Scott Rose
    Jabber scribe: George Michaelson

    - 2538bis Request for input
    proxy: Olafur Gudmundsson

    RFC2538bis CERT RR Simon Josefsson has taken on the task of updating and advancing the document along the standards track. Send him comments on the document and reports of implementations. If no changes, we can advance it, otherwise rev it and then advance it.
    Goal: to finish this before next IETF meeting

    - Key crypto
    Donald Eastlake
    draft-ietf-dnsext-ecc-key-05 and

    o ECC - Draft only defines key format, not RRSIG

    Questions for group:
    - Include RRSIG format back into draft?
    - Make format applicable to KEY/DNSKEY and IPSECKEY

    There was a question if there are any crypto libraries that contain ECC, at least one open source one was identified.

    o TSIG-SHA: Specification of the SHA with various

    sizes. includes specification for truncation to shorter MACs Open questions that need to go to WG:
    - Why go to SHA1 it it is no longer than MD5?
    - Why not standardize on longer SHA1?

    Donald's answer:Some crypto people like SHA1, and it is quicker to compute.

    Follow up
    - why have to allocate all these names?
    - take discussion to list
    WGLC action to be issued soon

    - QR clarification
    Roy Arends

    Summary in one line: Servers must not answer an incoming message with the QR bit set.

    Room does not object if this document becomes a WG document.

    Based on discussion Roy needs to update document to have slightly better definition on what the scope is (ie. only about the Q/R bits).

    - Wildcard clarification
    Ed Lewis

    New material (editorial concerns)
    1. Drop "clarifying" from title
    2. include text on "* IN DS"
    presentation on what "* IN DS" could mean
    RFC1034: if the query has a qname="*", the results should not be cached...

    Example in presentation:
    Zone has*.example. IN 3600 NS bogon.example.
    *.example. IN 3600 NSEC twn.example. NS NSEC RRSIG

    twn.example. IN 3600 NSEC twp.example. ...
    twn.example. IN 3600 RRSIG NSEC ... signed by example. ...

    twp.example. IN 3600 NSEC example. ...

    Query: two.example. IN NS

    Answer has (?):
    AA = 1, RCODE = 0 (not name error)
    Answer: two.example. IN 3600 NS bogon.example.
    Authority:twn.example. IN 3600 NSEC twp.example. ...
    twn.example. IN 3600 RRSIG NSEC ... signed by example. ...

    Suggested fixes:
    a. outlaw loading zones with * NS
    b. exempt certain types from wildcard processing
    c. instruct DNSSEC validators to ignore "problem"
    d. Specify * label can't have certain types and cannot be subdomained


    There where some statements that c. was the right way to go, but need for a clear definition what that means. There was also discussion that this is an answer not a referral but that needs to be discussed on the mailing list.

    - Requirements for future work on Denial of Existence (approx 20 minutes)
    Olaf Kolkman

    Chairs had a meetings with req. editors and others to prioritize reqs and solution sets at the IETF to facilitate high bandwidth exchanges.

    Rip Loomis presentation on the priority of requirements" http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-2/sld1.htm Please read slides for full contents of this presentation) New ID Will contain a list of the requirements as the priority: Required, med-level desire, low-level desire, very low-level desire.

    There was discussion on exposing online keys, not everyone is concerned with zone enumeration, but some are. Some of the "don't care" about zone walking may care about having keys online

    In the discussion about "Universal signing": Which zones can (under which conditions) not be signed?
    Ans: some zones with long domain names may not be able to be signed with hashed based schemes (over 255 label limit)

    A comment was made that current NSEC design and DNSSEC does not cover the RCODE in the message. Some of the proposed solutions to zone walking cover RCODE.

    Olaf K and proposals for zone walking: http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-0.pdf (pages 9-11)

    There are basicly two characteristics of proposals, hash-based or online-signing both have various flavors, and they measure differently against requirements/constraints. WG needs to evaluate proposals against priority list of requirements and form plan for possible long term solution.

    The three main categories of solutions are
    Epsilon signing (white lies)
    New type for Negative answers that contains information from the query (called magic type in the discussion, better name needed)
    Hash based solutions with varying flavors of Opt-in and wildcards

    Proposed way forward:

    o Fast track Epsilon Signing as that has minimal impact on implementations (only authorative servers affected) and moves the cost of deployment on the parties that can not live with NSEC;

    o and work on a protocol change that does not need on-line keys.

    Goal is to have at most one DNSSECter (ie solutions that require changes in resolvers)

    Question: Does this way forward make sense? Room seems to think so.

    - DNSSEC keymanagement issues

    Johan Ihren

    Mike StJohns

    Ben Laurie

    DNSSEC key management issues
    Johan Ihren (Threshold based trust update)
    Possible IPR issues with schema editors will investigate.
    Draft is better, implementation of version 00 is available

    Changes in draft:
    o Simplified Definition of M and N threshold params
    o Documented the state machine better
    o Fixed the replay attack that was possible before
    No questions

    Question: how long to complete?

    Ihren: fairly complete with some issues. Priming stuff needs more work. Overall it works. IPR issues are up in the air.

    Mike St Johns (rolling over the trust anchor)

    No major changes from prior version mainly related to timers and DNSKEY removal from apex.

    Question to group - is it worth pursuing an in-band mechanism?

    Ben Laurie (DNS Key distribution)

    new, individual submission
    (draft-laurie-dnssec-key-distribution-00.txt) not a WG item yet: need more readers/comments/etc! Islands of trust issues, some people don`t like single auth. inband stuff is tricky. lots of keys, lots of data Mechanism is cross-signing scheme. start with one, fetch more. can recurse or stop

    Closing remarks

    Olafur Gudmundsson: WG is to consider which KEY mechanisms to promote. Timers and Threshold both say they are close to be ready for LC. Chair to check with Security AD if there are any obvious security problems with either proposal.

    - Cross fertilization
    (DNS related work in other groups that needs review)

    James Snell

    Patrik Faltstrom

    DNS issues in SPF
    Stephane Bortzmeyer

    + James Snell(DNS Endpoint discovery)
    Individual submission not seeking to be a WG document (draft-snell-dnsepd-00.txt)

    This is used for providing web-services tools
    2 new RR: XML and EPR

    There where concerns that the XML RR was to open and should be changed to Web services only with restrictions. Number of people suggested that they use NAPTR records for this. Editors thanked for feedback and will update documents based on that.

    + Patrik Faltstrom (DNS Design Choices)
    IAB draft: (draft-iab-dns-choices)
    - discussion of DNS choices in protocol design.

    - question about scope of who to go to with DNS questions involving new DNS RRs

    - TomasN: 2 part response:
    1 is it going to hurt DNS?

    2. Does it help the protocol in question that is requesting it?
    DNSEXT or successor will deal with topic 1. .

    - Is there a need to have a separate draft to request the new RR type?
    A: no.

    Stephane Bortzmeyer (DNS and SPF)
    non-wg draft: draft-lentczner-spf-00.txt

    SPF: Sender Policy Framework. this is a request for a new RR type used by mail-servers to detect spoofed email's. SPF is defined as TXT RR with a new name.

    There where concerns with reusing TXT due to implementation problems in the past. Suggestion from WG to specify a new RR with one RDATA field and use RDLEN as indicator of how long the data is. There where also questions raised about the recommendation that Mail server check for both types (TXT and SPF) and the policies for issuing these queries (serial, parallel, which one takes preference).

    End of meeting


    ECC Key and TSIG SHA
    Requirements related to DNSSEC Signed Proof of Non-Existence
    DNSKEY Threshold-based Trust Update
    Trust Anchor Update
    DNS Endpoint Discovery (DNS-EPD)
    A new RR type for SPF
    Wildcard Clarify