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

example.com.   CAA 0 issue "pki.goog"
example.com.   CAA 0 issue "letsencrypt.org"

1
2
3
4
5

gcloud compute ssl-certificates describe web-cert --global --format='yaml(managed)'
# managed:
#   domainStatus:
#     www.example.com: PROVISIONING | ACTIVE | FAILED_NOT_VISIBLE | FAILED_CAA_FORBIDDEN | FAILED_CAA_CHECKING | FAILED_RATE_LIMITED
#   status: PROVISIONING | ACTIVE

Para que pase a ACTIVE tienen que cumplirse tres cosas a la vez: el A/AAAA del dominio apunta a la IP del balanceador (y a nada más), el certificado está adjunto a un target proxy con su forwarding rule, y ningún CAA de la zona prohíbe a las CAs de Google. Después, hasta 60 minutos.

Por qué

Google emite los certificados gestionados con Google Trust Services (pki.goog) o con Let’s Encrypt, y elige una u otra en cada emisión o renovación. Para validar el dominio hace una comprobación HTTP contra la IP a la que resuelve el nombre, así que hasta que el DNS apunte al balanceador no hay nada que validar. Y como cualquier CA, respeta los registros CAA: si tu zona dice que solo digicert.com puede emitir (política corporativa típica), Google no puede.

Los estados lo cuentan:

El CAA correcto

Sin ningún registro CAA, cualquier CA puede emitir y Google funciona. Si tienes CAA (o tu organización lo exige), añade las dos CAs:

1
2

example.com.   CAA 0 issue "pki.goog"
example.com.   CAA 0 issue "letsencrypt.org"

Poner solo una obliga a Google a usar siempre esa; la documentación lo desaconseja porque una renovación puede salir por la otra. Los CAA se heredan hacia abajo: un CAA en example.com cubre www.example.com si el subdominio no tiene el suyo.

1

dig +short CAA example.com

Certificate Manager: emitir antes de cambiar el DNS

Con los certificados clásicos (compute ssl-certificates) el dominio tiene que apuntar ya al balanceador, lo que en una migración significa unos minutos de HTTPS roto. Certificate Manager resuelve eso con autorización DNS: publicas un CNAME de validación y Google emite el certificado mientras el tráfico sigue en el sitio viejo.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

gcloud certificate-manager dns-authorizations create www-auth --domain=www.example.com
gcloud certificate-manager dns-authorizations describe www-auth --format='yaml(dnsResourceRecord)'
# dnsResourceRecord: name: _acme-challenge.www.example.com. type: CNAME data: xxxx.authorize.certificatemanager.goog.

# publica ese CNAME en tu zona y luego:
gcloud certificate-manager certificates create www-cert \
  --domains=www.example.com --dns-authorizations=www-auth
gcloud certificate-manager maps create web-map
gcloud certificate-manager maps entries create www --map=web-map --certificate=www-cert --hostname=www.example.com
gcloud compute target-https-proxies update web-proxy --certificate-map=web-map

Cuando el certificado esté ACTIVE, cambias el A/AAAA y el corte es cero. Los CAA aplican igual.

Trampas

• Cloudflare u otro proxy delante del balanceador: el A apunta al proxy, no a Google, y la validación falla con FAILED_NOT_VISIBLE. Nube gris durante la emisión, o Certificate Manager con autorización DNS.
• Un certificado gestionado no adjunto a nada no se emite. Crearlo y esperar no hace nada; adjúntalo al target proxy primero.
• Cambiar la lista de dominios crea un certificado nuevo: adjunta el nuevo, espera ACTIVE, y solo entonces quita el viejo del proxy, o tendrás un hueco.
• Wildcards solo con Certificate Manager y autorización DNS; los certificados gestionados clásicos no los admiten.
• DNSSEC mal firmado rompe la lectura de CAA: FAILED_CAA_CHECKING aunque no tengas ningún CAA.

Referencia: Google-managed SSL certificates y Certificate Manager en la documentación de Google Cloud.

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.

Opción limpia (split DNS): Services → DNS Resolver → Host Overrides → app.example.com → IP interna del servidor (192.168.1.50). Los clientes de la LAN tienen que usar el firewall como DNS.

Opción NAT reflection: System → Advanced → Firewall & NAT:

• NAT Reflection mode for port forwards: Pure NAT
• Enable NAT Reflection for 1:1 NAT: ✔
• Enable automatic outbound NAT for Reflection: ✔

Save y prueba desde un cliente de la LAN contra la IP pública.

El problema

El port forward WAN:443 → 192.168.1.50:443 funciona desde Internet. Desde un equipo de la misma LAN, https://app.example.com (que resuelve a la IP pública) responde con la GUI de pfSense, un error de certificado, o Potential DNS Rebind attack detected.

El paquete sale del cliente hacia la IP pública, llega al firewall por la interfaz LAN y ahí se queda: la regla de port forward escucha en la WAN, no en la LAN, y la IP de destino es una dirección del propio firewall. Nunca “sale y vuelve a entrar”.

Opción 1: split DNS

Es la que recomienda Netgate: el nombre resuelve a la IP interna dentro y a la pública fuera. El tráfico va directo, el servidor ve la IP real del cliente y el firewall no toca nada.

1. Services → DNS Resolver → Host Overrides → Add: host app, dominio example.com, IP 192.168.1.50. Si el servicio tiene varios nombres, añade Additional Names.
2. Los clientes deben usar el firewall como DNS (lo normal si el DHCP lo entrega). Un cliente con 8.8.8.8 fijo seguirá yendo a la IP pública.
3. nslookup app.example.com desde la LAN → 192.168.1.50.

Requisitos: el puerto interno y el externo tienen que ser el mismo (si fuera reenvías 8443 → 443, el cliente interno tendrá que usar 443 directamente).

Si usas DNS Forwarder (dnsmasq) en vez del Resolver, el ajuste equivalente está en Services → DNS Forwarder → Host Overrides.

Opción 2: NAT reflection

Cuando no controlas el DNS de los clientes, o hay un montón de puertos, el firewall puede “reflejar” la conexión: reescribe el destino a la IP interna y, con el outbound NAT automático, también el origen, para que la respuesta vuelva por el firewall.

System → Advanced → Firewall & NAT, sección Network Address Translation:

También se puede activar por regla: Firewall → NAT → Port Forward → editar → NAT reflection → Enable (Pure NAT), dejando el global en Disable.

Costes: el servidor ve como origen la IP LAN del firewall (no la del cliente), y todo ese tráfico pasa por el firewall aunque cliente y servidor estén en el mismo switch.

OPNsense

Misma idea, otros menús:

• Split DNS: Services → Unbound DNS → Overrides → Host Overrides.
• Reflection: Firewall → Settings → Advanced → Reflection for port forwards, Reflection for 1:1, Automatic outbound NAT for Reflection.

Trampas

• DNS rebinding. Si en vez de un host override apuntas el Resolver a un DNS externo que devuelve IPs privadas (un DNS interno de otra sede, un proveedor con vistas), Unbound descarta esas respuestas por protección contra rebinding. No desmarques Disable DNS Rebinding Checks en System → Advanced → Admin Access: añade en Services → DNS Resolver → Custom options private-domain: "example.com" y solo ese dominio queda exento.
• El cliente con DNS fijo se salta el split DNS. O lo obligas por DHCP, o lo capturas con una regla de NAT de puerto 53, o usas reflection.
• Pure NAT necesita saber la interfaz y el gateway en el momento de cargar reglas; con WANs dinámicas que cambian de IP, un Filter Reload después del cambio de IP lo arregla.
• Puertos distintos dentro y fuera solo funcionan con reflection; split DNS no traduce puertos.
• Certificados: con split DNS el navegador sigue viendo app.example.com, así que el certificado del servidor sirve igual. Si reflejas por IP pública, también. El error de certificado del principio era el de la GUI del firewall, no el del servidor.

Referencias: Port Forwards from Local Networks y NAT Reflection en la documentación de Netgate.