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.