home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / dns / dns-minutes-93jul.txt < prev    next >
Text File  |  1993-08-27  |  10KB  |  224 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5.  
  6. Reported by Rob Austein/Epilogue Technology
  7.  
  8. Minutes of the Domain Name System Working Group (DNS)
  9.  
  10. Thanks to Bill Manning for providing the notes on which these minutes
  11. are based.
  12.  
  13. The first part of the meeting consisted of status reports from the chair
  14. of the working group and the leaders of several subgroups that have
  15. undertaken specific tasks assigned at previous meetings.
  16.  
  17. The first report was from James Gavin, leader of the subgroup working on
  18. DNS security (please see the end of these minutes for subgroup mailing
  19. list information).  Per recent discussions on the DNS Working Group
  20. mailing list, the security subgroup believes that an IP-level security
  21. mechanism does not provide the service security needed by the DNS, and
  22. that the right model for the DNS is a digital signature providing
  23. end-to-end authentication of RR data.  The exact digital signature
  24. mechanism to be used is still under discussion.  The subgroup expects to
  25. begin serious work in the near future (that is, before the 28th IETF in
  26. Houston).
  27.  
  28. The working group explicitly absolved James's subgroup from
  29. responsibility for the so-called ``just as good as IP security'' issues,
  30. some of which have already been addressed by code contributed to BIND
  31. version 9.1 by USC-ISI.
  32.  
  33. The DNS MIB has been split into two separate MIBs (one for resolvers,
  34. one for name servers), per advice from the Network Management
  35. Directorate (NMAREA). The latest revisions of the MIB documents
  36. (draft-ietf-dns-resolver-mib-01.txt and
  37. draft-ietf-dns-server-mib-01.txt) have been submitted to the IESG for
  38. approval as Proposed Standards.  Calls for objections were issued both
  39. to the DNS Working Group mailing list and verbally at the working group
  40. meeting; the authors of the MIB documents feel that they have
  41. successfully defended the current documents against the one objection
  42. that was raised (to the authors' last-minute decision to remove the
  43. variable dnsServCounterNonAuthNoNames from the server MIB), and that the
  44. documents are (finally!)  ready for promotion to Proposed Standard
  45. status.  We expect a decision from the IESG in the near future,
  46. certainly before the 28th IETF.
  47.  
  48. Liaison work with the X.400 Operations Working Group (X400OPS) has been
  49. proceeding in fits and starts, but we believe that we are making
  50. progress.  As of the X400OPS meeting on the morning of 14 July, we
  51. believe we have an understanding with X400OPS on how their DNS work
  52. should proceed, and we expect to receive a copy of the next draft of the
  53. X400OPS ``mapping table'' paper from Claudio Allocchio, our liaison
  54. within X400OPS, as soon as he has a chance to write it.
  55.  
  56.                                    1
  57.  
  58.  
  59.  
  60.  
  61.  
  62. On 1 July, the RFC Editor asked the DNS Working Group to review a short
  63. document entitled ``Service Advertisement Using the DNS.'' This document
  64. had been submitted directly to the RFC Editor without starting life as
  65. an Internet-Draft.  The DNS Working Group chair reviewed the document,
  66. solicited other reviewers from the working group and sent comments to
  67. the RFC Editor.
  68.  
  69. The report for the Load Balancing subgroup was given by Thomas Brisco.
  70. Based on commentary from the DNS Working Group Chair and the Service
  71. Applications Area Director, the load balancing subgroup believes that
  72. their problem would be best solved by implementation hacks, without
  73. attempting to extend the DNS protocol by adding new magic RR types.
  74. Accordingly, the subgroup will now write a document describing the kinds
  75. of implementation hacks that best address their problem, put said
  76. document up for review and publication as an Informational RFC, and
  77. terminate the subgroup after a suitable review period.  The document
  78. will include text warning about known implementation problems (e.g.,
  79. zero TTLs) and required sanity checking.
  80.  
  81. Next, the working group heard a short presentation by Marshall Rose,
  82. outlining some technical details of how Marshall's ``experiment in
  83. remote printing'' uses DNS MX RRs with wildcard owner names to map
  84. international telephone numbers to SMTP servers.  In brief, an
  85. international phone number like +1-415-123-4567 would be mapped to the
  86. DNS name 7.6.5.4.3.2.1.5.1.4.1.TPC.INT, thus allowing all of the San
  87. Francisco area to be covered by a wildcard name such as
  88. *.5.1.4.1.TPC.INT. We concluded that Marshall's proposal was technically
  89. feasible, but warned him that his scheme could be construed as
  90. duplication of the global authority tree, and that he might encounter
  91. administrative or political problems similar to the ones encountered by
  92. X400OPS. See RFC 1486, ``An Experiment in Remote Printing,'' for more
  93. details on this topic.
  94.  
  95. A brief discussion followed on adding timestamps to the DNS protocols.
  96. Several proposals currently under discussion (the P. Internet Protocol
  97. Working Group (PIP) DNS work and Anant Kumar's proposed incremental zone
  98. transfer protocol) involve use of a timestamp mechanism to detect
  99. out-of-date RRs.  One way of retrofitting a timestamp mechanism into the
  100. DNS protocols would be to define a new DNS class; all the RR types in
  101. this class would have a timestamp as the first part of their RDATA
  102. portions.  We would also need to allocate new RR type codes for
  103. timestamped versions of all the ``class-invariant'' RR types.  This is
  104. ugly, but would retain backwards compatibility with existing DNS code
  105. that thinks it knows how to parse any RR. Several members of the working
  106. group suggested using a new DNS opcode instead of a new DNS class; this
  107. avoids all the delegation problems associated with a new class, but
  108. doesn't preserve strict backwards compatibility with the existing
  109. protocol.  This is still a research topic.
  110.  
  111. During the timestamp discussion, Masataka Ohta pointed out that the
  112. timestamp-based incremental zone transfer protocol as circulated, does
  113. not provide any way to delete RRs, only to add them.  Fixing this
  114. shouldn't be hard, it just requires some kind of deletion pseudo-type as
  115. in Paul Mockapetris's original proposal (the DNS2 BOF held at the 25th
  116.  
  117.                                    2
  118.  
  119.  
  120.  
  121.  
  122.  
  123. IETF).
  124.  
  125. Next, Sue Thomson presented the most recent DNS design work done by the
  126. PIP Working Group.  The details of this work are described in the
  127. current Internet-Draft ``draft-ietf-pip-dns-01.txt.''  Briefly, the
  128. document proposes to allocate a new DNS class for PIP; this solves
  129. several of the problems discussed at the Columbus (26th IETF) DNS
  130. Working Group meeting, but introduces all the known difficulties
  131. associated with use of multiple DNS classes.  The document also suggests
  132. using a timestamp mechanism.  This is still a snapshot of a work in
  133. progress.
  134.  
  135. Last, the working group agreed to take on responsibility for the
  136. Internet-Draft, ``Common DNS Errors and Suggested Fixes'' submitted to
  137. the working group by Jon Postel.  There was not enough time to discuss
  138. the document itself.  Please read the Internet-Draft and send comments
  139. to Anant Kumar, anant@isi.edu, or to the DNS Working Group mailing list.
  140. Anant will coordinate changes.
  141.  
  142.  
  143. Subgroup Mailing Lists
  144.  
  145. DNS Security
  146.  
  147.  
  148.    o General Discussion:  dns-security@tis.com
  149.    o To Subscribe:  dns-security-request@tis.com
  150.  
  151.  
  152. Load Balancing
  153.  
  154.  
  155.    o General Discussion:  dns-wg-lb@ns1.rutgers.edu
  156.    o To Subscribe:  dns-wg-lb-request@ns1.rutgers.edu
  157.  
  158.  
  159. Attendees
  160.  
  161. Robert Austein           sra@epilogue.com
  162. Anders Baardsgaad        anders@cc.uit.no
  163. Tony Bates               tony@ripe.net
  164. David Borman             dab@cray.com
  165. Erik-Jan Bos             erik-jan.bos@surfnet.nl
  166. Thomas Brisco            brisco@pilot.njin.net
  167. Henry Clark              henryc@oar.net
  168. Geert Jan de Groot       geertj@ica.philips.nl
  169. Francis Dupont           francis.dupont@inria.fr
  170. Osten Franberg           euaokf@eua.ericsson.se
  171. John Hopkins             J_Hopkins@icrf.icnet.uk
  172. Marc Horowitz            marc@mit.edu
  173. Steven Horowitz          witz@chipcom.com
  174. Phil Irey                pirey@relay.nswc.navy.mil
  175.  
  176.                                    3
  177.  
  178.  
  179.  
  180.  
  181.  
  182. Thomas Johannsen         thomas@ebzaw1.et.tu-dresden.de
  183. Dale Johnson             dsj@merit.edu
  184. Marijke Kaat             marijke@sara.nl
  185. Frank Kastenholz         kasten@ftp.com
  186. Peter Koch               pk@techfak.uni-bielefeld.de
  187. Mark Kosters             markk@internic.net
  188. Pekka Kytolaakso         pekka.kytolaakso@csc.fi
  189. Eliot Lear               lear@sgi.com
  190. Jose Legatheaux Martins  jalm@fct.unl.pt
  191. Carl Malamud             carl@malamud.com
  192. Bill Manning             bmanning@rice.edu
  193. Greg Minshall            minshall@wc.novell.com
  194. Keith Mitchell           keith@pipex.net
  195. Clifford Neuman          bcn@isi.edu
  196. Peder Chr.  Noergaard    pcn@tbit.dk
  197. Masataka Ohta            mohta@cc.titech.ac.jp
  198. Petri Ojala              ojala@eunet.fi
  199. Michael Patton           map@bbn.com
  200. Charles Perkins          perk@watson.ibm.com
  201. Lars Poulsen             lars@cmc.com
  202. Juergen Rauschenbach     jrau@dfn.de
  203. Robert Reschly           reschly@brl.mil
  204. John Romkey              romkey@elf.com
  205. Luc Rooijakkers          lwj@cs.kun.nl
  206. Marshall Rose            mrose@dbc.mtview.ca.us
  207. Miguel Sanz              miguel.sanz@rediris.es
  208. Jon Saperia              saperia@tay.dec.com
  209. Tim Seaver               tas@concert.net
  210. John Stewart             jstewart@cnri.reston.va.us
  211. Erdal Taner              erdal@vm.cc.metu.edu.tr
  212. Marten Terpstra          marten@ripe.net
  213. Susan Thomson            set@bellcore.com
  214. Gregory Vaudreuil        gvaudre@cnri.reston.va.us
  215. Ruediger Volk            rv@informatik.uni-dortmund.de
  216. Jost Weinmiller          jost@prz.tu-berlin.d400.de
  217. Sam Wilson               sam.wilson@ed.ac.uk
  218. Wilfried Woeber          Wilfried.Woeber@CC.UniVie.ac.at
  219. Romeo Zwart              romeo@sara.nl
  220.  
  221.  
  222.  
  223.                                    4
  224.