Current Meeting Report
Slides
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
Chair(s):
Lars-Johan Liman <liman@autonomica.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. |
Internet-Drafts:
- 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:
| RFC | Status | Title |
|---|
| RFC2870 | BCP | Root Name Server Operational Requirements |
| RFC3258 | I | Distributing Authorittative Name Servers via Shared Unicast Addresses |
Current Meeting Report
DNSOP WG
IETF 54
17:00
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.
Summary:
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.
Slides
None received.