SERVFAIL looking up A/CAA with DNAME and DNSSEC

Help
1

My domain is: challenger.slxh.nl (and challenger.slxh.eu). slxh.nl has a DNAME to slxh.eu.

I ran this command: dehydrated --cron -d challenger.slxh.nl (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 challenger.slxh.nl",
    "status": 400
  },

or

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

The DNS servers for slxh.nl and slxh.eu 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 8.8.8.8, 9.9.9.9, 217.31.204.130

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 9.9.9.9 if you hit a PowerDNS recursor instead of Unbound.

2

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 82.197.194.135#53(ns1.slxh.eu) in 386 ms

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

3

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.

4

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