1. Delega una zona pequeña a la máquina donde correrá acme-dns (registros en tu DNS real):

   1 2	auth.example.com. NS acme.example.com. acme.example.com. A 203.0.113.10

2. acme-dns en esa máquina (/etc/acme-dns/config.cfg), escuchando DNS en el 53 y la API en el 443:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

   [general] listen = "0.0.0.0:53" protocol = "both" domain = "auth.example.com" nsname = "acme.example.com" nsadmin = "hostmaster.example.com" records = [ "auth.example.com. A 203.0.113.10", "auth.example.com. NS acme.example.com.", ] [api] ip = "0.0.0.0" port = "443" tls = "letsencrypt" disable_registration = false

3. Registra un cliente y crea el CNAME:

   1 2 3

   curl -s -X POST https://acme.example.com/register -H 'Content-Type: application/json' \ -d '{"allowfrom": ["203.0.113.0/24"]}' # {"username":"eabcdb41-…","password":"pbAX…","fulldomain":"d420c923-….auth.example.com","subdomain":"d420c923-…","allowfrom":["203.0.113.0/24"]}

   1	_acme-challenge.example.com. CNAME d420c923-….auth.example.com.

4. certbot con el hook:

   1 2 3 4 5

   curl -fsSL -o /etc/letsencrypt/acme-dns-auth.py https://raw.githubusercontent.com/joohoi/acme-dns-certbot-joohoi/master/acme-dns-auth.py chmod +x /etc/letsencrypt/acme-dns-auth.py sed -i 's|^#!/usr/bin/env python$|#!/usr/bin/env python3|; s|^ACMEDNS_URL = .*|ACMEDNS_URL = "https://acme.example.com"|' /etc/letsencrypt/acme-dns-auth.py certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py \ --preferred-challenges dns --debug-challenges -d '*.example.com' -d example.com

   La primera vez el hook se registra solo, guarda las credenciales en /etc/letsencrypt/acmedns.json y se para para que crees el CNAME que imprime; Enter, y valida. Las renovaciones (certbot renew) ya no preguntan nada.

Por qué

DNS-01 es el único reto que da wildcards y el único que funciona para máquinas sin puerto 80 público. El precio habitual es un token de API de tu proveedor DNS en cada servidor que pide certificados; ese token normalmente puede cambiar cualquier registro de la zona, y vive en texto plano en /etc/letsencrypt.

acme-dns le da la vuelta: es un servidor DNS autoritativo de una zona propia (auth.example.com) que solo sabe servir registros TXT bajo subdominios aleatorios, con una API para actualizarlos. Como _acme-challenge.example.com es un CNAME hacia uno de esos subdominios, Let’s Encrypt sigue la cadena y valida el TXT allí. Las credenciales de cada cliente solo sirven para su subdominio; robadas, lo peor que pasa es que alguien pida un certificado para ese nombre, no que reescriba tu zona.

cert-manager

El mismo esquema, con las credenciales en un Secret:

1

kubectl -n cert-manager create secret generic acme-dns --from-file=acmedns.json=./acmedns.json

1
2
3
4
5
6
7
8
9

