Welcome! Log In Create A New Profile

Advanced

Re: Fastcgi_pass, resolver, and validating functionality.

Francis Daly
December 06, 2016 03:24PM
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@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Subject Author Posted

Fastcgi_pass, resolver, and validating functionality.

ahamilton9 December 06, 2016 12:43PM

Re: Fastcgi_pass, resolver, and validating functionality.

Francis Daly December 06, 2016 03:24PM

Re: Fastcgi_pass, resolver, and validating functionality.

ahamilton9 December 07, 2016 03:39PM

Re: Fastcgi_pass, resolver, and validating functionality.

Maxim Dounin December 08, 2016 09:06AM

Re: Fastcgi_pass, resolver, and validating functionality.

ahamilton9 December 22, 2016 11:55AM

Re: Fastcgi_pass, resolver, and validating functionality.

Maxim Dounin December 22, 2016 12:52PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 319
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready