resolver: A vs AAAA

[Ruslan Ermilov]

On Wed, Dec 14, 2016 at 09:38:41PM +0300, Dmitry Sivachenko wrote:
> 
> > On 14 Dec 2016, at 20:50, Maxim Dounin <mdounin на mdounin.ru> wrote:
> > 
> > Hello!
> > 
> > On Wed, Dec 14, 2016 at 08:06:31PM +0300, Dmitry Sivachenko wrote:
> > 
> >>> On 14 Dec 2016, at 19:59, Maxim Dounin <mdounin на mdounin.ru> wrote:
> >>> 
> >>> Если в конфиге действительно proxy_pass на имя - то при чём тут 
> >>> resolver?  Первыми будет использоваться IPv4-адреса из-за порядка 
> >>> сохранения записей, который случается в ngx_inet_resolve_host().
> >>> 
> >>> Однако как и в случае resolver'а - порядок ни на что не влияет, 
> >>> кроме, может быть, отдельных краевых эффектов, т.к. все полученные 
> >>> адреса будут использоватся и запросы между ними будут 
> >>> балансироваться по round-robin.
> >> 
> >> Допустим, что nginx работает на ipv6-only сервере, а some.ip (аргумент proxy_pass) -- имеет и A, и AAAA.
> >> Я не хочу чтобы nginx вообще пытался устанавливать соединение к ipv4-адресу.
> > 
> > Если у вас ipv6-only сервер - так и будет, т.к. nginx использует 
> > getaddrinfo() с флагом AI_ADDRCONFIG, и неподдерживаемые адреса 
> > система просто не вернёт nginx'у.
> 
> 
> В моем случае на машине настроены ipv4-over-ipv6 туннели, так что реально ipv4-адреса на интерфейсе есть, но роутинг работает только для ipv6.
> 
> Раз используется getaddrinfo(), то эта функция как раз возвращает адреса в нужном порядке (учитывает ip6addrctl_policy).
> 
> Так что кажется что проблема лишь в 
> ----------
> Первыми будет использоваться IPv4-адреса из-за порядка 
> сохранения записей, который случается в ngx_inet_resolve_host().
> ----------
> 
> Если сохранять порядок, возвращаемый getaddrinfo(), то будет то поведение, которое нужно.

Как уже написал Максим ранее, эти адреса используются в режиме
round-robin, поэтому все они рано или поздно будут попробованы.
Вот зеркальная ситуация с unroutable IPv6:

1-й запрос:
2016/12/15 09:10:07 [error] 35029#0: *1 kevent() reported that connect() failed (61: Connection refused) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://88.198.44.17:12345/", host: "127.1:8000"
2016/12/15 09:10:07 [error] 35029#0: *1 connect() to [2a01:4f8:a0:1064::2]:12345 failed (65: No route to host) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://[2a01:4f8:a0:1064::2]:12345/", host: "127.1:8000"
[...]

2-й запрос:
2016/12/15 09:10:21 [error] 35029#0: *4 connect() to [2a01:4f8:a0:1064::2]:12345 failed (65: No route to host) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://[2a01:4f8:a0:1064::2]:12345/", host: "127.1:8000"
2016/12/15 09:10:23 [error] 35029#0: *4 kevent() reported that connect() failed (61: Connection refused) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://88.198.44.17:12345/", host: "127.1:8000"