Building a Private Anycast DNS Content Delivery Network with CoreDNS and GoBGP

Introduction to Anycast DNS in Modern Enterprise Infrastructure

In the digital enterprise landscape, network latency and high availability are critical determinants of application performance and user experience. Domain Name System (DNS) resolution is the fundamental first step of every network interaction. If your DNS infrastructure is slow or suffers from downtime, your entire digital ecosystem halts. To mitigate this risk, modern infrastructure engineers leverage Anycast routing.

Traditionally, Unicast routing assigns a unique IP address to a single physical interface. Anycast, conversely, allows multiple geographically dispersed servers to share the exact same IP address. The underlying network routing topology, typically governed by the Border Gateway Protocol (BGP), automatically routes client requests to the topologically nearest available server instance. By decoupling service availability from a single physical machine, Anycast provides inherent load balancing, localized low latency, and robust DDoS mitigation capabilities.

This technical guide provides a comprehensive blueprint for engineering a private Anycast DNS system. By combining CoreDNS, a cloud-native, highly extensible DNS server, with GoBGP, a high-performance BGP implementation written in Go, organizations can deploy a resilient, scalable, and fully controlled internal content delivery and resolution network.

Architectural Overview: The Anycast Ecosystem

Before diving into configuration files, it is crucial to understand how the components interact within an enterprise autonomous system (AS). The architecture consists of three main layers:

The Client Layer: End-user devices or application servers requesting DNS resolution using a standardized Anycast IP address.
The Routing Layer (BGP Peers): Top-of-Rack (ToR) switches or core routers that receive BGP path advertisements and decide the optimal path based on network metrics like AS-path length.
The Service Layer (Anycast Nodes): Multiple independent servers running both CoreDNS and GoBGP concurrently.

Key Concept: The GoBGP daemon on each local server establishes a peering session with the nearest upstream router. It advertises the specific Anycast IP address prefixed as a /32 route (IPv4) or /128 route (IPv6). If a node fails, the GoBGP daemon drops the session, the router removes the route from its table, and traffic automatically converges to the next closest node without human intervention.

Step 1: Setting Up the Infrastructure Prerequisites

To successfully implement this architecture, ensure your environment meets the following specifications:

At least two independent Linux servers (Ubuntu 22.04 LTS or newer recommended) deployed in different network segments or racks.
Upstream switches or routers that support BGP peering and are configured to accept dynamic route advertisements.
A designated dummy network interface configured on each server to host the Anycast IP address locally.
Private Autonomous System Numbers (ASNs) assigned for your routers and your Anycast nodes (e.g., AS 65001 for routers, AS 65002 for nodes).

Configuring the Anycast Dummy Interface

Since multiple servers share the same Anycast IP, this IP must not be bound to the primary physical network interface directly to avoid ARP conflicts on local subnets. Instead, we use a loopback or dummy interface. Edit your network configuration (e.g., via Netplan or systemd-networkd) to add the dummy interface:

# Example command to create a temporary dummy interface for testing
sudo ip link add dev anycast0 type dummy
sudo ip addr add 192.0.2.10/32 dev anycast0
sudo ip link set dev anycast0 up

In this architecture, 192.0.2.10 will serve as our global Anycast DNS address.

Step 2: Configuring CoreDNS for High-Performance Resolution

CoreDNS is favored in cloud-native environments due to its modular design driven by plugins. We will configure CoreDNS to listen on our newly created Anycast IP address and handle requests efficiently.

The Corefile Configuration

Create a configuration file named Corefile. This configuration binds to the Anycast IP, enables caching to minimize upstream load, reads local zone files, and forwards unknown queries to a fallback internal resolver:

192.0.2.10:53 {
    errors
    health {
        lameduck 5s
    }
    ready
    cache 3600 {
        success 10000
        denial 2500
    }
    hosts /etc/coredns/hosts.custom {
        fallthrough
    }
    forward . 10.0.0.1 10.0.0.2 {
        policy round_robin
    }
    reload
}

By utilizing the health and ready plugins, CoreDNS exposes an HTTP endpoint (typically on port 8080) that indicates whether the service is functioning correctly. This endpoint is vital for health-checking scripts running alongside our BGP daemon.

