woods@ncar.ucar.edu (Greg Woods) (09/19/88)
I want to modify sendmail to check the /etc/hosts file if a host name lookup to the name server fails with a non-temporary error. 1) Has anyone done this already, before I go and reinvent the wheel? 2) I'm running a version of 5.58 hacked to work on a Sun-4. Does anyone know if vanilla 5.59 from Beserkeley will run on a Sun-4? Under SunOS4-3.2 or Sun OS 4.0? What does 5.59 buy me over 5.58? Is it worth the hassle to try and convert? These are related issues, because if I'm going to go in and hack the source, I'd just as soon start with the most up-to-date version that I can get to work without an excessive amount of work. --Greg P.S. If it matters, I'm running BIND 4.8 on a Sun-4/280, currently under SunOS4-3.2 but soon to be upgraded to Sun OS4.0. This machine does not run yellow pages.
deke@socrates.ee.rochester.edu (Dikran Kassabian) (09/20/88)
In article <713@ncar.ucar.edu> woods@ncar.UCAR.EDU (Greg Woods) writes: >I want to modify sendmail to check the /etc/hosts file if a host name lookup >to the name server fails with a non-temporary error. I always thought this was a great idea, and never heard anyone else mention it. I'll open myself up to flames and suggest going one step further.... why not have gethostbyname() try the hosts file once upon failing to resolve a name via named? I guess one argument would be that this might contribute to the slow changeover to nameservers, allowing people to get by simply by registering in local host tables and not with a nameserver. But it would certainly help to make more sites reachable right now. ^Deke Kassabian, deke@ee.rochester.edu or rochester!ur-valhalla!deke Univ of Rochester, Dept of EE, Rochester, NY 14627 (+1 716-275-3106)
hedrick@athos.rutgers.edu (Charles Hedrick) (09/20/88)
The suggestion was made to look at /etc/hosts if a domain query fails, so that you can add info for a host that isn't yet registered. It seems to me that if you want to add local hacks like that you can just have your name servers load an extra startup file. In /etc/named.boot, just include an extra file that defines local additions. The only problem I can think of with this is that these local definitions will take precedence, so you have to remember to remove them once you no longer need them.
deke@socrates.ee.rochester.edu (Dikran Kassabian) (09/21/88)
In article <Sep.20.12.33.16.1988.6235@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: >The suggestion was made to look at /etc/hosts if a domain query fails, >so that you can add info for a host that isn't yet registered. It >seems to me that if you want to add local hacks like that you can >just have your name servers load an extra startup file. In >/etc/named.boot, just include an extra file that defines local >additions. Well sure, that works, but it only addresses the case where there are a few hosts that I know I want to reach... Many times a user on one of my systems begins a correspondance with someone at a site we previously never mailed to. The user at the remote site gives our local user an address that he "knows" is good, 'cause its in the hosts table. Our user sends mail to that address and it bounces... there isn't a nameserver to answer for that host in that domain. The local user can only conclude that my mail configuration is "screwed up". After all, his friend's mail makes it here (our address ee.rochester.edu, can be found both in /etc/hosts and by asking our nameserver, which I believe is the only way currently to be absolutley correct). To top it all off, the address my users wants to reach is actually in /etc/hosts! "Proof positive" that my mail configuration is lousy. What is the "right thing" to do here? Many many sites continue to publish addresses that are either in /etc/hosts (as distributed currently by NIC) or served by their nameserver, but not in both places. Understandable, I suppose in a world that's in a state of transistion. Add to this the "backwards" addresses of JANET and other nightmares, and the temptation to kludge things to work in the "exceptions" cases grows. This is some of the motivation behind my suggestion to change the way gethostbyname() works.... and as I said in my original posting, I freely open myself up to the flames. ------------------------------------------------------------------------ \\\ Deke Kassabian, URochester Department of Electrical Engineering \\\ \\\ deke@ee.rochester.edu "I never metacharacter \\\ \\\ or ...!rochester!ur-valhalla!deke I didn't like......" \\\ ------------------------------------------------------------------------- "Isn't fun the BEST thing to have ?"
ane@hal.UUCP (Aydin "Bif" Edguer) (09/21/88)
In<1473@valhalla.ee.rochester.edu>deke@ee.rochester.edu(Dikran Kassabian)writes: >In<Sep.20.12.33.16.1988.6235@athos.rutgers.edu>hedrick(Charles Hedrick) writes: >>The suggestion was made to look at /etc/hosts if a domain query fails, >>so that you can add info for a host that isn't yet registered. It >>seems to me that if you want to add local hacks like that you can >>just have your name servers load an extra startup file. In >>/etc/named.boot, just include an extra file that defines local >>additions. >Well sure, that works, but it only addresses the case where there are >a few hosts that I know I want to reach... Pardon my ignorance but why do you say it only works in the case of "a few hosts?" And why would you EVER want more than "a few hosts?" How many unregistered internet sites are there? >Many times a user on one of my systems begins a correspondance with someone >at a site we previously never mailed to. The user at the remote site >gives our local user an address that he "knows" is good, 'cause its in the >hosts table. Our user sends mail to that address and it bounces... there >isn't a nameserver to answer for that host in that domain. In that case contact the Zone Contact for this domain - It is their responsibility to maintain their files, not yours. >our address ee.rochester.edu, can be found both in /etc/hosts >and by asking our nameserver, which I believe is the only way >currently to be absolutely correct) If you are running the nameserver then the /etc/hosts file is necessary only during those times the nameserver is down, such as in standalone mode or during testing. >What is the "right thing" to do here? The "right thing" would be to contact the other site. Any site in the NIC's host file is available to the nameserver. Any information in local /etc/hosts is local to that machine only. >This is some of the motivation behind my suggestion to change the way >gethostbyname() works.... and as I said in my original posting, I freely >open myself up to the flames. Gethostbyname() works fine. When the nameserver is DOWN it does look in the local /etc/hosts file. Otherwise IT SHOULD NOT. /etc/hosts is supposed to be a minimal list of sites. It is not supposed to be considered authoritative for all the sites listed. My suggestion AS A TEMPORARY FIX would be just to use the internet number for the site rather than the site name. Try mailing to ane@[129.22.144.1] rather than ane@hal.cwru.edu. It should work either way. Aydin Edguer ane@hal.cwru.edu "The opinions expressed here are probably wrong but if you really BELIEVE..."
woods@ncar.ucar.edu (Greg Woods) (09/21/88)
In article <285@hal.UUCP> ane@hal.cwru.edu (Aydin "Bif" Edguer) writes: >>Many times a user on one of my systems begins a correspondance with someone >>at a site we previously never mailed to. The user at the remote site >>gives our local user an address that he "knows" is good, 'cause its in the >>hosts table. Our user sends mail to that address and it bounces... there >>isn't a nameserver to answer for that host in that domain. This is *precisely* the situation I am running into, and all too often the "user" in question is our Division Director, or some other bigwig here. >In that case contact the Zone Contact for this domain - It is their >responsibility to maintain their files, not yours. That isn't a good answer, although a lot of people seem to think it is, based on the mail I've gotten. My users want mail to work. They don't want to hear a lot of excuses about how it's the other site's fault. Especially since the "simple" hosts-file-based mailer on the other machine can get it there. That is the reality. It's all well and good for us hackers to know that it is, in fact, the other site's fault. We all know they've had plenty of time to convert. But my users don't *care* about that; they really don't! And besides, if they don't have a working name server, how the hell do I find out who the "Zone Contact" is? Face it, folks, it ain't a perfect reality we live in. There are hosts and domains out there that were registered before the days of name servers, that are legitimately registered, and that my users want to send to. My bosses want to send there. Therefore, I have to support it. That's it. Period. What those other sites *should* be doing is TOTALLY IRRELEVANT to the reality I (and apparently some others too) am faced with. >If you are running the nameserver then the /etc/hosts file is necessary >only during those times the nameserver is down, such as in standalone >mode or during testing. Untrue, see above. >>What is the "right thing" to do here? >The "right thing" would be to contact the other site. That doesn't get mail working. That is the "right thing" in one sense, but in reality it does NOTHING to solve my problem. Nor does it deal with the "it works on the other machine" hassles. Nor does it help me justify the added effort to keep up the name server, resolver, and hacked versions of sendmail and other applications. >Any site in the NIC's host file is available to the nameserver. WRONG. See first paragraph. >My suggestion AS A TEMPORARY FIX would be just to use the internet number >for the site rather than the site name. Not a good temporary fix from the user's point of view. Fine for us, but the users don't want to deal with this nonsense. All they understand is that the information is available and my mailer can't find it. Thanks to those who sent me patches. None of them were for the exact software I have, so I haven't been able to make any of them work yet. In BIND 4.7.2, there were 4 patches to gethostnamaddr.c. With the BIND 4.8 code, none of them would apply. I can only find two of the places in the code where they should go, and even after putting them in by hand, neither nslookup nor sendmail can resolve host names I placed in /etc/hosts that aren't available through the name servers. Running nslookup under dbx(1) shows that gethostbyname() is never called unless a server is specified on the command line, so it never gets to the patched part of the code. I hope to have more luck with the 5.59 sendmail patch I got, although what I have is hacked 5.58, so I'm expecting more trouble. --Greg
grandi@noao.edu (Steve Grandi) (09/21/88)
In article <285@hal.UUCP> ane@hal.cwru.edu (Aydin "Bif" Edguer) writes: >My suggestion AS A TEMPORARY FIX would be just to use the internet number >for the site rather than the site name. Try mailing to ane@[129.22.144.1] >rather than ane@hal.cwru.edu. It should work either way. About half the time when we try such a mail address, we get back an error from the other machine's sendmail saying "I refuse to talk to myself" and the user's mail drops on the floor one more time! In other words, I agree with Greg that having bind use /etc/hosts as an ultimate backup would be desirable although I have survived so far by adding a few "unregistered" names to my local name server. -- Steve Grandi, National Optical Astronomy Observatories, Tucson AZ, 602-325-9228 UUCP: {arizona,decvax,ncar}!noao!grandi or uunet!noao.edu!grandi Internet: grandi@noao.edu SPAN/HEPNET: NOAO::GRANDI (NOAO=5355)
ane@hal.UUCP (Aydin "Bif" Edguer) (09/21/88)
In<1473@valhalla.ee.rochester.edu>deke@ee.rochester.edu(Dikran Kassabian)writes: >>>Many times a user on one of my systems begins a correspondance with someone >>>at a site we previously never mailed to. The user at the remote site >>>gives our local user an address that he "knows" is good, 'cause its in the >>>hosts table. Our user sends mail to that address and it bounces... there >>>isn't a nameserver to answer for that host in that domain. In article <729@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes: > My users want mail to work. Okay. I want it to work to. I want the network to work also. I don't want the temporary fixes like checking /etc/hosts to last so long they become the defacto standard that must be lived with. Lets not go backwards. > They don't want to hear a lot of excuses about how > it's the other site's fault. Unfortunately, it is not an excuse. It is a fact. >Especially since the "simple" hosts-file-based mailer on the other >machine can get it there. That is the reality. Your "simple" name server based mailer can do the same thing. Here are some options available to you. 1) Ask why they are going to all the "trouble" of remembering addresses for their friends. Tell them about mail aliases. Add an alias for foo@[127.0.0.1] to their .mailrc. They'll thank you for making life easier and it will solve your problem. 2) Add the names to your name server. No code hacking is required. This is what Charles Hedrick suggested. In <Sep.20.12.33.16.1988.6235@athos.rutgers.edu> Charles Hedrick writes: >>>In /etc/named.boot, just include an extra file that defines local >>>additions. The only problem I can think of with this is that these >>>local definitions will take precedence, so you have to remember to >>>remove them once you no longer need them. >And besides, if they don't have a working name server, >how the hell do I find out who the "Zone Contact" Try using the whois(1) command. Or send mail to Postmaster@site.do.main. Or call the NIC. >Face it, folks, it ain't a perfect reality we live in. Agreed. I'm just not sure if I agree with your solutions to the imperfections. >There are hosts and domains out there that were registered before >the days of name servers, that are legitimately registered, >and that my users want to send to. If the hosts and domains are truly "REGISTERED" then the NIC knows them and you can find them using a nameserver. There are UNREGISTERED hosts or subdomains inside registered domains. In a case such as this, the REGISTERED domain is responsible for delivery to the unregistered subdomains. Tack on a "@registered.domain:" in front of "user@unregistered.do.main". >My bosses want to send there. Therefore, I have to support it. That's it. >Period. What those other sites *should* be doing is TOTALLY IRRELEVANT >to the reality I (and apparently some others too) am faced with. Not really. If no one ever complains then they won't have any reason to change. That is a reality. If your boss tells their boss that he cannot reach them because THEIR software is broken, maybe THEY will have to change. Add the alias to show how much you want things to work but point out how this is just a work around of THEIR PROBLEM. >In article <285@hal.UUCP> ane@hal.cwru.edu (Aydin "Bif" Edguer) writes: >>If you are running the nameserver then the /etc/hosts file is necessary >>only during those times the nameserver is down, such as in standalone >>mode or during testing. > Untrue, see above. I hate to make this seem like a "yes you are/no I'm not" match, but there are solutions USING THE NAMESERVER. The /etc/hosts file is necessary only when the nameserver is down <PERIOD>. >>The "right thing" would be to contact the other site. > That doesn't get mail working. That is the "right thing" in one sense, >but in reality it does NOTHING to solve my problem. Nor does it deal with >the "it works on the other machine" hassles. Nor does it help me justify >the added effort to keep up the name server, resolver, and hacked versions >of sendmail and other applications. OKAY. It may not be the ONLY thing you should do. But it is ONE of the things you should do. I do not agree that you should be hacking on the name server or resolvers. Sendmail on the other hand could use some hacking. (WHEN WILL IDA FOR SENDMAIL 5.59 GET POSTED??!!!) If you want to do this hacking then I would suggest instead that is the nameserver cannot resolve a name it try for the domain above. Example: to: fred.cs.BlueU.Edu. fails try: cs.BlueU.Edu. if that fails try: BlueU.Edu. This should NEVER fail. If it does - contact the NIC immediately This should at least resolve to an MX. >>Any site in the NIC's host file is available to the nameserver. > WRONG. See first paragraph. As far as I know this is not wrong. Could you please point out a case where it is not true. Note I said the NIC's host file not your /etc/host file. >>My suggestion AS A TEMPORARY FIX would be just to use the internet number >>for the site rather than the site name. > Not a good temporary fix from the user's point of view. You might have to remember 4 3-digit numbers instead of some.long.name.edu. But if you use aliases you don't have to remember either one. Look. If it works for you then go with it. I disagree with your solution but good luck anyway. Aydin Edguer
woods@ncar.ucar.edu (Greg Woods) (09/21/88)
In article <286@hal.UUCP> ane@hal.cwru.edu (Aydin "Bif" Edguer) writes: > > They don't want to hear a lot of excuses about how > > it's the other site's fault. >Unfortunately, it is not an excuse. It is a fact. You see it as a fact. People who have had mail bounce see it as an excuse. Unfortunately, it is THEY that I have to deal with on a day-to-day basis, not you. > >Especially since the "simple" hosts-file-based mailer on the other > >machine can get it there. That is the reality. >Your "simple" name server based mailer can do the same thing. Here are some >options available to you. The problem with these options is that they cannot be implemented until mail has ALREADY BOUNCED. I want to do something that will get the mail there BEFORE it bounces. >If the hosts and domains are truly "REGISTERED" then the NIC knows them and >you can find them using a nameserver. Does this mean that the NIC's root servers provide host information for registered hosts in domains that do not yet have working name servers? That is what would be required for your statement to be correct. >Tack on a "@registered.domain:" in front of "user@unregistered.do.main". Again unacceptable, because it requires changes on the part of the users and because we don't find out that this is needed until after the mail bounces. >Not really. If no one ever complains then they won't have any reason to >change. That is a reality. If your boss tells their boss that he cannot >reach them because THEIR software is broken, maybe THEY will have to change. Agreed, execpt that my boss doesn't want to deal with this sort of thing. From his point of view, it is my job to do whatever is necessary to make it work. You are right that we ought to complain when these situations are detected, though. But my users aren't willing to sacrifice having their mail go through just to make a point. > >>Any site in the NIC's host file is available to the nameserver. >As far as I know this is not wrong. Could you please point out a case >where it is not true. Note I said the NIC's host file not your /etc/host >file. This statement, even if true, is irrelevant. It is the hosts in our file that the users want to send to. Most of them are not even aware of the distinction. All they know is that they can FTP there but they can't mail there, and in their eyes it is my fault, since I'm in charge of mail. In any case, these examples happen only once a month or so. One could argue that in that event it's no big deal. And depending on which user has his mail bounce, that might be true. But all it takes is one wrong bounce for the wrong user to make life difficult for me. The next time it happens, I'll post the example. I don't save them all, so I don't have any handy. >You might have to remember 4 3-digit numbers instead of some.long.name.edu. >But if you use aliases you don't have to remember either one. But you still have to have the mail bounce before you determine that this is needed. That is what I am trying to prevent in the first place. --Greg
jordan@zooks.ads.com (Jordan Hayes) (09/22/88)
Greg Woods <woods@handies.UCAR.EDU> writes:
Face it, folks, it ain't a perfect reality we live in. There
are hosts and domains out there that were registered before the
days of name servers, that are legitimately registered, and
that my users want to send to.
I'm having a real hard time with this one.
I want an example of a "domain out there that was registered before the
days of nameservers" ... the only two I can think of are ".arpa" and
".Berkeley.ARPA" ... for that first one, the NIC maintains the
nameservers for those weary hosts. For the second, that was a hack
that went away a few years ago.
By definition, "legitimately registered" (as opposed to
illegitimately?) means you have a nameserver out there *somewhere* ...
and you can't get a domain from the NIC without some nameservice ...
Now, if you're simply saying your nameserver doesn't work, that's a
whole different story.
/jordanhedrick@athos.rutgers.edu (Charles Hedrick) (09/22/88)
> Does this mean that the NIC's root servers provide host information for >registered hosts in domains that do not yet have working name servers? >That is what would be required for your statement to be correct. Not quite. What it means is that you aren't allowed to start using a domain until that domain has working name servers. Until that point, you can only register hosts in .arpa or some other generic domain. "registered hosts in domains that do not yet have working name servers" is a contradiction in terms. What I think happens is that in practice there's a period of time during which things are in transition, and so bad things happen. This can happen in two ways: 1) A site asks for authorization from NIC to create a domain, and immediately starts using domain-format names, without waiting for NIC's response. We had that problem with a neighboring site. We kept getting mail from foo.bar.edu, but the root servers hadn't heard of bar.edu. The management of bar said "oh, well, we've asked NIC to register bar, but things are being held up." We fixed this by telling our name servers about bar's name servers. 2) A site asks for authorization to use a domain before they've got name servers running. This is perfectly OK, but they shouldn't start using domain-format names until they've got the servers up. In both cases, the basic problem is the same: It is not allowed to use a name foo.bar.edu until bar.edu is both (1) authorized by the NIC and (2) has working name servers. Until that happens, mail should be sent out with return addresses of the form user%foo@bar.arpa, where bar.arpa is a mail gateway that is in the NIC host table and is prepared to forward mail to all of your internal sites. If the domain has been authorized but does not yet have working name servers, another approach is to have the NIC delegate the domain to a temporary set of name servers. These would have a single MX entry that points *.bar.edu to your relay machine. Once you get your real name servers up you would then tell the NIC to change the delegation to point to them. If this problem is common enough to be worth worrying about, NIC could do a couple of things to help: - change the domain application to have a note at the bottom: WARNING: do not start using host names in this domain until (1) the NIC has notified you that the root domain servers have delegated it to your name servers and (2) your name servers are operational. - when they get requests to add new hosts to the host table, first check that a domain query can find them.
ane@hal.UUCP (Aydin "Bif" Edguer) (09/22/88)
In article <733@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes: >In article <286@hal.UUCP> ane@hal.cwru.edu (Aydin "Bif" Edguer) writes: >> In article <729@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes: >> >Especially since the "simple" hosts-file-based mailer on the other >> >machine can get it there. That is the reality. >>Your "simple" name server based mailer can do the same thing. Here are some >>options available to you. > The problem with these options is that they cannot be implemented until >mail has ALREADY BOUNCED. I want to do something that will get the mail >there BEFORE it bounces. Okay. Point #1: You should be running the nameserver (at least caching) on all your machines. Point #2: Your C library functions should be compiled to use the nameserver on all your machines. Point #3: Your networking software (ftp, telnet, sendmail, etc) should all be compiled using the libraries that use the nameserver on all your machines. Why? This leads to consistent behavior. This is easier to maintain. No more... >All they know is that they can FTP there but they can't mail there, >and in their eyes it is my fault, since I'm in charge of mail. [note: this should never happen on your machine since ftp uses the nameserver too! Unless your running with improperly compiled programs.] Well, that is just the ideal case. As you have pointed out the world is not ideal. You may not have that much control over the environment. I've run this issue into the ground by now but I would also like to help you. Here is a possible solution to your problem. Problem statement: 1) You want to find problems with incompatibilities between an /etc/hosts and the nameserver. 2) You want to find the problems before a user tells you that their mail is not going through. Solution statement: 1) Write a shell program which will a) go through a file in /etc/hosts format and extract the fully qualified domain names. b) take each name found and use nsquery (distributed with named) to look up each name in the nameserver. c) Examine the output of nsquery for failure and notify you. d) EXTRA CREDIT: Make it add an entry to your local mod file for the nameserver. 2) Automate the process of getting the /etc/hosts from offending machines by using batched ftp (there have been a couple posted to the net.) 3) You should only need to do this ONCE. After that time people should either a) not be modifying their /etc/hosts files. b) make them modify the local mod file for the nameserver at the same time they are modifiying the /etc/hosts file on their machines. c) notify you whenever they make a change to their /etc/hosts file. The second possible solution I posted last time - Hack on sendmail to look up parent domains and forward the mail to the parent domain (allowing the authoritative server to figure out the correct address.) This should always work unless the network goes down (in which case the mail won't be delivered anyway). The only case this will fail is when a domain has not been registered, in which case IT SHOULD NOT BE USED. The NIC can get very ornery when it happens. The offending site can lose ALL Internet priviledges. > Agreed, execpt that my boss doesn't want to deal with this sort of thing. > From his point of view, it is my job to do whatever is necessary to make > it work. You are right that we ought to complain when these situations > are detected, though. But my users aren't willing to sacrifice having > their mail go through just to make a point. I don't suggest sacrificing their mail (not even to the great god Murphy) but instead point out that you DO make their mail work. You should point out that a bounced message will only be delayed a short while, till resent with more information, not lost. After all we're talking Internet not UUCP. Aydin Edguer
gmp@rayssd.ray.com (Gregory M. Paris) (09/22/88)
In article <729@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes: > based on the mail I've gotten. My users want mail to work. They don't > want to hear a lot of excuses about how it's the other site's fault. ... > We all know they've had plenty of time to convert. But my users don't > *care* about that; they really don't! And besides, if they don't have ... > My bosses want to send there. Therefore, I have to support it. That's it. > Period. What those other sites *should* be doing is TOTALLY IRRELEVANT > to the reality I (and apparently some others too) am faced with. Not to mimimize Greg's problem, and I do sympathize with him, but I don't agree totally with his argument. I suffer, or more precisely this domain suffers, from what might be described as the reverse problem of the one Greg's having. Users at sites that are still using the host file constantly tell people here that they can't mail to them because we're not in the host table. (As if it was some failure on our part, no less.) I get little pleasure out of telling employees of this company that it's not our (my) fault, but the fault of old software on the other end. Why is it that they don't seem to believe me? Why is it that they look at me blankly when I mention nameservers and MX records? Why is it that the people at the other site act like they think I'm full of sh*t? Using Greg's rationale, I'd have to say that it's TOTALLY IRRELEVANT what the people at the other site should be doing. I should make it work, dammit! Easier said than done. Sometimes the %-sign kludge works, sometimes other things work, but sometimes nothing works. I've failed! Using Greg's rationale does not make me feel very good. -- Greg Paris <gmp@rayssd.ray.com> {decuac,gatech,necntc,sun,uiucdcs,ukma}!rayssd!gmp NO KILL I
deke@galaxy.ee.rochester.edu (Dikran Kassabian) (09/22/88)
In article <287@hal.UUCP> ane@hal.cwru.edu (Aydin "Bif" Edguer) writes: > Point #1: You should be running the nameserver (at least caching) > on all your machines. > Point #2: Your C library functions should be compiled to use the > nameserver on all your machines. > Point #3: Your networking software (ftp, telnet, sendmail, etc) > should all be compiled using the libraries that use > the nameserver on all your machines. Hmmm. Some of us have binary only distributions to Operating Systems that have a strange mechanism for resolving host names through the "yellow pages" One vendor in particular causes me alot of grief with their lack of under- standing of existance in an Internet environment. But they make great work- stations. On machines where sources are available, I'd make an argument for having two versions of telnet, ftp, finger, rlogin, etc. One that uses nameserver (in /usr/ucb) and the other using /etc/hosts (in /usr/old or something like that). > >All they know is that they can FTP there but they can't mail there, > >and in their eyes it is my fault, since I'm in charge of mail. > [note: this should never happen on your machine since ftp uses > the nameserver too! Unless your running with improperly compiled > programs.] ...Or programs that come with the binary only distribution. Has everyone forgotten what it is like to be without sources? A sysadmin is still expected to make things work. >Here is a possible solution to your problem. >Problem statement: > 1) You want to find problems with incompatibilities > between an /etc/hosts and the nameserver. > 2) You want to find the problems before a user tells you > that their mail is not going through. >Solution statement: > 1) Write a shell program which will > a) go through a file in /etc/hosts format and extract > the fully qualified domain names. > b) take each name found and use nsquery (distributed with > named) to look up each name in the nameserver. > c) Examine the output of nsquery for failure and notify > you. That ought to take about a month and all the cpu I can muster... > d) EXTRA CREDIT: Make it add an entry to your local mod > file for the nameserver. And now I'm a nameserver for the world. > 2) Automate the process of getting the /etc/hosts from offending > machines by using batched ftp (there have been a couple posted > to the net.) Does this assume that every machine has anonymous ftp configured and that the hosts file is ready to be grabbed by anyone? Do I miss your point? >The second possible solution I posted last time - > Hack on sendmail to look up parent domains and forward the mail > to the parent domain (allowing the authoritative server to figure > out the correct address.) This should always work unless the > network goes down (in which case the mail won't be delivered > anyway). meaning turn person@bogushost.do.main into person%bogushost@do.main ? Thats what the users end up doing anyway, but I guess its an okay idea to have sendmail do it. Okay. I'm through making waves for now. Stan Barbor at Baylor says that Bind 4.8 at most recent patch level does what I want.... it asks /etc/hosts if nameserver fails (not to be confused with "if nameserver isn't available") If thats so, we are arguing over nothing. What I'm looking for exists. Can anyone comment? ^Deke Kassabian, deke@ee.rochester.edu or ur-valhalla!deke Univ of Rochester, Dept of EE, Rochester, NY 14627 (+1 716-275-3106)
honey@umix.cc.umich.edu (Peter Honeyman) (09/22/88)
Greg says: >All they know is that they can FTP there but they can't mail >there, and in their eyes it is my fault, since I'm in charge of mail. i know a lot of users like that. so i recompiled ftp (and everything else) to use the nameserver. end of problem. peter
wisner@killer.DALLAS.TX.US (Bill Wisner) (09/22/88)
>And besides, if they don't have >a working name server, how the hell do I find out who the "Zone Contact" >is? The WHOIS/NICNAME database on SRI-NIC.ARPA. Bill Wisner wisner@killer.dallas.tx.us killer!wisner
wisner@killer.DALLAS.TX.US (Bill Wisner) (09/22/88)
>>Try mailing to ane@[129.22.144.1] >>rather than ane@hal.cwru.edu. It should work either way. >About half the time when we try such a mail address, we get back an error >from the other machine's sendmail saying "I refuse to talk to myself" and >the user's mail drops on the floor one more time! Quite common. The sendmail.cf used at MIT LCS takes care of this by defining class I as a list of all valid IP addresses for the site. One of the rulesets rewrites user@[xx.xx.xx.xx] into user@LOCAL and everything's peachy. Bill Wisner wisner@killer.dallas.tx.us killer!wisner
ron@topaz.rutgers.edu (Ron Natalie) (09/22/88)
> Point #1: You should be running the nameserver (at least caching) > on all your machines. No, you need not run the nameserver on all your machines. My sun3/50 is having enough trouble just running EMACS. What you want is to have a name server close by that you can call. You only need a resolver. > Point #2: Your C library functions should be compiled to use the > nameserver on all your machines. Your C library calls should be linked with the resolver code to make a query to a local name server. > Point #3: Your networking software (ftp, telnet, sendmail, etc) > should all be compiled using the libraries that use > the nameserver on all your machines. Ditto, resolver not server. Resolver is the client part of the domain system.
woods@ncar.ucar.edu (Greg Woods) (09/23/88)
In article <4780@umix.cc.umich.edu> honey@citi.umich.edu (Peter Honeyman) writes: >so i recompiled ftp (and everything else) to use the nameserver. > >end of problem. That's great, but it requires one thing I haven't got: the sources to ftp and everything else. --Greg
clarke@acheron.UUCP (Ed Clarke) (09/23/88)
From article <1482@valhalla.ee.rochester.edu>, by deke@galaxy.ee.rochester.edu (Dikran Kassabian): > Hmmm. Some of us have binary only distributions to Operating Systems that > have a strange mechanism for resolving host names through the "yellow pages" Sendmail 5.59 and bind are both Berkeley code. To quote from 'main.c' in sendmail (partial quote only): Redistribution and use in source and binary forms are permitted provided that this notice is preserved and that due credit is given to the University of California at Berkeley. So throw out your binaries and use the source! When the IDA patches come out, there's YP support built in ( bind is the name server from 4.3bsd ). I think sendmail and named/bind were distributed last year in comp.sources.somthingorother. Or grab them from ucbarpa since you are on the internet. Ed Clarke uunet!bywater!acheron!clarke
deke@socrates.ee.rochester.edu (Dikran Kassabian) (09/23/88)
In article <246@acheron.UUCP> clarke@acheron.UUCP (Ed Clarke) writes: >From article <1482@valhalla.ee.rochester.edu>, by deke@ee.rochester.edu >> Hmmm. Some of us have binary only distributions to Operating Systems that >> have a strange mechanism for resolving host names through the "yellow pages" > >Sendmail 5.59 and bind are both Berkeley code. To quote from 'main.c' in >sendmail (partial quote only): > > Redistribution and use in source and binary forms are permitted > provided that this notice is preserved and that due credit is > given to the University of California at Berkeley. > >So throw out your binaries and use the source! >Ed Clarke >uunet!bywater!acheron!clarke You quote me out of context... Yes I have source to sendmail, no I don't have source for ftp, telnet, finger, and others. The discussion was moving towards the perceived difference in "reachable" hosts, by the users, in sendmail vs. say, ftp. In particular, they would want to know why they CAN ftp to a site, but CAN'T mail. The answer of course is that we have an entry for some site in /etc/hosts, but there is no nameserver to answer for them, and we use the distributed ftp and the Berkeley sendmail. Summary: I know things will eventually work themselves out when everyone uses nameservers and not host tables. But right now its pretty darn frustrating. State of transistion. ^Deke Kassabian, deke@ee.rochester.edu or ur-valhalla!deke Univ of Rochester, Dept of EE, Rochester, NY 14627 (+1 716-275-3106)
nowicki%rose@Sun.COM (Bill Nowicki) (09/24/88)
> >About half the time when we try such a mail address, we get back an error > >from the other machine's sendmail saying "I refuse to talk to myself" and > >the user's mail drops on the floor one more time! I fixed this in SunOS sendmail by just adding all the IP addresses to the "w" class. You might have to shuffle around some of the lines in your sendmail.cf to make this work, but it has the advantage that a single sendmail.cf runs on all your machines; no need to hardwire in the addresses. Note the IDA enhancement that allows multi-token class matches needs to also be incorporated for this to work. -- WIN
usenet@cps3xx.UUCP (Usenet file owner) (09/24/88)
In article <287@hal.UUCP>, ane@hal.UUCP (Aydin Edguer) writes: >In article <733@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes: > (...) >>All they know is that they can FTP there but they can't mail there, >>and in their eyes it is my fault, since I'm in charge of mail. >[note: this should never happen on your machine since ftp uses > the nameserver too! Unless your running with improperly compiled > programs.] There are still a few sites out there (like this one) which don't have software for full nameserver support. We're running SunOS 3.5 (yes, we should upgrade to 4.0, but convincing everyone of this, especially when their software would break, is hard). We have a patched version of sendmail that uses the name server; nothing else does yet. So we have the same problem, at least until we convert over to 4.0 (just when is management's decision). So sometimes we need workarounds for these sorts of things. Convincing people around here to upgrade is hard (some machines are still running 2.x!!!). I agree that looking in /etc/hosts could slow down the conversion process (to nameservers); however, we aren't really going there right now anyway. Anton Rang DISCLAIMER: All opinions and mistakes are either my own, or those of an alien which has taken over my mind (who knows which?). +---------------------------------------------------+ | Anton Rang (grad student) | "VMS forever!" | | Michigan State University | | +---------------------------------------------------+
usenet@cps3xx.UUCP (Usenet file owner) (09/24/88)
My .sig hasn't been updated in a while!
casey@admin.cognet.ucla.edu (Casey Leedom) (09/24/88)
In article <69882@sun.uucp> nowicki%rose@Sun.COM (Bill Nowicki) writes: > >About half the time when we try such a mail address, we get back an error > >from the other machine's sendmail saying "I refuse to talk to myself" and > >the user's mail drops on the floor one more time! > > I fixed this in SunOS sendmail by just adding all the IP addresses to the > "w" class. You might have to shuffle around some of the lines in your > sendmail.cf to make this work, but it has the advantage that a single > sendmail.cf runs on all your machines; no need to hard wire in the > addresses. Note the IDA enhancement that allows multi-token class > matches needs to also be incorporated for this to work. A much better way of doing this is to properly canonicalize names in your sendmail.cf using $[...$]. $[foo$] will return/substitute the canonical name of "foo", even if foo is an IP address. No wonder you never ran into the $[...$] bug in your sendmail Bill ... :-) Casey P.S. I also toss my vote in on the side of *NOT* munging the name server to grung through /etc/hosts if it fails to get a response for a given name query. So far all the proponents have managed to say is: ``Oh, oh, oh - it's just too much work to find all those names we've added to our local hosts table over the years and add them to a special name server file.'' If you're so bloody well hooked on all those localisms, fine. But don't insist on inflicting your bad management and laziness on everyone else. You couldn't keep track of all the local additions you made to your hosts table, not us. The name server has a perfectly adequate method of dealing with the problem that you've come to us with as has been pointed out several times now. The change that you're asking for is both pointless and detrimental to the conversion to the domain name system. If you have to, grab the latest NIC hosts table, process and sort it, sort yours, and then do a comm(1) to extract your localisms and then put them into a special name server file so your users are happy. P.P.S. The previous P.S. had nothing to do with Bill's note. I'm sure I would never see him arguing for such additions to the name server. He knows better. (Very definitely a sharp cookie that one is.) Bill just got stuck with the Subject line that that discussion has been running under.
zjat02@apctrc.UUCP (Jon A. Tankersley) (09/28/88)
Has anyone successfully gotten Sun named or BIND to work to set up a root-less network? I am trying to set up named/BIND for a network that has no ARPA connections. Is this possible? I need to spoof named/BIND on an internal network. I am going to be following as closely as possible the established configuration for the name server, but we may never get a connection to the ARPA net. If we do, then I shouldn't need to do a lot of extra work to connect. -tank- -- #include <disclaimer.h> /* nobody knows the trouble I .... */