Domain Working Group
Chairperson:  Paul Mockapetris/USC/ISI





CURRENT MEETING REPORT
Reported by Paul Mockapetris



AGENDA


   o Redeployment of high level servers.

   o Short and Long Term fixes for excessive DNS usage reported in the
     NSFNET and elsewhere.

   o What should the DWG suggest to the Host Requirements WG.

   o Addition of dynamic add and delete to the DNS.

   o Enhancements to the DNS in general.


ATTENDEES


  1. Almquist, Phil/almquist@jessica.stanford.edu

  2. Brackenridge, Billy/brackenridge@isi.edu

  3. Burgan, Jeffrey/jeff@nsipo.nasa.gov

  4. Crocker, Dave/dcrocker@ahwahnee.stanford.edu

  5. Edwards, David/dle@cisco.com

  6. Fedor, Mark/fedor@nisc.nyser.net

  7. Kincl, Norman/kincl@iag.hp.com

  8. Lottor, Mark/mkl@nic.ddn.mil

  9. Natalie, Ron/ron@rutgers.edu

 10. St.  Johns, Mike/stjohns@beast.ddn.mil

 11. Stahl, Mary/stahl@sri-nic.arpa

 12. Volk, Ruediger/rv@germany.eu.net

 13. Woods, C. Philip/cpw@lanl.gov


MINUTES



                                        2
The Domain Working Group met at Stanford University IETF. Mike St.  Johns
discussed some possibilities for offloading some of the top-level domains,

such as EDU and COM, from management by the NIC.DDN.MIL. Some preliminary
thoughts were presented, but a firm plan has not yet been made.  The
majority of the meeting was spent discussing recent DNS usage problems,
cures, and the most needed repairs to BIND.

Problems:


     The best known aspect of the usage problems was NSFNET
     observations of 20% DNS packets on some links at certain times.
     Traffic monitoring revealed that these large packet fluxes were
     from relatively few sites, the so called "screamers".  The
     screamers are typically sites with Sun's YP using the DNS as a
     backstop, i.e.  configured so that queries which cannot be
     answered by YP drop into the DNS. The trouble is that under
     certain cases YP retries DNS queries as fast as possible, so a
     simple failure is repeated over and over.


     The same problem also caused more severe consequences in local
     environments.  In one case, DNS screaming leading to gateway
     overload, leading to gated cycle starvation, leading to EGP
     problems, leading to connectivity loss.  In another, the same
     traffic which was 20% of a NSFNET T1 was more than 100% of a
     56Kbit link.


     In addition to the screaming phenomena, others noted low level
     useless traffic which becomes significant when multiplied by the
     large number of hosts, but still much less than screaming.


Cures:


     DNS screaming has been fixed by new Sun YP software.  However,
     others could easily make the same mistake, so in the future we
     need firewalls to stop this behavior in both the resolver and name
     server since we cannot always assume control of either.  The
     method is an extension of negative caching.
     The extensions and already defined negative caching mechanisms are
     needed even if screamers are fixed so that the system will
     continue to scale up.
     Total load of DNS should be 1% or less.



                                        3
BIND needs:


     The attendees made the following list of the most important
     problems with existing DNS implementations, usually BIND.

        o All retry mechanisms should use exponential backoff, with
          settable upper and lower limits.

        o Negative caching of:

          -- Name errors and no data as in RFCs

          -- Temporary failures

          -- Server failures

        o Cooperation between forwarding name servers and waiting ACKs
          to resolvers.

        o Satisfactory implementation TTL=0 RR handling.

        o Correct operation in an environment without root server
          connectivity.

        o Correct implementation of master file defaults and minimums.

        o Broadcast and multicast implementation.

     ACTION ITEMS



       1. P. Mockapetris to produce detailed draft of problems and
          proposed cure.

       2. Group of interested parties to draft incremental update
          method.