SERVFAIL when dry-run for rfc2136

Help
1

I have been attempting to perform a dry-run to renew a certificate. It uses the rfc2136 plugin. So far, it has failed.

I searched for similar posts regarding rfc2136. They were solved by fixing file permissions. However, none of the posts mentioned which permissions, what the permissions were, or how they were changed.

My domain is: sma-inc.us
I ran this command:

sudo certbot certonly \
 -v \
 --domains "*.$DOMAIN" \
 --agree-tos \
 --dns-rfc2136 \
 --dns-rfc2136-credentials "/root/.secrets/certbot/rfc2136.ini" \
 --dns-rfc2136-propagation-seconds 10 \
 --dry-run

It produced this output:
(Note: the log output, letsencrypt.log, is quite long. Is there a way to attach a file?) Here is a (hopefully) useful excerpt:

2022-11-18 11:48:06,500:INFO:certbot._internal.auth_handler:Performing the following challenges:
2022-11-18 11:48:06,500:INFO:certbot._internal.auth_handler:dns-01 challenge for sma-inc.us
2022-11-18 11:48:06,511:DEBUG:certbot_dns_rfc2136._internal.dns_rfc2136:No authoritative SOA record found for _acme-challenge.sma-inc.us
2022-11-18 11:48:06,516:DEBUG:certbot_dns_rfc2136._internal.dns_rfc2136:Received authoritative SOA response for sma-inc.us
2022-11-18 11:48:06,522:DEBUG:certbot._internal.error_handler:Encountered exception:
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/certbot/_internal/auth_handler.py", line 85, in handle_authorizations
    resps = self.auth.perform(achalls)
  File "/usr/lib/python3.6/site-packages/certbot/plugins/dns_common.py", line 76, in perform
    self._perform(domain, validation_domain_name, validation)
  File "/usr/lib/python3.6/site-packages/certbot_dns_rfc2136/_internal/dns_rfc2136.py", line 81, in _perform
    self._get_rfc2136_client().add_txt_record(validation_name, validation, self.ttl)
  File "/usr/lib/python3.6/site-packages/certbot_dns_rfc2136/_internal/dns_rfc2136.py", line 144, in add_txt_record
    .format(dns.rcode.to_text(rcode)))
certbot.errors.PluginError: Received response from server: SERVFAIL

Ouput from named:

18-Nov-2022 11:48:06.518 update: info: client @0x7f78c41facf0 192.168.69.246#58112/key letsencrypt: updating zone 'sma-inc.us/IN': adding an RR at '_acme-challenge.sma-inc.us' TXT "IVhQbly7ce141NJIcQoqMp3XGMYTTgda0AUeZ4pI_lU"
18-Nov-2022 11:48:06.518 general: warning: dns_dnssec_findzonekeys2: error reading Ksma-inc.us.+005+15981.private: file not found
18-Nov-2022 11:48:06.518 general: warning: dns_dnssec_findzonekeys2: error reading Ksma-inc.us.+005+38578.private: file not found
18-Nov-2022 11:48:06.518 update: error: client @0x7f78c41facf0 192.168.69.246#58112/key letsencrypt: updating zone 'sma-inc.us/IN': found no active private keys, unable to generate any signatures
18-Nov-2022 11:48:06.518 update: error: client @0x7f78c41facf0 192.168.69.246#58112/key letsencrypt: updating zone 'sma-inc.us/IN': RRSIG/NSEC/NSEC3 update failed: not found
18-Nov-2022 11:48:06.530 update: info: client @0x7f78c41facf0 192.168.69.246#58140/key letsencrypt: updating zone 'sma-inc.us/IN': deleting an RR at _acme-challenge.sma-inc.us TXT

My DNS server is (include version):
BIND (named) 9.16.33

The operating system my DNS server runs on is (include version):
opensuse LEAP 15.4

I can login to a root shell on my machine (yes or no, or I don't know):
Yes.

The version of my client is certbot 1.22.0:

3

This can happen for many reasons.

In "common" global DNS systems, I see only one authoritative DNS server:

sma-inc.us      nameserver = ns1.sma-inc.us

Following the root DNS system, it shows two names:

ns1.sma-inc.us  internet address = 192.88.109.73
ns2.sma-inc.us  internet address = 192.88.109.73

[false sense of redundancy - as both names return the same IP address]

In short: A single point of failure.

Other than that, ...
For testing:

  • change to the --staging environment [slightly more than --dry-run]
  • increase the propagation time
  • check for TXT record create/deletion/existence from the Internet
2 Likes
4

@rg305 Note that the SERVFAIL comes from the local BIND nameserver when the RFC2136 tries to add the TXT record and not from the nameservers when the ACMS server tries to validate the authz.

@jimoe It seems your BIND tries to sign the added TXT record for DNSSEC ("inline-signing"), but is unable to. That's probably not something easily tutored on this Community though, as named is rather hard to configure and debug IMO and it's not the main subject of this Community. In any case, you should review your BINDs DNSSEC configuration or disable it altogether (your domain seems to have some sort of DNSSEC configured, but does not have a secure delegation from the .us TLD to your domain).

4 Likes
5

Was there supposed to be a link for the last sentence? The text is colored and the pointer changes, and nothing happens when clicked.

1 Like
6

Osiris probably meant to link to this result at DNSViz
https://dnsviz.net/d/sma-inc.us/dnssec/
Review the last warning message especially

3 Likes
7

Mike is correct, apparently I copy/pasted something else instead of the URL to DNSViz :rofl:

While certainly important, it was not what I was referring to with my dysfunctional link. This one is relevant with regard to my point of DNSSEC not functionally being active: " * NSEC3 proving non-existence of sma-inc.us/DS".

3 Likes
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.