FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Kubuntu User

 
 
LinkBack Thread Tools
 
Old 09-01-2012, 10:25 PM
Glenn English
 
Default domain name

On Sep 1, 2012, at 3:53 PM, Bob Proulx wrote:

> It turns out that this is configurable.
>
> man host.conf

This is interesting. man host conf says:

> order This keyword specifies how host lookups are to be performed. It should be followed by one or more lookup methods, separated by commas. Valid methods are bind, hosts, and
> nis.

If I set the order to hosts dns nis with Webmin, the /etc/host.conf doesn't
change; /etc/nsswitch.conf does:

> hosts: files dns nis

There seems to be more than one way to set this order...

--
Glenn English




--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: C464AC57-725E-4667-91A4-F457DBA4C287@slsware.com">http://lists.debian.org/C464AC57-725E-4667-91A4-F457DBA4C287@slsware.com
 
Old 09-01-2012, 11:15 PM
Bob Proulx
 
Default domain name

Glenn English wrote:
> Bob Proulx wrote:
> > Debian sets the hostname from /etc/hostname.
>
> 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. :-)

And confusingly NIS/yp also talks about domain names but means
something completely different! So beware of the context of the
discussion or it may take a turn into a different area.

> >> and not from the "kernel.domainname = "
> >> line in /etc/sysctl.conf? ("kernel.domainname = example.com" is
> >> that line, commented out, in my recently installed squeeze.)
> >
> > Definitely not.
>
> Apparently not :-) I tried, but couldn't get it to have any effect
> on anything. It does make me wonder, though, what that line is doing
> there. It looks like it should (used to?) set the domain name...

I have no idea why that is there. I don't know what nook that
configures. I would let it lie dormant. It might be some legacy
xerox or token ring network interface for all I know.

> > DNS is used for the ill conceived 'hostname -f' option. Whoever wrote
> > that code should be stripped of any street cred. It is terrible.
>
> It may be terrible code, but that doesn't seem to be how it works
> here. hostname -f returns the fqdn of the host in question, even if
> its DNS server is set incorrectly (/etc/hosts is correct, and I've
> set the resolver to look first at hosts, then DNS).

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
", 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.

I previously said that it got an IP address from the machine with some
vague hand waving about the first one it finds because I wasn't sure
how it got it. But it doesn't look at the actual system. It simply
does a DNS lookup of the hostname. This doesn't change the fact that
a host may have multiple IP addresses and each of those will have
hostnames associated with them.

I just tried an experiment to verify this behavior. I changed the
hostname of a system to another machine that had both forward and
reverse DNS set correctly. Doing nothing but changing the hostname to
the short name of the other machine caused 'hostname -f' to return the
fQDN of that other machine. Really 'hostname -f' is operating
entirely on domain name information and nothing more.

> > 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'm guessing that's just because I've always set up eth0
> to be the 'Net facing interface. A long time ago, I wrote a big shell
> script to init iptables, and the way it's written, eth0 *has* to point
> to the 'Net. Just lucky, I guess :-)

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. But looking at the hostname code it I see that it
simply does a dns lookup of the hostname. Sorry for the diversion
into the weeds on this part of the topic.

> > Note that a perfectly valid configuration may specify the hostname as
> > a fully qualified domain name. Many BSD systems are set that way.
> > And BSD is the progenitor of networking.
>
> Yup. But the Debian dox say very clearly not to do that. It does seem to
> work pretty well, though. I've set up several machines that way.

I usually recommend to follow the documentation. Except when I
recommend the opposite. :-)

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.

> > If all you changed was /etc/hosts then it is likely that your change
> > is incomplete.
>
> Quite possibly, but it seems to have done the job. AFAIK, it's the only
> place, outside of some server configs, where the domain name is mentioned.

Some server configs? That is pretty vague! :-)

But probably in the MTA configuration for sure. And I would count
that as being in the set of "some server configs". (chuckle)

> > Also, what mail transfer agent are you using? Postfix? Exim? Almost
> > certainly one of those will need a tweak too.
>
> Postfix. And there's a domain name in its config for sure.

Yes. That is the primary need for domain information.

> > Because it pulls together information from several different and
> > independent programs that are not related to each other except by all
> > running on the same machine.
>
> That's very true. But if I were writing all that stuff, the host's domain
> name relevant to TCP/IP would be in one place, and everybody would go there
> (or to a kernel call) to get it.

If *I* were writing it I wouldn't store this information in the kernel
at all. The kernel doesn't need it. I would store it in a file on
the filesystem and have the libc routine look it up from there.

> It's all too easy to have the kernel and
> Postfix thinking they're running at different domains.

Since the kernel doesn't care if I replace "kernel" with "general
config outside postfix" then I would counter that it is a perfectly
valid configuration. I can think of a lot of hosts that handle mail
for other sites and that type of thing is normal standard operating
procedure.

> > Many modern systems associate the hostname with 127.0.1.1
>
> I ran across that -- IIRC, it's supposed to be what I put in hosts
> when the host's IP is dynamic or it has no domain. And it can cause
> troubles when the host is a server on the 'Net with a static IP and
> a domain.

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.

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.

For something a little more fun I have seen this problem with the
Spring RTS game too. It is why the lobby and the game host needs to
be on different machines. If on the same machine then clients can't
connect since they are handed a 127.* address instead of the correct
remote peer address. And that is in a free software game! The code
is there (somewhere) and could be fixed. :-) But it is extremely easy
to work around too and so there isn't a very deep itch to scratch.

> 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?

> > And alternatively using 127.0.0.1 is problematic because then instead
> > of the desired name 'hostname -f' would return "localhost" or possibly
> > "localhost.localdomain" depending upon what is in /etc/hosts.
>
> Seems to me it should return "localhost" in that case, because 127.0.0.1
> *is* localhost.

Yes. On Debian. But on Red Hat (at least at some point in the
history if not now) it used to be localhost.localdomain there.
Probably even on Debian at one point. This is an area that hasn't
been completely stable over the years.

People start with a problem and then try various implementations to
solve the problem. That is good. And I think we have matured to the
point where it is relatively well understood by operating system gurus
who are assembling a software distribution. (I said it like that
because we have already discussed that it might not be particularly
well documented. But the people who need to know the most have
figured it out. I think.)

> > The localhost.localdomain is a hack / trick to make all of the system
> > configuration internally consistent with a private configuration in
> > isolation from a public network. That's great. But if you have a
> > public name and IP address then you would use it instead.
>
> Depending of whether you wanted to talk to yourself or somebody outside
> the host??

If you refer to localhost or localhost.localdomain for software that
insists upon having a fqdn then it will successfully talk to itself.
If you talk to other systems such as www.debian.org then it will talk
successfully there too. But if you were to set up an apache web
server and try to server web pages then using the fqdn URL of
http://localhost.localdomain/ would only work from the local system.
You wouldn't use it from other systems. They would end up connecting
to themselves. From other systems for services like that you would
need to assign and configure a name and IP address known outside of
the localhost.

> 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. But in the old days the one
that needed to go out to the network card was slower. It had to pass
through more network code layers. The data would actually travel
through the entire software stack to the network card, ping there, and
then return. It was noticeably slower. This was one reason why BSD
Unix domain network sockets were used for things like X window
communication on the local host. It was hugely faster. Since then
that path of code down to the network card has been optimized out as
useless extra work. So today it isn't a difference. But it used to be.

So by using the 127.* loopback device locally it was more efficient.
So that was yet another reason to use it instead of a public IP
address in /etc/hosts for local proceses. (Or to use a Unix domain
socket instead.) Of course that reason has gone away now. I didn't
mention it until you brought up efficiency. Because in ancient times
it was more efficient.

> > If you have questions then ask. The above was simply an off the top
> > of the head description and I am sure I didn't do a great job of it.
>
> Thanks hugely for the long, detailed response. But you seem to hold a
> couple opinions that I don't think are optimally correct on Debian. Or
> maybe they are. I really don't know -- I haven't looked at the source.
> Whatever, both ways seem to work. Maybe someday the Debian documentation
> will describe this process more clearly...
>
> If you *do* know the code, and it indicates that my impression(s) are
> wrong, I'd love to hear about it.

A very nice and tactfully worded response! Very well done. :-)

Let me say that I have looked at the source of a lot of software. I
have written a number of network daemons over the years. But memory
fades with time. And I am only human and I make my fair share of
mistakes! I don't intentionally lead people astray. But sometimes
errors do creep in.

If you have particular points where you think I have it wrong I would
appreciate being educated on what is actually happening. A good team
is always stronger than any individual.

Bob
 
Old 09-01-2012, 11:23 PM
Bob Proulx
 
Default domain name

Glenn English wrote:
> Bob Proulx wrote:
> > It turns out that this is configurable.
> > man host.conf

And honestly I had forgotten about that part of things.

> This is interesting. man host conf says:
> > order This keyword specifies how host lookups are to be performed.
> > It should be followed by one or more lookup methods, separated by
> > commas. Valid methods are bind, hosts, and nis.

I am not sure that file controls that part of the resolver library
anymore. It might be stale. Or it might depend upon yet another
configuration to trigger it. I would guess that it would only control
the section that reads /etc/hosts and doesn't do anything with the
domain name resolution section. But that is just a feeling of mine at
this time.

> If I set the order to hosts dns nis with Webmin, the /etc/host.conf doesn't
> change; /etc/nsswitch.conf does:
>
> > hosts: files dns nis
>
> There seems to be more than one way to set this order...

