Fastcgi_pass, resolver, and validating functionality.

[Francis Daly]

On Tue, Dec 06, 2016 at 12:43:50PM -0500, ahamilton9 wrote:

Hi there,

> 1) Does using a variable in fastcgi_pass actually allow the resolver to run,
> or is it just for proxy_pass as I've seen in 90% of examples?

Observation suggests "yes".

> 2) Is this configuration valid? It WORKS, but the resolution doesn't seem to
> do anything, or I'm not sure how to check that it's updating. The server's
> resolv.conf points to the same DNS server and uses a search domain so
> "php:9000" does work:

tcpdump -nn -i any host x.x.x.x and port 53

It might be easier if you pick an address that is *not* otherwise used,
but this should be good enough to show that it works as you want.

When I repeatedly try to access http://127.0.0.1/fake.php, I get my
response (Bad Gateway, in this case, but that does not matter). The
tcpdump shows queries for A? php. and AAAA? php., followed by a response
of 1/0/0 A 127.0.0.12 (which is what my resolver is set to return).

I see queries at 19:55:07, 19:55:18, and 19:55:29, and not in between.

So nginx makes a dns request, does not make any more for 10 seconds,
and then makes one the next time a request comes in.

> 3) How do I validate that the resolver is working properly outside of
> waiting for an outage again?

Use a name-resolving tool of your choice -- dig, host, nslookup, others
exist no doubt -- to query your resolver yourself.

Note that because you say valid=10s, nginx will only issue a new query
more than 10s after the previous successful query. So if the resolver
has a problem, nginx will notice within 10 seconds and start returning
HTTP/1.1 500 Internal Server Error until the resolver responds again.

The "valid" time is a balance between "how short should I use the old
value before learning that there is a new one", and "how long should I
use the old value while the resolver breaks and recovers".

> Is there a way to get the current cached DNS
> entries from nginx to compare? I found a tcpdump command, but I'm not really
> sure what I'm looking at, and it usually gives me no data. Is there a better
> method?

I don't know of a way to get the nginx value, other than to "tcpdump"
and see what ip address nginx is trying to access on port 9000 -- that
will be the value that it is currently using -- or checking the debug
log for the "name was resolved to" or "connect to" lines. Or check the
error log for the "connect" line if the connect failed.

All of those are indirect. tcpdump is probably easiest; but you could
use a "debug_connection 127.0.0.100;" and then make your test to that
address, hoping that most other people will not, and then look for the
debug log lines after each time you test.

	f
-- 
Francis Daly        francis at daoine.org