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

Re: Debian and FQDN lookup



Alex Mestiashvili wrote:
> >> and as far as I see it simply asks the DNS about the hostname using 
> >> getaddrinfo.
> > 
> > But, with stock nsswitch.conf, it issues uname(2) syscall first, goes
> > to /etc/hosts second, and if it encounters FQDN hostname - it all ends
> > here.
> > If /etc/hosts contain only bare hostname - it'd return a bare hostname.

But /etc/hosts shouldn't have a bare hostname, right?  It should
always have a canonical name first followed by aliases second.

  man hosts

       This  manual  page  describes  the format of the /etc/hosts file.  This
       file is a simple text file that associates IP addresses with hostnames,
       one line per IP address.  For each host a single line should be present
       with the following information:

              IP_address canonical_hostname [aliases...]

The debian-installer will set things up right with an entry such as
this one.

  127.0.1.1 foo.example.com foo

Some people will be running software such as CAD/EDA software that
passes IP addresses around interchangeably with hostnames.  That
software is fundamentally broken.  But for those using it the only
possibility is to work around it.  The old classical Unix config
would have had a single public IP address there instead.

  93.184.216.34 foo.example.com foo

That works but requires always on networking.  It isn't suitable for
laptops or other mobile devices.  But it is fine for an always on
server host.

> > Only if /etc/hosts does not contain a hostname - a DNS search will be
> > performed (or other resolving method, all according to nsswitch.conf).

The entire 'hostname --fqdn' hack is really a nasty hack that I wish
had never entered the GNU/Linux community.  You won't find it on a
classic Unix system.  Actually I have debugged many installation
scripts that call 'hostname -f' and instead set the hostname to "-f".
On legacy Unix systems there are no options.  Whatever is in the first
argument is what is set as the hostname.

But that isn't the worst of it.  The 'hostname -f' model thinks that a
host has one IP address and that one IP address maps to one host.  It
looks up the name and finds the first IP address.  It looks up that IP
address to find the name associated with it.  Basically it assigns the
name found through DNS lookups.  It expects a one-to-one mapping of
exactly one IP address and the entire loop must match.

That thinking is so 1985!  It is now 30 years later in 2015 and that
relationship just isn't true in the general case.  Lots of servers
have multiple IP addresses.  A server might be serving multiple
domains.  What is the canonical domain in that case?  I sarcastically
say that 'hostname -f' will always pick the wrong one for you if you
have several to choose from.  That is one of the reasons for the great
compromise of using '127.0.1.1 fqdn' in the /etc/hosts file.

The /etc/nsswitch.conf file configures name lookups.  The usual line
for the hosts file lookup mapping is:

  hosts:          files dns

That looks in /etc/hosts first and dns second.  (Some sites may have
NIS/yp or LDAP or other configured there.)  Since files is first it
has priority for /etc/hosts entries before DNS entries.  That allows
the strategy mapping through 127.0.1.1 to work.

Here is some discussion on the various issues.

  https://lists.debian.org/debian-boot/2005/06/msg00639.html

  https://lists.debian.org/debian-devel/2013/07/msg00809.html

  https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/234543

There is also 'libnss-myhostname' which I mention for completeness.
However I find it causes me more bugs and problems than not using it
and simply using the above strategies.  Therefore I recommend NOT
using the libnss-myhostname package.

> Yes, agree, though you will not see any of steps above if nscd is
> running as it was in my case.

You menion nscd and that trips another pet peeve.  The nscd is another
Evil bad model that never understood the /etc/passwd file structure
and explicit order.  The nscd hashes the contents and destroys the
order.  Therefore nscd is fundamentally broken whenever there are
multiple names mapped to the same uid number.  That is a very common
configuration in many environments.  I always purge nscd whenever I
want correct behavior.  It doesn't improve performance significantly.
Correct is better than fast anyway.  And if account lookups are slow
then it is better to add more NIS/yp or LDAP slaves and improve your
performance there anyway.

Bob

Attachment: signature.asc
Description: Digital signature


Reply to: