Welcome! Log In Create A New Profile

Advanced

Re: PATCH: Add $fqdn stream and http variable.

Maxim Dounin
November 26, 2018 09:52AM
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@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/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
Subject Author Views Posted

PATCH: Add $fqdn stream and http variable.

David Coles 280 November 23, 2018 05:32PM

Re: PATCH: Add $fqdn stream and http variable.

Maxim Dounin 97 November 24, 2018 07:36AM

Re: PATCH: Add $fqdn stream and http variable.

David Coles 102 November 25, 2018 05:50PM

Re: PATCH: Add $fqdn stream and http variable.

Maxim Dounin 120 November 26, 2018 09:52AM



Sorry, you do not have permission to post/reply in this forum.

Online Users

Guests: 295
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready