NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Lars-Johan Liman <liman@autonomica.se>
Ray Plzak <plzak@arin.net>
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Randy Bush <randy@psg.com>
General Discussion:dnsop@cafax.se
To Subscribe: dnsop-request@cafax.se
Archive: http://www.cafax.se/dnsop/maillist/
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
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. |
· Handling of DNS Zone Signing Keys
· Distributing Root or Authorittative Name Servers via Shared Unicast Addresses
· Domain Name System (DNS) Security Key Rollover
RFC |
Status |
Title |
RFC2870 |
Root Name Server Operational Requirements |
DNSOP WG Meeting Minutes
March 20, 2001 (5:00 - 6:00 PM)
Prepared by Richard Jimmerson
Posted agenda:
DNSOP WG Agenda
*) Open meeting, welcome, and agenda bashing.
*) Scribe and blue sheet.
*) draft-ietf-dnsop-keyhand-03.txt (Ed Lewis)
*) *NEW*: draft-ietf-dnsop-parent-sig-00.txt (Miek Gieben)
*) draft-ietf-dnsop-hardie-shared-root-server-02.txt (Ted Hardie)
*) draft-ietf-dnsop-ohta-shared-root-server-00.txt (Masataka Ohta)
*) draft-ietf-dnsop-ohta-shared-root-server-test-00.txt (Masataka Ohta)
*) draft-ietf-dnsop-rollover-00.txt (D. Eastlake, M. Andrews)
*) NEW: draft-ietf-dnsop-inaddr-required-00.txt (Daniel Senie)
*) IPv6 DNS (Alain Durand)
*) RSSAC and IPv6 DNS (Johan Ihren)
*) AOB
*****
*) Open meeting, welcome, and agenda bashing.
5:00 PM - Meeting called to order and agenda reviewed.
Comments on agenda: Place Rob Jofre on agenda after Johan Ihrer
*) Scribe and blue sheet.
Blue sheets were passed to the group and it was noted a scribe had been identified.
*) draft-ietf-dnsop-keyhand-03.txt (Ed Lewis)
Ed's talk covered the Handling of DNS Zone Signing Keys draft. He stated he scrapped the entire draft and put in new content that was covered in new (recent) workshops. The new version of the draft will include issues covered in the workshops. He requested feedback from the group regarding key handling. He is listing all efforts of the attendees of the San Diego meeting about key handling. Ed encouraged the group to take a look at the document and make comments.
There were no comments or questions from the group.
*) *NEW*: draft-ietf-dnsop-parent-sig-00.txt (Miek Gieben)
Miek's talk covered the Parent's SIG over child's KEY draft. Key rollover was talked about. Miek stated they are not using Mark Andrew's draft, but their own. He stated this would be handled tomorrow in the dnsext meeting. He stated he thinks dnssec could be deployed right now and that there is no reason to wait any further. He wanted to note the experiment resulted in much less communication between dns administrators, made parent zone resigning easier, and that there were less bad zones. Miek said that anyone interested in commenting on the draft would need to do so tomorrow during the dnsext meeting.
There were no comments or questions from the group.
This document is being moved to the dnsext WG.
*) draft-ietf-dnsop-hardie-shared-root-server-02.txt (Ted Hardie)
Ted's talk covered the Distributing Authoritative Name Servers via Shared Unicast Addresses draft. Ted explained it was agreed at the last WG meeting that the document would remove references to root and that the new document (January, 2001) has done so, except for in the file name. The secretary did not approve the change to the filename. He stated two comments have been received on the new document since January. One comment pointed out the document only deals with IPv4.
Ted asked if there were any questions and explained one more draft is coming.
The Chair suggested Ted put one more draft to the list and consider it a last call to the list. There were no objections from the group.
*) draft-ietf-dnsop-ohta-shared-root-server-00.txt (Masataka Ohta)
The Chair stated this draft had expired.
Masataka stated he wants to discuss this on the mailing list.
The Chair suggested that this draft should be submitted as an experimental and there were no objections from the group.
*) draft-ietf-dnsop-ohta-shared-root-server-test-00.txt (Masataka Ohta)
The Chair stated this draft had expired, as well.
Masataka stated he wants to submit this as an informational.
Randy Bush recalled the reason for the test was to ascertain whether this kind of test was scalable or operational. He does not believe the scale at which we are doing that is enough to ascertain. He pointed out the assertion he made long ago on this is that it would work technically, but not operationally because when it "bums" up it would not know where to call. Randy asked if anyone cared to argue the point so there could be a discussion.
Bill Woodcock stated Nominum and UltraDNS have experience running this and that it seems to work fine advertising in one AS.
Randy Bush stated Sprint, Verio, etc., have experience with this in one AS, but the difference is they know where to call.
The Chair stated this draft should describe the scope and scale of the experiment and point out what could not be measured.
Michael Patton agreed with Randy and feels it should go from draft to an informational RFC only when we get the useful data Randy talked about.
The Chair suggested the WG will let the draft die unless anyone disagreed with Michael.
There were no statements of disagreement.
*) draft-ietf-dnsop-rollover-00.txt (D. Eastlake, M. Andrews)
Mark Andrews said that at this stage he is trying to get an implementation done and that he hasn't had a chance to address this since the last IETF.
The Chair acknowledged this as said it would be placed on the agenda for the next meeting.
*) NEW: draft-ietf-dnsop-inaddr-required-00.txt (Daniel Senie)
Daniel's talk covered the Requiring DNS IN-ADDR Mapping draft. He pointed out the draft has been updated about a month ago. He recalled the draft was brought to the WG in Pittsburgh to see if there was interest. Feedback there resulted in some questioning and he would like to hear more comments on the mailing list.
A general discussion followed:
* The practice of using in-addr lookups for security was discussed. The WG generally agreed that this was not a good practice and that the next version of the draft should reflect this.
* The use of "MUST" and "SHOULD" was discussed. The sense of which term to use has gone back and forth. There is still not a mood of consensus on which term to use.
* The use of canonical names in the PTR record was discussed. The general sense of the WG was that canonical names were the only names to use in a PTR record.
The chair asked if anyone was opposed to going forward with this draft. The WG was not opposed.
*) IPv6 DNS (Alain Durand)
Alain Durand presented some options for IPv6 DNS. Since San Diego there have been some discussions to describe the needs for IPv6 DNS operation. A draft will be submitted following the Minneapolis IETF.
Slides describing three possible architectures were presented. These three possible architectures were labeled as:
* All IPv6 DNS servers send queries to the root using IPv4
* Dual stack "relay" DNS server
* Logical "dual stack" root server
Next steps to discussing this topic were identified as:
* The ngtrans meeting on Thursday, where Rob Austein would discuss AAAA to A6 transition, evaluating A6, and DNSSEC
* Continue the discussion on the ipv6-dns@sunroof.eng.sun.com mailing list
Comments and discussion included:
* Alain was asked to return to slide describing the logical "dual stack" root server architecture. It was then commented it would not work until there is an entire IPv6 universe.
* Alain agreed but stated this has to go to final call.
* It was commented this option is useless.
* Comment: If you require we wait for an entire IPv6 universe we will not get there in the next 20 years.
* It was commented the protocol requires it and that it was not understood how there can be a pure v6 resolver in a universe with only v4 servers.
* They can be passed through the tree.
* You are recreating new.net in a new and wonderful way.
* A WG member stated that as an implementer he expects they will have a clause stating where the dual state boxes live and that everyone will have to learn. We are going to have to go this one way sooner than later.
* How do we move the tree from the top down?
* It is asked, "how do we move the tree from the top down?"
* The logical dual stack root server diagram will work.
* The dual stack machine can be two completely independent machines (v4 and v6).
* Are we duplicating the Internet for v6?
* At least this will enable v6 only machines to talk to each other without having to go through v4 machines. We should move forward with this solution.
Randy Bush requested that a message please be posted to the mailing list explaining how this will work without partitioning the Internet.
*) RSSAC and IPv6 DNS (Johan Ihren)
Johan's talk covered the RSSAC position on pilot deployment of IPv6 DNS infrastructure.
Johan stated the previous presentation described a one step process. NS in two sets given this model we can provide more and more DNS hierarchy over a v6 transport infrastructure through authorative name servers. We can leave it this way for some time and make a decision when to change.
Johan explained this issue has been considered by the RSSAC. He also pointed out that changes to the root servers should be planned carefully. The RSSAC is considering a pilot deployment to give the basic community something to work with -- different than pure testing. Johan said that what he is presenting is not a concrete plan, but present views on the issue. They suggest discussion stay on the v6dns list and that they will have to report carefully back to ICANN.
Johan identified the major issues related to this as:
* Changes to the root zone is not to be considered lightly
* The size of the response to the initial system query
* There is always a risk of having problems backing out from wrong starts
* Potential breakage
* The ability to fit all root server names plus all glue (v4 and v6) in a response packet to the initial system query.
Johan made it known they will not make any changes to the official root zone hints file before prior testing and studies.
The Chair observed the mailing list has not been very active lately. He pointed out this issue is of interest to everyone and encourage the WG to get back on the list and participate.
*) AOB
The chair asked the WG if there was any other business to be discussed. There were no other items identified. The Chair thanked the WG and adjourned the meeting.
None received.