INTERIM_MEETING_REPORT_

Reported by Randy Bush/RGnet

Minutes of the DNS IXFR, Notification, and Dynamic Update
Working Group (DNSIND)

The DNSIND Working Group held an interim meeting at Stanford on
8 February 1995.  The meeting was chaired by Randy Bush.

The goal of the meeting was to review the draft of 31 January.  The
group hopes to reach closure and have a solid draft for review at the
Danvers IETF -- implementations and standards track by the Stockholm
meeting.  The group will need two sessions in Danvers.



Draft Issues and Discussion

It appears that the draft was not posted, so it will be resent.  It can
still be obtained from:

     ftp://thumper.bellcore.com/pub/set/dynupd.txt

Susan Thomson started the presentation of issues with the current draft.
There was immediate discussion of the overlapping semantics of
ADD/ADDNEW/ADDEXIST. Are the semantics necessary?  Maybe not, but they
may be very convenient.  Uses can be seen.  This will be left as an open
discussion item and the overlapping semantics will remain for now.

One protocol transaction is atomic and may only affect one zone.
Failure of one sub-operation causes failure of the entire transaction.

Are there multiple primaries?  What has to be said about that?  There
should be a note stating that a single primary is assumed, and multiple
primaries are an implementor's issue.

Should the zone serial be incremented synchronously or must it be done
on each update?  If asynchronously, then when is it updated?  Decision
was to update the serial either when the soa must be returned for a
query or when some time has passed since any change.  There needs to be
an upper bound on that time, maybe 5-10 minutes, surely less than the
soa refresh time, and it should also be configurable.

Servers may provide recursion on updates.  Not all servers that need to
be contacted for referrals will have dynamic updates implemented and so
full-service resolvers will need to implement queries to get referrals
for dynamic update requests anyway.  In the spirit of providing one
mechanism to get referrals, rough consensus was to rely on queries only.

Recursion is seen as separate, as it will allow a lazy stateless client.
Discussion went on for a long while, general opinion wavered toward
removing it.  Clearly, clients must be prepared for an environment where
local servers do not support dynamic update and or recursion on updates.

Should updates be asynchronous and possibly unreliable?  Nobody could
see why.  Rumor is that a respected working group member has cause to
allow this.  Would s/he please explain to the list?  In the meantime the
draft will continue to assume synchronous.

Only a primary server should cache an update.  Intermediate servers can
not do so as they might then have inconsistent data.

Serial resource records seem unnecessary:


   o To prevent replay attacks, use dnssec sig records, which need
     expanded definition of the time of signature.

   o User driven zone consistency checks can be achieved by delete and
     update of any arbitrary rr.

   o Fear of benign udp replay should be answered by use of tcp.


There was considerable discussion of the appropriate use of sig records
to prevent replay of an update transaction.  Consensus was achieved.
When dynamic updates are used with sig records, udp is sufficient to
prevent replay failure.  Therefore, serial records are not needed, and
should be dropped.  For dynamic update, either use a sig record or use
tcp.

Request record format:


   o Note that the AA being unset may mean that the request was not
     satisfied because the server which received it was not
     authoritative and either recursion was not requested or it was not
     available.

   o rcode=4 is likely a server which does not know about update.


There was strong presentation of the case for not making an update
visible until that update has been successfully propagated to all
authoritative servers.  This seemed beyond our immediate charter, as
Notify is being used to cause faster convergence.  So, a primary may,
but should not be required to, make an update visible before that update
has been successfully propagated to all authoritative servers.


Other Items

Our deepest appreciation to RL ``Bob'' Morgan for hosting the meeting in
such excellent facility and for providing audio MBONE services.

An RFC will be produced based on the results of this meeting and the
comments (received by 19 February) on these minutes.