home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / dnsind / dnsind-minutes-95feb.txt < prev    next >
Text File  |  1995-05-26  |  4KB  |  111 lines
  1.  
  2. INTERIM_MEETING_REPORT_
  3.  
  4. Reported by Randy Bush/RGnet
  5.  
  6. Minutes of the DNS IXFR, Notification, and Dynamic Update
  7. Working Group (DNSIND)
  8.  
  9. The DNSIND Working Group held an interim meeting at Stanford on
  10. 8 February 1995.  The meeting was chaired by Randy Bush.
  11.  
  12. The goal of the meeting was to review the draft of 31 January.  The
  13. group hopes to reach closure and have a solid draft for review at the
  14. Danvers IETF -- implementations and standards track by the Stockholm
  15. meeting.  The group will need two sessions in Danvers.
  16.  
  17.  
  18.  
  19. Draft Issues and Discussion
  20.  
  21. It appears that the draft was not posted, so it will be resent.  It can
  22. still be obtained from:
  23.  
  24.      ftp://thumper.bellcore.com/pub/set/dynupd.txt
  25.  
  26. Susan Thomson started the presentation of issues with the current draft.
  27. There was immediate discussion of the overlapping semantics of
  28. ADD/ADDNEW/ADDEXIST. Are the semantics necessary?  Maybe not, but they
  29. may be very convenient.  Uses can be seen.  This will be left as an open
  30. discussion item and the overlapping semantics will remain for now.
  31.  
  32. One protocol transaction is atomic and may only affect one zone.
  33. Failure of one sub-operation causes failure of the entire transaction.
  34.  
  35. Are there multiple primaries?  What has to be said about that?  There
  36. should be a note stating that a single primary is assumed, and multiple
  37. primaries are an implementor's issue.
  38.  
  39. Should the zone serial be incremented synchronously or must it be done
  40. on each update?  If asynchronously, then when is it updated?  Decision
  41. was to update the serial either when the soa must be returned for a
  42. query or when some time has passed since any change.  There needs to be
  43. an upper bound on that time, maybe 5-10 minutes, surely less than the
  44. soa refresh time, and it should also be configurable.
  45.  
  46. Servers may provide recursion on updates.  Not all servers that need to
  47. be contacted for referrals will have dynamic updates implemented and so
  48. full-service resolvers will need to implement queries to get referrals
  49. for dynamic update requests anyway.  In the spirit of providing one
  50. mechanism to get referrals, rough consensus was to rely on queries only.
  51.  
  52. Recursion is seen as separate, as it will allow a lazy stateless client.
  53. Discussion went on for a long while, general opinion wavered toward
  54. removing it.  Clearly, clients must be prepared for an environment where
  55. local servers do not support dynamic update and or recursion on updates.
  56.  
  57. Should updates be asynchronous and possibly unreliable?  Nobody could
  58. see why.  Rumor is that a respected working group member has cause to
  59. allow this.  Would s/he please explain to the list?  In the meantime the
  60. draft will continue to assume synchronous.
  61.  
  62. Only a primary server should cache an update.  Intermediate servers can
  63. not do so as they might then have inconsistent data.
  64.  
  65. Serial resource records seem unnecessary:
  66.  
  67.  
  68.    o To prevent replay attacks, use dnssec sig records, which need
  69.      expanded definition of the time of signature.
  70.  
  71.    o User driven zone consistency checks can be achieved by delete and
  72.      update of any arbitrary rr.
  73.  
  74.    o Fear of benign udp replay should be answered by use of tcp.
  75.  
  76.  
  77. There was considerable discussion of the appropriate use of sig records
  78. to prevent replay of an update transaction.  Consensus was achieved.
  79. When dynamic updates are used with sig records, udp is sufficient to
  80. prevent replay failure.  Therefore, serial records are not needed, and
  81. should be dropped.  For dynamic update, either use a sig record or use
  82. tcp.
  83.  
  84. Request record format:
  85.  
  86.  
  87.    o Note that the AA being unset may mean that the request was not
  88.      satisfied because the server which received it was not
  89.      authoritative and either recursion was not requested or it was not
  90.      available.
  91.  
  92.    o rcode=4 is likely a server which does not know about update.
  93.  
  94.  
  95. There was strong presentation of the case for not making an update
  96. visible until that update has been successfully propagated to all
  97. authoritative servers.  This seemed beyond our immediate charter, as
  98. Notify is being used to cause faster convergence.  So, a primary may,
  99. but should not be required to, make an update visible before that update
  100. has been successfully propagated to all authoritative servers.
  101.  
  102.  
  103. Other Items
  104.  
  105. Our deepest appreciation to RL ``Bob'' Morgan for hosting the meeting in
  106. such excellent facility and for providing audio MBONE services.
  107.  
  108. An RFC will be produced based on the results of this meeting and the
  109. comments (received by 19 February) on these minutes.
  110.  
  111.