Notes: DNS Root Server System Advisory Committee
Date:
15 July, 2002
RSSAC, 15 July 2002, Yokohama, Japan
The following agenda was presented:
ccTLD mtg report
CRADA report
Contrract process
CAIDA/WIDE measurement
IPv6
Members (RSSAC list) -discuss list?� Openness?
Schedule
Jun Murai asked whether there were any additions or adjustments to the
agenda.� Bill Manning suggested�some discussion about openness, etc. perhaps
an rssac-discuss mailing list?
Note takers: Bill Manning, Cathy Murphy, George Michaelson, Louis Touton,
Johan Ihren
Attendees
Ray Plzak, ARIN
Joao Dumas, RIPE NCC, K
Frederico Neves, LACNIC
Louis Touton, ICANN
Don Wilder, ARIN
George Michaelson, APNIC
John Crain, ICANN, L
Suzanne Woolf, L,F
Bill Manning, B
Nevil Brownlee, CAIDA
David Conrad, Nominum
Paul Vixie, C, F
Randy Runkles, G
Cathy Murphy, ARIN
Akira Kato, M
Jun Murai, Chair & M
Lars Liman, I
Johan Ihren, I
Paul Wilson, APNIC
Brad Verd, A, J
Kenjiro Cho, SONY
Yuji Sekiya, WIDE
Jerry Sneeringer� � phone
kc Claffy - phone
ccTLD Bucharest report: - Crain
http://www.wwtld.org/~wwtld/livescribe/
contains copies of the presentations given to ccTLD managers in Bucharest.�
The overall theme of these presentations was:� Who are we and what do
we do? They included a short introduction/update for ccTLD managers. They
obviously feel the need for some sort of contact mechanisms to reach us
in contingencies.
RSSAC making presentations to ccTLD managers and talking about what
we do fills a real hole and alleviates some worries/doubts that they may
have had. They would like RSSAC to better document its process, recommendations,
and proceedings.
CRADA report:
Extended goal to 30 June 2002 �Paul Vixie reported that a rough draft
was circulating and that additional text is being worked on.� Nonetheless
the editorial team needs more raw material (substance) to complete the
draft for wider circulation.�
The schedule for getting draft to DoC was discussed.� Louis Touton reported
that ICANN received a letter from DoC, expressing concern over the fact
that the report had not yet been received.� A good target would be to
get a draft to DoC by mid-August.� To achieve that, comments on the draft
should be sent to the list once it is circulated. Johan Ihren asked whether
it was feasible to get a draft to the list by mid-July, so that it was
stable by mid-August.
Jun Murai noted that the existing draft had some missing parts.� In particular,
he noted that material from the presentation at the November 2001 ICANN
meeting on root-server security should be added. Louis Touton noted that
a draft covering that material would be very useful, particularly if it
could be completed in July.��About 20-30 pages of material would be good.
Jun Murai asked whether monetary support is available from ICANN to support
this effort. Louis Touton responded that monetary support would be possible,
provided it were limited in extent.
Jun Murai commented that the draft report could use broader circulation,
earlier.� Perhaps a first pass this weekend.� Need much more help. He
noted that everyone needs to do their part to meet the deadline.
Contractual Process:
At the time of the last RSSAC meeting there was a decision to assemble
a list of representatives of the root-operator organizations that can
sign contracts.� In many cases, the individual operators are not able
to �bind their organizations legally.� So, at the time of the last meeting
Jun Murai requested names of those who could legally bind the hosting
organizations.� We now have a list, but it may not be accurate�it is simply
�a first pass. It does serve as a tentative list, however, and we can
start discussion with this group and then evolve it.� The papers/MOU�s
have been circulated to this group,� This signers� group might have as
input, for example, things on ICANN reform.
Bill Manning asked whether there is there any interaction between this
policy group and RSSAC.� Jun Murai asked for opinions of the committee
on this point.� Louis Touton stated that, perhaps, the RSSAC might be
used to ensure the policy folks understand the technical issues.� Paul
Vixie noted that a reason for assembling the signers group is to explore
the reasons why none of the organizations have entered MoUs.� Having a
group facilitates communications between organizations on why they did
not sign. Will meet between now and next RSSAC meeting.� Appears to have
input into the CRADA report so could meet soon. The goal is to get to
a point where a contract could be signed. An issue is the difficulty in
finding the individuals with signing authority.
Measurement:
Nevil Brownlee presented his slides, which are available at http://www.caida.org/.�
The CAIDA work involves three types of analyses:
- passive measurements
- bind log file� analysis� from (F)� - now RFC1918 servers
- skitter � (all are deployed now)�� - simulation of the impact of
server removal� (presumption of� heterogenous resolver code)
He stated that CAIDA is looking for direction on how/where to go from
here?� Ggw asked whether more measurement siteswere needed?� Nevil stated
that four more are needed. Louis Touton asked whether that will this give
meaningful data? Nevil was not sure that it would.
Paul Vixie showed some MRTG data for Hazel (the RFC1918 server used
above � anycast).� He pointed out the interesting spikesm, which reflect
human activity, human factors theories: small networks, no sysadmin, misconfigured.�
The data also show accumulated behaviours of lots of small things.� It
was thought to be the result simply of a microsoft bug, but this has been
reasonably disproved. Looking at hosts sending the requests� and 1/3 identified
as M$ (at most)� or misconfiguration, or causal synch of some other effect
eg DHCP lease renew.
Kato: more servers in Tokyo.� Interesting TCP data.� TKEY exchange is
statistically significant. Looks like all Microsoft requests.
Bill: can make old 1918 server logs available.
Kenjiro Cho presented some slides, which are posted at http://mawi.wide.ad.jp/mawi/dnsprobe/results
Good data on the resolvers server selection algorithms as a driver on
server placement. The question is how to get that information back to
developers.� Paul Vixie noted that the surest way to get developers to
correct their code is to submit patches to them.�
Louis Touton noted that the method of analysis of root-server placement
described in Kenjiro Cho�s presentation is based on assumptions about
resolver strategies.�Prediction of resolver strategies, and how developers
may change them in the future, is speculative.� He suggested announcing
what the assumptions were when placement occurred, so that developers
could factor the assumption into their resolvers.�
Paul Vixie, while agreeing that the resolver strategies are important,
pointed out is the analysis of placement being discussed involves less
than 1000 servers (roots/cctlds).� The impact on resolver performance
is more affected by other DNS topology considerations, such as where Yahoo
places its nameservers.� We are very much in the minority in terms of
the number of DNS transactions handled.
Louis Touton asked whether the RSSAC understood why the different resolver
strategies were selected.� In response, Paul Vixie indicated that the
BIND 4/8 strategy was developed based on experience of sys-admins. BIND
9 was initially based on a more theoretical approach. He believed that
other resolvers also lacked the benefit of sys-admin experience. He suggested
that the issue of resolver strategies should be referred back into DNSext
WG, since it is not an RSSAC issue.
Placement:
Anycast can mitigate the hole left by the temporary failure of any single
machine or site. Anycast instances should be deployed at the Internet core
for best benefit to the greatest number, not on congested links.
Akira Kato handed out the beginnings of a memorandum on providing for
IPv6 responses by the root servers and asked where that memo should be
discussed.� It was decided that it should be discussed on the root-ops
list and then, when matured, fed back to RSSAC.
Louis Touton noted that the IPv6 approach proposed does have the potential
for truncation, and needs justification for making the changes to ensure
no enduser visability.� Paul Vixie, although noting that he likes to avoid
�bit-twiddling� in RSSAC, suggested one possible approach.
Do we need to send queries back their response? He mentioned that a
possible approach might be to omit the query section in root-server DNS
responses, then adding the AAAA records for IPv6 support. Louis Touton:
�environmental impact statement� would be nice.
Akira Kato quoted measurements showing that EDNS0 was not yet widely
used in terms of overall load. The 512-byte limitation must be considered
until EDNS0 is more broadly deployed.
RSSAC membership & better communication
(Jun Murai):
Jun Murai mentioned that he had received requests for observer status.�
The RSSAC had open/closed sessions in the past.�
He posed the questions for discussion:
Should the RSSAC have more open sessions to increase transparency? Better
documentation/publication?� Louis Touton stated that one simple step to
increase transparency would be to renew efforts to publish minutes.� After
some discussion, it was decided that Bill Manning will summarize past
meetings and send them out subject to 14-day last call.� He will target
sending out one set per week.� Louis Touton will work with Bill, particularly
to fill out the minutes in narrative-paragraph form.� The 14-day last
call will simplify getting approval of the minutes from the RSSAC, so
they can be posted as official minutes.
A discussion ensued about possible ways to increase community access
to, and the transparency of, the RSSAC�s activities.� One positive measure
would be to establish an official �open way in�, so that comments can
be received. Louis Touton agreed to set up a formal mechanism so that
submissions to the RSSAC are collected and submitted to the committee.
Another mechanism discussed was a moderated discussion list for RSSAC
issues.� In discussion, the difficulties in moderating a list, including
the possibility of controversy over the moderation, were discussed.� It
was decided to implement the formal submission mechanism now, and review
the situation at the next meeting (or earlier on the list, if appropriate)
to decide whether also to implement a RSSAC discussion list.
Jun Murai asked whether RSSAC membership should be expanded or reevaluated.�
He also suggested that public forums should be held (noting the success
of the ccTLD presentation in Bucharest discussed at the beginning of the
meeting).� There was some support for this, along the model of the ASO
forums at ICANN meetings.� Most members felt, however, that IETF meetings
should continue to be the main venue for RSSAC meetings, due to convenience
factors.� Several members noted that having renewed IAB/IESG involvement
would be helpful, and it was agreed that a renewed invitation to IAB/IESG
to designate liaison members should be made.�
Jun Murai indicated that the next RSSAC meeting will be held in connection
with the Atlanta IETF meeting, on the Sunday afternoon.
