Last Modified: 2004-06-15
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: email@example.com To Subscribe: firstname.lastname@example.org 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 email@example.com. 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.
|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 RFC253bis 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|
|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|
|RFC3445||PS||Limiting the Scope of the KEY Resource Record out|
|RFC3597||PS||Handling of Unknown DNS Resource Record (RR) Types|
|RFC3596||Standard||DNS Extensions to support IP version 6|
|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|
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.