Skip to content

Multi-Region Setup

Distribute your DNS infrastructure across multiple regions or availability zones for maximum availability and performance.

Spreading within one cluster

This page covers running separate instances per region, each with its own identity and address. If instead you have one Kubernetes cluster spanning several availability zones and want the operator to distribute nameservers across them automatically, see Zone Spreading and Pod Placement — that is handled by spec.placement, and a soft zone spread is applied by default whenever a role has two or more servers.

Architecture Overview

A multi-region DNS setup typically includes:

  • Primary instances in one or more regions
  • Secondary instances in multiple geographic locations
  • Zone distribution across all instances using label selectors

Creating Regional Instances

Primary in Region 1

apiVersion: bindy.firestoned.io/v1beta1
kind: Bind9Instance
metadata:
  name: primary-us-east
  namespace: bindy-system
  labels:
    dns-role: primary
    region: us-east-1
    environment: production
spec:
  replicas: 2
  version: "9.18"
  config:
    recursion: false
    allowQuery:
      - "0.0.0.0/0"
    allowTransfer:
      - "10.0.0.0/8"
    dnssec:
      enabled: true

Secondary in Region 2

apiVersion: bindy.firestoned.io/v1beta1
kind: Bind9Instance
metadata:
  name: secondary-us-west
  namespace: bindy-system
  labels:
    dns-role: secondary
    region: us-west-2
    environment: production
spec:
  replicas: 1
  version: "9.18"
  config:
    recursion: false
    allowQuery:
      - "0.0.0.0/0"

Secondary in Region 3

apiVersion: bindy.firestoned.io/v1beta1
kind: Bind9Instance
metadata:
  name: secondary-eu-west
  namespace: bindy-system
  labels:
    dns-role: secondary
    region: eu-west-1
    environment: production
spec:
  replicas: 1
  version: "9.18"
  config:
    recursion: false
    allowQuery:
      - "0.0.0.0/0"

Distributing Zones Across Regions

Create zones that target all regions:

apiVersion: bindy.firestoned.io/v1beta1
kind: DNSZone
metadata:
  name: example-com
  namespace: bindy-system
spec:
  zoneName: example.com
  type: primary
  instanceSelector:
    matchExpressions:
      - key: environment
        operator: In
        values:
          - production
      - key: dns-role
        operator: In
        values:
          - primary
          - secondary
  soaRecord:
    primaryNs: ns1.example.com.
    adminEmail: admin@example.com
    serial: 2024010101
    refresh: 3600
    retry: 600
    expire: 604800
    negativeTtl: 86400

This zone will be deployed to all instances matching the selector (all production primary and secondary instances).

Deployment Strategy

Option 1: Primary-Secondary Model

  • One region hosts primary instances
  • All other regions host secondary instances
  • Zone transfers flow from primary to secondaries
graph LR region1["Region 1 (us-east-1)<br/>Primary Instances<br/>(Master zones)"] region2["Region 2 (us-west-2)<br/>Secondary Instances<br/>(Slave zones)"] region3["Region 3 (eu-west-1)<br/>Secondary Instances<br/>(Slave zones)"] region1 -->|Zone Transfer| region2 region2 -->|Zone Transfer| region3 style region1 fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px style region2 fill:#e1f5ff,stroke:#01579b,stroke-width:2px style region3 fill:#e1f5ff,stroke:#01579b,stroke-width:2px

Option 2: Multi-Primary Model

  • Multiple regions host primary instances
  • Different zones can have primaries in different regions
  • Use careful labeling to route zones to appropriate primaries

Network Considerations

Zone Transfer Network

Ensure network connectivity for zone transfers:

  • Primaries must reach secondaries on TCP port 53
  • Use VPN, peering, or allow public transfer with IP restrictions

Client Query Routing

Use one of:

  • GeoDNS - Route clients to nearest regional instance
  • Anycast - Same IP announced from multiple locations
  • Load Balancer - Distribute across regional endpoints

Failover Strategy

Automatic Failover

Kubernetes handles pod-level failures automatically:

spec:
  replicas: 2  # Multiple replicas for pod-level HA

Regional Failover

For regional failures:

  1. Clients automatically query secondary instances in other regions
  2. Zone data remains available via zone transfers
  3. Updates queue until primary region recovers

Manual Failover

To manually promote a secondary to primary:

  1. Update DNSZone to change primary servers
  2. Update instance labels if needed
  3. Verify zone transfers are working correctly

Monitoring Multi-Region Setup

Check instance distribution:

# View all instances and their regions
kubectl get bind9instances -n bindy-system -L region

# Check zone distribution
kubectl describe dnszone example-com -n bindy-system

Monitor zone transfers:

# Check transfer logs on secondaries
kubectl logs -n bindy-system -l dns-role=secondary | grep "transfer of"

Best Practices

  1. Use Odd Number of Regions: 3 or 5 regions for better quorum
  2. Distribute Replicas: Spread replicas across availability zones
  3. Monitor Latency: Watch zone transfer times between regions
  4. Test Failover: Regularly test regional failover scenarios
  5. Automate Updates: Use GitOps for consistent multi-region deployments

Next Steps