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>
chemavxandClaude Opus 4.8
af162bf34d