PATCH: Add $fqdn stream and http variable.

[Maxim Dounin]

Hello!

On Sun, Nov 25, 2018 at 02:49:12PM -0800, David Coles wrote:

> Hi Maxim. Thanks for your comments.
> 
> On Sat, Nov 24, 2018 at 4:35 AM Maxim Dounin <mdounin at mdounin.ru> wrote:
> > No, thank you.  This change makes nginx startup unconditionally
> > dependant on the DNS availability.  This is not something we are
> > going to accept.
> 
> That's reasonable. I based this behaviour off `hostname -f` which also
> uses `gethostbyname` for resolving the FQDN.
> Note, on most systems this doesn't trigger an actual DNS lookup
> provided that hosts canonical name (usually the FQDN) is configured in
> `/etc/hosts` (See paragraph 5 of THE FQDN
> <https://manpages.debian.org/testing/hostname/hostname.1.en.html>).

The "no DNS lookup on most systems" is not something we can rely 
on.

> On some systems `gethostent` can be used to explicitly walk
> `/etc/hosts`, but behaviour is so inconsistent I would avoid it.

Trying to use /etc/hosts will lead to results different from 
results of normal name resolution, so this doesn't looks like an 
option.

> How would you feel about trying to resolve the FQDN at nginx startup
> and, if unavailable falling back to `$hostname`? This matches the
> behaviour of other languages (e.g. Python's `socket.getfqdn()`
> <https://docs.python.org/3/library/socket.html#socket.getfqdn>).

Even trying to resolve the FQDN will imply DNS dependency.  If DNS 
is not availble it will wait for a timeout to expire before 
proceeding any further.

> I could also make this a runtime evaluation, but it would be nice to
> only evaluate once as it would often be used in hot paths like logging
> and tracing.

Using system resolver at runtime is basically not possible, 
because there is no non-blocking interface to system resolver, and 
using blocking one will will block the whole worker process during 
name resolution - which can take significant time.  That's 
basically why nginx has resolver in it.

The only option I see is doing name resolution only conditionally, 
either when requested by a configuration directive, or when the 
variable is actually used in the configuration.  But I don't think 
this worth the effort - configuring appropriate hostname and/or 
using the name directly in nginx configuration would be a better 
idea.

[...]

> Linux in particular seems to have interpreted `gethostname` as
> returning a DNS label (maximum of 63 characters) rather than a full
> DNS name (up to 213 characters).
> Thus it's impossible to represent certain DNS names as the system hostname.

There is more than one Linux distribution, and Debian is just one 
of them.  There are others which use FQDN:

https://serverfault.com/questions/331936/setting-the-hostname-fqdn-or-short-name

Note well that Debian can use FQDN as well, and "hostname -f" is 
smart enough to use such name without looking further.

While length restrictions might make it impossible to represent 
some names, this is unlikely a practical problem.

-- 
Maxim Dounin
http://mdounin.ru/