Re: domain name
Let me try to explain my ignorance.
In my mis-spent youth I worked on radio stations. I was
obsessed with audio (tape recorders, microphones, etc.)
In the middle 1970s, digital started creeping in -- I was
at an Audio Engineering Society convention and saw one of
the first digital tape recorders. Several racks of equipment.
I had no idea of what was going on inside, so I quit my job
and got a degree in Computer Science in 1980. I found that
computers are as much fun as tape recorders, so I became a
computer geek.
I spent the next few years on embedded systems and minis and
desktops, but there wasn't a word about networking in what I
was working on or in the classes I'd taken.
Now I'm a retired computer geek, and I decided I wanted to play
with the Internet. So I've got a little Internet node downstairs,
running on Linux.
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.
It still seems pretty important to what I'm doing: 100% networking.
The rest of computing is a lot like the CP/M and RT-11 and MS-DOS I
was used to. Yeah, *nix is a little slicker...
So, back to the domain names:
On Sep 1, 2012, at 5:15 PM, 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.
> 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.
>>> That may be okay for a very large number of
>>> typical systems but it is also completely incorrect for many valid
>>> systems with more IP addresses than just one and more network
>>> interfaces than just one.
>>
>> I've got systems with more than one interface, and I've never run into
>> that problem.
>
> I just got confused. What is the exact problem being referred to at
> this moment in the conversation? *I* am not having any problems. I
> thought you were? And now you say that you aren't. I'm confused.
I read you to say that <whatever we were talking about at the time>
could cause problems with multiple IPs or interfaces. And I was trying
to say that I hadn't run into that trouble. I suspect that may be just
because I haven't gone down that path yet.
> 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??
> 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 made me think hostname wasn't the place
for the FQDN. But that may have been a couple versions ago.
>> 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.
> If *I* were writing it I wouldn't store this information in the kernel
> at all. The kernel doesn't need it.
No, but a lot of its friends do :-)
> I would store it in a file on
> the filesystem and have the libc routine look it up from there.
Yeah, that'd do fine, IMHO. Like /etc/hostname or /etc/hosts...
> Hmm... It is kind'a a good idea in most situations.
> 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 :-)
> 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. If both the
127* == localhost and the IP == FQDN are declared in hosts, wouldn't
the software work no matter how it's written?
>> And it can cause troubles when the host is a server on the 'Net with
>> a static IP and a domain.
>
> I have no idea what you are meaning here. It is pretty vague. Could
> you say a few more words describing the problem?
No. I don't remember what I was talking about.
> People start with a problem and then try various implementations to
> solve the problem. That is good.
If it's documented :-)
>> Or might it be more efficient to have a localhost IP to use
>> for internal tasks??
>
> Now there you have mentioned an interesting historical facet!
> (Interesting to history buffs such as myself anyway.) If a system has
> a public IP address configured then these days using TCP to talk to it
> will be almost as efficient as talking to the loopback device.
>
> $ ping -c 10 localhost
> $ ping -c 10 $(hostname)
>
> Today that should be almost the same.
I tried that on my LAN server, and they were the same to 4 digits:
> --- lanserver.slsware.lan ping statistics ---
> 10 packets transmitted, 10 received, 0% packet loss, time 8999ms
> --- localhost ping statistics ---
> 10 packets transmitted, 10 received, 0% packet loss, time 8999ms
In a couple other tests they varied in the 4th digit. Close enough...
I guess we don't really need localhost anymore, except maybe for old
software?? (And old habits...)
> I don't intentionally lead people astray. But sometimes
> errors do creep in.
Are you implying here that you're a mortal, Bob :-)
Like you and Einstein, I like to know when I'm wrong so I can change
and no longer believe false ideas. This question seemed so simple when
I asked it. But a bunch of false ideas in my brain and a whole lot of
*nix badness has showed up in the responses.
One very important bad datum I just got rid of: I thought Debian didn't
have flaws. I thought that when they fixed a bug or changed a procedure,
they cleaned up the code. Oh, well. At least they commented it out.
Thank you all.
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.
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.
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?
--
Glenn English
Reply to: