home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / protocol / tcpip / domains / 718 < prev    next >
Encoding:
Internet Message Format  |  1992-11-20  |  5.2 KB

  1. Xref: sparky comp.protocols.tcp-ip.domains:718 comp.protocols.tcp-ip:5257
  2. Newsgroups: comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
  3. Path: sparky!uunet!caen!destroyer!news.iastate.edu!john
  4. From: john@iastate.edu (John Hascall)
  5. Subject: Re: Domain Name Service Deficiencies
  6. Message-ID: <By1EEG.KHu@news.iastate.edu>
  7. Keywords: DNS resolvers resolv.conf
  8. Sender: news@news.iastate.edu (USENET News System)
  9. Organization: Iowa State University, Ames, IA
  10. References: <4285@bcstec.ca.boeing.com>
  11. Date: Fri, 20 Nov 1992 22:56:39 GMT
  12. Lines: 94
  13.  
  14. tld5032@bcstec.ca.boeing.com (Terry Davis) writes:
  15. }
  16. }        This post attempts to summarize some experiences in utilizing DNS
  17. }        in  a  very large corporate environment.  The installed base here
  18. }        of TCP/IP includes over 50,000 active IP  addresses ...
  19.  
  20.      Here are some of my thoughts.  We are about an order of magnitude
  21.      smaller but make a fair use of DNS and its cousin Hesiod.
  22.  
  23. }        1) DNS is designed to support INTERNET access  not  local  users.
  24. }        If  the local LAN does not have a DNS nameserver on it, many user
  25. }        environments will cease to function if the primary  network  feed
  26. }        is lost.
  27.  
  28.      I am not sure I understand what you are saying here.  I agree that
  29.      if a host can not reach a nameserver then things get grim, but I
  30.      don't know why you'ld need one on each LAN.  I would think 2
  31.      or 3 per "campus" would be adequate.
  32.  
  33. }        Configurable timeouts and re-trys  might  help  this  greatly  by
  34. }        allowing  the  system  to  be  tuned  for its environment, LAN or
  35. }        INTERNET.  It seems likely that these should  be  placed  in  the
  36. }        /etc/resolv.conf file if they are used.
  37.  
  38.      I hate the way it always scans /etc/resolv.conf from top to bottom.
  39.      This file should be read in-core and when the number-1 server is
  40.      not responding, switch to another until it returns -- in fact I have
  41.      toyed with the idea of writing a kluge daemon which does periodic DNS
  42.      requests and re-orders /etc/resolv.conf when trouble is found.
  43.  
  44. }        2) There is  no  standard  way  of  determining  which  secondary
  45. }        database  to  use (/etc/hosts or yphosts) when DNS is inoperable.
  46. }        Worse yet is the case where no secondary lookup is allowed by the
  47. }        operating system.  Very strange things happen when DNS  fails and
  48. }        the secondary lookup either is non-existent or also fails.  Often
  49. }        mounts and remote processes simply vanish.  It should not be  re-
  50. }        quired for instance, for the administrator to maintain /etc/hosts
  51. }        when NIS is already  running on  the system or to run NIS just to
  52. }        support a  secondary lookup  function for DNS when  /etc/hosts is
  53. }        already configured.
  54. }        
  55. }        Again, a configurable database lookup sequence for  gethostbyname
  56. }        and gethostbyaddress resolve would go far to solve this problem.
  57.  
  58.      Like DEC's /etc/svc.conf which I really like.   Example line:
  59.  
  60.        hosts=local,bind,yp
  61.  
  62. }        4) In the operations area one of the shortcomings of DNS is  that
  63. }        the  "refresh"  and  "expire"  fields cannot be set to a specific
  64. }        time like refresh 5 minutes after every hour, or expire  at  4:45
  65. }        AM  on Thursdays much like a crontab entry.  In a large operation
  66. }        with tens of primary and secondary servers, the timing  of  these
  67. }        events  becomes  increasingly  important to overall DNS stability
  68. }        and responsiveness.
  69. }        
  70. }        5) Another DNS flaw is the lack of the ability to force a primary
  71. }        server to reload or update only one of its many zones.  Often DNS
  72. }        primary servers are reloaded hourly in  order  to  keep  up  with
  73. }        changes  coming  in.   This  can  render a server unavailable for
  74. }        several minutes when it has dozens of zones and thousands of host
  75. }        and address entries to re-hash.
  76. }        
  77. }        6) Full implementation of dynamic updates to DNS would be a major
  78. }        improvement in its operational functionality.  This could relieve
  79. }        many of DNS operational difficulties.
  80.  
  81.      This is what I wish for most.  We update every hour and every hour
  82.      we have a minute or so of wierdness while they read their files.
  83.      Also, if we happen to have lost connectivity to the world (the root
  84.      DNS servers) everything is all hosed over.
  85.  
  86. }        9) Another issue on the horizon, is the compatibility of  Netbios
  87. }        nameservice,  DNS,  and X.500.  It would seem that these services
  88. }        should be converging on a single standard; as of yet  this  isn't
  89. }        clear.
  90.  
  91.      DCE CDS, maybe?
  92.  
  93. }        11) In addition to  DNS, the  resolver  routines  "gethostbyname"
  94. }        and "gethostbyaddr" need  some extensive enhancements for life in
  95. }        the network environment.  Some form of short lived caching  needs
  96. }        to be provided, probably a most recent "10" lookups ...
  97.  
  98.      There would need to be some sort of short clock-time limit as well.
  99.      I know we have machines which could go for a long time before looking
  100.      up that 11th machine.
  101.  
  102. John
  103. -- 
  104. John Hascall                   ``An ill-chosen word is the fool's messenger.''
  105. Systems Software Engineer
  106. Project Vincent
  107. Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551
  108.