Notes: DNS Root Server System Advisory Committee
Date:
17 March, 1999
RSSAC, 17 March
1999, Minneapolis, USA
Present:
Daniel Karrenberg RIPE NCC K Mirjam Kuehne RIPE NCC Paul Wilson APNIC Mark Bohannon US DoC Akira Kato WIDE M Ray Plzak DDN NIC G Lars-Johan Liman KTH I Mark Kosters NSI A, J Suzanne Woolf IANA David Conrad ISC F Piet Barber DDN NIC G Doug Engebretson DISA G Maurizio Binello LINX K James Fielding ARL H Shane Kerr ARIN Kim Hubbard ARIN Gerry Sneeringer University of Maryland D Josh Elliott IANA Mike Roberts ICANN Esther Dyson* ICANN Paul Vixie ISC F Randy Bush* IESG Evi Nemeth CAIDA Bill Manning ISI B , L *Attended part of the meeting
Agenda:
1. Review previous minutes
2. Committee scope & membership
3. Work items-- discuss and assign
The first RSSAC meeting was for organizing
what the tasks and issues are and who is invited by ICANN to participate
in resolving them. This one will be to start getting down to business
on breaking up the tasks.
Membership:
There is very limited guidance in the ICANN bylaws on the membership
of the committee. The Board must be advised who the members are, but
this is essentially at the chair's discretion. List for meetings so
far: the current root server operators, the IANA staff, liaisons from
the leadership of the IETF and ICANN Supporting Organizations, and recognized
experts in various relevant technical areas.
Consensus points from the discussion:
Committee membership is the root server operators and the ICANN/IANA
staff, with additional input and support from invited liaisons to other
groups and experts in relevant technical areas like routing, topology,
and performance measurement.
a. Form of membership
Formal membership is largely irrelevant because the committee is expected
to function in the IETF style of consensus rather than voting. Work Items
discussed:
b. Operational guidelines and requirements issues
RFC 2010 is in need of some updating. There is also a new root server
operational requirements draft RFC. Concerns with 2010 include security
and performance specifications. There is however some need recognized
to avoid over-specifying so as to encourage diversity – we are
*not* interested in specifying hardware, software, etc.
There is also discussion of how the work on specifying operational procedures
does or doesn't overlap the DNSOps effort in IETF. The usual model and
the one preferred here is that the IETF sets general principles and people
will adapt and extend whatever IETF the does as necessary to solve their
particular set of problems.
ICANN needs a statement from the operators that there are documented operational
guidelines that the root server operators are committed to following.
The consensus answer is that the Root Servers will treat RFC 2010 as the
baseline operational standard for current guidance and will adjust to
changes as specified by RSSAC. People expect that the DNSOps working group
if any will significantly overlap RSSAC participation; we will work with
the IETF on developments and add our own features.
A tentative deadline for an initial draft of this compliance statement
is set for May, to have a published version available in June.
Leads: Ray Plzak, Daniel Karrenberg
2. Discussion on RFC 2010 and
RFC 1591: operational authority
Most operators agree to follow what IANA directs. Some will only follow
Amendment 11/DoC, but all agree that a joint direction or statement
from DoC and ICANN/IANA is sufficient authority for them at this time.
DoC position per Mark Bohannon on operational authority over the root
zone: The transition described in Amendment 11 is underway. DoC &
IANA are working closely together, and it's unlikely that there will be
disagreement because everyone knows what is operationally unacceptable.
Any discrepancies are an operational issue and will be dealt with
as such. Operators will check with multiple sources to verify new instructions.
(Note that with respect to certain changes the current state is frozen.)
At present historically off-the-shelf, cheap, generic machines work adequately.
New DNS features such as DNSSEC or records to supportIPv6 may change that.
There is some discussion of the potential to separate gTLDs from the
old roots.
All agree this is a good idea. There are several possibilities for how
to do this. It has to be handled with sensitivity because any significant
change e.g. renumbering servers is going to need serious thought and
buy-in by many people.
A draft document should codify existing practice. It should include the
infrastructure zones carried on the root server machines (.in-addr.arpa,
root-servers.net) at least for now.
Leads: Doug Engebretsen, Bill Manning, Mark Kosters
3. Discussion on deployment issue
The location, number, distribution and deployment of new servers (or redeployment
of existing servers) are a separate issue from how to operate once deployed.
Number is bounded but we haven't yet made most effective use of all
available slots, note that both J and L were initially deployed with
the intention of finding a suitable place and redeploying them. Location
and distribution are open items and will probably require participation
by outside experts on topology and traffic. CAIDA has some thought and
resources to start studying this.
Leads: Bill Manning, Evi Nemeth, Jun Murai
4. Discussion on drafting possible contract terms
There needs to be more formal understanding of the obligations towards
and from the operators of root servers. Network Solutions has been attempting
this with regard to the operation for the gTLDs. DoC and ICANN offer the
help of their legal staffs on formulating these draft guidelines.
The draft will need to consider possible expansion of the number of gTLDs.
It also needs to cover the case that off the shelf hardware may not always
do the job. Paul Vixie offered to draft some general language.
It is also noted that the implications of the prospective contractual
relationship between root server operators and ICANN include support and
remuneration for expenses incurred and labor spent (Mike Roberts).
Leads: Jun Murai, David Conrad, Mark Kosters, Daniel Karrenberg
5. Y2K issues.
USG did formal evaluation on BIND 8.1.2, which passed. (Report not available
yet.) Various informal tests have been performed (F & L at least)
in which system clocks have tested the 0001 1/1/00 rollover with no problems
found, but the USG is very eager to have a formal statement.
RIPE-NCC staff, David Conrad, Akira Kato, Mark Kosters and Bill Manning
can make efforts to document/define a common statement.
The basic principle to emphasize is that "Diversity builds robustness"
machines and supporting infrastructure are diverse enough that systemic
failure seems unlikely. The statement will need to clearly indicate the
span of control of the root servers, since there are many components and
limited ability to certify others' pieces.
Mark Bohannon: we do have to specify Y2K compliance (which we note is
an OS issue!) DoC is eager also to see the process work as an example
they can use to demonstrate context for later discussion and decisions.
The focus here needs to be on longer term stability and robustness for
the system overall.
Next meeting set for Oslo IETF, with a working session that may or may
not be a formal meeting expected sometime between Minneapolis and Oslo.
"To Be Determined" probably May or early June.
