SERVFAIL looking up A/CAA with DNAME and DNSSEC

My domain is: (and has a DNAME to

I ran this command: dehydrated --cron -d (against both production and v2 staging).

It produced this output:

  "error": {
    "type": "urn:ietf:params:acme:error:connection",
    "detail": "DNS problem: SERVFAIL looking up A for",
    "status": 400


  "error": {
    "type": "urn:ietf:params:acme:error:connection",
    "detail": "DNS problem: SERVFAIL looking up CAA for",
    "status": 400

The DNS servers for and are PowerDNS authoritative 4.1 servers and most of them are under my control.

Both the A and CAA records validate correctly using:

  • DNSViz
  • Unbound DNS checker: A, CAA
  • Manual queries with dig to,,

The most likely explanation seems to me that the Let’s Encrypt resolver has not implemented the DNSSEC/DNAME combination correctly, see RFC 6672 section 5.3.

Edit: turns out that it is also possible to get a SERVFAIL using if you hit a PowerDNS recursor instead of Unbound.

I am guessing that this may have something to do with a limitation of Boulder/the Let's Encrypt resolver to only handle 512-byte responses.

I think this has been patched in master but I am not sure if it has made it to production.

For example, doing CAA or AAAA queries to your resolver results in a response over that size:

;; Received 541 bytes from in 386 ms

edit: Actually I'm no longer sure at all that this is the problem :\

The size shouldn’t be a problem. The stub resolver doesn’t ask to see the DNSSEC records, so it’s only about 145 bytes.

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