Where does FQDN come from when not set explicitly

hostname

When there is no FQDN explicitly specified on an Ubuntu server:

$ cat /etc/hostname
banana

$ cat /etc/hosts
127.0.0.1 localhost banana

Then where does mydomain.com come from?

$ hostname -A
banana.mydomain.com

Does this have anything to do with DNS records? (They seem to have been set to Google DNS on my virtual host.)

$ cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4

DNS records say as follows:

$ nslookup myip
myip.in-addr.arpa name = banana.mydomain.com

Does this mean that hostname -A falls back to DNS records?

I have dozens of hostnames associated with the server IP address through DNS. How do I decide which of the many hostnames is used as the "official" or "primary" hostname?

Best Answer

The FQDN is something you don't set on the machine itself, it's the DNS resolvable name of your machine. To be precise, it is the host name returned by the getaddrinfo system call.

From the hostname manpage:

The FQDN of the system is the name that the resolver(3) returns for the host name.

The resolver is a set of functions, that query the hostname over domain name systems, according to configurations made in the files /etc/resolv.conf and /etc/nsswitch.conf or /etc/host.conf.

The former defines name servers to query for DNS lookups (in your case the Google DNS servers). The latter defines the order in which name queries should be performed. It depends on the resolver library version which of the latter two is used.

Related Solutions

How to deny access to specific port when destination is NOT a specific host

IPTables is working on IP and TCP level, so it doesn't actually know DNS.

When a client creates a TCP connection to a DNS name it first looks up the IP address corresponding to the DNS name and then connects to the IP, not to the DNS name.

This means IPTables can't possibly know which DNS name a client is connecting to, it only knows which IP the client connects to.

If you specify --destination sub.domain.com as a parameter, IPTables will simply do a name look up to the IP that corresponds to this name, and then use the IP in it's rules.

If your port 1000 serves HTTP it would be possible to configure an HTTP server on that port to not handle requests to domains other than sub.domain.com, but IPTables doesn't have the necessary information to this.

If you could put sub.domain.com and sub.domain2.com onto two different IPs on the same server, then IPTables would be able to deny access to one but not to the other, because it could decide based on the IP.

This illustrates nicely that the Domain Name System is on top of Transport (TCP) and Internet (IP), for more details you can read the wikipedia article about it:

ISO OSI

Determine FQDN when hostname doesn’t give it

It appears that under-the-hood, Puppet uses Facter to evaluate the domain names:

$ facter domain
domain.com
$ facter hostname
kungfumaster
$ facter fqdn
kungfumaster.domain.com

The answer is in the relevant Facter source code.

It does the following in order and uses the first one that appears to contain a domain name:

hostname -f
dnsdomainname
parsing resolv.conf for a "domain" or "search" entry

Best Answer

Related Solutions

How to deny access to specific port when destination is NOT a specific host

Determine FQDN when hostname doesn’t give it

Related Question