Purpose of LEGO_DISABLE_CNAME_SUPPORT

At Gandi (my domain registrar and dns provider) my zone file has this:

@ 3600 IN A xxx.xxx.xxx.xxx
* 3600 IN CNAME example.com.
www 3600 IN CNAME example.com.

So the A record contains an IPv4 to the VPS, and the "*" and "www" subdomains are CNAMEs pointing to the A record.

I failed to get a wildcard certificate. After scouring the forums I found this:

environment:
  - "LEGO_DISABLE_CNAME_SUPPORT=true"

When I add that, it works.

Why?

Hello,

it's because lego follows CNAME to resolve the domain.

I recommend reading the Let's Encrypt article about CNAME:

The following of the CNAME is useful when for example you want to use only one DNS account to handle multiple accounts or one DNS account to handle multiple DNS providers.

FYI lego is the library that uses Traefik to handle ACME challenge.

2 Likes

@Idez Thanks! I know the difference between A and CNAME, but I'm not an expert like you... :smiley:

The log error is

acme: error presenting token: gandiv5: no subdomain because the domain and the zone are identical:

My zone file is "typical". Why is this not a problem for other people - is it maybe because of Gandi specifically? I had similar config with other dns providers (e.g. digitalocean, ovh, linode) but never had this weird problem.

I wonder whether the problem is the provider, or is it me (my config).

(This is not a problem, I am using that setting and it works. I'm just trying to understand because there was no docs about this, so I'm curious and it took a long time to figure out.)

The error can be different for each DNS provider, it depends on the DNS client implementation.
It can also depend on the version of lego.

I was not trying to explain CNAME but just how it can be use in the context of ACME challenge :wink:

1 Like

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