k8gb incorrectly updates Nameserver A record TTL when multiple GSLB objects exist with different TTLs

[steemax]

Description

When multiple GSLB objects exist in the cluster with different dnsTtlSeconds values, the k8gb controller incorrectly applies these TTL values to the Nameserver A record in the DNSEndpoint resource. This results in an infinite loop where the controller continuously changes the Nameserver A record TTL, alternating between values from different GSLB objects.

Steps to Reproduce

1. Create two or more GSLB objects with different dnsTtlSeconds values:

apiVersion: k8gb.absa.oss/v1beta1
kind: Gslb
metadata:
  name: gslb1
  namespace: namespace1
spec:
  ingress:
    ingressClassName: traefik
  resourceRef:
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    matchLabels:
      app: gateway1
  strategy:
    dnsTtlSeconds: 20
    primaryGeoTag: apa
    splitBrainThresholdSeconds: 120
    type: roundRobin

and

apiVersion: k8gb.absa.oss/v1beta1
kind: Gslb
metadata:
  name: gslb2
  namespace: namespace2
spec:
  ingress:
    ingressClassName: traefik
  resourceRef:
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    matchLabels:
      app: gateway2
  strategy:
    dnsTtlSeconds: 10
    primaryGeoTag: apa
    splitBrainThresholdSeconds: 120
    type: roundRobin

2. Observe the DNSEndpoint resource in the k8gb namespace:

apiVersion: externaldns.k8s.io/v1alpha1
kind: DNSEndpoint
metadata:
  annotations:
    k8gb.absa.oss/dnstype: extdns
  name: k8gb-ns-extdns
  namespace: k8gb
spec:
  endpoints:
    - dnsName: common.geo.paywb.com
      recordTTL: 20  # Incorrectly applied TTL
      recordType: NS
      targets:
        - gslb-ns-apa-common.geo.example.com
        - gslb-ns-ipa-common.geo.example.com
    - dnsName: gslb-ns-ipa-common.geo.example.com
      recordTTL: 20  # Incorrectly applied TTL
      recordType: A
      targets:
        - 10.230.107.10

3. Notice that the TTL for the Nameserver A record is constantly changing as the controller alternates between different TTL values from GSLB objects.

Expected Behavior

Changing dnsTtlSeconds in a GSLB object should only affect the DNS records for that specific service.
The Nameserver A record TTL should not be altered based on different GSLB objects’ TTL values.

Actual Behavior

The k8gb controller updates the Nameserver A record TTL based on dnsTtlSeconds from any GSLB object in the cluster, causing continuous updates.

Versions

k8gb: v0.14.0
external-dns: v0.13.4-azure-ns-multiarch
Kubernetes: v1.27

[ytsarev]

@steemax Thanks a lot for the details report and the investigation!

@kuritka @k0da have you seen this behavior in the latest iterations? fixing it should reduce the load on the upstream DNS server, can be a part of recent optimizations

[k0da]

Hi, I don't understand what is meant by Nameserver A record TTL. dnsTTLSeconds is used only in dnsEndpoint for respective application.

Later code had a lot of changes in this regard. Now this is the only appearance of it

[steemax]

hi, i'll try to explain in more detail

we have a DNSEndpoint with annotation
k8gb.absa.oss/dnstype=extdns for example

apiVersion: externaldns.k8s.io/v1alpha1
kind: DNSEndpoint
metadata:
  annotations:
    k8gb.absa.oss/dnstype: extdns
  name: k8gb-ns-extdns
  namespace: k8gb
spec:
  endpoints:
    - dnsName: common.geo.paywb.com
      recordTTL: 20  # Incorrectly applied TTL
      recordType: NS
      targets:
        - gslb-ns-apa-common.geo.example.com
        - gslb-ns-ipa-common.geo.example.com
    - dnsName: gslb-ns-ipa-common.geo.example.com
      recordTTL: 20  # Incorrectly applied TTL
      recordType: A
      targets:
        - 10.230.107.10

this is where the A records for NS servers are stored, and the TTL for them should not change, but it does. When I make a change for just one application in any GSLB resource, it will cause the TTL value for DNSEndpoint with the extdn label to change, although it should only change DNSEndpoint with the k8gb.absa.oss/dnstype=local label

[k0da]

Ok, in next release that's no longer be a case. TTL for GlueA is taken from DNS_ZONES configuration, not GSLB object