home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / dnsind / dnsind-minutes-96mar.txt < prev    next >
Text File  |  1996-03-14  |  8KB  |  153 lines
  1. Editor╒s note: These minutes have not been edited
  2.  
  3. DNS IXFR, Notify, and Dynamic Update WG
  4. IETF 35, Thu, Mar 7, 1996
  5.  
  6. Administrivia
  7.  
  8. Pontification by the chair: WG has exceeded time limit in charter, turned left and right in 
  9. search of truth. Time is running out. IXFR draft has already gone to IESG, some folks now want 
  10. to change it to be aligned with dynDNS and notify drafts. Proposal: ask IESG to delay 
  11. reviewing IXFR draft, WG will progress dynDNS and notify drafts to where they can be 
  12. submitted to the IESG, bringing all three drafts into alignment (or not), by 4/15/96. 
  13.  
  14. AD then held WG's feet to the fire, stating that the WG needs to finish current, chartered 
  15. drafts before entertaining new topics. 
  16.  
  17. Drafts for discussion during WG meeting: 
  18.  
  19. M Ohta
  20. draft-ietf-dnsind-ixfr-06.txt (Standards track) P Vixie
  21. draft-ietf-dnsind-dynDNS-07.txt (Standards track) draft-ietf-dnsind-notify-06.txt (Standards 
  22. track) R Elz
  23. draft-ietf-dnsind-serial-01.txt (Informational track) draft-ietf-dnsind-clarify-00.txt 
  24. (Standards track) draft-ietf-dnsind-2ndry-00.txt (Best Common Practice track) M Patton
  25. draft-ietf-dnsind-expires-00.txt (Standards track) 
  26.  
  27.  
  28. + draft-ietf-dnsind-ixfr-06.txt
  29.  
  30. Draft was not discussed, since it has already been submitted to IESG. 
  31.  
  32.  
  33. + draft-ietf-dnsind-dynDNS-07.txt
  34.  
  35. New semantics require that opcode be examined first in order to correctly decode remainder of 
  36. the packet; older RFCs do net specifically state this; goal is to find a new wire format that 
  37. supports the new semantics yet retains backwards compatibility; e.g. Network General Sniffer 
  38. does not look at opcode before decoding contents of DNS packets. 
  39.  
  40. Changes to draft for next version (-08): - add rcode for zone error (from discussion on mailing 
  41. list) - forwarding loops: possibilities exist for loops in forwarding updates; 
  42. language will be added to draft to recognize this and warn DNS administrators. Some 
  43. discussion about whether the DNS admin can do this easily, to be continued on the list. A 
  44. suggestion was made to use an additional RR field to prevent looping. New ideas are to be 
  45. discussed on the list, before 4/1/96.
  46.  
  47. Interaction with DHCP requires the ability to expire individual RRs, with expiration time 
  48. tied to DHCP lease time, therefore, need to pass expiration time in dynanimic update. WG 
  49. chair noted that the request had been heard, and would be discussed on the list, WG will 
  50. attempt to resolve it by 4/15/96 deadline if possible. A DHCP imlementor stated that he can 
  51. live without this ability, but really needs to see completion of dynamic update specification.
  52.  
  53. It was noted that the class field is overloaded in the current draft, i.e. the proposed format is 
  54. not purely 103x. 
  55.  
  56. It was noted that there has been a change in granularity; what apears to the user as a single 
  57. transaction has become two transactions, raising the possibility of an intervening transaction 
  58. and potential conflicts. Seemed to be consensus that this is not the case. 
  59.  
  60. There were questions about updates to glue records; there was general agreement that issues 
  61. exist, in particular there are possible problems with secure DNS; need to solve these by 
  62. 4/15/96. 
  63.  
  64.  
  65. + draft-ietf-dnsind-notify-06.txt
  66.  
  67. Changes have been suggested on namedroppers, Vixie wants to make the changes and post the 
  68. next version.
  69.  
  70.  
  71. + draft-ietf-dnsind-serial-01.txt
  72.  
  73. Minor editorial changes have been suggested. There were no comments from the WG, consensus 
  74. from the WG is to go forward with the draft. 
  75.  
  76.  
  77. + draft-ietf-dnsind-clarify-00.txt
  78.  
  79. Discussion of problems related to getting an answer from a different address than was used in 
  80. the query. It was noted that the server cannot identify when a query was sent to a 
  81. {multi,any}cast address, therefore when a client sends a query to a {multi,any}cast address, the 
  82. client should accept reply from any address. Servers should reply from an address that clients 
  83. can use for subsequent, follow-on queries.
  84.  
  85. Difficulties interpreting TTLs on RRsets were discussed. It was stated that all RRs in an RRset 
  86. should have the same TTL; it was noted that this could be effectively achieved by using the 
  87. minimum TTL of the RRs in the RRset. Some details need to be elaborated in the draft. 
  88. Difficulties can arise when RRsets with different TTLs are merged; WG sentiment is to not 
  89. merge RRsets from different sources and to specify rules for choosing between old and new RRset 
  90. data.
  91.  
  92. Vixie has list of clarifiactions that need to be incorporated into the draft; this work will 
  93. continue on the mailing list. 
  94.  
  95.  
  96. + draft-ietf-dnsind-2ndry-00.txt
  97.  
  98. No substantial discussion in the WG, draft was punted to Bush for progress as a BCP.
  99.  
  100.  
  101. + draft-ietf-dnsind-expires-00.txt
  102.  
  103. Suggestion to use a bitmap to allow simultaneous expiration of multiple RRs. Counter-suggestion 
  104. was made to change the type field allow qtypes, including "any" in an expire record; general 
  105. agreement that counter- suggestion is preferable.
  106.  
  107. It was then noted that expiration of entire RRset as a unit is not sufficient, need the ability to 
  108. expire individual RRs, it's preferable to have the expiration data in each RR. This can be done 
  109. with creation of a new, extended query (new qtype), then need a new zone-xfer protocol to 
  110. handle this; DHCP implementor stated he can deal with difficulties caused by not providing 
  111. RR-specific expiration, again he just wants dynDNS spec to be done. There was agreement to not 
  112. hold up the current draft, and deal with this issue later.
  113.  
  114. The question was raised, does SOA serial number change when a record goes away? It was 
  115. decided that this is a contentious issue, therefore the draft is put on hold until the three 
  116. required drafts are completed; then to be discussed on the list.
  117.  
  118. The chair stated his intention to aggressively discourage discussion on list of the Elz and Patton 
  119. drafts until required drafts are submitted to IESG. 
  120.  
  121.  
  122. + discussion of AXFR wire format, BIND's perversion of it, the problems 
  123. caused thereby, to get some ideas about how to proceed. 
  124.  
  125. Older versions of BIND don't handle multiple RRs in AXFR properly, may dump core. Want to 
  126. include as many as 16K RRs in a single message in the interest of efficiency (compression). DiG 
  127. makes assumption that if answer count is not 0, it must be 1; similar problems exist throughout 
  128. the BIND code, Vixie has fixed many of these and continues to do so. Vixie is pleased with 
  129. improved performance of new AXFR ("LONGAXFR"), but is worried about effects on older 
  130. server implementations. "Insane" proposal to implement new qAXFR allowing multiple RRs. 
  131. Consensus was to provide a 4.9.3p? that will not dump core, wait a few months, then release 
  132. 4.9.4 that causes older servers to break. It was noted that this may not be such a wide-spread 
  133. issue, since it will only happen when secondarys are not updated before primaries. Next version 
  134. of BIND will support LONGAXFR by default, with option to use older" AXFR.
  135.  
  136. Discussion of CERT Advisory warning of gethostbyaddr being fed an arbitrary string with 
  137. newline. There was consensus that appropriate protection needs to be in gethostby{name,addr}. 
  138. Existing sendmails need to be relinked (or upgraded to current version)
  139.  
  140. + Frank Kastneholz (AD) asked for indications of future directions for 
  141. DNS work. Answers from the WG:
  142. o Marker RR needs work.
  143. o Indirect A records, to renumber a large set of hosts, changing only a 
  144. few records.
  145. o DNS for autonomous systems.
  146. o DNS equivalent of host requirements spec o Extended queries
  147. o Breaking the packet size barrier.
  148. o Investigate how DNS will scale for the next 10 years o Multiparty update of domains
  149. o Something like what drums is doing for mail o Clarify usage of CNAME records
  150.  
  151.  
  152. Thanks to Ken Lindahl for the minutes!
  153.