mail confusion

[Derek Martin]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20051104/d2a1e019/attachment-0001.sig>