ExternalDNS

External-dns operates by computing a plan to reconcile the desired state (Kubernetes resources) with the current state (DNS provider). If a provider returns a conflict error (e.g., HTTP 409), it indicates a state mismatch rather than a software bug.

Key behaviors:

• No Auto-Correction: External-dns does not automatically resolve arbitrary conflicts to avoid accidentally deleting records that services depend on. It drops some well-known invalid records (like CNAME self-references) but otherwise requires manual intervention.
• Crashloop Amplification: If a conflict causes a hard exit, the resulting crashloop causes Kubernetes informers to perform full LIST calls on every restart, which can lead to Kubernetes API server throttling.

How to resolve conflicts:

1. Ensure Single Ownership: Verify only one external-dns instance owns a specific zone or record set. If using the TXT or DynamoDB registry, use a unique --txt-owner-id per instance and ensure --domain-filter scopes do not overlap.
2. Direct Provider Cleanup: Manually remove or update conflicting records directly in your DNS provider's console.
3. Validate Annotations: Check for invalid definitions, such as mixing CNAME records with A/AAAA records for the same hostname.
4. Check Other Controllers: Ensure no other automation or controllers are writing to the same DNS zone.
5. Emergency Scaling: If the state is highly inconsistent during a migration, scale external-dns to zero, reconcile the DNS state manually, and then scale it back up.

ExternalDNS supports defining multiple targets (IPs or Hostnames) within a single Kubernetes resource (such as an Ingress or Service). Instead of creating separate DNS records for each target, ExternalDNS aims to treat a single resource as the owner of a DNS name and manage all its associated targets as a single unit.

Key Behaviors

• Resource Ownership: A DNS record is owned by a specific Kubernetes resource. This is managed via TXT records that store a back-reference to the resource (e.g., "heritage=external-dns,external-dns/resource=ingress/default/my-ingress-object-name").
• Conflict Resolution: If two different resources (e.g., Ingress A and Ingress B) request the same hostname but provide different targets, ExternalDNS will not allow both to create records. It will choose one (based on a predefined strategy) to prevent one resource from "hijacking" another's record.
• Updates: DNS records are updated only if:
  • The owning resource's target list changes.
  • The owning resource is deleted (allowing the record to be reclaimed by another resource).
  • Other properties like TTL change.

Provider Support

If a specific DNS provider does not fully support multiple targets, the provider implementation is responsible for handling the change list. A common fallback strategy is to use only the first target in the list.

ExternalDNS uses three prioritized sources of information to decide which DNS name to create for a Kubernetes object:

1. Object Specifications & Annotations:
   • Ingress: Uses the hosts specified in the Ingress object or the external-dns.kubernetes.io/hostname annotation. You can force the source using the external-dns.kubernetes.io/ingress-hostname-source annotation with values defined-hosts-only or annotation-only.
   • Services: Uses the external-dns.kubernetes.io/hostname annotation for the LoadBalancer IP, or the external-dns.kubernetes.io/internal-hostname annotation for the Service IP.
2. Compatibility Mode: If the --compatibility flag is set (e.g., --compatibility={mate,molecule}), ExternalDNS parses annotations used by Zalando/Mate or wearemolecule/route53-kubernetes.
3. FQDN Template: If the --fqdn-template flag is provided (e.g., --fqdn-template={{.Name}}.my-org.com), ExternalDNS generates the name using the provided template applied to the service/ingress specifications.