[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: dnsop@cafax.se
From: Ray Plzak <plzak@ops2.nic.mil>
Date: Mon, 24 Apr 2000 11:19:22 -0400 (EDT)
Sender: owner-dnsop@cafax.se
Subject: Minutes of DNSOP WG

Here are the minutes from the WG meeting in Adelaide.  Any comments?

Ray

<<<<<<<<<<<<<<<<<<<<<<<<<<< CUT HERE >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
DNSOPS Working Group

Tuesday, March 28, 2000 13:00

Prepared by Ray Plzak

1.  Agenda Bashing
Ray Plzak

A discussion of the root ops draft was added by the chair.

2.  Experience with Classless In-Addr Delegation on Bit Boundry
Ray Plzak

Peter Koch was not in attendance.  He had sent email to Ray Plzak stating
that he was working on draft and would be at the Pittsburgh meeting to
discuss the draft.

3.  Root Ops Draft
Ray Plzak

The draft went to WG last call in Dec 99 and to IESG last call in Feb 00.
The WG was queried to see if there were any technical objections to the
draft as it is written.  There were none.  A HUM indicated a consensus on
this.  Ray Plzak will send out an announcement to the list to see if there
are any further technical objections to the draft.  If there are none,
Bert Wijnen (the AD), will take the draft to the IESG so that the draft
can progress to a RFC.

4.  Shared Unicast DNS Servers
Ted Hardie

* Ted Hardie provided an update for his draft concerning distributing root
or authoritative name servers via a unicast address.

* Comments that Ted had received via email

-- * Bill Manning.  This document should also deal with authoritaive name
servers not just the root servers.  The document abstract will be changed:
"and authoritative name servers" was added to the abstract.

-- Bill Woodcock.  In the original draft, it says two interfaces:  He said
that it was unclear that logical interfaces were required.  Wordsmithing
will be done so that they can be logical interfaces, instead of two
different physical interfaces.  Loosely or tightly synchronized.  For this
draft, there is a requirement that both servers who share a unicast
address be tightly coordinated.  Should the addresses be announced from a
single AS.  This draft presumes that it is a single administrative entity
for all instances of each root.  Other changes:  The root servers are a
common target of attack.  Added to Security Considerations "authoritative
name servers may also be targets"

* Comments From the Floor

-- Servers in an authoritative context may be different that the root
context, mostly because of the difference in the AXFR.  The draft needs to
have new language about this concept.

-- For server requirements, refer to the server requirements document.

* Test of concept.

-- Hardie is testing it with shadows internal to his organization.  He
wants to use a test TLD (non operational) for further tests.

-- Randy Bush says that this an old hack and is familar to many ISPs.  It
has been operationally tested.

--  Hardie wants to put one up for people to test out.

5.  Anycast DNS Servers Test
Masataka Ohta

* Ohtasan presented an update to his draft.  Because of a schedule
conflict he was unable to report to the WG in Washington.  The draft has
expired. He will update it and publish a new one.  He reported that at the
Anycast BOF in Washington a conclusion was reached that anycast is useful
for DNS but is costly.

* Discussion then ensued about a means to test Ohta-san's proposal. Randy
Bush [Verio] will provide the unicast IP address, AS number, and domain.
The scope of the test was discussed.  Ohta-san proposed that the test
duration be for one [1] year.  The test scope will be limited to
demonstrate that ANYCAST will provide the desired result.  There were
several members of the WG who volunteered to participate in the test.  It
is important to have participants from various global points of the
Internet.  The participants will exchange information with Ohtasan.  The
test will start within a few months.  Ohtasan will write an ID for the
test plan.  Randy Bush will set up a mail list for the test.

* There was a general discussion about concerns regarding system
administration and debugging. It is not clear how outside parties will be
able to determine the source of a problem, how to isolate the problem, or
how to contact the appropriate administrative authority.  If a server
fails in an ANYCAST situation, how are queries blocked to the failed
server?  More queries should not be directed to the failed server.
Techniques such as the OSPF keepalive should kill the route to the server
from the router.

6.  DNSSEC Update
Olafur Gundmusson

* Olafur presented a report on the status of the drafts being worked on by
Ed Lewis

-- The key handling draft is on hold pending the final version of BIND 9.

-- There have been some changes to the core concept of the DNS zone
security draft.  Olafur encouraged all to read it over again since all of
the changes are significant.

* Olafur presented an update of the activities of the DNSEXT WG.

-- The TSIG draft has gone through WG last call.  There have been four
versions done since then to get it through IESG last call.  Hopefully the
drafts will be an RFC within a few months.  The implementation software is
already out in a BETA version.


Home | Date list | Subject list