nelson@sun.soe.clarkson.edu (Russ Nelson) (04/19/91)
In article <1234@foo.bar> name@changed.to.protect (The Guilty) writes:
Hi, there,
Could somebody mail me the common pc-ftp sites' IP address
to me ? My computer cann't check the site's internet name.
Thanks,
Per the quoted message, I'd have to say "No, the Domain Name System
(DNS) is not working". Requests like these are not uncommon. They
would be even more common except for the fact that people publishing
site names have learned to include the IP address.
I run a well-used archive site (grape.ecs.clarkson.edu) that recently
(Feb. 20th) changed its IP address. Since then, we have kept a
"victim" PC running on the old IP address [128.153.13.196]. The home
FTP directory on this PC has files that direct a user to the new 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.
I suppose it's a little unfair to lay the blame at the feet of the
DNS. After all, hosts using the DNS can simply FTP to grape. Or, if
your host doesn't use the DNS, a moment with nslookup or dig will get
you grape's IP address. But it is exactly this latter case that
causes the problem. On these hosts, a user must use a program that
prints the IP address, then they must reenter the IP address to the
FTP client. Once you know the IP address of a machine, why look it up
again?
Fairness, then, would dictate laying part of the blame on those system
administrators who use /etc/hosts in preference to the DNS. And for
the sake of truth, both I (on grape) and the sysadmin of
sun.soe.clarkson.edu refuse to use the DNS (consider this message a
confession, and the TCP-IP list the confessional). For my part, the
OS on grape.ecs.clarkson.edu experienced kernel crashes when using
the DNS. I went back to /etc/hosts and the crashes went away.
But I think that's a minor problem.
A more serious problem is faced by servers on the Internet. On the
one hand, the sysadmin would like users to be able to access any
machine on the Internet, and that means using the DNS. 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 think we need a hero to document the work-around. I don't think the
grand Usenet tradition of volunteering the complaintant should apply
in this case because I'm not the sysadmin on sun.soe.clarkson.edu.
Besides, I don't *know* what the work-around is. I just want the
person who DOES know to step forward, or at least to remain still while
the rest of us step backwards.
Thank you, you wonderful person, whoever you might turn out to be.
--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.bergum@SRC.Honeywell.COM (David Bergum) (04/19/91)
In article <NELSON.91Apr18230637@sun.clarkson.edu> nelson@sun.soe.clarkson.edu (Russ Nelson) writes: >Russ> In the past six days, we have had 287 FTP sessions initiated at the >Russ> OLD IP address. This, to me, is evidence that users have learned to >Russ> avoid using host names, preferring to use IP addresses. Not neccessarily. It takes time for the old IP address to age out of local cache, so the users may be using the host name and dns, but getting some old data from their local server. A good thing to do when you are going to change an IP address is to set a short TTL for the A RR some time in advance of the change, so ti will age out more quickly and the old data will be replaced with the new RR with a normal TTL. A -----/|\---------------------------------------+ - / | \ Bergum@CIM-VAX.Honeywell.COM | - /__|__\ Dave Bergum [MN26-3190] | - t--'--/ 2701 4-th Ave. S., Mpls, MN 55408 | -~~~~~~~~~~ (612)870-5839 | -----------------------------------------------+
hotz@isi.edu (Steve Hotz) (04/20/91)
In article <NELSON.91Apr18230637@sun.clarkson.edu> 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
cathyf@lost.rice.edu (Catherine Anne Foulston) (04/20/91)
In article <NELSON.91Apr18230637@sun.clarkson.edu> nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) writes: >I suppose it's a little unfair to lay the blame at the feet of the >DNS. .... >Fairness, then, would dictate laying part of the blame on those system >administrators who use /etc/hosts in preference to the DNS. Some of the blame should surely be laid at the feet of vendors who implement tcp/ip but not DNS. (Or who implement it so poorly that it's unusable.) If you're going to add tcp/ip capability to a system, you should include the ability to use the nameservice. (See RFC 1123.) Cathy -- Cathy Foulston + cathyf@rice.edu + Rice University, Network & Systems Support
emv@ox.com (Ed Vielmetti) (04/20/91)
anonymous ftp sites are particular prone to stale data, to wit: - the 'anonymous ftp site' list which gets posted monthly has ip numbers in it - 'comp.archives' postings have ip numbers in them (and I won't send one out unless I can identify an address - various and sundry of these numbers have been squirreled away on machines of all persuasions, including systems (like pre-NOS versions of KA9Q) with no working name server. If you capture the addresses of the originating sites to the old machine, it would be interesting to see a breakdown of what operating systems were involved. Dollars to donuts quite a few are running KA9Q net.exe. -- Msen Edward Vielmetti /|--- moderator, comp.archives emv@msen.com "With all of the attention and publicity focused on gigabit networks, not much notice has been given to small and largely unfunded research efforts which are studying innovative approaches for dealing with technical issues within the constraints of economic science." RFC 1216
markb@unix386.Convergent.COM (Mark Beyer) (04/23/91)
hotz@isi.edu (Steve Hotz) writes: >In article <NELSON.91Apr18230637@sun.clarkson.edu> >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". : : > for the most part DNS problems are due to misconfigurations >by administrators. Personally, I think the DNS administrative interface was designed by the IRS. It has to rank right up there with root canal work as one of the most fun things to contemplate. But you're right, it's probably the administrators' fault(s). ( :-) ). -- Mark Beyer markb@convergent.com {uunet,sun,decwrl,hplabs}!pyramid!ctnews!markb
imp@Solbourne.COM (Warner Losh) (04/23/91)
In article <7335@unix386.Convergent.COM> markb@unix386.Convergent.COM (Mark Beyer) writes: >Personally, I think the DNS administrative interface was designed by the IRS. >It has to rank right up there with root canal work as one of the most fun >things to contemplate. This may be a little off topic, but isn't sendmail's configuration files even harder to comptemplate, let alone complete :-) Warner -- Warner Losh imp@Solbourne.COM We sing about Beauty and we sing about Truth at $10,000 a show.
nelson@sun.soe.clarkson.edu (Russ Nelson) (04/24/91)
In article <EMV.91Apr19190011@poe.aa.ox.com> emv@ox.com (Ed Vielmetti) writes:
If you capture the addresses of the originating sites to the old
machine, it would be interesting to see a breakdown of what operating
systems were involved. Dollars to donuts quite a few are running KA9Q
net.exe.
I'll take you up on that bet. I studied a more-or-less random sample
of machines over a day and a half[1]. I telnetted to the machine, and
captured the output. Of the machines listed below, only 6 could
*possibly* be KA9Q, and none are *definitely* KA9Q.
[1] For the statistically-minded, I took the first 40 machines
that tried to FTP to the old machine on Monday and Tuesday (4/22
and 4/23). I discarded duplicate attempts. All results are included,
even failures to connect. This would *seem* to be random, but then
again, statistics are full of surprising correlations.
I'll take a dozen please (plain donuts will be fine):
Russell Nelson
11 Grant St.
Potsdam, NY 13676
The machine identifications are (and some of them are *really* weird):
Node MV218
Curtin Computing Centre VAX7 - VMS 5.3
VAX 8650 VMS System
4.3 BSD UNIX (olivej)
4.3 BSD UNIX (sdcsvax.ucsd.edu) (ttyp1)
4.3 BSD UNIX (tbd2.brl.mil)
Bull DPX (riri)
Connection closed by foreign host.
DYNIX(R) V3.0.17.9 (hydra.gatech.edu)
Domain/OS sr10 (sys2)
Enter validation for service access.
NeXT Mach (calvin) (ttyp0)
PRIMENET 21.0.4m APOLLO
SunOS UNIX (att)
SunOS UNIX (bill.UCSC.EDU)
SunOS UNIX (cec2)
SunOS UNIX (dip.eecs.umich.edu)
SunOS UNIX (engr)
SunOS UNIX (gilmer)
SunOS UNIX (gumbo)
SunOS UNIX (homer)
SunOS UNIX (kiss)
SunOS UNIX (mesunw54)
SunOS UNIX (splinter)
SunOS UNIX (sun.nsfnet-relay.ac.uk)
SunOS UNIX (sunee)
System V.3.1 / UTS 2.0 (tamuts)
ULTRIX V4.0 (Rev. 179) (neptune)
ULTRIX-32 (lepus)
UNISYS 5000 Series - This login banner resides in /etc/issue
USC Student Computing Facility -- SunOS Unix (aludra.usc.edu) (ttypc)
VAX/VMS V5.2 on RUGR86 (VAX 8650 at RuG)
VIRTUAL MACHINE/SYSTEM PRODUCT
login:
telnet: connect: Connection timed out
telnet: connect: Connection timed out
telnet: connect: Host is unreachable
telnet: connect: Host is unreachable
telnet: connect: Host is unreachable
telnet: connect: Network is unreachable
--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.
It's better to get mugged than to live a life of fear -- Freeman Dyson
I joined the League for Programming Freedom, and I hope you'll join too.evan@IS.RICE.EDU (Evan R. Wetstone) (04/24/91)
Warner Losh writes: > > In article <7335@unix386.Convergent.COM> markb@unix386.Convergent.COM (Mark Beyer) writes: > >Personally, I think the DNS administrative interface was designed by the IRS. > >It has to rank right up there with root canal work as one of the most fun > >things to contemplate. > > This may be a little off topic, but isn't sendmail's configuration > files even harder to comptemplate, let alone complete :-) I suppose DNS could be 1040EZ, but then sendmail.cf would be Form 1040 with schedules A,B,C,D,E, and supplemental worksheets. You know, I believe I would rather write a sendmail.cf file from scratch then have to figure out my taxes......;-) -- Evan Wetstone Network Support Rice University/SesquiNet
c_bstratton@HNS.COM (Bob Stratton) (04/26/91)
Date: 24 Apr 91 19:35:06 GMT
From: <horrendous return address deleted!> (Russ Nelson)
Organization: Clarkson University, Potsdam NY
References: <NELSON.91Apr18230637@sun.clarkson.edu>, <17653@venera.isi.edu>
Sender: tcp-ip-relay@nic.ddn.mil
If you capture the addresses of the originating sites to the old
machine, it would be interesting to see a breakdown of what operating
systems were involved. Dollars to donuts quite a few are running KA9Q
net.exe.
I'll take you up on that bet. I studied a more-or-less random sample
of machines over a day and a half[1]. I telnetted to the machine, and
captured the output. Of the machines listed below, only 6 could
*possibly* be KA9Q, and none are *definitely* KA9Q.
<stuff deleted>
Well, I'll agree with you that some of those are really weird, and
that most probably aren't running ka9q. I CAN, however vouch for one
of these namely:
Domain/OS sr10 (sys2)
which is an Apollo at my site (Hughes Network Systems). It's not
running ka9q.
I missed the beginning of this thread. What was the selection criteria
for these machines? I know that this machine has some problems -
that's why I'm here. If someone has noticed something losing about it,
please let me know.
Bob Stratton |
Stratton Systems Design| SMTP: strat@gnu.ai.mit.edu, c_bstratton@hns.com
Alexandria, Virginia | PSTN: +1 301 428 5500 x3298(W), +1 703 823 6463 (H)
"Personally, I think the DNS administrative interface was designed by the IRS."
--Mark Beyerlance@motcsd.csd.mot.com (lance.norskog) (04/30/91)
This thread reminds me of an idea I head awhile back: a DNS MIB. You ask a particular host, "make this DNS request via your normal method, and send me back the results". The point being, that every morning at 3AM you can do a spot check on all your hosts and make sure that they can see their local servers, their main servers, and can get out on the internet. SNMP is the natural avenue for doing this check. Lance Norskog Ever notice that UDP is only used on the Internet for infrastructure? Except for NFS, which should use TCP anyway?
PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD) (05/02/91)
I pick this subject for a question about a strange DNS behavior.
The NIC has introduced our
165.139.IN-ADDR.ARPA NS IN 518400 VM1.ULG.AC.BE
165.139.IN-ADDR.ARPA NS IN 518400 GEORGES.MONTEFIORE.ULG.AC.BE
with no A-records for these servers. "be" is delegated to other servers,
so there's no hint to our servers off the root otherwise.
Name servers often reply that 1.32.165.139.in-addr.arpa, for one, doesn't exist
the first time they are queried, but reply correctly afterwards, until cached
data disappeared (query examples below).
Is a resolver compelled to enter forward resolution to complete a reverse one?
Or are A-record mandatory hints with NS replies and should I ask the NIC?
I hope only this detail causes the problem. My servers seem to reply
correctly indeed.
VM1.ULG.AC.BE 139.165.32.1 (primary)
=============
Question:
1 1.32.165.139.in-addr.arpa PTR IN
Answer(s): (ie. Primary Results of the Query)
1 1.32.165.139.IN-ADDR.ARPA PTR IN 84900 VM1.ULG.AC.BE
Elapsed time 0.07 sec.
A query of a non-recursive server shows there are no A-records:
NS.NIC.DDN.MIL 192.67.67.53 (root, non recursive)
==============
Question:
1 1.32.165.139.IN-ADDR.ARPA PTR IN
Authority: (ie. Authoritative Nameservers)
1 165.139.IN-ADDR.ARPA NS IN 518400 VM1.ULG.AC.BE
2 165.139.IN-ADDR.ARPA NS IN 518400 GEORGES.MONTEFIORE.ULG.AC.BE
Elapsed time 1.60 sec.
I think the problem occurs when a recursive server is queried.
As shown below, when cached data do not exist, these servers successively
give 3 kind of replies:
1) does not exist
2) answer only
3) answer+authority+additionals
x) idem until cache expiration:
TERP.UMD.EDU 128.8.10.90 (root, recursive)
============
--- Query Name: 1.32.165.139.IN-ADDR.ARPA Qtype: PTR
Server 1/1: 128.8.10.90 128.8.10.90
Question:
1 1.32.165.139.IN-ADDR.ARPA PTR IN
Name Does Not Exist. RC=3
Elapsed time 1.16 sec.
Question:
1 1.32.165.139.IN-ADDR.ARPA PTR IN
Answer(s): (ie. Primary Results of the Query)
1 1.32.165.139.IN-ADDR.ARPA PTR IN 86400 VM1.ULG.AC.BE
Elapsed time 2.81 sec.
Question:
1 1.32.165.139.IN-ADDR.ARPA PTR IN
Answer(s): (ie. Primary Results of the Query)
1 1.32.165.139.IN-ADDR.ARPA PTR IN 86385 VM1.ULG.AC.BE
Authority: (ie. Authoritative Nameservers)
1 165.139.IN-ADDR.ARPA NS IN 518400 VM1.ULG.AC.BE
2 165.139.IN-ADDR.ARPA NS IN 518400 GEORGES.MONTEFIORE.ULG.AC.BE
Additional: (ie. A records for others)
1 VM1.ULG.AC.BE A IN 86366 139.165.32.1
2 GEORGES.MONTEFIORE.ULG.AC.BE A IN 86366 139.165.16.1
Elapsed time 1.97 sec.
Andr'e PIRARD SEGI, Univ. de Li`ege 139.165 IP coordinator
B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) +32 (41) 564932
pirard@vm1.ulg.ac.be alias PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU