jeff@hammer.TEK.COM (Jeff Beadles) (04/03/88)
In article <4750002@hpscdc.HP.COM> garyg@hpscdc.HP.COM (Gary Gitzen) writes: >>It also means that if there is another machine on the net with your >>site name on it, you'll never see postings from it, so you may never find >>out they exist. Unfortunately, the code is deeply ingrained in the net, so >>it's rather hard to change. > >Sounds like a good reason to register one's sitename. If newsfeeds were >routed only to registered sites, the problem wouldn't occur. > This has one very obvious flaw. There are hundreds of machines that exist within domans. Many of those machines are not 'in the maps'. Does this mean that we have to add all of the hosts that are within a domain to the already huge maps? I can't see the advantage of doing this. ------------------------------------------------------------------------------- | Jeff Beadles IDG Customer Support Center Tektronix, Inc. | | jeff@tekcsc.MKT.TEK.COM -or- POB 1000 | | ...!tektronix!tekcsc.MKT.TEK.COM!jeff Wilsonville, OR. 97070 MS 63-171| -------------------------------------------------------------------------------
woods@hao.ucar.edu (Greg Woods) (04/04/88)
For a domain with many sites, only the one site that imports news to the domain, and the domain itself, need to be registered. That way any mail to any site within the domain is simply mailed to the one registered site for that domain (which is responsible for delivering it within the domain). For example, there are a couple of dozen sites in our "ucar.edu" domain, but only "ncar" is registered in the maps. --Greg
pleasant@porthos.rutgers.edu (Mel Pleasant) (04/04/88)
In a previous message someone describes the well known problems and symptoms of a new site apearing in USENET with a name that duplicates another already in use by some other site. In response, Gary Gitzen (garyg@hpscdc.HP.COM) points out that if a site registered its name and if registered sites would only pass news onto other reigstered sites, the problem would go away. Jeff Beadles then goes on to say that: > This [Gary's suggestion] has one very obvious flaw. There are hundreds of > machines that exist within domains. Many of those machines are not 'in > the maps'. Does this mean that we have to add all of the hosts that are > within a domain to the already huge maps? I can't see the advantage of > doing this. The answer to the question is a resounding *no*. What is flawed however is the implementation of the use of a domain. One thing must be done such that everything works out smoothly for you, your neighbors and the map database. One way or another, all sites within a domain must use fully qualified names in all news and mail headers. This includes the Path: header in news articles as well. The only exception might be the n sites acting as UUCP/domain gateways into your domain. The whole point behind acquiring a domain is to allow you to choose whatever names you like for your hosts. By appending the `.domain' to your names, the names you choose become unique because your domain is unique to you. BUT, your names are only unique with the domain appended to them!! There are lots of `sites' out there that have acquired a domain. None of the documentation surrounding domains gives any indication as to the magnitude of work that goes into using a domain effectively. Herein lies the rub!!! If you're looking to acquire a domain and solve your naming problems once and for all, be prepared to a) modify *all* of your mail systems, NOT JUST YOUR GATEWAY MAIL SYSTEM; b) modify *all* of your news systems, NOT JUST YOUR GATEWAY NEWS SYSTEM. You really want fully qualified names to appear in *all* mail and news headers and to be so generated by *all* of your systems. Until all names appear as fully qualified host.domain names, some new site can come along and bite you by using one of your internal names. Jsust in case anyone missed it, the operative word throughout what I've just stated is `all.' Conceptually its simple enough. However, its a real pain in the ass to convert all of your systems. The political realities may make it nearly impossible to do. But, from experience, try your hardest to include as much as you can under that word `all.' Someone `installing' a domain does has some choices in all of this. The choices will require about the same amount (e.g. lots) of work for the initial installation. There are two practical choices really. Most of the rest are some combination of these two. The first is more or less spelled out above. Namely, modify all of your systems such that the names generated are fully qualified everywhere. The 2nd choice is to is to generate addresses as if all of your users on all of your systems have mailboxes on your gateway system. Then, the only host name that need appear in mail/news headers outside of your domain is the name of your gateway system. It is very likely however, that your internal systems will have to flag messages in such a way that your gateway system can recognize them as being internally generated thereby distinguishing them from the rest of the pack. Obviously, you can create a list of your internal systems on your gateway machine. However, if you're a large `site' (as in a univeristy), where you might not even know when new internals systems have come on line, you'll need some other method of identifying your internal sites to your gateway system. This will most likely involve your internal sites identifying themselves to the gateway system instead of your gateway system attempting to identify them by dead reckoning. As you can see, with either choice there is much work to be done. Good luck!! -- Mel Pleasant {backbone}!rutgers!pleasant pleasant@rutgers.edu mpleasant@zodiac.bitnet
wcs@ho95e.ATT.COM (Bill.Stewart.<ho95c>) (04/04/88)
In article <90@ncar.ucar.edu> woods@hao.UCAR.EDU (Greg Woods) writes:
: For a domain with many sites, only the one site that imports news to
:the domain, and the domain itself, need to be registered.
That helps a lot, but it doesn't do the whole job. For
instance, what if you have local machine named "b.ucar.edu", which you
address locally as "b", and I register a machine named "b".
If you get a mail message for "joe@b" or "b!joe", who do you send it to?
Domains help, but they only solve the problem if everyone has one, and
if all transactions always use them.
--
# Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
# So we got out our parsers and debuggers and lexical analyzers and various
# implements of destruction and went off to clean up the tty driver...jerry@oliveb.olivetti.com (Jerry Aguirre) (04/05/88)
In article <Apr.3.17.36.56.1988.9857@porthos.rutgers.edu> pleasant@porthos.rutgers.edu (Mel Pleasant) writes: > One way or another, all sites within a domain must use fully >qualified names in all news and mail headers. This includes the Path: >header in news articles as well. The check against sending an article to a site already in the path is simple to bypass for anyone who has a real need to do so. The software simply compares the first field of the NEWSDIR/sys entry to each site listed in the path line. So an entry like: oliveb:comp,sci,...world:F would not send an article that has "oliveb" in the path but an entry like: oliveb+:comp,sci,...world:F:/usr/spool/batch/oliveb would send them because "oliveb+" would not match "oliveb". So anyone concerned about duplicate site names and willing to pay the costs of any resulting duplications can modify their sys file without changing the software. I have seen a case where a duplicate name was causing articles to not reach a site. There are two sites named "sun" on the net. I post "ihave" messages to one of the systems and while checking the articles in its sendme messages I found that every article from "sun.soe.clarkson.edu" was requested. Without the ihave messages there was no way for them to ever reach "sun.uucp". The suggestion that sites use a fully qualified domain name in the path header line brings up several ramifications. If I was to start putting "oliveb.olivetti.com" in the path line then my neighbors would start sending those articles back to me. This is because their NEWSDIR/sys entries have "oliveb:" in them, not "oliveb.olivetti.com". Obviously any such change would have to be coardinated with them. With the current software it is possible to ease the transition by having an entry like: oliveb/oliveb.olivetti.com:comp,sci,... which would catch both forms of the name. This would of course defeat the purpose of the domain as it would still not send anything with "!oliveb!" in the path so if there was another "oliveb" I still would not see their postings. Assuming I changed my path entries to be "oliveb.olivetti.com" and my news neighbors changed their sys files to match only on that string then the unique path test should work correctly. But that will leave somewhat of a mess. An entry like: oliveb.olivetti.com:comp,sci,...:F is going to put the batch output in a rather strange place. Certainly one not very useful to sendbatch. Of course you can manually specify the pathname to batch into. (Unless you want to run ihave/sendme.) Using full domains in the path is also going to make it several times longer. I am not against the idea but I think that practical implementation is going to require some changes in the news software to better support this. Perhaps the simplest is to provide a separate control of what is tested against the path line and what is used to generate the 4th field of the sys entry. By example if: oliveb/oliveb.olivetti.com:comp,sci,...:F Were redefined to use the first name "oliveb" for path and command generation and only test the portion after the "/" against the path then the changes would be minimal. Another alternative is to have the software truncate on the "dot" when generating the path/command. Certainly there is more to this than just having inews put your full domain in the path. Jerry Aguirre
woods@ncar.ucar.edu (Greg Woods) (04/05/88)
In article <2098@ho95e.ATT.COM> wcs@ho95e.UUCP (46323-Bill.Stewart.<ho95c>,2G218,x0705,) writes: >For instance, what if you have local machine named "b.ucar.edu", which you >address locally as "b", and I register a machine named "b". >If you get a mail message for "joe@b" or "b!joe", who do you send it to? You can't have a domain named "b", nor anything else that I could name a machine here. All domains (except phony ones like "uucp") have at least one period in them. This makes them clearly distinguishable from a local machine name. Thus in your example, without question I send it to our local machine "b". You COULD conceivably have a domain named "b.edu" or "b.com", but even then "b.com!joe" would be clearly distinguishable as non-local while "b!joe" is local. I can only get in trouble if one of my local machine names matches one of the sites that I have a direct uucp link to. For example I can't name a ucar.edu machine "b.ucar.edu" if I also have a uucp link to a site whose uucp name is "b", or else "b!joe" WOULD be ambiguous. Fortunately even a backbone site like us has only a dozen or so uucp links, so that just means a dozen names we can't use. Note that only DIRECTLY-CONNECTED uucp links have this problem, not every name in the map. Not too hard for any halfway responsible site to avoid. --Greg
henry@garp.mit.edu (Henry Mensch) (04/05/88)
wcs@ho95e.UUCP (46323-Bill.Stewart.<ho95c>,2G218,x0705,) wrote:
-> That helps a lot, but it doesn't do the whole job. For
->instance, what if you have local machine named "b.ucar.edu", which you
->address locally as "b", and I register a machine named "b".
->If you get a mail message for "joe@b" or "b!joe", who do you send it to?
->Domains help, but they only solve the problem if everyone has one, and
->if all transactions always use them.
I thought this was pretty easy; the message gets delivered to
joe@b.ucar.edu. Can't hold everyone else responsible if you don't do
the right things and get a true domain name ...
# Henry Mensch / <henry@garp.mit.edu> / E40-379 MIT, Cambridge, MA
# {ames,cca,rochester,harvard,mit-eddie}!garp!henry