Re: domain name
On Sun, 2 Sep 2012 14:30:08 -0600
Glenn English <ghe@slsware.com> wrote:
>
> My first real immersion in *nix and networking was with that
> hardware and a pile of O'Reilly books on Internetting. So domain
> names seemed vastly important to me. Apparently, it isn't to anybody
> else: pretty much just a side effect of DNS, it looks like from
> the responses I've gotten here.
>
I would have said so, and I believe I did. It's a matter of 'need to
know'. Other people and computers in other networks need a FQDN to
reach your public IP address(es), you and your network computers don't.
Let me throw another item into the works as an example, one not present
in all networks but present in most home and small business networks:
NAT. My server and workstations all connect to web and other servers
out on the Internet, and those servers all need to know my [single,
fixed] public IP address. Do any of my computers need to know it? No,
my DSL router knows it, and conveniently re-labels all my outgoing
messages with it. None of my computers, not even the server, have any
record of my public IP address, and there's nothing they could do with
it if they did have it. They're all on private IP addresses.
Similarly, none of my workstations need to know any domain name which
can be used to reach the network. I lease about a dozen domains, none of
which are returned by my PTR record. That resolves to a sub-domain of
my ISP, which I never use for any networking purpose. My mail server
knows about the sub-domain, and all my leased domains, as it must
accept mail for all of them, but this is purely an SMTP function. All
the domains have A records which resolve to my IP address, since all
the domains have MX records which need them. Mail servers are
naturally extremely fussy about domain names, but not much else is.
As it happens, I run a full (BIND9) nameserver, purely internally, which
of course exists for no other purpose than knowing host and domain
names. To keep it happy, I've told it to use my main email domain name,
but I could have picked any of them, or even something completely
fictitious. I don't need a nameserver, or at least not a proper one, my
router would do enough of a job for most purposes, but I feel I need to
know at least the basics of running a real nameserver.
So nominally, all my workstations (three or four) are 'in' my main email
domain, but this has no actual meaning to them. To make full use of the
nameserver, they all need to know the local search domain
(in /etc/resolv.conf of the Linux machines), which will be appended to a
bare hostname, but they don't use this domain name for anything but
their own nameserver lookups. If I didn't run BIND (or an equivalent),
all the computers would need to be in each others' /etc/hosts, a file
that even Windows computers have, but only by hostname, not FQDN. In
that case, I wouldn't need a domain name anywhere in the network other
than in the SMTP server.
I've tried to convey here the independence between a small
NAT-connected network and the URL(s) used to reach it from the
Internet. A local domain name is much more important for networks which
have multiple public IP addresses and a dedicated (actually at least
two) public DNS server, but these days it's only fairly sizeable
businesses which have to operate that way. Most small and medium
businesses are fine on a single public IP address, with a few DNS
records at their domain host. And even in what appears to be a fully
public network, the chances are that the real physical machines are
on private IP addresses behind one-to-one NAT and have completely
different hostnames from their public URLs...
--
Joe
Reply to: