K 10
svn:author
V 6
iulius
K 8
svn:date
V 27
2017-09-18T20:13:48.982000Z
K 7
svn:log
V 2016
Clarify the use of FQDN in documentation

There are two things here. First, the FQDNs that exist in the DNS for a given host: some may be A and AAAA records, other may be CNAME records, and the host may know them or not.

Second, the FQDN that the host system will report (hostname --fqdn), which is a single one, always the same as long as the configuration will not change. With GNU/Linux, it seems to be determined this way:

* if the system hostname contains a dot, return it;
* if the system hostname does not contain a dot, resolve it to an FQDN  using getaddrinfo() (which will resolve it to an IP address and then  back to a name using a reverse resolution, usually using /etc/hosts,  but possibly using the DNS).

The problem is mostly the over-usage of the term ?\226?\128?\156FQDN?\226?\128?\157, which can sometimes be incorrectly understood as meaning ?\226?\128?\156a host's canonical name?\226?\128?\157. This is emphasized by the fact that some news services, if not most of them, are referred to with a service name such as news.example.com, which is fully qualified, but which is just an alias to the server canonical name such as gruyere.example.com, which will probably be the result of a reverse lookup of its IP address as well.

Most of the time, when resolving a host name to an IP address), the fact that it is fully qualified or not is irrelevant, as long as it does resolve. In such cases, it is enough to just mention ?\226?\128?\156a host name?\226?\128?\157.

For checking a client IP address against a host name, the fact that it is FQ or not is again irrelevant, but what is relevant is whether this check is done by direct lookup of the configured host name, or by reverse lookup of its IP address.

For reporting connections with a host name rather than an IP address, it is not relevant either, this is just a reverse lookup, and it will almost always return an FQDN indeed, but that depends on the system configuration.

Thanks to Tanguy Ortolo for his suggestion of improvement.

END
