[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: where is /etc/hosts supposed to come from?

On Tue, Dec 29, 2009 at 10:31:25PM +0100, Vincent Lefevre wrote:

> Well, the node name is unique. From that, you'll obtain the FQDN with
> either the obsolete function gethostbyname or the new POSIX function
> getaddrinfo (by using the AI_CANONNAME flag). POSIX says:
>   If the AI_CANONNAME flag is specified and the nodename argument is
>   not null, the function shall attempt to determine the canonical name
>   corresponding to nodename (for example, if nodename is an alias or
>   shorthand notation for a complete name).

Read what you have written: _attempt_. It does not say that you can
expect it to succeed even in common situations.

> And here's what the getaddrinfo(3) man page says under Debian:
>   If hints.ai_flags includes the AI_CANONNAME flag, then the ai_canonname
>   field of the first of the addrinfo structures in the returned  list  is
>   set to point to the official name of the host.
> Then you need to configure your machine according to the spec, i.e.
> you need a single FQDN / canonical name / official name of the host.

If getaddrinfo(AI_CANONNAME) fails, that is fully conformant with the
spec you have quoted.

> > Example: there is a router box called "gw" which has about a dozen
> > addresses that resolve to "gw.<domain>" for just as many domains. Some
> > addresses even share the same NIC. Which FQDN should "hostname -f"
> > display?
> This doesn't really matter. The FQDN may also be another name, i.e.
> the nodename may be something more meaningful than "gw".

But it is not. This is a real world example. Reality does not match your
dream world.

> > Why that one, and not some other?
> You should ask this question to those who configured such routers
> (but this would be more a practical matter, as you may have plenty
> of choices).

_I_ did configure it. I _know_ that none of the addresses is more
important than the other.

And you know, if you do not pretend such silly things that a host should
have just a single FQDN or that "hostname -f" should return anything
meaningful, then the above configuration works flawlessly. Only if you
start to pretend things that are simply not true you start having

> A FQDN is not associated with an IP address, but with a host. You
> cannot call them FQDN, which already has a well-established meaning.

Now this is bullshit. FQDN is a term related to DNS. An FQDN resolves to
a set of resource records, which may be IPv4 or IPv6 addresses and a
couple of other things, but definitely _NOT_ hosts, as that term has no
meaning for the DNS.

If the FQDN resolves to multiple IP addresses, then the very same FQDN
can belong to multiple hosts simultaneously. Similarly, if a host has
multiple IP addresses, then multiple FQDNs may point to it. You can even
mix these:

- host1 has addresses and
- host2 has addresses and
- the DNS has the following records:

	service1.domain.	IN	A
				IN	A
	service2.domain.	IN	A
				IN	A

Now both hosts has two FQDNs, and both FQDNs point to two hosts; neither
"host1" nor "host2" is resolvable. And it all works just fine if you do
not make invalid assumptions about what FQDNs are and how they are used.

> If I understand correctly, you do a reverse DNS lookup. Now, I'm
> wondering... Can a hostname obtained by reverse DNS lookup resolve
> to different IP addresses?

Of course it can. And it is common to refuse connections from such hosts
using the PARANOID option of TCP wrappers (which was first released more
than 18 years ago, so don't pretend it is some new thing).

> "hostname -f" just follows the POSIX notion of canonical name (a.k.a.
> FQDN). So, I doubt it will die.

Please quote the exact text from POSIX that says that

- there MUST be a canonical name,
- and that name MUST be an FQDN.


     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences

Reply to: