Current Meeting Report

2.4.4 Domain Name Server Operations (dnsop)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 06/24/2002

Lars-Johan Liman <>
Ray Plzak <>
Operations and Management Area Director(s):
Randy Bush <>
Bert Wijnen <>
Operations and Management Area Advisor:
Randy Bush <>
Mailing Lists:
General Discussion:
To Subscribe:
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.
  • - draft-ietf-dnsop-inaddr-required-03.txt
  • - draft-ietf-dnsop-dontpublish-unreachable-03.txt
  • - draft-ietf-dnsop-v6-name-space-fragmentation-01.txt
  • - draft-ietf-dnsop-serverid-00.txt
  • Request For Comments:
    RFC2870BCPRoot Name Server Operational Requirements
    RFC3258 I Distributing Authorittative Name Servers via Shared Unicast Addresses

    Current Meeting Report

    IETF 54
    16 July 2002
    Yokohama, Japan

    Prepared by Ray Plzak

    1) Welcome, scribe, agenda bashing

    Ray Plzak volunteered to be scribe. There were no changes to the agenda.

    2) draft-ietf-dnsop-dontpublish-unreachable-03.txt

    The Chair solicited comments from the group.


    a) There were a few comments concerning the point from which unreachability was determined. The general feeling of the WG was that reachable from where should be specified.

    b) There was a considerable discussion about the enforcement. There were two points of discussion. First, the provisions of the draft should not be enforced. Second, this would probably become a BCP and that enforcement would be by voluntary participation. There was no conclusion reached. The discussion will continue on the list.

    c) There was some discussion about the effect that this document would have on NATs. The general sense of the WG was that this document would not pertain to the private side of the NAT.

    d) The Chair announced that the draft to go to the list for WG last call to solicit further comments.

    3) draft-durand-ngtrans-dns-issues-00.txt

    Alain Durand presented his draft. (Not an ngtrans document. This is a personal submission.)

    Draft was accepted as a DNSOP WG draft.

    There was a short discussion about whether using wild cards was a good idea. No conclusion or consensus was reached. The document will be sent to the list for further comment.

    It was noted by the Area Director that this was the first of several ngtrans related documents that would be sent to the WG for consideration. The other documents may be documents that are currently in the NGTRANS WG. This was part of a general movement to spread NGTRANS documents and issues to the other WG of the IETF as IPv6 was now operational.

    4) draft-ietf-dnsop-v6-name-space-fragmentation-01.txt

    The discussion of this draft was postponed until an analysis of the documents that might be adopted by the DNSOP WG as WG documents from the NGTRANS WG.

    5) draft-ietf-dnsop-inaddr-required-03.txt

    The draft was not discussed. The last call on this document will be delayed so that participation by the IPv6 WG can be solicited.

    6) draft-ietf-dnsop-serverid-00.txt

    There was no presentation of the draft. The author (David Conrad) did note that there were no comments on the list.

    It was noted that some servers do not always answer a query. A discussion then commenced about whether this draft should provide for an always answerable query. There were several reasons mentioned for having an always answerable query such as finding a bad server in an anycast pool or conducting studies of servers. One reason advanced for not having an always answerable query was that this could be exploited in a denial of service attack.

    It was noted that the draft has some areas that need to be clarified. Discussion will be continued on the list.

    7) Discussion of DNSOP future.

    It appears that the WG will have additional work with the inclusion of the NGTRANS documents. The Chair will update the charter to reflect this and present it to the WG.

    8) AOB - None.

    9) Closing. The meeting was adjourned.


    None received.