Skip to content

Replication

Implement multi-region DNS replication strategies for global availability.

Replication Models

Hub-and-Spoke

One central primary, multiple regional secondaries:

graph TB primary["Primary (us-east-1)"] sec1["Secondary<br/>(us-west)"] sec2["Secondary<br/>(eu-west)"] sec3["Secondary<br/>(ap-south)"] primary --> sec1 primary --> sec2 primary --> sec3 style primary fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px style sec1 fill:#e1f5ff,stroke:#01579b,stroke-width:2px style sec2 fill:#e1f5ff,stroke:#01579b,stroke-width:2px style sec3 fill:#e1f5ff,stroke:#01579b,stroke-width:2px

Pros: Simple, clear source of truth Cons: Single point of failure, latency for distant regions

Multi-Primary

Multiple primaries in different regions:

graph TB primaryA["Primary A<br/>(us-east)"] primaryB["Primary B<br/>(eu-west)"] sec1["Secondary<br/>(us-west)"] sec2["Secondary<br/>(ap-south)"] primaryA <-->|Sync| primaryB primaryA --> sec1 primaryB --> sec2 style primaryA fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px style primaryB fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px style sec1 fill:#e1f5ff,stroke:#01579b,stroke-width:2px style sec2 fill:#e1f5ff,stroke:#01579b,stroke-width:2px

Pros: Regional updates, better latency Cons: Complex synchronization, conflict resolution

Hierarchical

Tiered replication structure:

graph TB global["Global Primary"] reg1["Regional<br/>Primary"] reg2["Regional<br/>Primary"] reg3["Regional<br/>Primary"] local1["Local<br/>Secondary"] local2["Local<br/>Secondary"] local3["Local<br/>Secondary"] global --> reg1 global --> reg2 global --> reg3 reg1 --> local1 reg2 --> local2 reg3 --> local3 style global fill:#f3e5f5,stroke:#4a148c,stroke-width:2px style reg1 fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px style reg2 fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px style reg3 fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px style local1 fill:#e1f5ff,stroke:#01579b,stroke-width:2px style local2 fill:#e1f5ff,stroke:#01579b,stroke-width:2px style local3 fill:#e1f5ff,stroke:#01579b,stroke-width:2px

Pros: Scales well, reduces global load Cons: More complex, longer propagation time

Configuration Examples

Hub-and-Spoke Setup

# Central Primary (us-east-1)
apiVersion: bindy.firestoned.io/v1beta1
kind: Bind9Instance
metadata:
  name: global-primary
  labels:
    dns-role: primary
    region: us-east-1
spec:
  replicas: 3
  config:
    allowTransfer:
      - "10.0.0.0/8"  # Allow all regional networks
---
# Regional Secondaries
apiVersion: bindy.firestoned.io/v1beta1
kind: Bind9Instance
metadata:
  name: secondary-us-west
  labels:
    dns-role: secondary
    region: us-west-2
spec:
  replicas: 2
---
apiVersion: bindy.firestoned.io/v1beta1
kind: Bind9Instance
metadata:
  name: secondary-eu-west
  labels:
    dns-role: secondary
    region: eu-west-1
spec:
  replicas: 2

Replication Latency

Measuring Propagation Time

# Update record on primary
kubectl apply -f new-record.yaml

# Check serial on primary
PRIMARY_SERIAL=$(kubectl exec -n dns-system deployment/global-primary -- \
  dig @localhost example.com SOA +short | awk '{print $3}')

# Wait and check secondary
SECONDARY_SERIAL=$(kubectl exec -n dns-system deployment/secondary-eu-west -- \
  dig @localhost example.com SOA +short | awk '{print $3}')

# Calculate lag
echo "Primary: $PRIMARY_SERIAL, Secondary: $SECONDARY_SERIAL"

Optimizing Propagation

  1. Reduce refresh interval - More frequent checks
  2. Enable NOTIFY - Immediate notification of changes
  3. Use IXFR - Faster incremental transfers
  4. Optimize network - Low-latency connections between regions

Automatic Zone Transfer Configuration

New in v0.1.0: Bindy automatically configures zone transfers between primary and secondary instances.

When you create a DNSZone resource, Bindy automatically: 1. Discovers secondary instances - Finds all Bind9Instance resources labeled with role=secondary in the cluster 2. Configures zone transfers - Adds also-notify and allow-transfer directives with secondary IP addresses 3. Tracks secondary IPs - Stores current secondary IPs in DNSZone.status.secondaryIps 4. Detects IP changes - Monitors for secondary pod IP changes (due to restarts, rescheduling, scaling) 5. Auto-updates zones - Automatically reconfigures zones when secondary IPs change

Example: 

# Check automatically configured secondary IPs
kubectl get dnszone example-com -n dns-system -o jsonpath='{.status.secondaryIps}'
# Output: ["10.244.1.5","10.244.2.8"]

# Verify zone configuration on primary
kubectl exec -n dns-system deployment/primary-dns -- \
  curl -s localhost:8080/api/zones/example.com | jq '.alsoNotify, .allowTransfer'

Self-Healing: When secondary pods are rescheduled and get new IPs: - Detection happens within 5-10 minutes (next reconciliation cycle) - Zones are automatically updated with new secondary IPs - Zone transfers resume automatically with no manual intervention

No manual configuration needed! The old approach of manually configuring allowTransfer networks is no longer required for Kubernetes-managed instances.

Conflict Resolution

When using multi-primary setups, handle conflicts:

Prevention

  • Separate zones per primary
  • Use different subdomains per region
  • Implement locking mechanism

Detection

# Compare zones between primaries
diff <(kubectl exec deployment/primary-us -- cat /var/lib/bind/zones/example.com.zone) \
     <(kubectl exec deployment/primary-eu -- cat /var/lib/bind/zones/example.com.zone)

Monitoring Replication

Replication Dashboard

Monitor: - Serial number sync status - Replication lag per region - Transfer success/failure rate - Zone size and growth

Alerts

Set up alerts for: - Serial number drift > threshold - Failed zone transfers - Replication lag > SLA - Network connectivity issues

Best Practices

  1. Document topology - Clear replication map
  2. Monitor lag - Track propagation time
  3. Test failover - Regular DR drills
  4. Use consistent serials - YYYYMMDDnn format
  5. Automate updates - GitOps for all regions
  6. Capacity planning - Account for replication traffic

Next Steps