Any recommendation for handling of nginx DNS caching when used as reverse-proxy

[ignoramous]

@amine

What I noticed is if I redeploy app B and thus its ipv6 address is now different; nginx in app A seems to still be using the stale ipv6 address from the previous instance.

I doubt caching is the problem as I see a TTL of just 5s on .internal queries.

/ # nslookup -debug <app>.internal 
Server:	fdaa::3
Address:	fdaa::3#53

Non-authoritative answer:
    QUESTIONS:
	<app>.internal, type = AAAA, class = IN
    ANSWERS:
    ->  <app>.internal
	has AAAA address fdaa:0:dead:aaaa:b3ef:1111:f2:2
	ttl = 5
    ->  <app>.internal
	has AAAA address fdaa:0:dead:aaaa:be3f:3333:f4:2
	ttl = 5
    ->  <app>.internal
	has AAAA address fdaa:0:dead:aaaa:b33f:5555:f8:2
	ttl = 5
    ->  <app>.internal
	has AAAA address fdaa:0:dead:aaaa:beef:7777:f16:2
	ttl = 5

Connection pooling could be the issue here… may be ICMP msgs aren’t approp sent to ngnix for it know the addresses previously reachable are now gone?

pinging @charsleysa, they may know what’s happening here.

@amine

What I noticed is if I redeploy app B and thus its ipv6 address is now different;

btw, if you want private-ip addresses to (mostly) remain the same after deploys, you could employ this hack trick outlined here: Can an instance have a persistent network identity? - #7 by kurt