Failing DNS resolution

My domain is:

I ran this command: letsencrypt-auto certonly --no-bootstrap --no-self-upgrade --standalone --renew-by-default

It produced this output:

   Type:   dns
   Detail: DNS problem: query timed out looking up A for

My web server is (include version): apache2 2.4.43-1+ubuntu16.04.1+deb.s

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is: Crazy Domains

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

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 1.5.0

Hi, noticed upon my last certificate renewal that I have problem related to DNS as per the message sent by the LE server above. Not sure what to make of it since I can resolve my domain name fine (and all other subdomains i the certificate SAN) which I confirmed with multiple tools and multiple locations around the globe.

This is the error from my last attempt:

2020-06-20 16:16:22,952:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Sat, 20 Jun 2020 06:16:22 GMT
Content-Type: application/json
Content-Length: 543
Connection: keep-alive
Boulder-Requester: 13965077
Cache-Control: public, max-age=0, no-cache
Link: <>;rel="index"
Replay-Nonce: 0101ujh-iVAvQI95mWSxsds7VEfJKuZsnao5LdUvcsLjjH8
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

  "identifier": {
    "type": "dns",
    "value": ""
  "status": "invalid",
  "expires": "2020-06-27T06:15:49Z",
  "challenges": [
      "type": "http-01",
      "status": "invalid",
      "error": {
        "type": "urn:ietf:params:acme:error:dns",
        "detail": "DNS problem: query timed out looking up A for",
        "status": 400
      "url": "",
      "token": "O7-bhjHfISMVXBMrYRsGYjFQ_aFMpvpTQ7vnGvwLoI4"

I have a self hosted named and the same configuration has ran without changes for years, except for software version updates of course. Any idea what can be the problem exactly?


1 Like

Your nameservers have link-local IPv6 addresses. That could have something to do with it. Let’s Encrypt’s resolvers might actually be trying to communicate with them.

$ dig +noall +answer aaaa       86123   IN      AAAA    fe80::21d:aaff:fe8f:4334

$ dig +noall +answer aaaa       86121   IN      AAAA    fe80::21d:aaff:fe8f:4334

Edit: On the other hand, Unbound should already be sanitizing these automatically, so it’s unlikely to be the cause of the timeout.

Requests to the production API are producing SERVFAILs rather than timeouts for me. Those are likely caused by your DNSSEC problem.

1 Like

Hi @igoratencompass

there are older checks of your domain (without wrong link-local ipv6), now checked - DNSSEC is broken -

A check created yesterday 19.06.2020 14:38:26 without link-local has the same.

Fatal error: Parent zone has a signed DS RR (Algorithm 8, KeyTag 40534, DigestType 1, Digest Oz/X2+zNJTXBQ9J2Rzfzk588tdo=), but the destination DNSKEY doesn’t exist or doesn’t validate the DNSKEY RR set. No chain of trust created.

Fatal error: Parent zone has a signed DS RR (Algorithm 8, KeyTag 40534, DigestType 2, Digest wmYK6lTQFcd6dbl9rmim19A3VssUfW+hnf6HPuKsn3E=), but the destination DNSKEY doesn’t exist or doesn’t validate the DNSKEY RR set. No chain of trust created.

Same with Unboundtest - - Timeouts.

Error running query: read udp> i/o timeout

With DNSSEC, no DNSKEY can be found, but a DS in the parent zone exists -> DNSSEC is broken -> you can’t create a certificate.

First step: Fix your connection problems.


Thanks guys, I made sure no bogus IPV6 records are present in the zone. Unfortunately the TTL is 2 days so will have to wait. Except if there is an option to tell LE to use A instead of AAAA records?

On the other hand I don’t get it how can this be the problem when the error says DNS query timeout looking up A RR and not AAAA?

About the DNSSEC problem, I’m not sure I understand the error. I haven’t touched the DNSSEC setup since 2016 so not sure what might have changed. For sure the zone has the key:

$ dig @ DNSKEY +dnssec +nostats +noadditional +nocomments +noquestion +nocmd +multiline

; (1 server found)
;; global options: +cmd		21599 IN DNSKEY	257 3 8 (
				) ; KSK; alg = RSASHA256; key id = 40534		21599 IN DNSKEY	256 3 8 (
				) ; ZSK; alg = RSASHA256; key id = 21633		21599 IN RRSIG DNSKEY 8 2 259200 (
				20200711110140 20200620100140 40534
				+rvaHKadeWeo6sco1N5f89iszcxMSSQn7A== )

And if I compare the DS RR for my domain:

$ dig @ DNSKEY | dnssec-dsfromkey -f - -2 IN DS 40534 8 2 C2660AEA54D015C77A75B97DAE68A6D7D03756CB147D6FA19DFE873EE2AC9F71

With the DS I extract from my dnskey:

# dnssec-dsfromkey <path-to-my-dns-key-id-40534> IN DS 40534 8 2 C2660AEA54D015C77A75B97DAE68A6D7D03756CB147D6FA19DFE873EE2AC9F71

we can see they are identical.

That’s not the problem, there are connection problems.

Rechecked with - no DNSKEYs found.

Unboundtest has different Servfails

Checked manual - via UDP DNSKEY query works. Via TCP there is a refused answer.

That’s fatal, authoritative name servers must answer via UDP and TCP / 53.

May be a local firewall, may be your provider blocks TCP Port 53.

PS: The refused answer comes from your server, doesn’t look like a provider problem.


You are right, fixed now. But still the dns server (bind) not responding to tcp queries and I have no idea why. Thanks for your support though.

1 Like

All fixed now, thanks again.

1 Like

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