Interval flag ignored on 0.19.0

[jan-ludvik]

What happened:
I updated to 0.19.0 and looks like interval flag stopped working. The updates to DNS are now every 5- 10s (I have interval of 10m set through helm chart.
What you expected to happen:
Keep interval at 10 minutes to not overload Route53 API.
How to reproduce it (as minimally and precisely as possible):
Update to 0.19.0 with bigger interval configuration.

Anything else we need to know?:
Logging rate on two version (0.17.0 and 0.18.0 at the time of update)

Environment:

• External-DNS version (use external-dns --version): 0.17.0 -> 0.19.0
• DNS provider: AWS/Route53
• Others:

[ivankatliarchuk]

Share applied pod spec. Hard to guess

[jan-ludvik]

I am sorry for delay. The spec didn't change between 0.18.0 and 0.19.0 and it started checking records a lot more frequently

apiVersion: v1
kind: Pod
metadata:
  annotations:
    ad.datadoghq.com/external-dns.check_names: '["external_dns"]'
    ad.datadoghq.com/external-dns.init_configs: '[{}]'
    ad.datadoghq.com/external-dns.instances: |-
      [
        {
          "metrics": [
            "*"
          ],
          "namespace": "external-dns",
          "prometheus_url": "http://%%host%%:7979/metrics",
          "send_distribution_buckets": true
        }
      ]
    ambient.istio.io/redirection: enabled
    kubectl.kubernetes.io/restartedAt: "2025-08-22T10:16:36+02:00"
  labels:
    app.kubernetes.io/instance: external-dns
    app.kubernetes.io/name: external-dns
  name: external-dns-65b67bf9dd-6m24w
  namespace: kube-system
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: external-dns-65b67bf9dd
spec:
  automountServiceAccountToken: true
  containers:
  - args:
    - --log-level=info
    - --log-format=json
    - --interval=10m
    - --source=service
    - --source=ingress
    - --policy=upsert-only
    - --registry=txt
    - --provider=aws
    - --zone-id-filter=<redacted>
    - --zone-id-filter=<redacted>
    - --zone-id-filter=<redacted>
    - --zone-id-filter=<redacted>
    - --zone-id-filter=<redacted>
    - --zone-id-filter=<redacted>
    - --annotation-filter=external-dns.alpha.kubernetes.io/exclude notin (true)
    - --exclude-domains=<redacted>,<redacted>
    - --txt-owner-id=<redacted>
    - --txt-prefix=k8s-dns.
    - --events
    - --aws-batch-change-size=1000
    - --aws-batch-change-interval=10s
    - --exclude-record-types=AAAA
    env:
    - name: AWS_STS_REGIONAL_ENDPOINTS
      value: regional
    - name: AWS_DEFAULT_REGION
      value: us-east-2
    - name: AWS_REGION
      value: us-east-2
    - name: AWS_ROLE_ARN
      value: arn:aws:iam::<redacted>:role/<redacted>
    - name: AWS_WEB_IDENTITY_TOKEN_FILE
      value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
    image: <redacted>:v0.19.0
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 2
      httpGet:
        path: /healthz
        port: http
        scheme: HTTP
      initialDelaySeconds: 10
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 5
    name: external-dns
    ports:
    - containerPort: 7979
      name: http
      protocol: TCP
    readinessProbe:
      failureThreshold: 6
      httpGet:
        path: /healthz
        port: http
        scheme: HTTP
      initialDelaySeconds: 5
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 5
    resources:
      limits:
        cpu: 50m
        memory: 200Mi
      requests:
        cpu: 5m
        memory: 40Mi
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      privileged: false
      readOnlyRootFilesystem: true
      runAsGroup: 65532
      runAsNonRoot: true
      runAsUser: 65532
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-nsfmj
      readOnly: true
    - mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
      name: aws-iam-token
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: <redacted>
  nodeSelector:
    <redacted>
  preemptionPolicy: PreemptLowerPriority
  priority: 2000000000
  priorityClassName: system-cluster-critical
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext:
    fsGroup: 65534
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  serviceAccount: external-dns
  serviceAccountName: external-dns
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoSchedule
    key: dedicated
    operator: Equal
    value: ondemand-system
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: aws-iam-token
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          audience: sts.amazonaws.com
          expirationSeconds: 86400
          path: token
  - name: kube-api-access-nsfmj
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace

[klasvo]

I am experiencing the same issue upgrading helm chart from 1.18.0 to 1.19.0 (app version 0.18.0 to 0.19.0). My helm values are as follows:

extraArgs:
- --managed-record-types=A
- --min-event-sync-interval=1m
interval: 30m
logFormat: json
logLevel: debug
policy: sync
provider:
  name: webhook
  webhook:
    ...
sources:
- service
- ingress
triggerLoopOnEvent: true
txtOwnerId: external-dns

Downgrading back to 1.18.0/0.18.0 immediately fixes the issue

[johnjeffers]

Seeing the same behavior. I was stuck on 0.17.0. Could not upgrade to 0.18.0 because of this, and just upgraded to 0.19.0 only to find this new regression. Back to 0.17.0.

[TobyTheHutt]

What you can (maybe) do:

• Disable event-triggered runs (turn off --events) or set --min-event-sync-interval to the same value as --interval
• Reduce the event volume watched by the service source by restricting to --service-type-filter=LoadBalancer and add namespace/label filters to reduce informer churn
• For Route53, enable provider-side throttling (--aws-batch-change-interval, --aws-batch-change-size, --provider-cache-time, --aws-zones-cache-duration) to lower API load

Sustainable fix:
We can make sure in controller.ScheduleRunOnce, that events cannot schedule runs earlier than --interval. This would align with the controller contract and stop the 5-10s loops.
Additionally in the service source, we'd only wire the Node informer when node data is actually needed (e.g. headless + endpoints-type=NodeExternalIP or publish host IP), and gate ScheduleRunOnce on address-set diffs to ignore heartbeat-only updates.

I'll try to come up with a PR.

Why this happens at all:
With 0.19.0 the service source started wiring the --events handler to the shared node informer. Since the default service type filter is empty, every node is observed. This means, the handler now fires on every node status heartbeat. The change supposedly fixed issues #3169 and #4955.

Basically, since min-event-sync-interval still defaults to 5s, every heartbeat forces a reconciliation every few seconds, regardless of --interval.

How this came to be:
Prior to 0.19.0, the event handler for the service source only subscribed to the service informer. Unless a Service actually changed, the controller waited for the configured --interval.