Current Meeting Report
Jabber Logs

2.3.2 DNS Extensions (dnsext)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 08/15/2002

O. Gudmundsson <>
Randy Bush <>
Internet Area Director(s):
Thomas Narten <>
Erik Nordmark <>
Internet Area Advisor:
Erik Nordmark <>
Mailing Lists:
General Discussion:
To Subscribe:
Description of Working Group:
NOTE: The DNSEXT Working Group actually uses two additional mailing lists.

DNS Security: To Subscribe: Archive: and Key Distribution: To Subscribe: Archive:

The DNSEXT Working Group has assumed the RFCs and drafts of both the DNSSEC and DNSIND working groups. DNS is originally specified in RFC's 1034 and 1035, with subsequent updates. Within the scope of this WG are protocol issues, including message formats, message handling, and data formats. New work items and milestones may be added from time-to-time with the approval of the Working Group and the IESG.

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 this Working Group's charter. These issues are considered in other venues, such as operational issues in the DNS Operations Working Group.

Broad topics under consideration in DNSEXT are dynamic update, notify, zone transfers, security and adjustments to address the requirements of IPv6 addressing. Security topics, mostly inherited from the erstwhile DNS Security Extensions Working Group, will be addressed in cooperation with the DNS Operations Working Group.

The principal task within this Working Group is to advance several documents describing proposed extensions to DNS. The current list of documents under consideration for advancement is:

Title RFC Status

DNS Server MIB Extensions RFC1611 Proposed

DNS Resolver MIB Extensions RFC1612 Proposed

Serial Number Arithmetic RFC1982 Proposed

Incremental Zone transfer RFC1995 Proposed

Notify RFC1996 Proposed

DNS SRV service location RFC2052 Experimental

Dynamic Update RFC2136 Proposed

Security for Dynamic Update RFC2137 Proposed

Clarification to DNS RFC2181 Proposed

Negative Caching RFC2308 Proposed

DNS Security Extensions RFC2535 Proposed

DSA KEYs and SIGs RFC2536 Proposed

RSA KEYs and SIGs RFC2537 Proposed

Storing Certificates RFC2538 Proposed

Diffie-Hellman Keys RFC2539 Proposed

Extensions to DNS0 RFC2671 Proposed

Non-Terminal DNS names RFC2672 Proposed

Binary Labels RFC2673 Proposed

Other specific work items are:

o TSIG - transaction signatures in (dnsind-tsig-xx.txt)

o TKEY - Secret Key establishment for DNS (dnsind-tkey-xx.txt)

o Securing dynamic update (dnsind-simple-secure-update-xx.txt)

o Protocol clarifications and corrections for DNSSEC (draft-ietf-dnsind-sig-zero-xx.txt) (draft-ietf-dnsind-zone-secure-xx.txt)

o Clarifications for IANA in DNS assignments (draft-ietf-dnsind-iana-dns-xx.txt)

o Documentation of the zone transfer protocol (AXFR)

o Retirement of DNS MIB's RFC's

New work items may be added from time-to-time with the approval of the Working Group and the IESG.

