2.4.6 Domain Name Server Operations (dnsop)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 15-Nov-00


Lars-Johan Liman <liman@sunet.se>
Ray Plzak <plzak@arin.net>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Advisor:

Randy Bush <randy@psg.com>

Mailing Lists:

General Discussion:dnsop@cafax.se
To Subscribe: dnsop-request@cafax.se
Archive: http://www.cafax.se/dnsop/maillist/

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.


Request For Comments:






Root Name Server Operational Requirements

Current Meeting Report

DNSOPS Working Group

Tuesday, March 28, 2000 13:00

Prepared by Ray Plzak

1. Agenda Bashing
Ray Plzak

A discussion of the root ops draft was added by the chair.

2. Experience with Classless In-Addr Delegation on Bit Boundry
Ray Plzak

Peter Koch was not in attendance. He had sent email to Ray Plzak stating that he was working on draft and would be at the Pittsburgh meeting to discuss the draft.

3. Root Ops Draft
Ray Plzak

The draft went to WG last call in Dec 99 and to IESG last call in Feb 00. The WG was queried to see if there were any technical objections to the draft as it is written. There were none. A HUM indicated a consensus on this. Ray Plzak will send out an announcement to the list to see if there are any further technical objections to the draft. If there are none, Bert Wijnen (the AD), will take the draft to the IESG so that the draft can progress to a RFC.

4. Shared Unicast DNS Servers
Ted Hardie

* Ted Hardie provided an update for his draft concerning distributing root or authoritative name servers via a unicast address.

* Comments that Ted had received via email

-- * Bill Manning. This document should also deal with authoritaive name servers not just the root servers. The document abstract will be changed: "and authoritative name servers" was added to the abstract.

-- Bill Woodcock. In the original draft, it says two interfaces: He said that it was unclear that logical interfaces were required. Wordsmithing will be done so that they can be logical interfaces, instead of two different physical interfaces. Loosely or tightly synchronized. For this draft, there is a requirement that both servers who share a unicast address be tightly coordinated. Should the addresses be announced from a single AS. This draft presumes that it is a single administrative entity for all instances of each root. Other changes: The root servers are a common target of attack. Added to Security Considerations "authoritative name servers may also be targets"

* Comments From the Floor

-- Servers in an authoritative context may be different that the root context, mostly because of the difference in the AXFR. The draft needs to have new language about this concept.

-- For server requirements, refer to the server requirements document.

* Test of concept.

-- Hardie is testing it with shadows internal to his organization. He wants to use a test TLD (non operational) for further tests.

-- Randy Bush says that this an old hack and is familar to many ISPs. It has been operationally tested.

-- Hardie wants to put one up for people to test out.

5. Anycast DNS Servers Test
Masataka Ohta

* Ohtasan presented an update to his draft. Because of a schedule conflict he was unable to report to the WG in Washington. The draft has expired. He will update it and publish a new one. He reported that at the Anycast BOF in Washington a conclusion was reached that anycast is useful for DNS but is costly.

* Discussion then ensued about a means to test Ohta-san's proposal. Randy Bush [Verio] will provide the unicast IP address, AS number, and domain. The scope of the test was discussed. Ohta-san proposed that the test duration be for one [1] year. The test scope will be limited to demonstrate that ANYCAST will provide the desired result. There were several members of the WG who volunteered to participate in the test. It is important to have participants from various global points of the Internet. The participants will exchange information with Ohtasan. The test will start within a few months. Ohtasan will write an ID for the test plan. Randy Bush will set up a mail list for the test.

* There was a general discussion about concerns regarding system administration and debugging. It is not clear how outside parties will be able to determine the source of a problem, how to isolate the problem, or how to contact the appropriate administrative authority. If a server fails in an ANYCAST situation, how are queries blocked to the failed server? More queries should not be directed to the failed server. Techniques such as the OSPF keepalive should kill the route to the server from the router.

6. DNSSEC Update
Olafur Gundmusson

* Olafur presented a report on the status of the drafts being worked on by Ed Lewis

-- The key handling draft is on hold pending the final version of BIND 9.

-- There have been some changes to the core concept of the DNS zone security draft. Olafur encouraged all to read it over again since all of the changes are significant.

* Olafur presented an update of the activities of the DNSEXT WG.

-- The TSIG draft has gone through WG last call. There have been four versions done since then to get it through IESG last call. Hopefully the drafts will be an RFC within a few months. The implementation software is already out in a BETA version.


None received.