home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.protocols.tcp-ip.domains:718 comp.protocols.tcp-ip:5257
- Newsgroups: comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip
- Path: sparky!uunet!caen!destroyer!news.iastate.edu!john
- From: john@iastate.edu (John Hascall)
- Subject: Re: Domain Name Service Deficiencies
- Message-ID: <By1EEG.KHu@news.iastate.edu>
- Keywords: DNS resolvers resolv.conf
- Sender: news@news.iastate.edu (USENET News System)
- Organization: Iowa State University, Ames, IA
- References: <4285@bcstec.ca.boeing.com>
- Date: Fri, 20 Nov 1992 22:56:39 GMT
- Lines: 94
-
- 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
-