For the upper level domain name configuration use /etc/nsswitch.conf.
That section is definitely the mainstream configuration for it.
Mostly forget about /etc/host.conf because I think (haven't looked)
that is only for reading /etc/hosts and you don't need to make any
changes there nor make any site specific configuration there.

That (/etc/host.conf) is definitely getting off into a dark alleyway
of the libc resolver library.

Bob
 
Old 09-02-2012, 12:04 AM
John Hasler
 
Default domain name

Glenn writes:
> Was there ever a time when there were no domains, just IPs?

There was a time before DNS when there were only hostnames. Everybody
had a hosts file (/etc/hosts on Unix) that they periodically ftp'd from
the NIC. Got cumbersome.

> Am I thinking wrong? Or is it possible somehow for a machine to have 2
> FQDNs?

On the public Internet my router is 174-124-12-228.dyn.centurytel.net
with IP 174.124.12.228. On my intranet it is caesar.dhh.gt.org with IP
192.168.1.1. On it "hostname -f" returns caesar.dhh.gt.org, but so
what? That's just for internal use, and nothing running on it cares.
My Raspberry Pi is raspberry.dhh.gt.org with IP 192.168.1.101 on my
intranet but on the Pi "hostname -f" returns raspberrypi while
"domainname" returns (none) as I have never bothered to configure its
FQDN. Doesn't matter. Works fine: my local DNS knows that
raspberry.dhh.gt.org means 192.168.1.101.

Your FQDN is what the relevant DNS says it is. It isn't something you
set locally, though you may want to record it locally for the
convenience of programs such as MTAs that want to know. You may want to
tell different programs different lies, though.

--
John Hasler


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87bohpi92b.fsf@thumper.dhh.gt.org">http://lists.debian.org/87bohpi92b.fsf@thumper.dhh.gt.org
 
Old 09-02-2012, 02:24 AM
Henrique de Moraes Holschuh
 
Default domain name

On Sat, 01 Sep 2012, Bob Proulx wrote:
> I have no idea why that is there. I don't know what nook that
> configures. I would let it lie dormant. It might be some legacy
> xerox or token ring network interface for all I know.

Not really. And the kernel does require DNS capabilities, but it uses
userspace helpers to do it. NFS, CIFS, CEPH, AFS... all [can] use DNS.

> If *I* were writing it I wouldn't store this information in the kernel
> at all. The kernel doesn't need it. I would store it in a file on

It used to need it in the past at the very least, it is not there just for
the heck of it. I am not sure how useful it is right now, though.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120902022446.GA15643@khazad-dum.debian.net">http://lists.debian.org/20120902022446.GA15643@khazad-dum.debian.net
 
Old 09-02-2012, 07:11 AM
Tom H
 
Default domain name

On Sat, Sep 1, 2012 at 5:49 PM, Glenn English <ghe@slsware.com> wrote:
> On Sep 1, 2012, at 3:15 PM, John Hasler wrote:
>>
>> The kernel has no interest in domain names. It deals only in IP
>> numbers. Dealing with DNS is the job of a resolver running in user
>> space.
>
> Thanks. I didn't know that -- makes sense. But it raises a question in
> my mind: Who does, beside servers? Just 'hostname'?
>
> I think I came into the TCP/IP networking business a little late. Was
> there ever a time when there were no domains, just IPs? That could
> explain a lot to me about why the domain name is so hard to get to...
>
>> A machine can be in more than one domain.
>
> I don't understand that. I've got several domains' nameserver records
> pointed at my server, serving a number of protocols. But the server
> itself is in only one domain. Apache and Postfix and Bind all handle the
> different domains, but I think of all of them as virtual domains, not the
> one true domain that my server is part of.
>
> Am I thinking wrong? Or is it possible somehow for a machine to have 2 FQDNs?
> I've never considered that. And I can't think of how to configure things so
> 'hostname --fqdn' could answer with 2 strings...

The domainname that you set on a box has nothing to do with dns. Even
the hostname has nothing to do with dns. They're needed for
nis/nisplus/ldap and the hostname's useful in a shell prompt if you
ssh into more than one box; but that's it. Anything else is just
cosmetic.

If you're serving out http, email, or anything else, it's the dns
server(s)' entries that matter. You have to ensure that the hostname
and domainname held in dns match the apache/postfix/... config.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CAOdo=SyqtHD1hrXfywNA4FQDTHp0O6fSnQc0q_51quXpnYVYr Q@mail.gmail.com
 
Old 09-02-2012, 08:30 PM
Glenn English
 
Default 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
", 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




--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 7EBA8FDF-8DC4-4EA7-B789-B60E9FA47A2E@slsware.com">http://lists.debian.org/7EBA8FDF-8DC4-4EA7-B789-B60E9FA47A2E@slsware.com
 
Old 09-02-2012, 10:37 PM
Joe
 
Default 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


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120902233727.7d91d545@jretrading.com">http://lists.debian.org/20120902233727.7d91d545@jretrading.com
 
Old 09-03-2012, 12:52 AM
Bob Proulx
 
Default domain name

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
", 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
 

Thread Tools




All times are GMT. The time now is 07:16 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org