2.3.6 DNS Extensions (dnsext)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-09-28


Olafur Gudmundsson <ogud@ogud.com>
Olaf Kolkman <olaf@nlnetlabs.nl>

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Margaret Wasserman <margaret@thingmagic.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, notify
and DNSSECbis documents to Draft standard.

The WG works on solutions for DNSSEC deployment issues that may
require protocol modifications. Two of these issues are identified
and are worked on under the umbrella of this WG. 1] (a) method(s) to
prevent the possibility of trivial zone enumeration and 2] a method
for automated rollover of trust-anchors configured in validating

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 sometimes 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 2535bis document set was edited by a team. This team was
chartered with making editorial changes only, with all substantiative
changes discussed on the WG list. The archive of this editors-only
mailing list is available at:

Specific work items are:

      o Advance the DNSSECbis document set through the standards

      o Clarification of RFC1034/1035 relating to DNSEXT ongoing work.
        + Clarification of wildcard processing rules.

      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.
        + 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 Identify (a) method(s) to prevent the possibility of trivial
        zone enumeration.

      o Define a method for automated rollover of trust-anchors
        configured in validating resolvers.

      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
        require any special processing and that do not require any
        special naming conventions.

Goals and Milestones:

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


  • draft-ietf-dnsext-dhcid-rr-10.txt
  • draft-ietf-dnsext-mdns-45.txt
  • draft-ietf-dnsext-dnssec-opt-in-08.txt
  • draft-ietf-dnsext-rfc2536bis-dsa-06.txt
  • draft-ietf-dnsext-rfc2539bis-dhk-06.txt
  • draft-ietf-dnsext-ecc-key-08.txt
  • draft-ietf-dnsext-insensitive-06.txt
  • draft-ietf-dnsext-wcard-clarify-09.txt
  • draft-ietf-dnsext-dnssec-trans-03.txt
  • draft-ietf-dnsext-tsig-sha-05.txt
  • draft-ietf-dnsext-interop3597-02.txt
  • draft-ietf-dnsext-signed-nonexistence-requirements-02.txt
  • draft-ietf-dnsext-trustupdate-threshold-01.txt
  • draft-ietf-dnsext-trustupdate-timers-01.txt
  • draft-ietf-dnsext-nsec3-03.txt
  • draft-ietf-dnsext-rfc2538bis-09.txt
  • draft-ietf-dnsext-dnssec-experiments-01.txt
  • draft-ietf-dnsext-dnssec-online-signing-00.txt
  • draft-ietf-dnsext-dnssec-bis-updates-01.txt
  • draft-ietf-dnsext-2929bis-01.txt
  • draft-ietf-dnsext-dns-name-p-s-01.txt
  • draft-ietf-dnsext-nsid-00.txt
  • draft-ietf-dnsext-ds-sha256-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
    RFC4033 Standard DNS Security Introduction and Requirements
    RFC4034 Standard Resource Records for the DNS Security Extensions
    RFC4035 Standard Protocol Modifications for the DNS Security Extensions

    Current Meeting Report

    DNSEXT IETF64 Meeting Minutes (draft) 
    Scribe: Wes Griffin 
    Chairs: Olafur Gudmundsson & Olaf Kolkman
    Date: 2005/Nov/08
    Document Updates
            IETF Last Call comments have been incorporated. Chairs will go over
            latest version and check against comments and then post a summary
            to the mailing list with a request for review.
            In RFC-Editors queue.
            Advanced to IESG, waiting for IETF Last Call.
        The chairs expect IETF Last Call shortly on most of these documents.
            Passed Working Group Last Call, waiting on write-up from chairs to
            advance to IESG.
            The documents passed Working Group Last Call, will be advanced.
            Sam Weiler asked the chairs whether there was any evidence these
            document had been reviewed. The chairs said that no comments at all
            were received during the Last Call and the default action to advance
            was in effect. Thomas Narten feels there is an issue with the default
            action of advancing work that no one seems to care about. At the end
            of the meeting (see later minutes) a discussion was held about the
            default action. The chairs still felt that advancing these specific
            documents was fine.
            From the editor, these documents do not change the RDATA format. They
            only update the specifications to refer to DNSKEY and RRSIG instead
            of the old 2535 RRs. Additionally, rfc2539bis-dhk updates the list
            of Diffie-Hellman groups to match the IPSEC DH groups.
        There are no drafts currently in Working Group Last Call.
        One draft has been "lost": draft-ietf-dnsext-axfr-clarify
            This draft will be resurrected by the chairs.
        There are some drafts that are queued for Working Group Last Call. These
        drafts have been queued so as not to overload the working group with work.
                Peter Koch said this draft is ready for Last Call.
                This document has been on the table for a while and will be Last
                The editor requested more feedback on this document, specifically
                from implementors. Olafur Gudmundsson asked if the current loose
                specification for key format could cause interoperability
                problems? Donald Eastlake felt that implementors are better suited
                to answer that question. A handful of people in the room have read
                the draft and one person has attempted implemented it.
        Ongoing Work
                This is a running request for implementors to document design
                decisions and provide input to this document.
                This document is attempting to address the perceived problem that
                it is difficult to get IETF Consensus or Specification Required
                for allocation of new RR Type Codes. The -00 version liberalized
                the early allocation process and also included a number of other
                updates to the IANA Considerations for the various DNS IANA
                Registries. This version met with considerable negative feedback
                at IETF63.
                The new version changes the allocation to half requiring Expert
                Review and half requiring Specification Required. The Expert
                Review process begins with a DNS RR Type Allocation template being
                filled out and posted to the namedroppers mailing list for 3
                Rob Austein asked if the latest version had Specification Required
                for RCODE Types. The answer was yes it does, and he asked that
                those be removed, as having RCODEs that implementations don't know
                about is bad.
                Thomas Narten asked if there were criteria for reviewing new RR
                Type Codes. He thinks there are a set of valid criteria for
                determining if new RR Type Codes can be allocated. He will prepare
                a document discussing these and post it to the mailing list.
                This document has been updated and needs reviewing.
                See later minutes.
    Possible New Work
            During implementation of dynamic update clients, it's been found that
            if a client only has the name needing an update and not the enclosing
            zone, there is no easy way for the client to determine the zone.
            Additionally, if the name doesn't exist, there are major negative
            caching issues with trying to determine the zone. The editor asked
            the working group to adopt this work.
            A handful of people have reviewed this document. The chairs asked
            how many people feel this document is solving a real problem, a few
            raised their hands. A handful of people said they would review this
            document. The chairs will propose to the mailing list to adopt it.
    Interoperability Testing Report
        Nobumichi Ozoe is part of the TAHI DNS Interoperability Testing project.
        They tested one DNS client and found some bugs in the client and some
        bugs in the testing tool. They did not find any issues with the basic
        DNS specifications.
        Version 0.1 of the test tool was released 2005/11/01 and is a free
        download. Current coverage includes the client functionality, basic
        extensions and TCP/UDP over IPv4. Future coverage will include server
        functionality and IPv6 transport. The next scheduled TAHI testing event
        is end of January 2006.
        There is now a mailing list: dnstest@tahi.org and interested people can 
        subscribe via dnstest-ctl@tahi.org
    NSEC3 Report and Discussion
        There is an issue tracker available for NSEC3:
        Issues, both open and closed:
        Issue 1: Signaling NSEC3 to NSEC3-unaware resolvers.
            Mark Andrews strongly objected to a flag day and so we need signaling.
            Ben Laurie answered that if we're going to do signaling, we need to
            decide how to do it.
        Issue 2: Transition from NSEC to NSEC3 by being insecure is fine.
        Issue 3: RFC2932 Base32 encoding is used to solve the sort order issue.
        Issue 4: NSEC3 hashes have owner names whose existence is denied.
            No one has yet to present a technical argument on how this is a
            problem. Peter Koch felt that we don't know yet whether this will be
            a problem and as such we can't summarily dismiss it. Especially
            considering we have a precedent of ignoring "problems" that have come
            back to haunt us. He has half-seriously proposed on the mailing list
            a solution involving using a new label type.
            Olafur Gudmundsson felt that we should do some experimentation to
            better determine if this will be a problem and keep this issue open
            until then. Olaf Kolkman said that the working group has agreed that
            for this document, it will not proceed until and engineering workshop
            has occurred and code has been tested. Ben Laurie stated that there
            are 3 implementations close to being completed.
            Ed Lewis said he won't consider this issue closed until he sees it in
            working operation. Russ Mundy said he wants the working group to
            figure out a way we can move forward.
            Mark Andrews stated that there is a way to do this that will have
            zero impact on the namespace of the zone.
        Issue 5: NSEC3 hash name and legitimate zone name collision is okay.
            The editor believes this is not an issue.
            Rob Austein said that he's 3/4 close to leaning towards Peter Koch's
            half-serious new label type proposal. He feels this is a much cleaner
            solution to all this collision stuff and has the added benefit that
            it can be defined as a binary-only label type which removes the sort
            order issue as well.
            Ben Laurie asked how this would interact with caches that don't grok
            the new label type. Rob replied that dnssec-bis doesn't work through
            dnssec-oblivious middle boxes, so this might just be a non-issue.
            Paul Vixie stated that the original idea behind the separate label
            type was to provide a way to store the various sets of metadata that
            aren't truly dns data and hence don't really belong in the actual
            database proper. This data we're talking about here is also not dns
            data and so a separate label type would go a long way to helping this.
            Ben asked if people were okay waiting until implementations were done
            before deciding on this.
        Issue 6: There is a potential DoS attack on resolvers.
            Evil editoritative servers can select such a high number of iterations
            that resolvers are overwhelmed. The proposal is to allow resolvers to
            specify an upper limit for iterations that it will accept and if a
            response has a higher number the resolver will treat is as bogus.
            Olafur Gudmundsson asked why we can't get rid of iterations and just
            use the salt. Ben explained that the iterations are designed to
            increase the cost of a dictionary attack, while the salt is used to
            increase the cost of a pre-computed dictionary attack. Olafur
            rephrased his question to is the salt sufficient for the threats
            people are seeing? Ben feels this is no, as a single iteration is
            very easy to handle with a network probe.
            Olaf expressed a concern that leaving this up to resolvers will cause
            some resolvers to set a low number and some a high number causing a
            zone to appear secure or bogus to different resolvers. Ben answered
            that by picking a sufficiently high number this shouldn't be a
            problem. It should be a single number and not in the draft.
            Mike St.Johns said that if a number is going to be chosen, please put
            it in the draft and be nice to implementors and users, don't make it
            configurable, just set it across the board. Ben says if the working
            group feels strongly about this it will be done.
            Someone asked if a mechanism could be added such that parent zones
            can set limits for the iterations. The room response was highly
        Issue 7: How secondaries know the NSEC3 parameters a zone is using.
            The solution is that any parameter set present at the apex will be
            present in the entire zone.
        Issue 8: The next version of the document will include additional detail
            about the design choices and rationale.
        Issue 9: The next version will have the hash algorithm field set to 8
            bits so that it can share the hash algorithm registry with the DS RR.
            Sam Weiler asked about his proposal to get rid of the algorithm field
            in the NSEC3 RR and just inherit the algorithm used by the DS RR.
            Olaf Kolkman asked how this would work if there was no parent.
            Mike St.Johns asked what if a zone is using multiple hash algorithms.
    Trust Anchor Management Reports and Discussion
        This space is rapidly growing with drafts and there has been very little
        review by non-involved participants. The chairs urge the working group to
        pay attention because this item is very important to deployment.
        Current Work:
            A co-editor stated that this update was primarily to boilerplate to
            refresh the draft so that it would be available for consideration.
            A prototype implementation is currently being worked on. This and the
            following 2 drafts have IPR claims on file with the IETF. The
            co-editor stated that he's been working with his university lawyer
            and can proceed on a prototype implementation. He expects it will be
            ready by the end of the year and will make it available to a select
            group of people who will not be affected by the IPR.
            The editor said this version is almost a boilerplate change to
            refresh the document. He has started an implementation in dnsjava.
            The author presented slides on some basics of trust anchor management
            including some discussion of requirements and how the TAKREM proposal
            Ben Laurie asked why, since emergency key rollover doesn't depend
            on key revocation and there will be some other mechanism to do
            revocation, why not just use that?
            Mike St.Johns asked about how previous keys are revoked. The author
            said the TTL would revoke the keys, it was pointed out that there is
            no built-in lifetime on keys. He said this would be addressed.
            Bill Manning asked about one slide bullet that said change control
            had been handed over to the IETF and if this meant the IPR claim no
            longer applied? The author said no.
            Steve Crocker said it would be much easier if the technology was
            unencumbered so that we could get on with implementation and testing.
            The editor said there was already an licence for GPL implementations.
            Ben Laurie, Paul Vixie, Matt Larson and a Cisco gentleman all said
            GPL was insufficient for their needs. Olaf Kolkman summed this as a
            requirement for the trust anchor management requirements document.
            The author stated a requirements document by the working group would
            be useful.
            The author said the original idea behind this proposal was to do it
            with x.509, but that x.509 has some issues with cross-signing and so
            a future version will use PGP signatures. This is the only proposal
            on the table that has no known IPR issues.
            Bill Manning asked about what transport this will use, as the user
            is expected to visit a URL and follow a signature chain. His concern
            is that the end-to-end assumption is increasingly wrong. Also, how
            does the proposal cope when data can't be pulled from the URL? The
            editor responded that http is the current transport, but really
            anything can be used. Also, the data can be pulled from any location
            so this shouldn't be an issue.
            Russ Housley asked why this is solving the problem, as he thinks it
            doesn't. Also, this looks exactly like what x.509 was designed to do.
            The author said that x.509 doesn't support multiple certificates with
            the same DN, Russ said it did.
            Michael Richardson asked if there could be some sort of cross
            signature threshold mechanism added so that resolvers only trust
            what's going on when there are a minimum number of signatures.
            The author said that this proposal was such that if a resolver
            trusts a zone, then it trusts what the zone signs (and cross-signs).
        Paul Vixie: Simple Key Rollover
            All of the current mechanisms seem overly complicated. This method:
                Adds a new zone apex RR that expresses H(keyset).
                This is included in the authority section in replies.
                Interested validators can track this RR.
                    When it changes, the validators can fetch the new keyset.
                    If the new keyset validates it becomes the new trust anchor.
                Interested validators can also pull.
                    This pulling is based on the half-life of the current keyset
                    signature lifetime and the half-life of the current keyset
                    The pulling is obviated by the new zone apex RR if seen.
                This new zone apex RR is an opportunistic optimization.
            This differs from the N-of-M proposal:
                N is now a per-algorithm constant, and 2 seems to be fine.
                    Removes a policy knob from the client.
                The new zone apex RR trumpets new keysets.
                    Most validators won't have to pull.
                Revocation is by omission only.
                    It is always good to have more than one key.
                This is very lightweight, but doesn't solve emergency rollover.
                Puts most of the policy on the server-side.
                Validator policy is simple.
                    All a validator does is track static configured trust anchors.
            Possible Server Side Policy:
                Never use a key without also publishing the next one (or the next
                Never use a key without also publishing a backup at the same time
                (for revocation purposes).
                Overlap current/next key lifetimes by 50%.
                Start using a new key at the second half-life (25% remaining) of
                the existing key.
            Roy Arends asked why we need to add a new zone apex RR, why not just
            publish the keys? Olaf Kolkman responded that there are size issues
            with publishing all the keys.
            Ed Lewis noted that while server side policy may not be an issue,
            DNSSEC has always been about the view of the DNS at the resolver.
        General Discussion:
        Margaret Wasserman stated that all of these mechanisms appear to be very
        different in everything that they're trying to do. For example, do we
        have consensus on needing emergency key rollover, or do we have ideas on
        requirements or threat models?
        Olafur Gudmundsson asked what do we have to do with trust anchors? For
        example, should a trust anchor management protocol be able to turn off
        DNSSEC for a zone? We need a better handle on the key rollover requirements.
        Olaf Kolkman stated that this work has come up through the mailing list
        and the solution space is expanding without the working group knowing
        which metrics we want to apply to make a choice. He asked for a volunteer
        to start a draft outlining the requirements. He also asked if this is work
        that interests the working group. If there is no work currently being done
        in the working group do we care about the work? A room hum is
        overwhelmingly in favor of the work.
        Olafur says we need volunteers to work on requirements, review documents,
        and do work. The chairs will ask on the mailing list for a deadline for
        requirements being done.
        Thomas Narten is troubled in that there seems to be some sort-of interest
        in this work, but the work itself is not getting done. Perhaps the wrong
        questions are being asked, how about asking something like "What are our
        3 top priorities, the 3 most important things to get off the table?"
        Ed Lewis stated that as a consumer of an ISP, I don't care about what
        keys zone operators are pushing out, but I do care about my ISP and
        what keys they are using.
        Olaf felt that we can't make further decisions here on a way forward. We
        need requirements and metrics on what is sensible and what the group
    Default Action For Document Review Discussion
        The chairs ask if the best way to handle review is to set a lower limit,
        on the order of 4 or 5 people, that must review a document before it is
        advanced. The room hums consensus.
        Peter Koch asks what will happen if the document doesn't reviewed, will
        it get dropped or will it remain on the work items list indefinitely?
        The chairs state that the document will be dropped and authors will have
        to do a personal submission.
        Sam Weiler asks that before the drop occurs, we keep it as a work item
        and have a review by name and then if there is still no movement, drop it.
        The chairs see 3 major work items:
            Trust Anchor Management
            Work dealing with forwarding documents along the standards track
                This includes rewriting any documents that need clarification.
        The chairs ask for a hand show of what is more important:
            NSEC3: 10
            TAM: 15
        The chairs asked if there is a reason we should NOT do this work in
        parallel? Sam Weiler said that as long as there is a critical mass of
        people working on each item, then we should do the work in parallel.
        Thomas Narten mentioned that even thought requirements documents have bad
        reputations, without them, important discussions are often side-stepped
        and not resolved. The requirements documents should be short-fused, if
        one cannot be completed in 3 months, the work has a serious problem.
        The chairs responded by saying that requirements are needed, and if the
        requirements are not completed in a timely manner the work will be


    Agenda reflecting the order of the meeting
    Eastlake drafts ECC + 2929bis
    NSEC3 update presented by Ben Laurie
    TAKREM introduction by
    Ben Laurie Key distribution presentation
    Simple Auto Key by Paul Vixie
    DNS Compliance testing report: