From: john@iastate.edu (John Hascall)
Subject: Re: Domain Name Service Deficiencies
Keywords: DNS resolvers resolv.conf
Organization: Iowa State University, Ames, IA
Date: Fri, 20 Nov 1992 22:56:39 GMT

tld5032@bcstec.ca.boeing.com (Terry Davis) writes:
}
}        This post attempts to summarize some experiences in utilizing DNS
}        in  a  very large corporate environment.  The installed base here
}        of TCP/IP includes over 50,000 active IP  addresses ...

     Here are some of my thoughts.  We are about an order of magnitude
     smaller but make a fair use of DNS and its cousin Hesiod.

}        1) DNS is designed to support INTERNET access  not  local  users.
}        If  the local LAN does not have a DNS nameserver on it, many user
}        environments will cease to function if the primary  network  feed
}        is lost.

     I am not sure I understand what you are saying here.  I agree that
     if a host can not reach a nameserver then things get grim, but I
     don't know why you'ld need one on each LAN.  I would think 2
     or 3 per "campus" would be adequate.

}        Configurable timeouts and re-trys  might  help  this  greatly  by
}        allowing  the  system  to  be  tuned  for its environment, LAN or
}        INTERNET.  It seems likely that these should  be  placed  in  the
}        /etc/resolv.conf file if they are used.

     I hate the way it always scans /etc/resolv.conf from top to bottom.
     This file should be read in-core and when the number-1 server is
     not responding, switch to another until it returns -- in fact I have
     toyed with the idea of writing a kluge daemon which does periodic DNS
     requests and re-orders /etc/resolv.conf when trouble is found.

}        2) There is  no  standard  way  of  determining  which  secondary
}        database  to  use (/etc/hosts or yphosts) when DNS is inoperable.
}        Worse yet is the case where no secondary lookup is allowed by the
}        operating system.  Very strange things happen when DNS  fails and
}        the secondary lookup either is non-existent or also fails.  Often
}        mounts and remote processes simply vanish.  It should not be  re-
}        quired for instance, for the administrator to maintain /etc/hosts
}        when NIS is already  running on  the system or to run NIS just to
}        support a  secondary lookup  function for DNS when  /etc/hosts is
}        already configured.
}        
}        Again, a configurable database lookup sequence for  gethostbyname
}        and gethostbyaddress resolve would go far to solve this problem.

     Like DEC's /etc/svc.conf which I really like.   Example line:

       hosts=local,bind,yp

}        4) In the operations area one of the shortcomings of DNS is  that
}        the  "refresh"  and  "expire"  fields cannot be set to a specific
}        time like refresh 5 minutes after every hour, or expire  at  4:45
}        AM  on Thursdays much like a crontab entry.  In a large operation
}        with tens of primary and secondary servers, the timing  of  these
}        events  becomes  increasingly  important to overall DNS stability
}        and responsiveness.
}        
}        5) Another DNS flaw is the lack of the ability to force a primary
}        server to reload or update only one of its many zones.  Often DNS
}        primary servers are reloaded hourly in  order  to  keep  up  with
}        changes  coming  in.   This  can  render a server unavailable for
}        several minutes when it has dozens of zones and thousands of host
}        and address entries to re-hash.
}        
}        6) Full implementation of dynamic updates to DNS would be a major
}        improvement in its operational functionality.  This could relieve
}        many of DNS operational difficulties.

     This is what I wish for most.  We update every hour and every hour
     we have a minute or so of wierdness while they read their files.
     Also, if we happen to have lost connectivity to the world (the root
     DNS servers) everything is all hosed over.

}        9) Another issue on the horizon, is the compatibility of  Netbios
}        nameservice,  DNS,  and X.500.  It would seem that these services
}        should be converging on a single standard; as of yet  this  isn't
}        clear.

     DCE CDS, maybe?

}        11) In addition to  DNS, the  resolver  routines  "gethostbyname"
}        and "gethostbyaddr" need  some extensive enhancements for life in
}        the network environment.  Some form of short lived caching  needs
}        to be provided, probably a most recent "10" lookups ...

     There would need to be some sort of short clock-time limit as well.
     I know we have machines which could go for a long time before looking
     up that 11th machine.

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551
Newsgroups: comp.protocols.tcp-ip.domains