2.4.4 Domain Name Server Operations (dnsop)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 09-Jun-99


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.


No Request For Comments

Current Meeting Report

15 July 1999

Reported by: Ray Plzak

1. Agenda Bashing. No agenda changes.

2. Short Announcements

a. DNSSEC Workshop in Sweden Lars-Johan Liman
- A DNSSEC workshop was conducted in Sweden in late May. Attendees were primarily Swedish ISPs with others including people from Norway and the US. There is a report of the proceedings at http://www.isoc-se.a.se/dns-ws.html. The report is not technically detailed.

Highlights of the workshop

There was a discussion of signed NS records for the root zone. The authoritative response to a query based upon the hints file was not tested. It is speculated that the signed root NS records probably will not fit in a UDP packet thus causing a TCP failover. This could cause a lot of open TCP connections by the root servers.

Bottom Line: DNSSEC software is far from being ready.

b. DNS Chapter in Book Evi Nenmeth

Evi Nemeth reported that she was writing the 3rd version of her book on UNIX system administration and that at her request, the publisher has released the DNS chapter from the copyright. This will permit the chapter to be used in an RFC. She will confer with Scott Bradner and will get this permission in writing.

3. draft-ietf-dnsop-opreq-root-01.txt - Randy Bush

Presented changes reflected in current draft from previous draft

Current draft says that a root server MUST not allow AXFR. Discussion on the list suggested that this ought to be changed to SHOULD not.

Discussion. There was a general discussion about the requirement for the availability of the information contained in the root zone. Comments:

Next Step - Get comments from the list, produce a new version of the draft, and go for a WG last call for the ID to become a BCP.

4. draft-ietf-dnsop-keyhand-00.txt Ed Lewis

An overview of the current draft was presented. This draft had been written earlier as part of an earlier DNSSEC effort. The draft needs to be reorganized and it needs operations/operator experience. The secure dynamic update that this draft discusses is being worked on in the DNSIND WG. The NXT and .PARENT should be dropped from the draft. Key transfer mechanisms are discussed in the DNSIND rollover draft. Other issues are self signing and key management within zone administration.


There was a general discussion about the possession of keys. In particular the possession of child keys by the parent. It was decided that operational experience would determine whether or not there was an affect on UDP overflow. Ed requested that anyone with operational experience to document it and send it to the list. The point was raised without discussion that if the DNSSEC RFC says that the parent MAY have the key of the child that then the Root Ops RFC should say that the root MUST NOT have the key of the child.

Masataka Ohta led a discussion about keeping the authoritative source for the key on a private server. A general discussion did not arrive at a consensus as to whether or not this was a requirement or an option. Consensus was that operational experience would be needed before a determination could be made. It as also noted that an RFC may be needed to document this process.

Ed closed with another solicitation for experience and stated that there maybe a DNSSEC workshop in the US within the next few months, in which case, the topic of key handling would probably be discussed.

Lar-Johan Liman gave a gave a short overview of the relationship between the registrant, the dns operator, the registry, and the registrar. He stated that Mark Kosters was working on a draft about this topic. The general discussion was in regard to clarification of the terms and relationship between the four parties. The consequences of changing registrars was briefly discussed. This would require a change in the administration of the zone and would affect NXT records. That this would probably would require some legal mechanism to be a part of this process would probably strengthen the reason to change the concept and implementation of the NXT record.

5. draft-hardie-dnsop-shared-root-server-00.txt Ted Hardie

Ted presented his draft.

The discussion raised the following points

The next version of this draft will be named: draft-ietf-dnsop-hardie-shared-root-server-00.txt

6. draft-ietf-dnsop-shared-root-server-00.txt Masataka Ohta

Ohta-san presented his draft

The discussion of the draft raised the following issues:

The next version of this draft will be named: draft-ietf-dnsops-ohta-shared-root-server-00.txt

7. The two drafts were compared. Consensus was that they were about 80% the same. Administration requirements for the Hardie version appeared to be less complex as there would only be one AS administrator to deal with. There was general discussion about conducting a test using a sub-domain of the .TEST top level domain. Both authors are to make presentations at the next IETF meeting. At that time the group will decide which, if either, version to pursue.

8. There was no other WG business.

9. draft-koch-dns-soa-values-01.txt Peter Koch

Peter presented his draft which provides recommendations for fixed SOA values to be used by domain administrators.

Peter asked for comments.

The only discussion was concerned whether the WG should take this draft as work of the WG. Consensus was for this document to proceed to become a RIPE document.


None received.