Glenn English wrote:
> My first real immersion in *nix and networking was with that
> hardware and a pile of O'Reilly books on Internetting.
A good start.
> 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.
Right. But remember that computer systems have existed for a lot
longer than the Internet. Remember way back in the day before
networking they would not have had domain names. And yet they had
computers and they had email. (Remember all of those '!' email
routing paths?) So by reasoning we know that computers do not
intrinsically require domain names to operate. It is only some
software programs that need it.
The domain name system is very much analogous to a telephone directory
such as a phone book. To call someone you need their phone number.
You start with their name. You also know their city. You look their
name up in the phone book for that city. You find their number. You
call their number. DNS is similar. You start with their name. You
also know their domain name (the city part). Look up their name for
that domain in DNS. Find their IP address. Connect to their IP
address.
A home network is similar to a business PBX phone exchange. If you
have a site PBX then that would be very similar to a site network.
You could call from one phone to another phone with a local short
digit number. But to call outside the site (in the US) you would need
to supply the full ten digit dialing. But for local PBX calling you
wouldn't need the full number with area code and prefix but perhaps
just the room number. This is very typical for schools and
businesses. Almost the same thing as local networking.
> Bob Proulx wrote:
> >> I never had a problem with the hostname. It was the domain name
> >> that was making me crazy.
> >
> > But you can't talk about one without the context of the other. :-)
>
> Sure I can. The hostname is something I create all by myself; the
> domain tells the universe, via /etc/hosts or DNS, how to get to the
> host. They're connected, but I can think about the two independently.
Not quite. /etc/hosts is only useful for your host local system. It
does nothing for me to connect to your host on my system. My system
will never see any changes you make to your /etc/hosts file. The
contents there are not relevant to me or anyone else in the world.
DNS on the other hand is relevant to me and the world. But that isn't
stored on your computer. It isn't in the /etc/hosts file. It is in
DNS. DNS is a distributed database. The space is split up into a
zillion nameservers. Each nameserver is authoritative for the domains
they are listed. These are usually on other hosts out on the 'net.
In order for you to set up a server that I could connect to then you
would need to register DNS zone data mapping a name to an IP address
in the domain name system. It is a large lookup tree. At the top are
the 13 top level nameservers that do nothing but delegate queries to
lower servers that are authoritative for that domain.
$ dig example.com ns +short
a.iana-servers.net.
b.iana-servers.net.
That query went out to the top level nameservers. I asked for the
nameservers that were authoritative for example.net. Back came the
answer. Now I can query one of those nameservers for the IP address
of the host that I want.
$ dig @a.iana-servers.net. www.example.net a +short
192.0.43.10
Of course that is the same as having the tool do everything for you
all at once. It is the same. But the above shows the individual
steps along the way.
$ dig www.example.net a +short
192.0.43.10
I also like the host command for this too:
$ host www.example.net
example.net has address 192.0.43.10
example.net has IPv6 address 2001:500:88:200::10
Domain names allow me to look up the IP address of other systems. But
they are not too meaningful on my local system.
Domain names are important for interactions between systems such as
for sending email. The mail transfer agent (Postfix) needs to know
how to handle the header tracking lines and the return address on the
message. But if a local system root process sends email to root and
it forwards to you as the local user on the machine then the domain
name won't matter since it is all a local interaction on the local
machine.
But try to send an email from the local machine to my machine and then
because spammers make the internet a hostile place the email must have
a properly formatted reply address (and meet other criteria) or my
site will reject it. Then domain names are very important. But only
important to the mail transfer agent Postfix and not to anything else.
> > I have actually looked at the source code to hostname. It has been a
> > while so I refreshed my memory just now. Basically it does this:
> >
> > gethostname(buf, buf_len)
> > hints.ai_flags = AI_CANONNAME;
> > getaddrinfo(buf, NULL, &hints, &res)
> > printf("%s\n", res->ai_canonname);
> >
> > That looks up the hostname. Gets an IP address. Due to hints having
> > AI_CANONNAME it causes the resolver library to include the reverse
> > lookup of the IP address back to a name. It then prints that name.
>
> That's certainly less than optimal. I claim that code is an excellent
> example of why the domain name should be available from a struct in the
> kernel. Or at least from a disk file.
Those in the camp that believes that way would make the hostname the
FQDN so that there isn't any need for any DNS lookup. Most software
will use any domain name set as the hostname for the domain name. But
it is program by program dependent. Postfix does this for example.
But there are no absolutes. Every program may be written uniquely
different. Bugs abound.
> > I am sorry for the vague hand waving where I thought hostname -f got
> > the IP address to look up from what was actually configured. I
> > thought it did.
>
> I claim it does. It gets the info from the configuration of a DNS server
> on the other side of the continent. Over a 300 baud dialup :-)
>
> Or from /etc/hosts, if told to hit hosts before DNS??
/etc/hosts should definitely be configured before dns in the
/etc/nsswitch.conf file and therefore will be searched first.
> > This is one of those times where I think in general that the
> > recommended config of a short hostname is good. But knowing how
> > things are actually working inside the box I also know that it is okay
> > to set a fully qualified domain name there regardless of what the
> > documenation says.
>
> I think I remember setting the FQDN in hostname and seeing the entire
> FQDN in the shell prompt.
That depends upon what you use in PS1. If you use \u@\h which is
typical then you won't. But if you use $USER@$HOSTNAME then you will
because $HOSTNAME is hostname which would be the FQDN in that case.
What you put in your PS1 is up to you.
In the bash man page for PS1 "PROMPTING" section:
\h the hostname up to the first `.'
> That made me think hostname wasn't the place
> for the FQDN. But that may have been a couple versions ago.
It isn't wrong. It is just telling it like it is. And like you
configure it. You can put anything you like in your prompt. It is a
matter of personal preference.
> >> AFAIK, it's the only
> >> place, outside of some server configs, where the domain name is mentioned.
> >
> > Some server configs? That is pretty vague! :-)
>
> Here I wanted to say that hosts was the only place the *system* got
> the domain. And several servers got the domain that particular
> server was interested in from their own configs. I didn't know at
> the time that *all* of them did because there's no (civilized)
> system call to get the domain.
The real problem is that there isn't any such thing a "The Domain
Name". The answer is always "it depends". It depends upon what you
want it for, when and where you want it, and what strategy you are
using in your environment.
For me the system default domain name would be the one that would be
appended to "foo" if I were to "ping foo". So for my strategy I want
to know what "search" path is configured in /etc/resolv.conf. But I
think equally valid and reasonable for others would be to default to
the domain configured in /etc/mailname because that would be the
domain name used when sending email. And I am sure there are other
possibilities too.
> > But sometimes it is simpler to list the public IP on an always
> > connected server host. Simpler is usually better so I like
> > simpler. But using the public IP isn't as general. It has
> > problems for mobile devices for example. And so the 127.0.1.1
> > technique was created.
>
> Like I said, I've learned this stuff from the vantage point of
> configuring servers. They need hard core IPs. I like simple too:
> there isn't so much this senior citizen has to remember :-)
And a lot of people configure everything using public static IPs.
Which is why I mentioned it. If I hadn't then certainly I would have
been called out as missing that very large population. It is fine.
But it doesn't work well for laptops or other mobile devices.
Eventually you will play around on a laptop or tablet or something and
find the problems and then you will appreciate the 127.0.1.1 solution.
But sometimes other software doesn't play well with 127.0.1.1 or
127.0.0.1 either. In those cases the public IP configuration will
work around their issues.
> > That isn't to say that using 127.* isn't sometimes troublesome. In
> > cases where network software is trying to pass around IP addresses the
> > technique doesn't work. Or rather the software that is trying to pass
> > around IP addresses is broken. But if that is a proprietary CAD/EDA
> > program for $100k then you probably won't get it fixed and working
> > around it is easier. If it passes around IP addresses then it will
> > pass over to its peer 127.0.1.1 (same problem if it were 127.0.0.1
> > too) and the peer won't be able to connect back. What it *should* do
> > instead is pass around the hostname or FQDN so that the peer can use
> > it to connect back.
>
> Oh dear! That's not how TCP Illustrated describes things.
Are you sure? It has been a while since I read it. I don't recall
that there. And I am not going to pull it down from the shelf to scan
through hit looking now. I will simply challenge it in absentia based
upon fading memory. :-)
> If both the 127* == localhost and the IP == FQDN are declared in
> hosts, wouldn't the software work no matter how it's written?
In a word, no. But it does depend upon how the software is coded.
But not in my experience.
Example: A system named "foo" with the following in /etc/hosts. (Yes,
I did try this example.)
127.0.0.1 localhost
127.0.1.1 foo.example.com foo
192.0.43.10 foo.example.com foo
This will return the following:
$ getent hosts foo
127.0.1.1 foo.example.com foo foo
192.168.230.110 foo.example.com foo foo
$ ping foo
PING foo.example.com (127.0.1.1) 56(84) bytes of data
So ping, and most software, would use the first IP address in the
list. If it exchanges that address with a network peer host then the
network peer host will try to connect using 127.0.1.1 and loop back to
itself. Instead it should pass along a FQDN. But then of course it
must determine a useful FQDN to pass. And that isn't trivial. Which
is why the program authors are often slack and pass along an IP
address instead. Which works if they are on a system using statically
configured public IP addresses. But fails if on a 127.0.1.1
configuration such as works on mobile devices.
I pointed to Spring RTS as an example of popular free software
available to anyone that does this as a real life example. But mostly
I have had this problem with 100k dollar CAD/EDA software. This type
of thing happens a lot in that area. And there is no hope of fixing
it there.
Now take that same example "foo" configuration but use public IPs.
(Yes, I did try this example.)
127.0.0.1 localhost
192.0.43.10 foo.example.com foo
This will return the following:
$ getent hosts foo
192.168.230.110 foo.example.com foo foo
$ ping foo
PING foo.example.com (192.168.230.110) 56(84) bytes of data
Other hosts on the LAN can connect. This is much more of the
traditional original BSD networking configuration. It is perfectly
valid on always online servers. It works. But not well for mobile
devices.
> > I don't intentionally lead people astray. But sometimes
> > errors do creep in.
>
> Are you implying here that you're a mortal, Bob :-)
No. I am implying that I am Socrates! All men are mortal. Socrates
is a man. I am mortal. Therefore I am Socrates. :-)
> It seems to me that /etc/hostname is the simplest and most reasonable
> place to store the domain name. It works pretty well, but Debian says
> not to do that, so I feel they may (inadvertently?) do something that
> breaks big time if I use that file.
Personally I am going to stick to putting my default domain name in
the /etc/resolv.conf "search" path. I am going to do it via the
/etc/network/interfaces file's "dns-search example.com" resolvconf
package interface for static servers. And by DHCP for mobile devices
like laptops. If I look up "foo" then /etc/resolv.conf's search path
configures what domain will be appended to it for DNS lookup and for
me that is my default domain. In order to keep email sane I am going
to configure a FQDN as the myhostname variable for Postfix in the
/etc/postfix/main.cf file. I am also going to configure both the
hostname and the FQDN as 127.0.1.1 in the /etc/hosts file. YMMV. But
that is what I am going to keep going. :-)
> I think I'm going to stick with /etc/hosts -- and be sure to keep hosts
> the first place for the resolver to hit. It's more complex and more obscure,
> but I have faith it will keep working.
I don't consider it obscure at all. (smile!)
> Wait a minute. Bob, if hostname -f is hitting the resolver, that FQDN in
> /etc/hostname is never going to see the light of day, is it? Or does
> something else use it?
The /etc/hostname is only used by the /etc/init.d/hostname.sh script
at boot time for sethostname(2). It isn't used for anything else.
The 'hostname -f' is going to take the gethostname(2) value and look
it up in DNS for an IP address and the reverse PTR record for that IP
addrses and get *a* FQDN name back from DNS.
Bob
Attachment:
signature.asc
Description: Digital signature