Right, so I conceptually know what this is, but how is it determined? What’s the impact?
As far as I can tell most applications couldn’t really care about the fqdn, exceptions would be email, and apache likes having one. The FQDN is basically the full name that a remote machine will use to recognize your machine with. Eg, my VoIP server sits at 196.35.70.140 but users use voip.uls.co.za to resolve it. If you do a reverse resolution of the IP then the name is r2d2.uls.co.za – and it’s this part that is important for us, the FQDN for that machine is r2d2.uls.co.za, it’s hostname is r2d2 with it’s dns domain name uls.co.za.
So how does Linux determine this? Dead simple actually.
- It does a forward lookup of it’s hostname (r2d2 in this case), including any domain and search domains configured in /etc/resolv.conf, if nsswitch actually reaches DNS lookups.
- It does a reverse lookup of the obtained IP and this result is used as the FQDN.
Complex? Not really, until you start looking at what all needs to work in order for this to be correct. A common thing done by many a sysadmin is to in /etc/hosts modify this line:
127.0.0.1 localhost
To:
127.0.0.1 localhost hostname
Well, this will result in hostname -f giving you “localhost” as the FQDN. That’s broken. The correct line above (for r2d2) would be:
127.0.0.1 r2d2.uls.co.za r2d2 localhost localhost.localdomain
That is overly complete and localhost.localdomain can probably be left out. There is another way though, because let’s face it, 127.0.0.1 isn’t our public IP. So here we go, with the “correct” way:
- Set the domain/search lines in /etc/resolv.conf correctly. Basically I’d recommend leaving “search” alone unless you want to search multiple domains for a “short” name, and only set up “domain”.
- Make sure that there is a properly configured PTR record for you public IP.
- Make sure that hostname.${domain} resolves to your, and only your, public IP.
Eg, in my /etc/resolv.conf I’ve got “domain uls.co.za” along with my nameservers (ok, 127.0.0.1 which points to a djb dnscache). Then my hostname is set to “r2d2”. With this configuration when I resolve r2d2 I get an IP of 196.35.70.140, then when I reverse-lookup that IP then I get r2d2.uls.co.za which is my FQDN. Forward looking up r2d2.uls.co.za again resolves to that IP which is exactly what I want.
/etc/nsswitch.conf is also important, at least if DNS was not set up on the box previously…
Linux uses /lib/libnss_*.so.* as resolvers, while Solaris uses /usr/lib/nss_*.so.1 as resolvers
well, nsswitch.conf just says how lookups are actually performed, so yes, whilst it’s important the defaults are usually OK for most people and unless you’re integrating NIS/ldap/mysql/some other lookup technology you shouldn’t need to touch it.
For reference sake, the defaults (on the systems I’ve worked on at least) for the “hosts” database is as follows:
hosts: files dns
This means the name server switch in libc (glibc usually) will first check /etc/hosts and then perform a DNS lookup if looking in /etc/hosts fails.