NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 13-Oct-99
Chair(s):
Lars-Johan Liman <liman@sunet.se>
Ray Plzak <plzak@nic.mil>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <wijnen@vnet.ibm.com>
Operations and Management Area Advisor:
Bert Wijnen <wijnen@vnet.ibm.com>
Mailing Lists:
General Discussion:dnsop@cafax.se
To Subscribe: dnsop-request@cafax.se
Archive: ftp://ftp.cafax.se/pub/archives/dnsop
Description of Working Group:
The DNS Operations Working Group will develop guidelines for the operation DNS name servers and the administration of DNS zone files. These guidelines will provide technical information relating to the implementation of the DNS protocol by the operators and administrators of DNS domains. The group will perform the following activities:
1. Define the processes by which Domain Name System (DNS) servers may be efficiently and correctly administered, configured, and operated on Internet networks. This will include root zone name servers, gTLD name servers, and the name servers of other DNS domains. As part of this effort, the group will produce documents explaining to the general Internet community what processes and mechanisms should be employed for the effective management and operation of DNS servers.
2. Publish (or assume sponsorship for) documents concerning DNSSEC procedures.
3. Publish (or assume sponsorship for) documents concerning the education of new/novice DNS "users" (FYI-RFCs).
4. Identify performance measurement tools and evaluate their effectiveness.
The group sees four main areas with related documents:
Root Name Server Operational Requirements draft-bush-dnsop-root-opreq-00.txt Editor: Randy Bush
Multiple servers sharing the same IP address
Editor: Masataka Ohta
Zone KEY RRSet Signing Procedure draft-ietf-dnssec-key-handling-00.txt Editor: Edward Lewis
Performance and measuring Editors: Randy Bush & Michael Patton
Goals and Milestones:
Jun 99 |
|
Publish revised Root Server Requirements. |
Jul 99 |
|
Publish revised version of Key Handling. |
Jul 99 |
|
Publish first version of Servers Sharing IP#. |
Sep 99 |
|
WG last call for Root Server Requirements. |
Sep 99 |
|
Publish first version of Performance and Measuring. |
Oct 99 |
|
Publish revised version of Key Handling. |
Oct 99 |
|
Publish revised version of Servers Sharing IP#. |
Nov 99 |
|
Submit Root Server Requirements to the IESG for consideration as Informational (BCP?). |
Dec 99 |
|
Publish 2nd revised version of Servers Sharing IP#. |
Jan 00 |
|
Publish revised version of Key Handling. |
Feb 00 |
|
Publish revised Performance and Measuring. |
Mar 00 |
|
WG last call for Key Handling. |
Mar 00 |
|
WG last call for Servers Sharing IP#. |
May 00 |
|
Publish revised Performance and Measuring. |
May 00 |
|
Submit Servers Sharing IP# to the IESG for consideration as Informational. |
Jun 00 |
|
Submit Key Handling to the IESG for consideration as BCP. |
Aug 00 |
|
WG last call for Performance and Measuring. |
Oct 00 |
|
Submit Performance and Measuring to the IESG for consideration as Informational. |
Internet-Drafts:
· Root Name Server Operational Requirements
· Handling of DNS zone signing keys
· Distributing Root Name Servers via Shared Unicast Addresses
· Distributing Root Name Servers via Shared Unicast Addresses
No Request For Comments
DNSOP WG
8 November 1999
Minutes
Prepared by Ray Plzak
1. Agenda Bashing.
Add Status Report on the draft Root Name Server Operational Requirements
2. Status Report
Root Name Server Operational Requirements - Randy Bush
One change to be made in paragraph 2.7 stating that the root servers SHOULD NOT allow AXFR of a zone. The draft is then ready for WG last call.
3. Report from CAIRN Workshop - Ed Lewis
A DNNSEC workshop was conducted on 29-30 September 1999 at the Collaborative Advanced Inter-agency Research Network (CAIRN) testbed at ISI's Northern Virginia offices. CAIRN is a DARPA funded testbed used by Government, University, and Commercial researchers to conduct Internet Protocol (IP) network based research. The workshop was modeled on the workshop that was conducted in Sweden in May 1999.
Full information on the conduct of the tests and results is contained in draft-ietf-dnsop-dnsseccairn-00.txt. Additional information on the CAIRN testbed is available at http://www.cairn.net. Details on the DNSSEC implementation in CAIRN can be found at http://www.cairn.net/DNSSEC.
The draft will be periodically updated to report on continued testing. Ed solicited other workshop sponsors to conduct similar testing.
It was not known if non CAIRN organizations could participate in the CAIRN testbed.
Liman stated that he has plans to set up an open DNSSEC test bed.
4. Intrepretation of DNSSEC Signatures - Olafur Gudmundsson
Several questions have arisen in regards to the meaning of DNSSEC signatures.
- Is there an implied liability in regards to the data?
- What does the AD bit cover?
- What should the server do when the CD bit is set?
RFC 2535 is not clear in this and should be updated. Work will begin on updating the RFC.
5. Handling of DNS Zone Signing Keys - Ed Lewis
Report on draft-ietf-dnsop-keyhand-01.txt.
There were primarily "mechanical" changes made since the last draft. There are some proposed changes that were prompted by the CAIRN workshop. These proposed changes/issues are
a. Expand the document to cover other cryptographic material used by a zone (TISG, SIG(0)).
b. Redefine the legal signing of keys. This is being changed in the DNSIND WG.
c. Dynamic Update Issues
- The conflict between the goal of off-line signing and the use of an on-line key for updates.
- The assignent of meaning to various key strengths in the KEY flags field.
d. Security Considerations that need to be documented:
- The impact of a broken key on the delegated zone.
- The risk of a poorly run parent to child zone.
e. Several issues created by having multiple alogrithms
- The problem in a parent's signing of a child's key.
- The implication of the number of NULL keys.
- How does the parent and child verify each others data when they don't share the same algorithm
The draft will be used to track DNSSEC changes and will therefore mature slowly. The next major step is the release of BIND 9. Ed solicited WG members to contribute to the document.
6. Distributing Root Name Servers via Shared Unicast Addresses
Ted Hardy reported on the updates to his draft. Masataka Ohta did not present his draft.
draft-ietf-dnsop-hardie-shared-root-server-00.txt
The purpose of this practice is to enable a single root server operator to provide access to a single named root server in multiple locations. It presumes a one-to-one mapping of between named root servers and the administrative entities. Implementation will increase the distribution of of the root DNS servers to previously under-served areas of the network topology and to reduce the latency for DNS query responses in those areas.
The mechanics of the practice were discussed. Details are in the draft. A major problem to be overcome is how to find a malfunctioning machine in the server suite.
The next step is to use the draft to gain operational experience. The draft should progress towards a BCP for all servers with a separate document being developed for Root Ops.
7. Charter Review - Lars-Johan Liman
Liman conducted a review of the WG charter.
Jun 99 Publish revised Root Server Requirements. - Done
Jul 99 Publish revised version of Key Handling. Done
Jul 99 Publish first version of Servers Sharing IP#. - Done
Sep 99 WG last call for Root Server Requirements.
- Move to Nov/Dec 99
Sep 99 Publish first version of Performance and Measuring.
- Move to Sep 00
Oct 99 Publish revised version of Key Handling. - Done
Oct 99 Publish revised version of Servers Sharing IP#. - Done
Nov 99 Submit Root Server Requirements to the IESG for consideration as Informational (BCP?).
- Will slip based on WG last call
8. Report on RIPE 203 Document - Peter Koch
This document provides guidance for the choice of time values for the SOA record. When it is adopted by ISP's Peter will submit it to the WG with the goal of making it a BCP.
9. RFC 2317 - Peter Koch
This document describes a practice for handling classless in-addrs. Peter raised the issue of whether this document should be updated. After discussion, the WG decided that operational experince with using the the practice should be doucmented and published. Peter will prepare the draft.
10. BCP Proposal - Mark Andrews
Mark proposed that a BCP be developed to do the following document the delegation process. Technical requirements that must be met and testing to be conducted prior to the delegation would be included. The WG was overwhelmingly in favor of producing this document. Mark will work on the draft.
11. Other items.
Liman will document the process to do DNSSEC. This will be a DNSSEC tools, testing and ops document which will list the processes and the order of the steps. Target for the draft is Feb 00.
None received.