Step 3: Deploying GoBGP for Dynamic Route Advertisement

With CoreDNS prepared to answer queries on the Anycast IP, we must now inform the corporate network that this specific server can handle traffic destined for 192.0.2.10. GoBGP will handle this via an active BGP session.

Writing the GoBGP Configuration

Create a configuration file named gobgp.conf on the node. This file defines the local ASN, the Anycast network to advertise, and the upstream neighbor switch parameters:

[global.config]
  as = 65002
  router-id = "10.0.1.15" # The unique physical IP of Node 1

[[neighbors]]
  [neighbors.config]
    neighbor-address = "10.0.1.1"
    peer-as = 65001
  [neighbors.timers.config]
    connect-retry = 10
    hold-time = 9
    keepalive-interval = 3

[[global.apply-policy.config.export-policy-list]]
  # Reference policy to allow advertising the Anycast prefix

Notice the low hold-time (9 seconds) and keepalive-interval (3 seconds). In a private cloud or enterprise datacenter, aggressive timers ensure that if a node suffers a sudden power or hardware failure, the upstream router quickly tears down the path, minimizing packet loss during failover.

Advertising the Anycast Prefix

Once the GoBGP daemon initializes and establishes a state of Established with the neighbor, execute the following command via the GoBGP CLI to inject the Anycast route:

gobgp global rib add 192.0.2.10/32

Step 4: Implementing Automated Health Checking and Failover

Advertising a route blindly introduces an operational risk: if CoreDNS crashes but the GoBGP process remains healthy, the upstream router will continue sending DNS traffic to a dead node. To prevent this, we must link the BGP advertisements directly to the operational health of CoreDNS.

We can implement a lightweight shell script or daemon process that continuously queries the CoreDNS health endpoint:

#!/bin/bash
ANYCAST_IP="192.0.2.10/32"
ROUTE_ADVERTISED=false

while true; do
    # Check if CoreDNS is responding normally
    if curl -s http://localhost:8080/health | grep -q "OK"; then
        if [ "$ROUTE_ADVERTISED" = false ]; then
            gobgp global rib add $ANYCAST_IP
            ROUTE_ADVERTISED=true
            logger "CoreDNS healthy. Anycast route advertised."
        fi
    else
        if [ "$ROUTE_ADVERTISED" = true ]; then
            gobgp global rib del $ANYCAST_IP
            ROUTE_ADVERTISED=false
            logger "CoreDNS unhealthy! Anycast route withdrawn."
        fi
    fi
    sleep 2
done

This loop guarantees that network paths are dynamically updated based on actual application-level availability, establishing a self-healing infrastructure framework.

Validation and Operational Best Practices

Once your infrastructure is active across multiple locations, rigorous testing is mandatory to validate global state and routing convergence parameters.

Verification Commands

From an external client machine, execute standard diagnostic tools to verify proper data routing and low latency:

dig @192.0.2.10 myservice.internal +nsid: Utilizing the CoreDNS NSID plugin allows you to identify exactly which physical node answered the query.
traceroute 192.0.2.10: Confirm that packets terminate at the network hop corresponding to the closest localized datacenter deployment.

Operational Considerations

When operating a private Anycast DNS system, keep the following architectural constraints in mind:

State Management: DNS over UDP works perfectly with Anycast because it is stateless. However, complex DNS queries that fall back to TCP (or Zone Transfers via AXFR) require persistent TCP handshakes. Ensure your network paths remain stable to avoid routing flips that break active TCP sessions.
Equal-Cost Multi-Path (ECMP): If you want to load-balance across multiple active nodes within the exact same rack, configure your upstream switch to use ECMP routing with consistent hashing algorithms.

Conclusion

Building a private Anycast DNS delivery network utilizing CoreDNS and GoBGP empowers infrastructure teams to gain total control over internal name resolution performance. By shifting high-availability logic away from complex application code and pushing it directly onto standard networking protocols, you achieve predictable, automated failover and sub-millisecond response times across the entire enterprise topology. As you scale out your infrastructure, this baseline architecture will serve as a resilient foundation capable of supporting mission-critical enterprise workloads.