home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / dnsind / dnsind-minutes-95apr.txt < prev    next >
Text File  |  1995-05-26  |  7KB  |  192 lines
  1.  
  2. CURRENT_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.  
  10. First Session
  11.  
  12. The meeting began with an introduction of one of the new Internet Area
  13. co-Directors, Frank Kastenholz.
  14.  
  15. Agenda bashing:
  16.  
  17.    o Main items:
  18.       -  Dynamic update
  19.       -  Notify
  20.       -  IXFR
  21.  
  22.    o Schedule adjusted for IPv6 meeting conflicts
  23.  
  24. The group had hoped this would be the last meeting, but it does not look
  25. likely.  The last meeting is now expected to be at the Stockholm IETF.
  26. More DNS issues may be assigned to the group and the charter must be
  27. re-written if so.  DNSSEC is inactive and the draft is out.
  28.  
  29.  
  30. Masataka Ohta -- IXFR
  31.  
  32.    o In AXFR: UDP SOA query-response, followed by TCP SOA AXFR.
  33.  
  34.    o In IXFR: UDP IXFR query, server responds with unrecognized, or UDP
  35.      SOA answer, or UDP zone transfer.  If UDP SOA answer, follow with
  36.      TCP IXFR for update.  Can client initiate with TCP IXFR? Answer:
  37.      no, need a UDP query first.  Should be able to start with TCP, due
  38.      to possible UDP fragmentation (no fragmentation in v6).  Opinion:
  39.      TCP may be too expensive for every query.  RFC 1034 states UDP must
  40.      be tried first.
  41.  
  42.    o IXFR answer formats:
  43.  
  44.       1. Just current SOA.
  45.  
  46.       2. Same as AXFR (current SOA, followed by full zone data, followed
  47.          by current SOA).
  48.  
  49.       3. Current SOA, followed by data to remove, followed by new SOA,
  50.          then data to add.
  51.  
  52.    o Each IXFR requires an SOA change, unlike dynamic update which may
  53.      not update SOA until several queries later.
  54.  
  55.    o Masataka, Sue and Paul should meet to hash out packet formats.
  56.  
  57.    o IXFR should be similar to dynamic update format (do not have two
  58.      different formats for similar things).
  59.  
  60.    o Why do you want UDP for IXFR? Answer:  it might avoid the need for
  61.      TCP in some cases (you need UDP SOA query for AXFR anyways).  Also,
  62.      if UDP is good enough for initial SOA in AXFR, it should be good
  63.      enough for IXFR.
  64.  
  65.    o Language will be modified -- need only packet format settled before
  66.      floating it as Proposed Standard.  Do we need an implementation
  67.      first?  The consensus was to delay going to RFC until
  68.      implementation -- approve at Stockholm if no problems.
  69.  
  70.    o If server determines UDP checksumming turned off, send an SOA so
  71.      that TCP is used
  72.  
  73.  
  74. Masataka Ohta -- Idea For IPv6
  75.  
  76.    o Already have AAAA records for full address.
  77.    o Propose XXXX record that has prefix pointer plus a host number.
  78.    o Prefix pointer has a separate record to get list of prefix numbers.
  79.    o Could this be done through a front-end, rather than the protocol?
  80.    o It also allows one-record IXFR if provider changes.
  81.  
  82.  
  83. Paul Vixie -- DNS Notify (And Others)
  84.  
  85.    o Notify now in draft status.
  86.  
  87.    o BIND 4.9.3 has code -- would not enable it.
  88.  
  89.    o LOC RR -- encode geographic location, use WGS84 reference spheroid
  90.      (same as GPS), BIND 4.9.3 conforms to draft.
  91.  
  92.    o SRV RR: There is a problem with ``ftp.yoyodyne.com''-type hosts
  93.      with asymmetric A/PTR RRs.  SRV RRs -- sort of like MX RRs (FTP on
  94.      one host, WWW on another).  Can also provide primitive load
  95.      balancing.  Somewhat controversial -- should it be in this working
  96.      group?  Remember what happened to WKS RRs.  Can multiple PTRs solve
  97.      the problem?  (Paul says he's still getting hate mail for making
  98.      this work.)  Where should this go?
  99.  
  100.    o Back to Notify -- changes:  Primary Master has the external data
  101.      source, must be listed in SOA MNAME and be one of NS RR. Slave:
  102.      uses AXFR/IXFR to fetch zone data, must be in NS RR. Master:
  103.      AXFR/IXFR server to other slaves.  Note:  Slaves can also be
  104.      Masters!  Lurker (?):  AXFR/IXFR client but is not in NS RR. Server
  105.      must receive and send data on DNS port.  Is there a reason why a
  106.      ``lurker'' should be authoritative?  (Lurkers should be notified by
  107.      default?)
  108.  
  109.  
  110. Bill Simpson:  IPv6 Address-to-Name Mapping
  111.  
  112.    o Host should answer its own queries for a hostname.
  113.  
  114.    o Uses ICMP.
  115.  
  116.    o Couple points raised:  useless for multicast.
  117.  
  118.    o Logging?  Bill:  inverse tree is not reliable either, IPv6 will be
  119.      much more dynamic (hosts and prefixes).
  120.  
  121.    o Both inverse DNS and direct-to-host queries are needed.
  122.  
  123.    o Some preference for UDP due to some implementation issues
  124.      w/protection in UNIX (non-prived processes cannot ICMP).
  125.  
  126.    o Should protocol be same as DNS (similarity vs.  complexity)?
  127.  
  128.    o Inverse DNS tree is not as rotten in Paul's experience as Bill
  129.      thinks.  Some people use inverse DNS for authentication.
  130.  
  131.  
  132. Second Session
  133.  
  134. Susan Thomson -- Dynamic Update
  135.  
  136. The goal is to try and make the next draft the last.
  137.  
  138. Topics and Open Issues:
  139.  
  140.  
  141.    o Add name new, add name exist, add operations
  142.    o No support for recursion, referrals
  143.    o Ordering of update requests
  144.    o Implementing mutual exclusion
  145.    o Name server technology
  146.    o DNSSEC
  147.  
  148.  
  149. Update is atomic transaction consisting of sequence of operations on
  150. multiple names and types in a single zone.  Atomic against just primary,
  151. or everywhere?  Answer:  cannot be everywhere, since secondaries may be
  152. out-of-date -- that is inherent in DNS. Can primary be inconsistent?
  153. Answer:  difference between visibility of data and atomicity of
  154. transactions.  Operations:  delete, add, add name new, add name exist.
  155. Add name new only works if name does not exist - ensures uniqueness Add
  156. name exist -- only works if name does exist.  NXD records?  Server
  157. should automatically fix these?  (The answer seems to be yes.)  Update
  158. is defined to be asynchronous, but server may make it synchronously
  159. anyways.  Updated data may not be visible right away -- there was much
  160. discussion on this.  Those in favor say that it allows for flexibility
  161. on the server side; secondaries are going to cause a problem with
  162. complete visibility anyways.  Those against it say that the client needs
  163. to have data visible; cannot read consistent view of the world.  A
  164. possible solution might be to return a delta time as to when an update
  165. will be visible.  (This seemed to be accepted.)  Zone serial number
  166. updated at discretion of primary.  Client can send request to any name
  167. server authoritative for zone.  (Statically-configured lurkers also
  168. allowed?  Answer:  yes) Only primary can update zone.  Secondary
  169. forwards synchronously to primary.  No support for recursion or
  170. referrals.
  171.  
  172. Duplicate detection is needed to protect against replay (malicious or
  173. accidental).  Ordering is required to make sure earlier requests do not
  174. succeed later ones.  Problem:  what do we use?  SOA serial number:
  175. concurrency issue (it is on the whole zone).  Need something more.  Use
  176. SIG ``time signed'' timestamp?  Or new RR per node?  In general:  some
  177. sort of serial number (not necessarily SOA's).  Cannot use absence of
  178. something as generic locking mechanism - so don't.
  179.  
  180. There was consensus that all three types of adds should be present.
  181. Name server terminology should be consistent between all three drafts.
  182.  
  183. DNSSEC: SIGs apply across all RRs for a given name.  To update a SIG,
  184. you must read all RRs first.  But what about delayed visibility?
  185. Authorization issues -- must have SIG signed by all affected by an
  186. update?  Current update definition does not have a wrapper -- Susan and
  187. Donald Eastlake will work one out.
  188.  
  189. There are still some concerns about visibility -- where is the right
  190. tradeoff?  This will be hashed out on the mailing list.
  191.  
  192.