CURRENT_MEETING_REPORT_

Reported by Randy Bush/RGnet

Minutes of the DNS IXFR, Notification, and Dynamic Update
Working Group (DNSIND)


First Session

The meeting began with an introduction of one of the new Internet Area
co-Directors, Frank Kastenholz.

Agenda bashing:

   o Main items:
      -  Dynamic update
      -  Notify
      -  IXFR

   o Schedule adjusted for IPv6 meeting conflicts

The group had hoped this would be the last meeting, but it does not look
likely.  The last meeting is now expected to be at the Stockholm IETF.
More DNS issues may be assigned to the group and the charter must be
re-written if so.  DNSSEC is inactive and the draft is out.


Masataka Ohta -- IXFR

   o In AXFR: UDP SOA query-response, followed by TCP SOA AXFR.

   o In IXFR: UDP IXFR query, server responds with unrecognized, or UDP
     SOA answer, or UDP zone transfer.  If UDP SOA answer, follow with
     TCP IXFR for update.  Can client initiate with TCP IXFR? Answer:
     no, need a UDP query first.  Should be able to start with TCP, due
     to possible UDP fragmentation (no fragmentation in v6).  Opinion:
     TCP may be too expensive for every query.  RFC 1034 states UDP must
     be tried first.

   o IXFR answer formats:

      1. Just current SOA.

      2. Same as AXFR (current SOA, followed by full zone data, followed
         by current SOA).

      3. Current SOA, followed by data to remove, followed by new SOA,
         then data to add.

   o Each IXFR requires an SOA change, unlike dynamic update which may
     not update SOA until several queries later.

   o Masataka, Sue and Paul should meet to hash out packet formats.

   o IXFR should be similar to dynamic update format (do not have two
     different formats for similar things).

   o Why do you want UDP for IXFR? Answer:  it might avoid the need for
     TCP in some cases (you need UDP SOA query for AXFR anyways).  Also,
     if UDP is good enough for initial SOA in AXFR, it should be good
     enough for IXFR.

   o Language will be modified -- need only packet format settled before
     floating it as Proposed Standard.  Do we need an implementation
     first?  The consensus was to delay going to RFC until
     implementation -- approve at Stockholm if no problems.

   o If server determines UDP checksumming turned off, send an SOA so
     that TCP is used


Masataka Ohta -- Idea For IPv6

   o Already have AAAA records for full address.
   o Propose XXXX record that has prefix pointer plus a host number.
   o Prefix pointer has a separate record to get list of prefix numbers.
   o Could this be done through a front-end, rather than the protocol?
   o It also allows one-record IXFR if provider changes.


Paul Vixie -- DNS Notify (And Others)

   o Notify now in draft status.

   o BIND 4.9.3 has code -- would not enable it.

   o LOC RR -- encode geographic location, use WGS84 reference spheroid
     (same as GPS), BIND 4.9.3 conforms to draft.

   o SRV RR: There is a problem with ``ftp.yoyodyne.com''-type hosts
     with asymmetric A/PTR RRs.  SRV RRs -- sort of like MX RRs (FTP on
     one host, WWW on another).  Can also provide primitive load
     balancing.  Somewhat controversial -- should it be in this working
     group?  Remember what happened to WKS RRs.  Can multiple PTRs solve
     the problem?  (Paul says he's still getting hate mail for making
     this work.)  Where should this go?

   o Back to Notify -- changes:  Primary Master has the external data
     source, must be listed in SOA MNAME and be one of NS RR. Slave:
     uses AXFR/IXFR to fetch zone data, must be in NS RR. Master:
     AXFR/IXFR server to other slaves.  Note:  Slaves can also be
     Masters!  Lurker (?):  AXFR/IXFR client but is not in NS RR. Server
     must receive and send data on DNS port.  Is there a reason why a
     ``lurker'' should be authoritative?  (Lurkers should be notified by
     default?)


Bill Simpson:  IPv6 Address-to-Name Mapping

   o Host should answer its own queries for a hostname.

   o Uses ICMP.

   o Couple points raised:  useless for multicast.

   o Logging?  Bill:  inverse tree is not reliable either, IPv6 will be
     much more dynamic (hosts and prefixes).

   o Both inverse DNS and direct-to-host queries are needed.

   o Some preference for UDP due to some implementation issues
     w/protection in UNIX (non-prived processes cannot ICMP).

   o Should protocol be same as DNS (similarity vs.  complexity)?

   o Inverse DNS tree is not as rotten in Paul's experience as Bill
     thinks.  Some people use inverse DNS for authentication.


Second Session

Susan Thomson -- Dynamic Update

The goal is to try and make the next draft the last.

Topics and Open Issues:


   o Add name new, add name exist, add operations
   o No support for recursion, referrals
   o Ordering of update requests
   o Implementing mutual exclusion
   o Name server technology
   o DNSSEC


Update is atomic transaction consisting of sequence of operations on
multiple names and types in a single zone.  Atomic against just primary,
or everywhere?  Answer:  cannot be everywhere, since secondaries may be
out-of-date -- that is inherent in DNS. Can primary be inconsistent?
Answer:  difference between visibility of data and atomicity of
transactions.  Operations:  delete, add, add name new, add name exist.
Add name new only works if name does not exist - ensures uniqueness Add
name exist -- only works if name does exist.  NXD records?  Server
should automatically fix these?  (The answer seems to be yes.)  Update
is defined to be asynchronous, but server may make it synchronously
anyways.  Updated data may not be visible right away -- there was much
discussion on this.  Those in favor say that it allows for flexibility
on the server side; secondaries are going to cause a problem with
complete visibility anyways.  Those against it say that the client needs
to have data visible; cannot read consistent view of the world.  A
possible solution might be to return a delta time as to when an update
will be visible.  (This seemed to be accepted.)  Zone serial number
updated at discretion of primary.  Client can send request to any name
server authoritative for zone.  (Statically-configured lurkers also
allowed?  Answer:  yes) Only primary can update zone.  Secondary
forwards synchronously to primary.  No support for recursion or
referrals.

Duplicate detection is needed to protect against replay (malicious or
accidental).  Ordering is required to make sure earlier requests do not
succeed later ones.  Problem:  what do we use?  SOA serial number:
concurrency issue (it is on the whole zone).  Need something more.  Use
SIG ``time signed'' timestamp?  Or new RR per node?  In general:  some
sort of serial number (not necessarily SOA's).  Cannot use absence of
something as generic locking mechanism - so don't.

There was consensus that all three types of adds should be present.
Name server terminology should be consistent between all three drafts.

DNSSEC: SIGs apply across all RRs for a given name.  To update a SIG,
you must read all RRs first.  But what about delayed visibility?
Authorization issues -- must have SIG signed by all affected by an
update?  Current update definition does not have a wrapper -- Susan and
Donald Eastlake will work one out.

There are still some concerns about visibility -- where is the right
tradeoff?  This will be hashed out on the mailing list.