Path: utzoo!utgpu!water!watmath!clyde!att-cb!osu-cis!tut.cis.ohio-state.edu!rutgers!aramis.rutgers.edu!porthos.rutgers.edu!pleasant From: pleasant@porthos.rutgers.edu (Mel Pleasant) Newsgroups: news.admin Subject: Re: Registered sitenames Keywords: registered hostnames, domains, maps Message-ID: Date: 3 Apr 88 21:36:56 GMT References: <1590@sigma.UUCP> <4750002@hpscdc.HP.COM> <3191@hammer.TEK.COM> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 66 To: jeff@hammer.UUCP 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