On Fri, Nov 04, 2005 at 11:07:34PM +1030, Tim wrote: > On Thu, 2005-11-03 at 13:41 -0500, Derek Martin wrote: > > I don't think you've provided any substantial reason why for a > > stand-alone network, one is required. And I assert that you will not > > find one. Though I've been wrong before... ;-) > > I'm sure someone could come up with a reason for a need for one, I'm sure they won't. ;-) I'm not saying they're not useful... obviously they are. But as for it being a technical requirement, there just isn't any. Except for broken software. Maybe I haven't stated my points clearly. For point of clarification, by "broken software" I mean software which imposes an artificial technical limitation on its user, which does not exist outside the constraints of that software. To clarify even further, TCP/IP networking does not in any way require FQDNs to work properly (see below for more on that). Therefore any software which absolutely mandates the use of FQDNs is broken, by the above definition. And that is true even if not using FQDNs is generally nonsensical in the usual case, to which I will stipulate. It remains true that, if I have my own personal TCP/IP network with no connection to the outside world, nothing will stop it from working properly without the use of FQDNs, except possibly for artificial limitations imposed by the application software. It is even true that in most cases, it will work just fine on the public Internet as well, without locally using FQDNs for hostnames. The only exceptions to this are when using protocols that are intended to be multi-site, which are specifically designed to make use of DNS as a means of identifying the remote site uniquely. In most cases, this is done for reasons of authentication. It has already been shown by security researchers that relying on DNS information for host authentication is folly... so one can argue that this is an exception which should not exist, and should be fixed. But that's really beside the point. > I certainly find having a local network domain name useful. Of course. I never said it wasn't useful. But if you're smart enough to realize the utility, why wouldn't you also be smart enough to realize that you should get your own, legitimate domain? It's not exactly expensive... so it's hard to argue that the cost is prohibitive. If you can afford the thousands of dollars to have the multiple computers neccessary to constitute a network (it ain't a network unless there are at least two computers involved), chances are you can afford a few bucks every year (or two) to register your own domain. Remember also that my original point was primarily that under no circumstances is there any technical need for 127.0.0.0/8 to have a FQDN associated with it. It simply doesn't, and no matter how useful domain names are, that won't change. The purpose of that interface is solely to refer to one single machine, which can not possibly connect to other machines, so there is no sane reason why it should ever need a FQDN. The only reason it needs a name at all is because "localhost" is a lot easier to type than the IP address... I only extended the argument to non-loopback interfaces because you insisted that a reserved domain name is needed for local networks; I don't agree, so I followed throuh to make the point: even when you ARE internetworking with a bunch of other machines, an FQDN is not strictly required. The entire DNS domain space was a construction that was created solely to make things more convenient for humans, because remembering hundreds or thousands of IP addresses is difficult (or impossible) for us. TCP/IP only cares about two things: IP addresses, and routes to get there. For local networks, DNS is utterly and completely unnecessary, and so too are FQDNs. If this were not true, MS Windows networking, which historically relied on netbios for name resolution and did not use DNS or FQDNs, would never have worked at all... But, while I won't comment about how WELL it worked, it did in fact work. ;-) If you want to use a reserved domain for this purpose, there are several already, you're free to use one of those. But I think that's a bad idea. It's a lot of needless configuration, and if you should need to connect those systems to the net later, you'll just need to do it all over again. Better to have some forsight and get a real domain. > Having a domain name also avoids the nonsense you get when you call your > mail server "mail" (sans-domain name) and your ISP does the same silly > trick. So use IP addresses instead. :-D [Yes, sendmail allows this, if configured properly, though no sane person would ever do it.] > Since having a domain name is the norm, as far as internet-style > networking is concerned. I'd say it's a bit of a bizarre want to > avoid them. Well, at the risk of sounding like a broken record, to sum it all up: If you are not participating in the public Internet, there simply is NO NEED to have one, and I can't even think of a useful purpose that it serves to have a fake one, if your network consists of only a handful of hosts. So if you are avoiding registering a legitimate one for some valid reason, you may as well not use one at all, and stick to hostnames only. If you ARE participating in the public Internet, you should have a LEGITIMATE domain. None of this necessitates a FQDN for 127.0.0.1, and nothing ever will, other than broken software. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D
Attachment:
pgpegAhQguTB7.pgp
Description: PGP signature
