Understanding DNS Fall Through and Fall Back: A Modern Engineering Perspective

In today`s exceedingly dynamic environments, DNS (Domain Name System) performs a essential function in making sure seamless connectivity and provider availability. While DNS primarily resolves domain names to IP addresses, scenarios often arise where primary resolution mechanisms fail. This is where DNS Fall Through and DNS Fall Back mechanisms come into play. These techniques enhance resilience, optimize resolution paths, and ensure service continuity.

In this blog, we’ll explore the need for these strategies, why they have gained prominence, and practical examples across different environments.

Why DNS Fall Through and Fall Back?

Modern networking infrastructures — whether cloud-native, hybrid, or multi-cloud — are getting increasingly complex.
They involve:

• Highly distributed systems (e.g., microservices).
• Multiple DNS zones (internal, external, public, private).
• Dynamic scaling (e.g., autoscaling in Kubernetes clusters).

Failures in DNS resolution can arise due to:

1. Network outages or latency issues.
2. Misconfigured DNS records.
3. Service provider downtime (e.g., cloud provider’s DNS service).
4. Load balancing or failover mechanisms requiring dynamic resolution paths.

Core Concepts: Fall Through vs. Fall Back

1. DNS Fall Through

• Definition: Fall through occurs when a DNS resolver tries to resolve a query but lacks the necessary information (e.g., domain not within its authoritative or cached scope). Instead of returning a failure, it forwards the query to another resolver for further processing.
• Focus: Query-specific delegation to alternate resolvers when the current resolver cannot handle the query.
• Typical Use Case: Multi-zone DNS environments where different resolvers manage different domains.

2. DNS Fall Back

• Definition: Fall back occurs when the primary DNS resolver fails entirely (e.g., due to a server crash or network failure). The system then automatically switches to a pre-configured secondary or backup resolver.
• Focus: Resiliency in case of resolver or server failure.
• Typical Use Case: Ensuring high availability and fault tolerance for DNS services.

Key Benefits

1. Resilience: Ensures high availability of DNS resolution even during failures.
2. Improved Latency: Reduces query time by leveraging optimal resolvers.
3. Load Balancing: Distributes DNS resolution across multiple resolvers, avoiding single points of failure.
4. Fault Isolation: Isolates DNS misconfigurations or failures in specific zones or services.

Real-World Scenarios and Implementations

Let’s dive deeper into how to configure DNS Fall Through and Fall Back across different environments and tools. These configurations help you implement resilient DNS setups in real-world scenarios.

1. Multi-Cloud Environments

In multi-cloud setups, applications might rely on different DNS providers depending on the region or availability zone. For instance:

• Primary Resolver: Cloud provider’s DNS (e.g., AWS Route 53).
• Fall Back: Public DNS (e.g., Google Public DNS or Cloudflare’s 1.1.1.1) to ensure continuity during provider-specific outages.

2. Kubernetes Internal DNS

In Kubernetes clusters, the CoreDNS service is responsible for resolving internal service names. However, misconfigurations or load on CoreDNS could lead to resolution failures. A common strategy:

• Primary Resolver: CoreDNS for internal services (cluster.local).
• Fall Through: External DNS (e.g., for domains outside the cluster).
  CoreDNS supports fall-through using configuration like:

forward . 8.8.8.8 1.1.1.1

3. Corporate Networks with Split-Horizon DNS

Corporate networks often use split-horizon DNS, resolving internal resources via private resolvers and external domains via public DNS. Failures in the internal DNS resolver could leverage:

• Primary Resolver: Internal DNS for private zones.
• Fall Through: Public DNS for external domains.
• Fall Back: Secondary internal DNS servers.

Configuration Examples

1. BIND DNS: Configuring Fall Through

BIND DNS (Berkeley Internet Name Domain) is a widely-used DNS server. It supports fall-through behavior through forwarders.

Fall Through Mechanism in BIND:

• If BIND receives a query that it cannot resolve using its authoritative or cached data, it falls through by forwarding the query to an external resolver.

Key Directive:

• forwarders: Specifies the IP addresses of alternate resolvers to query.
• forward only: Ensures that queries are not resolved recursively by BIND itself if the forwarders fail.

Configuration:

options {
    directory "/var/named";
    forwarders {
        8.8.8.8;  # Google Public DNS
        1.1.1.1;  # Cloudflare DNS
    };
    forward only;  # Queries will only use forwarders
};

Detailed Workflow:

1. A query for example.com arrives.
2. BIND checks its local authoritative data and cache.
3. If no record is found, the query falls through to the forwarders.
4. First, it queries 8.8.8.8. If unsuccessful, it falls through to 1.1.1.1.

Benefits:

• Efficient handling of queries for external domains.
• Reduces query latency by avoiding recursive resolution attempts.

2. CoreDNS in Kubernetes: Fall Through for External Domains

In Kubernetes, CoreDNS handles internal service discovery (.svc.cluster.local) but can be configured to fall through for external domains.

Fall Through Mechanism:

• CoreDNS resolves internal Kubernetes services and forwards any unresolved queries to external resolvers for non-cluster domains.

Configuration in Corefile:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            fallthrough in-addr.arpa ip6.arpa
        }
        forward . 8.8.8.8 1.1.1.1
        cache 30
        loop
        reload
        loadbalance
    }

Detailed Workflow:

1. Internal queries for my-service.svc.cluster.local are resolved by CoreDNS.
2. Queries for externaldomain.com fall through to 8.8.8.8 and, if needed, 1.1.1.1.

Benefits:

• Ensures seamless resolution for both internal and external domains.
• Provides flexibility in managing multiple DNS zones.

3. DNSMasq: Lightweight Fall Through and Fall Back

DNSMasq is a simple, lightweight DNS forwarder, often used in smaller environments.

Fall Through Mechanism:

• Queries for specific domains are routed to a specified DNS server.
• If no matching domain is found, DNSMasq falls through to default resolvers.

Configuration:

server=/internal.example.com/192.168.1.1  # Internal resolver
server=8.8.8.8                           # Fall through for non-matching domains
server=1.1.1.1                           # Additional fall-through resolver

Fall Back Mechanism:

• If 192.168.1.1 is unavailable, fallback resolvers like 8.8.8.8 and 1.1.1.1 are used.

Detailed Workflow:

1. Query for internal.example.com → 192.168.1.1.
2. If 192.168.1.1 fails, queries fall back to 8.8.8.8 and then to 1.1.1.1.

Benefits:

• Simple yet effective mechanism for managing internal and external domains.
• Lightweight with minimal resource usage.

4. AWS Route 53: Failover and Fall Back

AWS Route 53 offers powerful DNS management with built-in failover mechanisms.

Fall Back Mechanism in Route 53:

• Route 53 uses health checks to monitor the primary resolver or resource.
• If the primary fails, DNS queries automatically fall back to a secondary endpoint.

Configuration:

1. Create Health Checks:

• Monitor the primary DNS server or application endpoint.

2. Configure DNS Records:

• Primary record: Resolves to primary endpoint (e.g., 10.0.0.1).
• Secondary record: Resolves to fallback endpoint (e.g., 10.0.0.2).

Detailed Workflow:

1. Query is directed to the primary endpoint.
2. If the health check for the primary fails, Route 53 automatically falls back to the secondary.

Benefits:

• Ensures high availability and fault tolerance.
• Seamless failover without user intervention.

5. Linux System-Level DNS (/etc/resolv.conf)

On Linux, DNS fallback is implemented at the system level using multiple resolvers in /etc/resolv.conf.

Fall Back Mechanism:

• If the first resolver fails, the system falls back to subsequent resolvers.

Configuration:

nameserver 192.168.1.1  # Primary DNS
nameserver 8.8.8.8      # First fallback
nameserver 1.1.1.1      # Second fallback

Detailed Workflow:

1. The system queries 192.168.1.1.
2. If 192.168.1.1 is unreachable, it falls back to 8.8.8.8 and then to 1.1.1.1.

Benefits:

• Simple, system-wide configuration.
• Ensures DNS resolution continues during primary resolver failures.

6. Istio Service Mesh: Fall Through for External Services

Istio facilitates service discovery within a mesh and external services through DNS fall-through.

Fall Through Mechanism:

• Queries not resolved within the mesh fall through to external DNS resolvers.

Configuration:

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: external-dns
spec:
  hosts:
  - "*.externaldomain.com"
  location: MESH_EXTERNAL
  resolution: DNS
  addresses:
  - 8.8.8.8
  - 1.1.1.1

Detailed Workflow:

1. Istio resolves internal mesh queries.
2. External queries fall through to public DNS (e.g., 8.8.8.8).

Benefits:

• Enhances service discovery across hybrid environments.
• Reduces dependency on internal DNS.

Challenges and Considerations

1. Latency Overhead: DNS Fall Back may introduce latency if queries traverse multiple resolvers.
2. Cache Staleness: DNS caching mechanisms can propagate stale results during fallbacks.
3. Complex Configuration: Ensuring correct fall-through/fall-back behavior in multi-environment setups requires meticulous planning.

Conclusion

DNS Fall Through and Fall Back mechanisms have become indispensable in modern distributed systems. They make sure high availability, fault tolerance, and ideal performance. As infrastructures evolve, understanding and leveraging these strategies can be key to creating fault-tolerant and robust systems. They not only enhance system reliability but also contribute significantly to user experience and service uptime.

Do you implement DNS resilience strategies in your environment? Share your thoughts and experiences in the comments!