Re: [gentoo-user] Why do we add the local host name to the 127.0.0.1 / ::1 entry in the /etc/hosts file?

[Michael]

On Thursday, 11 March 2021 16:50:37 GMT Grant Taylor wrote:
> On 3/11/21 6:38 AM, Michael wrote:
> > I'm losing my thread in this ... thread, but what I'm trying to say
> > is the AD/ DC and Kerberos way of processing the /etc/hosts entries,
> > when an /etc/hosts file is used, is different to your run of the mill
> > Linux box and server.
>
> I disagree.
>
> First, AD/DC ~ Kerberos don't process the /etc/hosts file.  They do ask
> the system to resolve names to IP addresses.

Yes, of course.  I realise I didn't express this point accurately.  I think 
the hosts file is parsed, if it exists, by the glibc which then provides the 
required IP info to applications.


> Second, the system will process the /etc/hosts file, DNS, NIS(+) in the
> order configured in the /etc/nsswitch file so that it can resolve names
> to IP addresses for programs that ask it to do so.

Yes, /etc/hosts could be even be configured to be the last source to be 
consulted, or not exist at all.


> Third, both non-AD / non-Kerberos and AD / Kerberos systems ask the
> system to resolve names to IP addresses.  Further, I'll bet dollars to
> donuts that they call the same functions and use the same subsystems.
>
> I will agree that non-AD / non-Kerberos systems are not sensitive to --
> what some consider to be -- the misconfigurations that AD / Kerberos
> systems are.

Right.  That's the nub of it.  Samba, with AD-DC and Kerberos configuration 
deserves special attention and the apps devs advise accordingly.


> > The Samba link in a previous message makes it clear the DC must have
> > a DNS domain, which corresponds to the domain for the AD forest,
> > this will be used by the Kerberos AD realm; and, the DC must have a
> > static IP address.
>
> Yes.  But that has nothing to do with the contents of the /etc/hosts file.

It does, insofar the hosts file contents and syntax could break Samba, AD/DC 
and Kerberos, if the Samba devs advice is not heeded.

Unless I got all this thread wrong, this is the main bone of contention - 
handbook recommendations can lead to such breakage.


[snip...]

> > Since /etc/hosts is parsed from the top, things may work fine when
> > the localhost entry is further down the list and further down than
> > any other entries acting as AD DNS resolvers - I don't recall testing
> > this on Samba to know for sure.
>
> Why are you putting entries for the DNS servers in the /etc/hosts file?

You wouldn't normally add in the hosts file the IP addresses of DNS 
forwarders/resolvers, but depending on the topology of the AD forest you could 
if you wanted to.


> > The same syntax won't break a LAMP, or vanilla linux PC, as long as
> > the same box is not acting as a DC.
>
> Actually it can.  I've seen it multiple times in the past.
>
> Bind a service to /only/ the LAN IP.  Then have the system try to
> connect to itself.  It will fail because the service isn't listening on
> the loopback IP.

Quite.  If you set up this service to only listen to the LAN IP address, 
rather than any address, it should do just so.  There is also the question why 
should a service for the LAN need to listen to localhost, it's not always 
necessary.


> This is (or was) common on web servers that had multiple IP addresses to
> use different TLS certificates before SNI became a viable thing.  Have
> each virtual web server listen on only it's specific IP address.  Have
> the virtual web server for the system's FQDN follow suit for consistency
> reasons.  Then trying to connect to the FQDN would fail if it was an
> alias for 127.0.0.1 or ::1.

Yes, I recall apache would fail if you tried to contact http://localhost or 
its FQDN from the server itself, with something like "... host name not valid 
for this server", but it would serve the default "It works!" webpage when the 
server's FQDN was called from clients.  Anyway, all this is O/T from the main 
question.


> > See my statement above re. entries for AD DNS resolvers, if these
> > are listed in the /etc/hosts file.
>
> You didn't answer my question.
>
> What does the number of DNS servers (configured in /etc/resolv.conf)
> have to do with the contents of the /etc/hosts file?

It doesn't, obviously the two files are fulfilling different purposes.  You 
could however specify in the DC's host file any additional DNS servers in the 
AD DNS zone with their static IP addresses.  I tend to do this and also check 
the hosts file in the first instance when I forget what other machines play 
some (important) role on the current host's functions.  This is by no means a 
rule or even a recommendation for others to do the same.  ;-)


> > The /etc/hosts file specifies the LAN IP address(es) of the DC which
> > acts as DNS resolver for the AD DNS zones.
>
> No, the /etc/hosts file has nothing to do with how /DNS/ resolution
> operates.

Yes, but I was not referring to DNS resolution mechanism itself, other than 
specifying static addresses of other DCs PCs in the hosts file.  It's just a 
list of IP addresses after all.  Since the localhost (DC) provides DNS 
resolution, its LAN address will be included.


> I'm wondering if your understanding is that there's a close relationship
> and interaction between the contents of /etc/hosts and /etc/resolv.conf
> as in the former effects the latter.  This is not the case.

Yes, we agree.  Two different files, mechanisms and purposes.


> /etc/hosts and /etc/resolv.conf are completely independent and can each
> quite happily exist without the other.  You can even run systems without
> one or the other.  Running without both is technically possible, but
> things start to get ... cumbersome.
>
> You can add entries in /etc/hosts for the DNS servers as a convenience.

Yes, that's what I was trying to express, evidently unsuccessfully.  :-)


[snip... ]

> This has been and is an interesting discussion.  However, I'm still no
> closer to learning why the Gentoo handbook wants the local host name
> added to the 127.0.0.1 / ::1 entry in the /etc/hosts file.  Something
> which I believe is wrong and bad advice.

I wouldn't call it majorly "wrong" on a standalone desktop use case, in the 
sense that it shouldn't break things - I think.  Address 127.0.0.1 is for 
internal consumption, it won't be seen by the external network and the host 
can refer to itself as its user desires.  Furthermore, LAN addresses and 
domains may change all the time on say a roaming laptop, so setting up aliases 
against a temporary LAN IP becomes cumbersome.  Yes, specifying a FQDN against 
localhost doesn't align with the practice of most distros and a number of 
RFCs, therefore asking why the handbook offers this guidance without 
qualifying it is worth exploring further.

We have already established the handbook suggestion creates breakage on Samba 
with AD/DC, potentially on a webserver, and perhaps other server applications.  
I agree using 127.0.0.1 for the special "localhost" hostname is cleaner and in 
these use cases the right solution.

I recalled old bugs filed about this and had a look.  I don't know of other 
dev conversations/bugs and what might have produced the current guidance in 
the handbook:

https://bugs.gentoo.org/40203
https://bugs.gentoo.org/53188


Interestingly you attracted my attention to the man page for the hosts file, 
which I assume is installed by baselayout.  I noticed this example quoted at 
the bottom where 127.0.1.1 is used for the host's FQDN:

EXAMPLES
       # The following lines are desirable for IPv4 capable hosts
       127.0.0.1       localhost

       # 127.0.1.1 is often used for the FQDN of the machine
       127.0.1.1       thishost.mydomain.org  thishost
       192.168.1.10    foo.mydomain.org       foo
       192.168.1.13    bar.mydomain.org       bar
       146.82.138.7    master.debian.org      master
       209.237.226.90  www.opensource.org

       # The following lines are desirable for IPv6 capable hosts
       ::1             localhost ip6-localhost ip6-loopback
       ff02::1         ip6-allnodes
       ff02::2         ip6-allrouters


If the Gentoo handbook recommends something different, I think the devs should 
at least qualify why this is so and potentially offer warnings on use cases 
where the handbook recommendation is inappropriate and must be deviated from.