как работает резолв dns в nginx

[BigBrother]

Всем привет. С помощью nginx 1.10.1 проксирую запросы на backend-ы

Код: Выделить всё

proxy_pass http://domain.service.consul

IP адресов у domain.service.consul несколько и они переодически меняются. Выдаются они consul-ом и чез него же резолвятся (он выступает днс-сервером). Проблема в том, что если !Р адреса у domain.service.consul поменялись, nginx не видит их и как я понимаю, отправляет запросы по старым !Р. Если после изменения !Р адресов у domain.service.consul, перезагрузить nginx, то он видит новые !Р адреса и все работает. Я так понимаю, что во время своего запуска, nginx делает resolve !Р адресов всех доменов, которые у него прописаны для proxy_pass, кладет их себе в кеш и использует их пока не будет полностью перезагружен. При этом

Код: Выделить всё

kill -HUP pid_of_nginx_process

не помогает. Нужен полный рестарт.
Это баг или так специально сделано? Если специально, то зачем?

[BigBrother]

Вопрос решен. По умолчанию, nginx кеширует резолв днс на 5 мин. Решений несколько:
1. менять ttl для домена на стороне днс-сервера.
2. Или изменить конфиг nginx:
а. В server пишем

Код: Выделить всё

 set $domain "http://domain.service.consul:PORT";
  location / {
    proxy_pass $domain;

б. За пределами server/location добавляем

Код: Выделить всё

resolver IP_DNS:53 valid=2s ipv6=off;
resolver_timeout 10s;

[Bizdelnick]

менять ttl для домена на стороне днс-сервера

Собственно, nginx (и кто угодно другой) имеет полное право кешировать адрес до истечения TTL. Так что это IMHO единственно верное решение (устранение причины, а не борьба с её последствиями).

[BigBrother]

Bizdelnick
valid=2s в конфиге nginx - тоже самое что и "менять ttl для домена на стороне днс-сервера.", только подход с другой стороны.

[Bizdelnick]

valid=2s в конфиге nginx - тоже самое что и "менять ttl для домена на стороне днс-сервера.", только подход с другой стороны.

Нет, это не то же самое. Это именно борьба с последствиями (на стороне клиента) вместо устранения причины (на стороне сервера). Решите добавить дополнительные фронтенды — опять наступите на те же грабли. Понадобится обращаться к бекенду откуда-то ещё (не из nginx) — снова те же грабли.