Goals and Milestones:
Done  Advance RFC2052bis to RFC.
JAN 00  Advance RFC1996 for Draft standard.
Done  Advance TKEY and IANA considerations for IESG consideration
FEB 00  RFC1995bis and AXFR advanced for Proposed
Done  SIG(0) advanced for IESG consideration
MAR 00  RFC2136bis advanced for Proposed standard
MAR 00  IXFR (RFC1995bis) interoperabilty testing complete
APR 00  Serial Number Arithmetic, Notify and DNS Clarify advanced to Draft Standard.
APR 00  RFC1611 and RFC1612 status chaned to historic.
MAY 00  RFC2308bis advanced for IESG consideration.
Done  Secure update completed and ready for IESG consideration
Done  RFC2137 Obsoleted
JUN 00  Request that TSIG be advanced to Draft Standard
JUL 00  Revised DNSSEC submitted for advancement to Draft Standard
  • - draft-ietf-dnsext-edns1-03.txt
  • - draft-ietf-dnsext-axfr-clarify-04.txt
  • - draft-ietf-dnsext-gss-tsig-05.txt
  • - draft-ietf-dnsext-dhcid-rr-05.txt
  • - draft-ietf-dnsext-dnssec-roadmap-05.txt
  • - draft-ietf-dnsext-dnsmib-historical-00.txt
  • - draft-ietf-dnsext-unknown-rrs-03.txt
  • - draft-ietf-dnsext-mdns-11.txt
  • - draft-ietf-dnsext-ad-is-secure-06.txt
  • - draft-ietf-dnsext-obsolete-iquery-04.txt
  • - draft-ietf-dnsext-delegation-signer-08.txt
  • - draft-ietf-dnsext-dnssec-opt-in-02.txt
  • - draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt
  • - draft-ietf-dnsext-rfc2536bis-dsa-02.txt
  • - draft-ietf-dnsext-rfc2539bis-dhk-02.txt
  • - draft-ietf-dnsext-dnssec-intro-02.txt
  • - draft-ietf-dnsext-ecc-key-02.txt
  • - draft-ietf-dnsext-ipv6-addresses-02.txt
  • - draft-ietf-dnsext-tkey-renewal-mode-01.txt
  • - draft-ietf-dnsext-restrict-key-for-dnssec-03.txt
  • - draft-ietf-dnsext-dns-threats-01.txt
  • - draft-ietf-dnsext-dnssec-records-01.txt
  • - draft-dnsext-opcode-discover-00.txt
  • Request For Comments:
    RFC2782 PS A DNS RR for specifying the location of services (DNS SRV)
    RFC2845StandardSecret Key Transaction Authentication for DNS (TSIG)
    RFC2931 PS DNS Request and Transaction Signatures ( SIG(0)s )
    RFC2929BCPDomain Name System (DNS) IANA Considerations
    RFC2930 PS Secret Key Establishment for DNS (TKEY RR)
    RFC3008 PS Domain Name System Security (DNSSEC) Signing Authority
    RFC3007 PS Secure Domain Name System (DNS) Dynamic Update
    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)
    RFC3226 PS DNSSEC and IPv6 A6 aware server/resolver message size requirements
    RFC3225 PS Indicating Resolver Support of DNSSEC

    Current Meeting Report

    IETF-55 Atlanta DNSEXT WG Minutes
    Chair: Olafur Gudmundsson
    Randy Bush (absent)
    Note takers: Jun-ichiro itojun Hagino
    Scott Rose
    Date: 2002/November/19 13:00-14:00 EST (18:00-19:00 UTC)
    Agenda Bash
    WG document status
        RFC editor: Restrict KEY, Roadmap, Obsolete IQuery
        IESG: AD is secure, AXFR clarify, Unknown Types, DS
        WG last call complete pending changes: Opcode Discover
        WG last call: RFC1886bis, DNSSEC Opt-In, TKEY Renewal
    GSSAPI and TSIG conflict:
        DNSEXT wg generated TSIG RFC
        DNSEXT wg processed gssapi TSIG
        just before rfc editor started 48hour period we got a report that 
    there was a conflict between two the documents.
        TSIG specifies that TSIG can only be used if original query 
    contains TSIG
        GSSAPI specifies that last message in TKEY exchange has TSIG last 
    message is empty, and this proves the key negotiated is working from 
    security point of view this is a good thing
        TSIG needs minor updates before advancing to draft standard:  is this 
    extensions one of them?
    The sense of the room was that this was a reasonable extensions and the 
    chair is instructed to take this question to the mailing list.
    RFC1886/AAAAbis  Vladimir Ksinant  presenting
        RFC 1886 Update:
        goal:  push AAAA to draft standard
        tests done in July '02
            minor changes in 1886 needed
        Status of draft:  00 in Sept, now -01 in Oct.
            Now in WG last call - comment now please.
    dnssec protocol changes
    opt-in David Blacka
        03 to 04: editorial
        02 to 03:
            interaction with wild-cards clarification
            ad-bit clarification
            validation process changes made more explicit
        increases code complexity
        2 independent code exists
        decreased cost in big registries (signing/whatever)
        way NXDOMAIN works in presence of DS and opt-in
        how NXDOMAIN change affect application?
    There was a comment that security section needs stronger language.
    Clearly list the need for zone transfer protection and risk from zone 
    hijacking of opt-outed delegations.
    Authors agreed examine if the current text is insufficient .
    Opt-in issues: Rob Austein
    opinions about OPT-IN from a study done by Rob and Roy A. -
            1. Corner cases are actually DNSSEC issues, not OPT-in 
            2. DNSSEC pushes a change to the cache algorithm that is 
    considered standard in DNS today.  You have to keep things together under 
    query names now in order to build auth chain.  Especially when NXT RRs are 
            3. OPT IN does make the code more complex - resolvers have to be 
    more intelligent now.
            4. No workshop experience dealing with OPT-IN.  That would be 
    nice, since DS has shown problems.
            5. It seems to help large delegation heavy zones, but not 
            6. From a technical (coding) viewpoint:  the costs are larger than 
    the benefits.  However, higher, operational interests may rule the day.
    Mark Kosters stated there are 2 independent implementations of opt-in 
    authorative server code. and 2 "independent" implementations of 
    resolver, both done by the same person in two different code bases.  There 
    where some discussion on if Opt-in is delaying or enabling the roll-out of 
    DNSSEC. All the speakers stressed the need for some kind of DNSSEC Real 
    Soon Now.
    DS status Olafur Gudmundsson
        1 resolver (or 2)
        2 server implementation
        3 different management tools in development
        3 workshops since Yokohama
        3 under specified corner cases found
          - need to specify what child server returns for DS query at apex
               parent not found
              - if child is served by the same server as ancestor other
               than parent
          - RFC2535 capable caches have problem with DS
        are there more undiscovered?
        one more document update to deal with ancestor problem
        solution: resolver detects this from authority section and asks for 
    delegation information on parent nameservers and then asks them the 
        TIME TO DECIDE if DS goes forward, is close.
    There's no way to determine if all relays are DS capable, does this 
    require flag to state if DNS entity is DS aware?
    Discussion addressed the problems experienced with DNSSEC failing due to 
    middle boxes that do not understand DNSSEC types or DS processing.
    Is it acceptable during deployment to not be able to do DNSSEC 
    resolution, or should DNSSEC require "clear path"?
    The sense of the room was that broken middle-boxes need to be updated and as 
    long as DNSSEC answers are not messing up middle boxes it is 
    acceptable to be only able to do DNSSEC resolution in places where 
    resolvers can talk directly to authorative servers.
    KS flag in KEY: Olaf Kolkman
       version 03 of draft.
       Using a bit in the flags of the KEY record to denote a Key signing
       key.  No protocol value assigned, for user/operator use only.
       Going to WG last call.
    Wild-card optimization: Olaf Kolkman
       assumption: one needs proof for non-existence of a wild-cards
        the proof is to be supplied in the common case where there is
            no wild-card in a zone that proof is complicated and somewhat
            expensive in terms of computational resources and packet size
        is there a way to signal that there is no wild-card in a zone?
        use a bit in the NXT RR's type bitmap to signal non-existence
        of wild-cards
        the meaning:
        there is no wild-card expansion possible of any name in the zone's 
    namespace spanned by a NXT RR simplest algorithm to set the bit turn it on on 
    all NXT RRs in the zone if there are no wild-cards in the zone turn it off on 
    all NXT RRs in the zone if there is any wild-card in the zone
        shortcut to a simple and fast code path for server and resolver 
    smaller footprint
        bypassed in the common case, the complicated verification code is 
    still needed RR type code without RR backward incompatible
        current version of doc
        the suggested algorithm for setting the bit contain an error
        clarifications are needed
        what's next
        update the draft
        does the working group think this is a sane path
        dnssec protocol specs need to describe algorithm for denial of 
    authentication of wild-cards
            if not, resolver implementers will do it wrong
            no need for more than 2 NXT RRs?
        if it makes things more complicated, object.
    There where some questions about savings on the wire (about 150 bytes in the 
    common case). Requires more code, not a lot in resolvers, some in 
    servers, a lot in signers.
    Take issues to the mailing list.
    Domain Name Auto Registration for plugged in IPv6 nodes: Hiroshi 
           This document is in a need of home for working group review is 
    DNSEXT the right home ?
           The DNSEXT chairs have suggested advancing the document either as 
    informational or experimental RFC. Authors would like a working group last 
    call for that status.
    Erik Nordmark commented that he thinks Experimental is a better status for 
    this as it might be promoted to standards track if it becomes widely used.
    After author updates document chair is to start working group last call.
    End of meeting. 


    Key-Signing Key Flag [1] & Wildcard-Optimization [2]
    DNSSEC Opt-In
    AAAA-Bis RFC 1886 Update
    'Domain Name Auto-Registration for Plugged-in IPv6 Nodes'