2.3.3 DNS Extensions (dnsext)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, California USA. It may now be out-of-date.

Last Modified: 2004-06-15

Chair(s):
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 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.

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

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

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 at: 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 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 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:
Jan 04  Forward NSEC rdata to IESG for Proposed Standard
Feb 04  Forward RFC2535-bis to IESG for proposed standard
Feb 04  Forward Case Insensitive to IESG for Proposed Standard
Feb 04  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
Internet-Drafts:
  • - draft-ietf-dnsext-dhcid-rr-08.txt
  • - draft-ietf-dnsext-mdns-33.txt
  • - draft-ietf-dnsext-dnssec-intro-11.txt
  • - draft-ietf-dnsext-tkey-renewal-mode-04.txt
  • - draft-ietf-dnsext-dns-threats-07.txt
  • - draft-ietf-dnsext-dnssec-records-09.txt
  • - draft-ietf-dnsext-dnssec-protocol-07.txt
  • - draft-ietf-dnsext-insensitive-04.txt
  • - draft-ietf-dnsext-nsec-rdata-06.txt
  • - draft-ietf-dnsext-dnssec-trans-00.txt
  • Request For Comments:
    RFCStatusTitle
    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
    RFC3658StandardDelegation Signer Resource Record
    RFC3755StandardLegacy Resolver Compatibility for Delegation Signer
    RFC3757StandardKEY RR Secure Entry Point Flag

    Current Meeting Report

    DNSEXT meeting August 2


    Scribe: David Blacka
    Jabber Scribe: George Michaelson


    Olafur Gudmundsson presented information on one various implementations of DNSSEC. There are number of projects going on in each of the major DNSSEC functional area's. There was a question to the meeting about the weather standardization in all APIs is an item of interest to working group. The sense of the room was that this would be a good thing to do.
    The chairs are to find people to start work on draft that documents what information is needed to pass to applications, from this specification an API can be formulated.



    DNSSEC key management or trust anchor maintenance:
    There were three presentations on approaches to maintain DNSSEC trust anchors.
    Mike St. John's presented his scheme using a revoke bit and timers.
    Johan Ihren presented his scheme is using n-of-m keys.
    Paul Vixie presented the DLV interim scheme available in bind-9.3.
    The sense of the room was that this its on important them for the working group to work on.
    The chairs are instructed to coordinate with related working groups (DNSOP) and security area AD's own how to approach this area. All presenters and others are invited to submit drafts for consideration as working group documents.


    Zone enumeration discussion:
    During the working group last call for DNSSEC this issue was raised as a barrier to entry for a number of TLD's.
    The working group commissioned two studies on this issue:
    Zone enumeration prevention requirements
    NSEC++ transition approaches and impact on protocol
    both of these reports where presented based on the current status off the work items.
    In addition two different proposals for NSEC replacement where presented. There a was extensive discussion on the different approaches and the need for even addressing this issue. At the meeting it was pointed out that there are both issues for large delegation zones as possibly for small enterprise zones and these may differ both in requirements and solution space.


    The sense off the room was that none of the proposals is fully baked and we can not do an engineering trade-off yet as the requirements are not known at this point. The working group will actively work on it requirements document before any protocol work is done.


    End off first meeting.


    After discussing with security area directors our new potential work item, the working group has two security advisers available:
    Russ Housley on key management and
    Hillary Orman on key strength issues and on-line signing.


    Second meeting Thursday August 5.
    Note taker: Peter Koch
    Jabber Scribe: George Michaelson


    Jakob Schlyter presented the results of his interoperabilty testing of RFC3597 (unknown RR types support).
    In his tests few bugs where found in implementations but no issues with the document. Jakob recommends advancement to Draft Standard based on the results.
    There are RR types with intra RR versioning (e.g. LOC), those have not been tested specifically.
    At this stage Olafur urges the WG members to volunteer for additional interop tests for the WG to be able to advance more documents to Draft. Jakob is asked to give an estimate of the effort needed for a test coordination "most of the work was getting the implementors to participate rest took 3 or 4 days".


    Donald Eastlake presented two documents for considerations for adoption by the working group: TSIG-SHA1 and ECC-KEYs.
    As there are lingering doubts about the long term viability of MD5 it is prudent to consider adding a stronger hash such as SHA1.
    ECC keys are shorter than RSA/DSA keys for same strength, basic technology is unencumbered, but lots of patents/patent claims wrt to implementation techniques.
    The working group will consider adopting both drafts as working group items.



    Rob Austein presented a straw man proposal for identification of nameserver answering a query. There is need for a mechanism for identifying DNS servers in an anycast set and the current approach (id.server, hostname.bind), which has a problem as it needs a separate query.


    The draft proposes the use of EDNS to ask server for an id to be attached to the response. Since this is a (proposed) protocol change, the doc is discussed here while earlier documents reside in DNSOP.
    There was lively discussion about various aspects of this issue, what to put in the identification string, how fine grain the identifier should be server/server+addr/view etc.
    The sense of the room was that this is of critical importance, but we need requirements first. DNSOP is working on these, please follow and contribute there.


    The chairs then presented their status of each of the current working group documents, majority of which are at IESG or in the last stages to advance there.


    In open mike session Roy Arends presented his and Jakob Schlyter's work on fingerprinting implementations. Noteworthy observations include a firewall product which answers queries with EDNS on with an IN-ADDR.ARPA query, enabling external queriers to detect the presence of this particular IDS systems.
    Another problem present in several implementations (vendors have been approached) is vulnerability against "DNS ping pong", i.e. systems answering unsolicited responses with another response


    Miek Gieben gave input to the recent enumeration discussion.
    He performed a dictionary attack (using john the ripper) on the NL zone. After 18 hours he was able to find 10% (135.000) of the 1.x million domain names.


    Meeting concluded, the chairs want to thank the note takers for excellent notes.

    Olafur + Olaf.

    Slides

    Agenda
    DNSSEC implmentations @ IETF-60 2004/08/02
    Trust Anchor Update
    DNSKEY rollover and priming
    dns://moda
    A path to future ways to Just say NO! in the DNS
    NSEC3
    NSEC2 v. DNSNR/NSEC3
    RFC 3597 Interoperability Report
    ECC Keys in DNS
    TSIG SHA
    Fingerprinting DNS Implementations