Hello Maxim,

> On startup, nginx does name resolution of various names in a
> configuration files, using system resolver. This includes initial
> resolution of OCSP responders if stapling is used. If your system
> resolver doesn't have internet access and blocks trying to resolve
> names - so nginx will do.

I see. But what is the parameter "resolver_timeout" for? I had 2 ssl_staple directives in my config, and I set a resolver_timeout of 5 secs. I thought the blocking should not exceed 10 seconds then, assuming the resolving is done sequentially? It took more than 40 seconds to start though.

> Traditional approach to the problem is to use local caching DNS
> server (which is less likely to fail than external services), and
> to use IP addresses or /etc/hosts for critical things.
>

That sounds good, but I've seen that the ocsp server has a TTL of 5 minutes for its A records. So they seem to change frequently and caching them would -in this case- not help a lot.

> It's also a good idea to have nginx _running_ instead of trying to
> start it in an emergency conditions. While nginx usually starts
> just fine, it is designed to keep things running by all means, not
> to start by all means. Startup may fail, e.g., due to failed DNS
> resolution or a listen socket grabbed by some other process. In
> contrast, if nginx was already started - it will keep running by
> all means.
>

Ok, that's something I should consider. Keep nginx running on both nodes. I hope it doesn't cause troubles if a web directory is empty and gets filled later on by mounting a DRBD device.

br,
Can