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.
signature.asc
Description: This is a digitally signed message part.
