RSSAC Meeting, Adelaide, AU 2000
RSSAC Meeting #6
presented agenda and attendees introduced themselves.
|Jun Murai (JM), (M and ICANN board rep)||Scott Hollenbeck (SH), (A and J)|
|Bill Manning (BM), (B and L)||Piet Barber (PB), (G)|
|Daniel Karrenberg (DK), (K and RIPE rep)||Pindar Wong (PW), (ICANN board rep)|
|Axel Pawlik (AP), (K and RIPE rep)||Gerry Sneeringer (GS), viabridge (D)|
|Ray Plzak (RP), (G)||Akiro Kato (AK), (M)|
|Evi Nemeth (EN), (CAIDA)||Mark Kosters (MK), (A and J)|
|David Conrad (DC), (E and F)|
Jun noted that his term as ICANN representative to RSSAC expires in July after the Yokohama, Japan meeting, and so it would be nice if we could get all the work done by then! It was noted that his term as chair of RSSAC was not tied to his being the ICANN representative.
- Technical criteria for root servers operations (DK)
- Segmentation of GTLDs from root servers A-I (MK)
- localhost and 127.0.0.1 (BM)
- Analysis/Measurement/skitter (EN)
- Y2K and other security issues (DC)
- BIND v9 update (DC)
- Statements on
- The root transition plan (BM)
- MoP and other contractual process (Mark Bohannon,DoC)
- Multi-lingual issues in DNS (PW)
1. Technical criteria for root servers operations
Issue: RSSAC needs
to recommend to ICANN technical criteria for
an RFP for operating root servers. What should those criteria be?
DK: We should work with the IETF on draft-dnsops-req-04.
BM: We should be careful; the draft has the IETF strong must/should language. Any recommendation to ICANN that references the draft, should suggest that they temper the draft with operational experience and implementation capabilities, as they currently exist. An issue is the use of the word "deployable" in the draft and its definition.
MK: What are the details of the problems.
BM: There are words about deployable that are related to cost, mostly of DNSSEC. This might be deployable for one root operator and not for another.
JM: What is status of the draft?
DK: It's before the
IESG. He realizes it's ambitious and parts
are not currently deployable. We should put a rider on our
recommendation, that ICANN should not just require operators
conform fully to the draft (or RFC if has been finished).
Consensus of the group: Recommend that ICANN use the draft/RFC as a basis for the RFP but add common sense so operators are not forced into using things that are not current implementation capabilities ("deployable").
MK: Tom Newell (NSI) promised a straw man contract for root servers. He posted it to the list this week; it's a start -- comes from NSI.
2. Segmentation of GTLDs from root servers A-I
Issue: Many of the current root servers handle the root zone and the GTLDs (com, net, org, etc.) on the same server. These are being separated onto different machines.
MK: This is currently underway, 2 machines have been done recently, D and H (F and J were done previously). Just com, net, and org have moved. Need a more precise schedule than just "done at the end of May".
BM: the TTL is 7 days on some, 2 days on others; there can be problems if it's not consistent.
JM: Can information
about separating the GTLDs be publicly available?
MK: will ask, lots of folks have to approve it (DOC, IANA).
RP: The MIL zone is planning to move in April, are adding 3 more servers.
JM: What is the status
BM: EDU will be taken over by EDUCOM.
DC: How about INT. and ARPA.?
JM: Are there issues with CCTLDs
BM: CCTLDs and INT. are not tied to any of the roots.
ARPA is still under discussion (by DOC and ICANN).
DK: We recommended
having ARPA. Stay with the roots (ICANN) in Singapore.
BM and MK debate two views on ARPA evolution: ARPA to stay with roots (BM), ARPA to go to the regional registries that need to populate them (MK). Trouble is that the regional registries aren't ready and the registries involved may not agree. [There was agreement that ARPA could stay with ICANN/IANA if it was deployed on different machines from the roots.]
Historical Note: Jon Postel gave ARIN day-to-day responsibility for IN-ADDR.ARPA while ICANN was formed. BM thinks his intent was that ARPA should come back to ICANN/IANA after the infrastructure existed to support it, just as the root distribution server will come back to ICANN/IANA. If ARIN or another regional registry wants to have ARPA, they would need to submit a proposal to ICANN. They have not done so yet.
- MK will fix the TTL issue.
- MK will also coordinate a schedule for GTLD migration off the remaining root servers.
- RSSAC will revisit the ARPA issue when ICANN is ready.
3. localhost and 127.0.0.1
Issue: The localhost name and 127.0.0.1 address are special, like addresses 0.0.0.0 or 255.255.255.255. Should a new TLD for them be created, and the zone file for it signed for DNSSEC. RFC 2606 created new "local host." TLD. Should the root servers authoritatively answer for localhost? Should they answer for 0.0.0.127.in-addr.arpa? Should they sign it? Are you (=root operators) responsible for answering localhost queries for anyone else but yourself? Do we want to do "localhost." too?
BM: when and if DNSSEC
is deployed, who should sign them? They are special cases like 0.0.0.0
and 255.255.255.255 and can only really be signed by IANA or left unsigned.
DC: this is one of the many areas of DNSSEC that needs to be played around with.
BM: We raised issue and need to think about it.
MK: should they be hosted in the root, we put them in, took them
out, etc. If advertised by the roots, then they should be signed.
JM: cannot recommend anything at this point; bring up the issue again. It's not a good idea to tell the ICANN board we don't know the answer, don’t have an opinion.
Action Items: JM to report to ICANN that RSSAC has raised the issue of the localhost/0.0.0.127.in-addr.arpa domains and whether they should be served by the roots and signed for DNSSEC. RSSAC is studying the issue.
Issue: CAIDA's skitter boxes are being located at root server locations to study the reachablility and round trip times to a set of clients from the root servers perspective. What can be done to get this moving more quickly and get more monitoring in place? Currently the only server that has been monitored regularly is F.
EN reported the status
of the skitter boxes used for these measurements. Presented a variety
of excuses, no disk space at CAIDA to store the data, lack of sysadmin
help at CAIDA delayed things a bit, politics at ISI and NSI blocking things
for a while, etc. The current status is:
F - monitored continuously since August, 1999. Data is automatically collected and put into daily web pages.
B - being set up
X - set up and running, data collection postponed till disk
space fixed, fixed now
A,J - box being set up
EN asked about European and Asian sites re. electrical power. Switching power supplies and local power cables will work.
EN also asked for
sites to gather a client list in advance of
being sent a box. A client list can be gathered in 3 ways:
1- by running tcpdump on a host on the same network segment
(shared), for example:
2- by enabling Cisco's netflow on the upstream router and using a special version of cflowd that was created by Daniel McRobb (CAIDA) to gather a host matrix instead of a network matrix and then create a client list.
3- by capturing transaction logs and running a script over them to extract the client list.
EN mentioned that
they see a lot of churn in the destination list.
The list collected at the F root server 8-9 months ago has about
16% dead targets at the present time. We have not yet determined
why they are no longer responsive -- firewalls blocking our probes,
machines (presumably name servers) changing their IP addresses, or
just disappearing. She noted that the percentage churn per month
is the same at the F root server as it is in CAIDAs general skitter
target list that contains primarily web servers. Daniel asked for
exact numbers and trends in the churn seen.
JM: resources needed?
EN: responded that DARPA had agreed to fund the additional boxes as an add-on to an existing DARPA grant that supports skitter research with boxes at other locations.
JM: May we have a copy of the contract with DARPA?
EN: agreed to ask CAIDA and supply it.
- EN to provide DARPA contract
- EN to get boxes sent out to other root operators
- EN to ask CAIDA about just supplying the software and letting the root operators supply the PC to run it on.
- Root operators to get client destination list prior to the arrival of the skitter box.
- EN to get exact numbers re. churn in the destination list.
5. Y2K and Other Security Issues
Issue: what is the status of the root servers against security incidents.
JM: Y2K went well,
no problems with root servers; nice statement
regarding Y2K risk was generated. What is the status of root servers against terrorist attack.
BM: Vint Cerf (WorldCom) did a threat analysis of MAE's and found items that should be addressed to increase resiliency of MAEs. Did they consider the roots that are close to the MAEs?
MK: We should not publish a document listing the vulnerability of the roots or the number of roots you need to take out to cripple the root server system.
RP: Should there be a survey/questionnaire that each root server uses to access vulnerability.
DC volunteered to take on the task of preparing such a survey; BM, RP joined in too. Lars Liman (I) has data taken at the bar BOF in Minneapolis. DC to contact, work with BM & RP on the survey.
DC: to do Y2K postmortem statement. But other security report re vulnerability of the roots to remain a confidential internal report.
Action Items: DC, RP, and BM to prepare a survey/questionnaire for root operators to use to access vulnerability of their site to terrorist attack. DC is to do Y2K postmortem report.
6. BINDv9 Update
DC: BIND version 9 is in B1, soon to go out in B2 [did during the Adelaide IETF]. It is still on target for 01may as release date. The missing piece in B2 is the validator for DNSSEC signatures. It will be in the B3. DC expects the performance to be significantly improved especially for multiprocessors; memory usage is better too.
JM: inquired on the
status of testing on the roots. DC said that
F would not begin formal testing until the final release in May.
7. Statement on New Features in BINDv9
A subset of operators is planning to test IPv6. They are talking to the 6bone folks to get advice. Testing is going on now with BSDI and BIND9 B1.
JM: What is the timeline, are there customers demanding it?
BM: There was an enthusiastic
implementation group at the DC
IETF that talked about it. We offered to experiment with it and get
back to them. They were OK with that (Perry Metzger, Jim Bound,
and a Sun guy [didn't get his name]). BM thinks that as long as we show forward progress they will be probably OK. The IPv6 range 3ff3:00/24 has been delegated for use by the root-server system.
DNSSEC is still under development in BINDv9. The root server community needs to look at the signing issues more than the software implementation issues. ISC has been contacted by CERTCO (certco.com) who holds a patent on dividing up a single key, so you can have multiple private keys all decryptable with the same public key. It would use a quorum technique for deciding if a zone transfer should be done. CERTCO seems to be willing to share, but wants the certificate business.
BM: Students have done some split key work so there might be a split key technology in the public domain available. It might still violate the patent.
JM: We need to see what materializes and then need to make a recommendation to ICANN. BM and DC will follow up.
8. The Root Transition Plan
BM: Suzanne Woolf posted a plan a long time ago -- 9 months or so, to move the distribution server from NSI to ICANN. It is provisionally on hold because ICANN is not quite ready topologically or with infrastructure. They are currently unable to proceed. Suzanne is on a temporary leave of absence; BM has inherited the transition folder now and has picked up a more prominent role in the operation of L. How to finish the transition plan and make it go forward using a distribution master. ICANN wants the whois data to follow the transition. Time frame is the end of april to get set up. Biggest complaint is they (ICANN) don’t have a 24x7 help desk. Their existing connectivity is OK, will need to be augmented.
PW: Are there any issues on numbering. BM answered no.
RP asked that the
latest copy be resent to all operators to ensure
that everyone is looking at the same document. BM will do so.
MK: If the transition occurs, how are outages to be addressed?
BM: That is a weakness
in document; you should raise it on
DK: The distribution
server doesn't need 24x7 coverage, the
whois server might.
BM: whois is part of it since the Department of Commerce won't approve the transition without it.
DK: We can do secondary or mirror sites, don't need 24x7 coverage on the distribution server.
BM: Will send the transition document out again, with 10-day response time.
9. MOP and Other Contractual Process
Mark Bohannan did not call in to present this item, however it was discussed.
JM: Asked if there was consensus among the group that the MOP is OK.
DK: We will sign it
if it’s necessary (to sign a physical copy);
we already sent email saying we would sign.
JM: Had a conversation
with Mark Bohannon (USDoC) and he wants
progress on this pretty soon.
DK: Thinks it would
be totally bad for the root operators
to go one-on-one into negotiations with ICANN.
BM: Suggested moving the discussion to root server list.
MK: What do we have
to do to fulfill the MOP? Is it enough
to email saying we agree. MK will send email saying NSI will agree.
10. Multi-Lingual issues in DNS
PW: Some country NICs have started taking registrations and have a technical solution to do it. Commercial companies too. They are forming a consortium to deal with multi-lingual naming, patching browsers, etc. It is still very early. The consortium to be wc3 type structure. If these islands of development need to integrate with the Internet they will need to integrate with this group. Sounds totally political. PW suggesting thinking of it as new GTLD's.
Next physical meeting, in Pittsburgh at IETF. JM requested an interim meeting via teleconference before INET in Yokohama. We need an announcement to the ICANN board and the public from RSSAC; the timeline is important.