Connection to Redis server fails with "could not be resolved (2: Server failure)"

```
2020/05/06 02:54:06 [error] 22#22: *2418323 [lua] ssl_certificate.lua:134: get_cert_der(): auto-ssl: error fetching certificate from storage for : could not be resolved (2: Server failure), context: ssl_certificate_by_lua*, client: , server: 0.0.0.0:443
2020/05/06 02:54:06 [error] 22#22: *2418323 [lua] ssl_certificate.lua:77: issue_cert(): auto-ssl: failed to obtain lock: could not be resolved (2: Server failure), context: ssl_certificate_by_lua*, client: , server: 0.0.0.0:443
2020/05/06 02:54:06 [error] 22#22: *2418323 [lua] ssl_certificate.lua:291: auto-ssl: could not get certificate for - using fallback - failed to get or issue certificate, context: ssl_certificate_by_lua*, client: , server: 0.0.0.0:443
```
And occasionally:
`2020/05/06 02:51:01 [error] 22#22: unexpected response for `

This is running on the "openresty:alpine-fat" docker image. The `` is an AWS ElastiCache cluster, specified using a domain, not IP address.

I wonder if it's an issue with the Nginx resolver. The problem remained after a restart. The Redis server was otherwise connectable. Research on the issue was inconclusive. The interesting thing is that it worked fine for more than a year and then started failing with seemingly no changes made.

Start by tracing the certificate and storage errors in ssl_certificate.lua around lines 77, 134, and 291, using the openresty:alpine-fat image and the reported AWS ElastiCache hostname. Reproduce the hostname-resolution and unexpected-response behavior, then compare the Nginx resolver path with Redis connectivity. Done means the failure has a confirmed cause and a verified fix or clear diagnostic guidance.

Written by the indexing model from the issue text.