Welcome! Log In Create A New Profile

Advanced

Re: Resolve hostname to IPv6 address in listen directive

Maxim Dounin
August 25, 2010 02:46PM
Hello!

On Wed, Aug 25, 2010 at 07:39:00PM +0200, Matthias-Christian Ott wrote:

> On Wed, Aug 25, 2010 at 03:04:44PM +0400, Maxim Dounin wrote:
>
> > On Wed, Aug 25, 2010 at 09:27:43AM +0200, Matthias-Christian Ott wrote:
> >
> > > At the moment nignx does not allow IPv6 addresses to specified by
> > > hostname in a listen directive, that is the following will not work:
> > >
> > > listen ipv6.example.com;
> > > listen [ipv6.example.com];
> > > listen ipv6.example.com ipv6only=on;
> > > listen [ipv6.example.com] ipv6only=on;
> > >
> > > Though I see a potential security problem with hostnames here (this
> > > also applies to IPv4), because DNS replies can be manipulated if
> > > DNSSEC is not used, I think that this feature would be helpful and
> > > simplifies administration.
> >
> > Note well: listen with hostname always uses *one* address returned
> > by hostname lookup, the first one returned by gethostbyname(). It
> > doesn't make sense to attempt to use it with hostname which
> > resolves to multiple addresses.
>
> Of course you would have to use getaddrinfo() (gethostbyname() is
> removed in POSIX.1-2008 and is deprecated by RFC 3493). Multiple
> addresses for one hostname are necessary for IPv4/IPv6 dual stack.
> So I see no reason why nginx should only associate one IP address
> with a hostname.

Directive "listen" specifies exactly one socket (address:port pair
for ipv4/ipv6, path for unix sockets) nginx will listen for
connections (and sets options for this socket). To listen on
multiple sockets you have to write multiple listen directives.
This is just how it works.

> > > Given that example.com resolves to an IPv4 and IPv6 address, simply
> > > binding to both addresses with the following directive would break
> > > backwards compatibility: listen example.com;
> > >
> > > For backwards compatibility I propose the following to resolve the
> > > IPv6 addresses of a hostname and listen on them:
> > >
> > > a) listen example.com ipv6only=on;
> > >
> > > b) listen [example.com];
> > >
> > > Solution b) has the disadvantage that it doesn't conform to RFC 3986.
> >
> > Both are bad. Attribute ipv6only serves completely different
> > purpose: it disables implicit mapping of ipv6 listen sockets to
> > ipv4 (for OSes where such mapping is on by default), i.e.
> > instructs nginx to do setsockopt(IPV6_V6ONLY) on listen socket.
> > See http://tools.ietf.org/html/rfc3493#section-5.3 for details.
>
> I know what the option means and I'm aware of the fact that my
> proposed solution introduces a semantic corner case for [::] since we
> “overload” the semantics of ipv6only. But I though for backwards
> compatibility this would be a good idea. If you prefer a new syntax
> simply suggest “ipv4” and “ipv6” as in:
>
> listen example.com ipv4;
> listen example.com ipv6;
>
> This would be the cleanest solution I can come up with.

I don't see any reason why a hostname with ipv4 and ipv6 addresses
should be handled differently from a hostname with two ipv4
addresses.

> Moreover, IPv4-compatible IPv6 address are deprecated by RFC 4291 and
> I think IPV6_V6ONLY should be the default option, so ipv6only could
> at least in 0.8 if not in 0.7 be removed or reused.

As I already said, this is for OSes which do implicitly open ipv4
sockets for ipv6 binds. It doesn't make sense to do extra work
for normal ones, and it doesn't make sense to remove it while such
OSes are still here.

> > I believe correct solution would be to make
> >
> > listen example.com;
> >
> > to use ipv6 address if no ipv4 addresses were found.
>
> No definitely not. This would make IPv4/IPv6 dual stack impossible. It
> should rather bind to all addresses returned by getaddrinfo() as any
> other server does. ipv4only/ipv6only or ipv4/ipv6 (depending on the
> final choice) could be used to listen only to IPv4 or IPv6 addresses
> of the hostname. This is pretty much the standard behaviour of every
> server that support IPv6 correctly.

This a) maintains backward compatibility, b) preserves "how it
works" and c) allows to specify ipv6 address by name. Again,
nobody stops you from using multiple "listen" directives.

But actually:

1. I see no reason to use hostnames in "listen" directive. From
my experience this causes more harm than good.

2. This discussion is mostly pointless without patches.

3. It's up to Igor, so feel free to ignore me.

Maxim Dounin

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://nginx.org/mailman/listinfo/nginx-devel
Subject Author Views Posted

Resolve hostname to IPv6 address in listen directive

Matthias-Christian Ott 3681 August 25, 2010 03:28AM

Re: Resolve hostname to IPv6 address in listen directive

mike 2343 August 25, 2010 03:32AM

Re: Resolve hostname to IPv6 address in listen directive

Maxim Dounin 1197 August 25, 2010 07:06AM

Re: Resolve hostname to IPv6 address in listen directive

Matthias-Christian Ott 1232 August 25, 2010 01:40PM

Re: Resolve hostname to IPv6 address in listen directive

Maxim Dounin 1183 August 25, 2010 02:46PM

Re: Resolve hostname to IPv6 address in listen directive

Matthias-Christian Ott 1453 August 25, 2010 07:56PM

Re: Resolve hostname to IPv6 address in listen directive

Piotr Sikora 1106 August 25, 2010 02:02PM

Re: Resolve hostname to IPv6 address in listen directive

Maxim Dounin 1129 August 25, 2010 03:02PM

Re: Resolve hostname to IPv6 address in listen directive

Piotr Sikora 1358 August 27, 2010 03:38AM

[PATCH] Make ipv6only default (was: Re: Resolve hostname to IPv6 address in listen directive)

Matthias-Christian Ott 1161 August 27, 2010 06:04PM

Re: [PATCH] Make ipv6only default (was: Re: Resolve hostname to IPv6 address in listen directive)

Matthias-Christian Ott 1514 August 28, 2010 06:56PM

Re: Resolve hostname to IPv6 address in listen directive

Matthias-Christian Ott 1313 August 25, 2010 08:26PM

Re: Resolve hostname to IPv6 address in listen directive

Piotr Sikora 1349 August 27, 2010 03:44AM



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

Online Users

Guests: 114
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 500 on July 15, 2024
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready