Todos los fallos del log eran el mismo: cada ciclo de 5 min intentaba detectar
la IP v6 contra api.cloudflare.com/cdn-cgi/trace, agotaba los 5s de
DETECTION_TIMEOUT y terminaba en "No valid IPv6 addresses were detected".
34 de 34 errores en las últimas 400 líneas; ni uno solo de IPv4.
Aquí no hay IPv6: la única dirección v6 global de los nodos es la ULA de
Tailscale (fd7a:115c:a1e0::/48) y no hay ruta a internet por v6. IP6_PROVIDER
no estaba puesto y cae por defecto en cloudflare.trace, así que lo intentaba
igual. Ahora va explícito a "none".
No se pierde ningún registro: no hay AAAA de origen que mantener. Los AAAA que
publica theexclusionzone.com son de Cloudflare (2606:4700::/32), sintetizados
por ser proxied, y el DDNS nunca los tocó.
Importa más de lo que parece: ese ruido constante es lo que haría invisible un
fallo de verdad en el servicio del que dependen los tres dominios.
De paso, fuera del fichero dos anotaciones que no son configuración deseada
sino estado del controlador: last-applied-configuration (además describía la
config de una sola zona, anterior al alta de los dos blogs) y
deployment.kubernetes.io/revision, que el fichero fijaba en 1 cuando la viva
iba por la 8.
Verificado con kubectl diff antes de aplicar (único cambio: +IP6_PROVIDER), y
después: el arranque ya no anuncia proveedor IPv6, comprueba los 7 registros A
y lleva 0 errores.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The theexclusionzone.com (Ghost EN) zone was never in DOMAINS, so favonia
never updated its origin A records. When the ISP rotated the public IP, the
EN records went stale and Cloudflare returned 522 (apex+www are proxied).
Add all three EN records to DOMAINS and use favonia 1.16.2's per-domain
PROXIED expression so apex+www stay orange while the wildcard and the
chemavx/zona zones stay grey, all from one DDNS instance.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
chemavxandClaude Opus 4.8