How to fix Nginx Resolver error on SSL stapling using 127.0.0.1

If you recently enabled the OCSP SSL stapling in your NGINX, you probably using localhost 127.0.0.1 as a DNS resolver for it. But using applying it to your server, you’ve got an message on your error log saying “send() failed (111: Connection refused) while resolving, resolver: 127.0.0.1:53” . The thing is, when it is failed to resolved the DNS, you will also unable to verify your OCSP stapling request for your website, ending up having no OCSP revocation information when testing at your site on SSL Labs.

The full error message looks like below.

2021/02/07 05:38:01 [error] 79590#79590: send() failed (111: Connection refused) while resolving, resolver: 127.0.0.1:532021/02/07 05:38:03 [error] 79590#79590: r3.o.lencr.org could not be resolved (110: Operation timed out) while requesting certificate status, responder: r3.o.lencr.org, certificate: "/etc/letsencrypt/live/YOUR_WEBSITE/fullchain.pem"

The other quick solution for using DNS resolver is via a public DNS like Google, OpenDNS and the others. But a post from Marc Bevand in 2016 that using a resolver from public DNS is unsafe and could lead to vulnerabilities and poison attack. The best way is to use the localhost (resolver 127.0.0.1).

For you not to use those public DNS and still allow you to use your localhost DNS resolver, but of course without those error message, the default 127.0.0.1 is actually not the default DNS resolver for most cloud hosting.

How to fix the Resolver Error

To fixed this error, you only need to use the localhost IP 127.0.0.53. So in your Nginx configuration file, use the following line instead:

resolver 127.0.0.53 valid=60s;

Also, don’t forget to add ssl_trusted_certificate pointing to your chain.pem if you’re using Let’s Encrypt Certbot.

ssl_trusted_certificate /etc/letsencrypt/live/YOUR_WEBSITE/chain.pem;

After these changes, restart your nginx sudo service nginx restart and you’re reading to go.

To test if you’re getting OCSP Stapling, try this openssl command:

openssl s_client -connect YOUR_WEBSITE.com:443 -servername YOUR_WEBSITE.com -status < /dev/null

You should get a similar result below:

OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = US, O = Let's Encrypt, CN = R3
    Produced At: Feb  4 05:36:00 2021 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 48DAC9A0FXXXD32D4FF0DE68D2F567B735XXXXXX
      Issuer Key Hash: 142EB317XXX856CBAE500940E61FAF9D8BXXXXXX
      Serial Number: 04C42438XXXAB06819611264934F6AXXXXXX
    Cert Status: good
    This Update: Feb  4 05:00:00 2021 GMT
    Next Update: Feb 11 05:00:00 2021 GMT

Troubleshoot

If the 127.0.0.53 is not working for your cloud hosting, they might be using different IP address. To find out your server DNS IP address, simply check /etc/resolv.conf.

And you should find a nameserver on it. That is your DNS IP.

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search members.linode.com

That’s it guys! Hope this help you and fixes your problem with your DNS resolver.