{
  "example.com": {
    "username": "eabcdb41-d89f-4580-826f-3e62e9755ef2",
    "password": "<password del registro>",
    "fulldomain": "d420c923-bbd7-4056-ab64-c3ca54c9b3cf.auth.example.com",
    "subdomain": "d420c923-bbd7-4056-ab64-c3ca54c9b3cf",
    "allowfrom": ["203.0.113.0/24"]
  }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-dns
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: letsencrypt-dns-account-key
    solvers:
    - dns01:
        acmeDNS:
          host: https://acme.example.com
          accountSecretRef:
            name: acme-dns
            key: acmedns.json

La clave del JSON es el dominio del certificado; para *.example.com y example.com vale la misma entrada (el CNAME _acme-challenge.example.com cubre ambos). Cada dominio distinto necesita su registro y su CNAME.

Trampas

• allowfrom con la IP que ve acme-dns: la pública de salida del servidor o del clúster, no la del pod. Si falla el /update con 401, es esto o la contraseña.
• TTL del CNAME: ponlo bajo (60–300 s) la primera vez; con un TTL de una hora, un error en el CNAME tarda una hora en corregirse a ojos de Let’s Encrypt. El TXT lo sirve acme-dns con TTL 1.
• Puerto 53 de verdad: acme-dns tiene que ser alcanzable por UDP y TCP desde Internet, y ser el NS de auth.example.com en tu zona padre. Sin el registro NS, la delegación no existe y la validación devuelve NXDOMAIN.
• Un registro por dominio, no por servidor: si tres servidores piden certificados para example.com, comparten el mismo registro y el mismo acmedns.json, o cada uno registra el suyo y el CNAME solo puede apuntar a uno. Comparte las credenciales.
• --manual renueva bien porque el hook está guardado en /etc/letsencrypt/renewal/<dominio>.conf; lo que no puedes es cambiar el hook sin volver a ejecutar certonly.
• Versión: acme-dns 2.0.2 es de febrero de 2025 y el proyecto sigue activo; el hook de certbot no ha cambiado en años y funciona con Python 3 tras corregir el shebang.

Referencias: acme-dns, acme-dns-certbot-joohoi y ACMEDNS en cert-manager.

Ver también

• cert-manager: el reto HTTP-01 devuelve 308 — cuando HTTP-01 es suficiente y no lo es.
• HAProxy en pfSense con ACME y Cloudflare — DNS-01 con el token del proveedor, el caso que acme-dns evita.
• DKIM de 2048 bits en un TXT partido — otro registro DNS que se rompe por detalles.

1
2

PUB=$(openssl rsa -in dkim.key -pubout -outform DER 2>/dev/null | base64 | tr -d '\n')
echo "v=DKIM1; k=rsa; p=$PUB" | fold -w 255 | sed 's/.*/"&"/' | paste -sd' ' -

Sale el valor listo para pegar en el proveedor de DNS, dos cadenas entre comillas separadas por un espacio:

1

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvs7EROOYh35C/1s7M//pIaRvu1XWXzdexgBR2dO7eq1oDw+X08BNJUVUEte3z7os5CNeP7YfZrAqyDJvA59wMK1qul6oHyy7z5P1aB4zNczvO7SZ20HogWjHjzYJ0qwmSUUtjlKvECQzoTCbS/F0gB9rdUZN02MJopDs8YWcohy8oqNLnrflHdxWm6jAb3sSa" "EQReu6iRKKPiXTGUISSetY+iXLo2j/2c5g5ppiIYkUTq58asamMNiCzB7BeF4WNkjz2P+9IJmmtkkJ0M/U4oThUMvBBtQ/XUV4i2N4PGB359G5d/PIMiCj4go2axA4p8ul7Qafbtv0fyPwOIGSojwIDAQAB"

Las dos van en el mismo registro TXT. Quien verifica DKIM las concatena sin espacios. Si el texto te lo dio Google Workspace o Microsoft 365 y no tienes la llave privada, es lo mismo sin el openssl: echo "<valor>" | fold -w 255 | sed 's/.*/"&"/' | paste -sd' ' -.

El problema

Un registro TXT se compone de una o más character-strings y cada una tiene un tope de 255 bytes (RFC 1035). El registro entero puede ser mucho más largo; lo que no puede es tener una sola cadena de 410 caracteres.

Google Workspace y Microsoft 365 generan llaves de 2048 por defecto, y con razón: 1024 está desaconsejado desde la RFC 8301. Así que hoy casi cualquier DKIM nuevo tropieza con esto, y cada proveedor reacciona distinto:

La RFC 6376 (§3.6.2.2) obliga a los verificadores a concatenar las cadenas antes de usarlas, así que partir la llave no es un truco: es el formato previsto.

Por proveedor

BIND / archivo de zona

1
2

selector._domainkey  300  IN  TXT  ( "v=DKIM1; k=rsa; p=MIIBIjANBgkq...primera parte"
                                     "segunda parte...IDAQAB" )

Route 53

En la consola, en Value pega las dos cadenas entre comillas separadas por un espacio o un salto de línea. Por CLI el valor es una sola string con las comillas escapadas:

1
2
3
4
5

aws route53 change-resource-record-sets --hosted-zone-id Z0123456789EXAMPLE --change-batch '{
  "Changes": [{"Action": "UPSERT", "ResourceRecordSet": {
    "Name": "selector._domainkey.example.com", "Type": "TXT", "TTL": 300,
    "ResourceRecords": [{"Value": "\"v=DKIM1; k=rsa; p=...primera parte\" \"segunda parte...\""}]
  }}]}'

Google Cloud DNS

En la consola, mismo formato en el campo de datos. Con gcloud:

1
2
3

gcloud dns record-sets create selector._domainkey.example.com. --zone=example-zone \
  --type=TXT --ttl=300 \
  --rrdatas='"v=DKIM1; k=rsa; p=...primera parte" "segunda parte..."'

Con Terraform (google_dns_record_set), un solo elemento en rrdatas con las comillas escapadas:

1

rrdatas = ["\"v=DKIM1; k=rsa; p=...primera parte\" \"segunda parte...\""]

Cloudflare

Pega el valor completo en Content; el panel lo parte al guardar. Al consultarlo con dig verás dos cadenas aunque tú metiste una: es normal.

Verificar

1

dig +short TXT selector._domainkey.example.com

Lo esperado es "v=DKIM1; k=rsa; p=MIIB..." "...IDAQAB": dos cadenas, en un solo registro. Después comprueba que la llave decodifica a 2048 bits, lo que confirma que no se perdió ningún carácter en el corte:

1
2
3
4

dig +short TXT selector._domainkey.example.com \
  | tr -d '" \n' | sed -E 's/.*p=([A-Za-z0-9+/=]+).*/\1/' \
  | base64 -d | openssl pkey -pubin -inform DER -noout -text | head -1
# Public-Key: (2048 bit)

Si base64 protesta, se coló un espacio dentro de la llave o faltan caracteres. Cierra con un correo de prueba y Authentication-Results: ... dkim=pass en la cabecera; para mirarlo con más detalle, el DKIM Inspector de dmarcian.

Trampas

• El corte puede ir en cualquier sitio, incluso a media base64, pero sin meter espacios dentro de la llave. El espacio entre las dos cadenas separa cadenas, no forma parte del dato.
• No dupliques comillas. Si el panel ya las pone por ti y pegas "...", dig devuelve "\"v=DKIM1...\"" y el verificador falla.
• Un registro, no dos. Dos TXT distintos con el mismo nombre son dos valores independientes, y ninguno es una llave válida.
• 2048 es el punto medio. 4096 son tres cadenas y una respuesta DNS que se acerca al límite UDP; funciona, pero no gana nada para DKIM.
• Rotación: publica la llave nueva con otro selector, cambia el firmante, y borra el selector viejo después del TTL. Nunca edites el selector en uso.
• SPF tiene el mismo límite, pero un SPF que no cabe en 255 suele ser señal de demasiados include:; ahí la solución es acortarlo, no partirlo.

Referencias: Google Workspace — problemas con DKIM, AWS re:Post — CharacterStringTooLong y el DNS record splitter de Mailhardener si prefieres no usar fold.