Notes: DNS Root Server System Advisory Committee
التاريخ:
18 مارس, 2001
RSSAC,
18 March 2001, Minneapolis, USA
Present:
Jun Murai WIDE/RSSAC chair m Havard Eidnes NORDUNET i Suzanne Woolf ICANN/MFN l Mirjam Kuehne RIPE NCC k Joao Damas RIPE NCC k John Crain ICANN l Mark Kosters Verisign a, j Brad Verd Verisign a, j Akira Kato WIDE/ISI m Bill Manning USC/ISI b Ashley Kitto Nominum e, f Chris Yarnell Nominum e, f Gerry Sneeringer U. Maryland d Johan Ihren Autonomica AB i Louis Touton ICANN - Nevil Brownlee CAIDA - kc claffy CAIDA - Paul Wilson APNIC - Ray Plzak ARIN/IETF DNSOPS co-chair - Cathy Murphy ARIN -
Agenda:
1. Contracts status between operators and ICANN (louis)
2. Transition status (mark)
DM rolltout status
gTLD migration
3. New TLD addition timeline (louis)
4. Add and delete process (jun)
5. Stats and measurements (kc)6. IPv6 (johan, kato)
7. DNSSEC (bill)
8. International names impact (mark)
9. Reporting to public (jun)
10. Scheduling, housekeeping, web site (jun)
1. contracts (louis)
Louis distributed a new version of the contract (now an MoU) during the
last couple of days to the root ops, trying to include comments he received
on the previous version.
ACTION on everyone to send comments on MoU to Louis before 16 April 2001.
ICANN will seek to extend the agreement with the USG for 6 months. This
will include getting the contracts (MoUs) signed and getting the distribution
master set up.
(Next RSSAC is going to be in August 2001 in London. This is 4 - 5 months
from now one. In the light of this, ICANN will seek extension of the agreement
for 6 more months.)
2. Transition status
2.1. Distribution Master roll out (Louis)
Behind schedule. John currently busy setting up a new location for the
root servers and other high volume servers. Also busy improving logging
and security mechanisms at ICANN.
Four documents need to be written by ICANN:
- General architecture
- procedural plan for shifting to new distribution system
- schedule>
- a root zone file maintenance procedures
2.2. gTLDs are taken off the root (Brad)
Bill: thinks it would be useful to have a mechanism for continuous updates
in place.
MarkK: gov and edu starts to create operational problems. Louis will
follow up on that with the gov/edu operators.
3. New TLD addition timeline (Louis)
ICANN currently discussing contracts with the new gTLDs. Intermediate
set up for .info, .biz, .name, and .pro. The other ones will follow over
the next few months.
Two likely deletions
- zr (has been transitioned into cd)
- Discussion with Willi Black to get gb out (only one entry left right
now)
Jun explains that the first round of new gTLDs have been selected under
the basis that they would not attempt to overload the DNS or other TLDs.
There will be other rounds of selections, do the root operators have an
opinion about that.
MarkK: purely from a technical point of view from the root ops, does
not see a problem, overloading semantics is not our problem. One has to
watch out for things like the idea to use CNAMES to go from one to the
other zone. You would always to go through the root to get the data.
Unless there is hack that would affect the root servers, the root server
operators do not have an opinion about new gTLDs.
Jun: thinks the RSSAC should still review the proposals.
Louis: Suggested policy or other related proposals are usually send to
the SOs for double check and feed back. He suggests to send proposals
concerning new TLDs also to RSSAC.
Jun: yes, please do so.
4. Add and delete process (Louis)
Bill and MarkK have earlier worked on a draft on how to re-distribute
root servers.
Jun: would like to get something on this matter decided soon.
Louis: ICANN gets volunteers from time to time to run a root server.
Response so far was that this will be decided based on technical criteria.
Would be nice if they had some document they can point to.
MarkK: RFC2870
Louis: not enough
ACTION on Bill and MarkK to re-visit and re-circulate the document they
wrote earlier (minimum requirements for running a root server) before
the August IETF.
This could then also serve as guidelines for whoever is going to decide
about new locations or operators.
Jun: we will also need an administrator for deciding the location (RSSAC
or a sub-group).
Louis: can we add two more root servers without breaking the UDP packet
restriction?
Bill, MarkK: not really yet, still needs to be tested better.
People agree that it is not a good idea to add new root servers. There
are a few existing ones that might need to be re-distributed though.
5. Stats and measurements (kc)
Only m has added a skitter box since the last meeting.
KC welcomes everyone to work with the data and to cooperate with her.
Kato: if one root server would be moved to a very far from the others,
would that effect the other root servers?
Bill: yes, it does. All servers need to be distributed as far as possible,
but stay as far as possible within the horizon of the Internet.
KC would like to have some more commitment, at the moment the process
is too vague
Jun: would like to coordinate a structure for measurement works.
6. IPv6
Root ops needs to describe what is needed to be tested
Johan volunteers to work with Alain to present something in DNSOP.
Bill: only talk about IPv6 proposals, something like: we are developing
an IPv6 implementation plan and we are going to circulate that before
we start to implement them.
7. DNSSEC (bill)
There are still many open issues with DNSSEC
Things like key management, key creating, validation periods need to
be tested. All these seem to be operational issued rather than technological.
Will probably not be able to deployed this year.
Bill, Mark and Suzanne volunteered to draft a document how root operators
can use TSIG to protect root server transfers.
8. IDN impact on root servers (MarkK)
MarkK believes there should not be any impact
Johann believes IDN should be avoided for the roots
People agree that the root server operators need to be informed in time,
ideally before the final decision is made, so that the root servers can
have input, can issue warnings, can test etc. People believe that test/experience
for at least six month period prior for the entire root server system
to introduce a new technology anyway.
How much influence do we have on the IETF? Concerns that a lot of the
development is actually done outside the IETF. What can ICANN do to avoid
confusion?
9. Public reporting (jun)
Our web needs to be improved.
ACTION on Jun to send previous minutes to ICANN (John) to update the
web site.
10. scheduling, housekeeping (jun)
next RSSAC meeting: 5 August 2001, London, UK
