Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!isi.edu!hotz From: hotz@isi.edu (Steve Hotz) Newsgroups: comp.protocols.tcp-ip Subject: Re: Is the DNS "working"? Message-ID: <17653@venera.isi.edu> Date: 19 Apr 91 21:28:30 GMT References: Sender: news@isi.edu Reply-To: hotz@chienne.isi.edu (Steve Hotz) Organization: USC-Information Sciences Institute Lines: 66 In article nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) writes: >> Per the quoted message, I'd have to say "No, the Domain Name >> System (DNS) is not working". Whoa whoa whoa there net cowboy ;-). That's a pretty amazing statement considering the hundreds of thousands of hosts that rely on DNS. While it is true that some of the implementations floating about could be better, and that DNS and YP still don't "play together" very well, for the most part DNS problems are due to misconfigurations by administrators. >> I run a well-used archive site (grape.ecs.clarkson.edu) that >> recently (Feb. 20th) changed its IP address. >> In the past six days, we have had 287 FTP sessions initiated at the >> OLD IP address. This, to me, is evidence that users have learned to >> avoid using host names, preferring to use IP addresses. This is usually evidence that DNS caching is working as it is supposed to, and that the reccommended procedure when changing DNS info of reducing the RR TTL before such a change is made wasn't followed. However, if it has been almost two months then there are either some *really* goofy implementations not paying attention to TTLs (the most common implementations do this correctly) or more likely, some folks don't use DNS resolver to get current information, so they use the old IP address they wrote down N months ago. >> I suppose it's a little unfair to lay the blame at the feet of the >> DNS. [... some text deleted ...] Now you're talking. The problem, more generally, is stale data, which by using the DNS mechanisms correctly, is quite nicely avoided. >> A more serious problem is faced by servers on the Internet. >> [... one hand deleted ...] On the other >> hand, the sysadmin MUST (at least this one must) keep the machine >> running even if access to the name server is cut off, even >> temporarily. A typical plaintive user cry is "Why can't we use >> sun.soe.clarkson.edu just because omnigate.clarkson.edu is down?" >> Perhaps there is a work-around. If there is, it's not well >> documented, because as I showed earlier, sun.soe.clarkson.edu is >> not the only machine relying on /etc/hosts. I believe it is documented with emphasis in the appropriate RFCs [1034 & 1035] that domain servers are required to be replicated (two is the required number). In fact, to be delegated a section of the namespace, one is supposed to show that this redundancy exists. If a domain can't keep one of two machines up at all times, then it makes sense to have further replication. With this redundancy, and a correctly configured /etc/resolv.conf life is good and peaceful! >> I think we need a hero to document the work-around. Although it may be reasonable to have the resolver library fall back on hosts.txt (argh) if no nameserver can be reached, i think i'd probably recommend that this "hero" be put on the "domain police" wanted list for crimes against the forward progress of the Internet ;-). Yours resolvedly, steve