IP Anycast Explained: BGP Anycast for DNS and CDNs and Failure Modes

IP anycast is the practice of announcing the same IP address, or the same covering prefix, from several independent locations so that the routing system delivers each packet to one of them. On the Internet that routing system is BGP, so a client reaches whichever instance its own network's BGP policy prefers, which is often but not always the closest one. DNS root servers, top level domain operators, public resolvers and content delivery networks use it to spread load, cut latency and absorb denial of service traffic, at the price of failure modes unicast does not have: catchments you do not control, TCP sessions that break when routes shift, black holes when a dead node keeps announcing, and hijacks that look like one more instance.

This post goes one level below our BGP explainer, our guide to getting an ASN and announcing your own prefix and our DNS protocol explainer, which cover sessions, address space and DNS messages. Here we stay on service anycast over BGP. First hop anycast gateways are a different use of the idea, covered in our VXLAN and EVPN and VRRP posts.

Key takeaways

• Anycast addresses are, in RFC 7094's words, "syntactically indistinguishable from unicast addresses." The behavior comes entirely from one prefix being reachable at more than one place.
• The first formal description was RFC 1546 (November 1993). Operational practice is RFC 4786, BCP 126 (December 2006); the architectural trade offs are RFC 7094 (January 2014).
• BGP has no idea where anything is on a map. The "nearest" instance is the one that wins each network's route selection: local preference first, then AS path length, origin, MED, eBGP over iBGP and interior cost. The resulting region is a catchment, and catchments routinely differ from lowest latency.
• On 25 October 2026 root-servers.org reported 2,049 operational root server instances run by 12 independent operators.
• Anycast suits short transactions such as DNS over UDP. A route change during a long TCP session moves it to an instance with no state, and the connection breaks.
• A node must withdraw when its service is unhealthy or it black holes its catchment, but it must not flap, and under a sustained attack withdrawing can just move the attack to the next node.
• Publish a ROA for every origin AS that announces an anycast prefix, avoid maxLength (RFC 9319), and consider a unique origin ASN per node (RFC 6382).

What anycast is, and what the RFCs say

Unicast, multicast, broadcast and anycast

RFC 7094 describes anycast delivery as best effort delivery "to one interface among the set of interfaces asserting reachability for the address," and notes the property that makes it both useful and risky: "it is not considered an error to assert the same anycast address on multiple interfaces." The routing system cannot tell a legitimate extra instance from an illegitimate one.

The RFC separates off link anycast, which relies on routing preferences and hop by hop forwarding and works for IPv4 and IPv6, from on link anycast, a formal IPv6 Neighbor Discovery feature with no IPv4 equivalent. This post is about off link anycast.

RFC 1546: the 1993 definition

RFC 1546, "Host Anycasting Service," was published in November 1993 by the Internet Research Task Force as an Informational memo describing "an experimental service." Its definition still holds: best effort delivery of a datagram to at least one of the hosts serving the anycast address. It also saw the hard part. UDP is easy because each datagram stands alone, but "two successive TCP segments" could land on different hosts. It proposed using the anycast address only for the initial SYN and switching to the real address of whichever host answered. That TCP change was never deployed.

RFC 3258: DNS anycast as "shared unicast"

RFC 3258 (April 2002) is the first specification of DNS anycast, under the name "shared unicast addresses." It argued no routing changes were needed beyond announcing the address from each site, and advised that when a server fails, operators shut down the DNS process rather than withdraw the route, relying on resolvers to time out and try another name server. RFC 7094 later disagreed in part, as the failure section explains.

RFC 4786 (BCP 126): how to operate anycast

RFC 4786, "Operation of Anycast Services" (December 2006), is the reference most operators work from. Its vocabulary:

• Service Address: the address clients use.
• Anycast Node: one location, a single host or a cluster, presenting "a unique path to the Service Address."
• Catchment: "the topological region of a network within which packets directed at an Anycast Address are routed to one particular node."
• Global and local nodes: a global node's route propagates everywhere; a local node is deliberately visible only to a subset, such as one Internet exchange.

Its stated goals include coarse load distribution, containing attacks and flash crowds within catchments, lower response times and reducing a list of servers to one address. It then works through protocol suitability, node placement, signalling availability, covering prefixes, damping, reverse path forwarding checks, data synchronisation, node autonomy and node identification.

RFC 7094: the architectural view

RFC 7094, "Architectural Considerations of IP Anycast" (January 2014), records the history, including an Anycast BOF at IETF 46 in November 1999 that expected global anycast to stay "limited to a small number of key uses," and states that by late 2007 at least 10 of the 13 root name servers were anycast. It analyses transport, middlebox and security implications and deliberately avoids prescriptions: operators should decide which layer of the stack provides redundancy for their service.

Timeline of anycast standards and milestones

How BGP picks the "nearest" instance

People picture packets flowing to the geographically nearest instance, or the one with the lowest round trip time. BGP knows neither. Each node's catchment is simply the set of networks whose route selection ends up pointing at it.

The decision order

RFC 4271 Section 9.1 first gives each route a degree of preference from local policy, expressed in practice as LOCAL_PREF. Only routes that tie on preference reach the Phase 2 tie breakers, which "MUST be applied in the order specified":

1. Fewest AS numbers in the AS_PATH.
2. Lowest ORIGIN value.
3. Lowest MULTI_EXIT_DISC (MED), compared only between routes from the same neighboring AS.
4. eBGP learned routes over iBGP learned routes.
5. Lowest interior cost to the NEXT_HOP.
6. Lowest BGP Identifier, then lowest peer address.

Distance, latency, link speed, load and geography are all missing. The only performance signal is interior cost, a number each network assigns to its own links.

Why policy beats path length

Most networks set local preference by business relationship: customer routes above settlement free peer routes, and peer routes above routes from a paid transit provider. Because local preference comes before AS path length, a long customer route beats a short peer route. A hypothetical example:

The ISP gives the customer route the highest preference and sends the client across an ocean, even though node A is in the same city. Nothing is broken; BGP is doing what the ISP's policy says. RFC 9199 puts it directly: anycast sends queries to the nearest locations "measured by the number of routing hops," and queries "are usually not evenly distributed."

Hot potato inside large networks

When external attributes tie, a large network breaks the tie with interior cost, so each of its routers picks the exit cheapest from where it sits. Customers attached near node A go to A and those near B go to B, which is why anycast performs well across big, well connected networks. A client in a small network with one upstream, by contrast, is pinned to whatever node that upstream prefers.

The knobs operators have

An anycast operator controls only its own announcements:

• Where to announce. Upstreams and exchange peering matter more than node count. RFC 9199 summarises a 2017 study from more than 7,900 RIPE Atlas probes: a root identity with 8 instances had median round trip times comparable to two others with 33 and 144 instances, all between 30 and 32 ms. Its conclusion: "optimizing routing policies is more important than simply adding new instances."
• AS path prepending. Makes one node's path look longer, shrinking its catchment where routes tie on preference. It does nothing where networks choose on local preference.
• BGP communities. Many providers publish communities for prepending toward specific peers, limiting export or lowering preference. They are provider specific.
• Local scope. Announce local nodes with no export or only at an exchange.
• Withdrawal. The bluntest tool, and the one health checks use.

Inside one network, RFC 4786 Section 4.4.3 also warns against per packet load balancing across paths that lead to different nodes, which can split a single TCP handshake. Per flow hashing, the usual router default, avoids it.

How DNS uses anycast

DNS is anycast's best fit. A query and response over UDP is one packet each way, so the transaction ends long before a route change could move it. RFC 4786 Section 4.1 makes that the test: routing must be stable "for substantially longer than the expected transaction time."

Root servers

The root zone is served from 13 identities, a.root-servers.net through m.root-servers.net, by 12 independent operators. On 25 October 2026 root-servers.org reported that "the root server system consists of 2049 operational instances operated by the 12 independent root server operators." The site lists each site with a scope, "Global Site" or "Local Site," which are RFC 4786 global and local nodes. The listing that day ranged from 6 sites for the B and G identities to 389 for the F identity.

The diversity is deliberate. RFC 4786 Section 4.7 recommends different operating systems, server software and routing software across nodes "such that a defect that appears in a single component does not affect the whole system." Twelve operators choosing independently produce exactly that.

The operators' joint report on 23 December 2025, published in July 2026, shows the design under load. A volumetric attack hit 10 of the 13 identities in multiple waves, "peaked at over one terabit per second" across all of them, and lasted just under ten minutes, between roughly 15:37 and 15:48 UTC. RIPE DNSMON data showed impact on several identities to varying degrees. The operators took no mitigation action given the short duration and report "no known reports of end-user visible error conditions," crediting DNS's tolerance of partial reachability among name servers and independent operations.

TLDs and large authoritative operators

RFC 9199 (March 2022) opens with "Deploy Anycast in Every Authoritative Server." The research it cites found that recursive resolvers query all of a zone's authoritative servers, skewed toward faster ones, so every NS record's latency matters and a unicast server in one region cannot serve the world well. Its case study: the .nl zone moved in early 2018 from seven mixed unicast and anycast servers to four anycast servers. Anycast does not replace NS redundancy; a zone should still list several name servers on different prefixes, as our post on whether you need a second DNS provider discusses.

Public recursive resolvers

Public resolvers announce one or two memorable addresses from many sites. Two differences from authoritative service: each site keeps its own cache, so a route change can briefly show a user different cached answers, and each site's outgoing queries use its own unicast addresses, so authoritative servers see which site is asking. Our post on recursive and authoritative DNS servers covers the split.

Identifying which instance answered

RFC 4786 Section 4.9 recommends building node identification into the protocol. DNS has two mechanisms. RFC 5001 (August 2007) defines the NSID option, EDNS option code 3: the client sends an empty NSID request and the server returns an operator chosen identifier, ideally one that does not reveal its unicast management address. Many servers also answer hostname.bind or id.server TXT queries in the CHAOS class, a widely supported convention.

# Ask the instance you reach to identify itself
dig @198.41.0.4 . SOA +norec +nsid
dig @198.41.0.4 hostname.bind CH TXT +short
dig @198.41.0.4 id.server CH TXT +short

Run these from two networks and you will usually get two answers.

How CDNs use anycast, and what happens to long TCP sessions

Content delivery networks resolve a site's hostname to an address announced from every point of presence. One mechanism delivers three benefits: users usually reach a nearby site, load spreads roughly with catchment size, and a distributed attack is split across catchments because each attacking device's traffic goes to the site its own network prefers. RFC 4786 lists this as a goal: a node "can act as a sink for attack traffic originated within its sphere of influence."

The TCP problem

Web connections last seconds to hours. RFC 7094 Section 4.2 describes a route change mid connection: packets start reaching an instance with no record of the connection, which "will likely elicit a connection reset but will certainly result in the disruption of the connection." RFC 4786 warns that long running flows have failure modes "more complex than a simple 'destination unreachable' failure using unicast."

RFC 7094 also acknowledges "expanding deployment (e.g., for content distribution networks)" despite this. Operators keep the odds and the cost of a mid connection move low:

• Stable routing. Catchments rarely change for a given client network outside maintenance, failures or deliberate traffic engineering, and sites are drained gradually where possible.
• Consistent state inside a site. A layer 4 load balancer or consistent hashing keeps each connection on one server, so only moves between sites break connections.
• Short transactions and retries. HTTP clients retry failed idempotent requests.
• Anycast for setup, unicast for the long part. RFC 4786 Section 4.1 suggests an initialisation phase on anycast and a sustained phase on non anycast servers chosen during setup.
• QUIC preferred address. RFC 9000 (May 2021) Section 9.6 lets a server move a client to a preferred address after the handshake, "particularly useful when clients initially connect to an address shared by multiple servers but would prefer to use a unicast address to ensure connection stability."

Middleboxes and reverse path checks

RFC 7094 Section 4.3 warns that NATs and stateful firewalls break designs where the server replies from an address other than the anycast address, because the middlebox holds no state for it. RFC 4786 Section 4.4.5 adds that a set of anycast nodes looks like one multi homed site, so strict reverse path forwarding checks can drop legitimate traffic. Use loose or feasible path modes.

How an instance withdraws itself on failure

A node attracts traffic for as long as its route exists. If the service dies and the route stays, every client in that catchment is black holed while every other node is healthy. RFC 4786 Section 4.4.1 asks for "a coupling between the routing information and the availability of the service."

The usual design

Each anycast server runs a BGP speaker (BIRD, FRRouting, GoBGP and ExaBGP are all used) driven by a health check:

1. The service address sits on a loopback or dummy interface so the server software can bind to it.
2. The BGP daemon announces a route for it to the upstream router.
3. A local health check queries the service through the anycast address every second or few seconds.
4. After a few consecutive failures it withdraws the route, by disabling a protocol in the daemon or removing a watched route.
5. After a run of successes and a minimum hold down since the last withdrawal, it announces again.

If the node loses power or network, the route disappears when the upstream's BGP hold timer expires; BIRD's guide defines hold time as the time "to wait for a Keepalive message from the other side before considering the connection stale." BFD shortens that to under a second, but BFD cannot tell whether the DNS server is answering, so you still need the service check.

What the health check must test

Query a real name through the anycast address on the node itself, and compare something like the SOA serial with the expected value so a node with stale data withdraws too. Check dependencies the service needs to answer correctly, but not a shared dependency that would fail every node at once, and run the check on the node, because a central checker that loses connectivity can withdraw everything simultaneously.

Five ways a withdrawal design goes wrong

1. No withdrawal at all. RFC 7094 Section 4.5 answers RFC 3258's advice: for resolvers in a failed instance's catchment to reach a working one, "a route withdrawal is almost certainly required." Resolvers do retry other NS addresses, but every query pays the timeout first, and stubs pointed at one anycast resolver address have nowhere else to go.

2. Flapping. RFC 4786 Section 4.4.4 explains that a rapidly flapping prefix can be suppressed by route flap damping far from the node, and that some damping implementations penalise by AS path, which can catch healthy nodes with similar paths. It recommends "a minimum delay following a withdrawal" before re advertising and diverse AS paths across nodes.

3. Withdrawing under attack. RFC 7094 Section 4.4 warns that withdrawing during a sustained attack "would simply move the attack to another service instance, potentially causing a cascaded failure." RFC 9199 describes two strategies seen during the November 2015 root server events: shift load by withdrawing or reshaping routes, or keep a site running as one of the "degraded absorbers" that sacrifice their own catchment to protect the rest. It recommends having both in playbooks beforehand.

4. Shared covering prefixes. When several services share one announced prefix, RFC 4786 Section 4.8 lays out the trade off: withdraw only when all fail and clients of the dead service are black holed; withdraw when any fails ("pessimistic withdrawal") and one broken service takes all of them offline at that node; or interconnect nodes so traffic for the failed service can be forwarded, at the cost of autonomy.

5. Withdrawing the last node. If a bad release or a shared dependency fails every node's check, every node withdraws and the service disappears. Some operators cap automatic withdrawal so a minimum set of well provisioned global nodes always stays announced.

Security concerns

Hijacks of anycast prefixes

A hijack works the same against anycast as against anything else: whoever announces your prefix, or a more specific one, attracts traffic from networks that prefer their route. RFC 4786 Section 6.3 adds that "a rogue Anycast Node might be difficult to detect," because legitimate nodes already appear in many places, and RFC 7094 notes that anycast "allows traffic stealing." On the other side, a hijack captures only the catchments where the attacker's route wins, and RFC 4786 Section 6.2 notes that a compromised node can be pulled from routing without taking the service down, if the procedure has been rehearsed. Our posts on route leaks versus hijacks and BGP monitoring with BMP cover detection.

RPKI ROAs for multi origin anycast

RFC 6811 (January 2013) defines route origin validation against Validated ROA Payloads, with three states: NotFound when no ROA covers the prefix, Valid when "at least one VRP Matches the Route Prefix," and Invalid when a ROA covers it but none matches. Networks that drop Invalid routes reject a hijacker announcing your prefix from the wrong origin.

The anycast trap: if nodes announce the same prefix from more than one origin AS, for example one ASN per node or a partner network announcing for a local site, each origin needs its own ROA. Miss one and that node's announcements are Invalid. Validating networks drop them, and the node's catchment quietly shrinks to networks that do not validate. Nothing alarms; the node and its session are up and its traffic simply goes elsewhere. Our post on what RPKI route origin validation does not stop covers the forged origin attacks ROV cannot catch.

RFC 9319 (October 2022, BCP 185) adds that operators "SHOULD use minimal ROAs" and "SHOULD avoid using the maxLength attribute" except in specific cases. A ROA for a /22 with maxLength 24 authorises every /23 and /24 inside it, which lets a forged origin attacker announce a more specific that is RPKI Valid and wins on longest match. For an anycast /24, publish a ROA for exactly that /24 per origin AS.

Unique origin ASN per node

RFC 6382 (October 2011, BCP 169) says globally anycast critical services "SHOULD utilize a unique origin ASN per node where possible." The discriminator lets anyone watching routing see which node a route leads to and detect "leaked or hijacked instances more quickly." It also helps RPKI: each node's ROA is managed separately, so revoking one cannot take every instance offline. The cost is more ASNs and ROAs to keep in sync, which is where the missing ROA mistake comes from.

Protect the data, not just the path

Routing security lowers the odds of reaching a rogue instance; it cannot guarantee it. RFC 4786 recommends protocols with strong authentication or integrity protection for anycast services, and RFC 7094 names DNSSEC among the end to end options. Sign your zones so a rogue instance cannot serve answers that validate (see what DNSSEC protects and what it does not), and serve web traffic over TLS with certificates a rogue cannot obtain.

Protect the control plane on each node

Every node runs a BGP speaker, so every node can announce something it should not. Use strict export filters allowing only the service prefixes (RFC 8212, July 2017, requires eBGP sessions with no policy to import and export nothing by default), max prefix limits on the upstream side, TTL security or session authentication, and read only access for monitoring. BIRD's client offers a restricted mode "which allows just read-only commands."

How operators measure catchments

RIPE Atlas. The RIPE NCC's network has "over 14,000 RIPE Atlas probes" hosted by volunteers. A DNS measurement from many probes to your anycast address with NSID or a CHAOS query returns, per probe, which instance answered and the round trip time: a catchment map and a latency map in one run. The RIPE NCC's DNSMON service monitors root and TLD servers from Atlas anchors and was the data source the root operators cited for December 2025. RFC 9199 notes Atlas's coverage bias toward Europe.

Verfploeter. RFC 9199 describes sending ICMP echo requests from the anycast address to a hit list covering every routed IPv4 /24 and recording which node receives each reply, which reveals each network's catchment. For a new site of the B root identity it predicted 81.6% of traffic would stay at the existing site, against 81.4% measured after launch. At the time it did not support IPv6, because IPv6 hit lists cannot be built by scanning.

Passive data. Each node's query logs show which source prefixes and ASNs it serves and how that changes after a routing change. Public route collectors and your own BMP feeds show the paths others see to each node.

Before any change. RFC 9199 recommends measuring a new site, prepend or community before it goes live, because adding or removing a node "changes the load distribution across all of its locations."

Anycast compared with DNS based load balancing and unicast behind load balancers

Many large services combine all three: anycast for DNS, DNS based steering to choose a site for web traffic, and load balancers inside each site.

The rule of thumb from RFC 4786 and RFC 7094: use anycast where transactions are short and resilience matters more than precise control, and pair it with DNS based steering or unicast where sessions are long or you must decide exactly which site a user reaches. See DNS TTL planning before a migration for the TTL side.

Step by step: a lab anycast DNS service with two BIRD nodes

This lab uses three Linux virtual machines or containers plus a client, with documentation ranges: 192.0.2.0/24 from RFC 5737 and AS numbers 64496 to 64511 from RFC 5398. Keep it isolated. An anycast announcement that leaks out of a lab is a route for space you do not hold.

Both nodes share one origin AS to keep the lab small. In production consider one ASN per node and matching ROAs.

Step 1: put the service address on each node

sudo ip link add anycast0 type dummy
sudo ip link set anycast0 up
sudo ip addr add 192.0.2.53/32 dev anycast0
ip addr show anycast0

Step 2: run the DNS server on the anycast address

NSD's identity answers CHAOS id.server queries and nsid sets the NSID string; its manual says nsid takes "a sequence of hex characters or with ascii_ prefix and then an ascii string."

# /etc/nsd/nsd.conf on node-a (node-b and 10.0.0.12 on the other node)
server:
    ip-address: 192.0.2.53
    ip-address: 10.0.0.11
    identity: "node-a"
    nsid: "ascii_node-a"
    hide-version: yes

zone:
    name: "lab.example"
    zonefile: "/etc/nsd/lab.example.zone"

# /etc/nsd/lab.example.zone (identical on both nodes)
$TTL 300
@       IN SOA ns1.lab.example. hostmaster.lab.example. (
                2026102501 3600 600 86400 300 )
        IN NS  ns1.lab.example.
ns1     IN A   192.0.2.53
health  IN TXT "ok"

sudo nsd-checkconf /etc/nsd/nsd.conf
sudo systemctl restart nsd
dig @192.0.2.53 lab.example SOA +short

Step 3: configure BIRD on each node

The static protocol holds the route the node announces, and the health check enables and disables it. The export filter allows only the service route.

# /etc/bird/bird.conf on node-a (10.0.0.12 for router id and local on node-b)
router id 10.0.0.11;

protocol device { }

protocol static anycast_dns {
    ipv4;
    route 192.0.2.53/32 blackhole;
}

filter export_anycast {
    if net = 192.0.2.53/32 then accept;
    reject;
}

protocol bgp upstream {
    local 10.0.0.11 as 64511;
    neighbor 10.0.0.1 as 64496;
    hold time 9;
    ipv4 {
        import none;
        export filter export_anycast;
    };
}

The blackhole route exists only in BIRD's table so it can be exported. With no kernel protocol on the node it never reaches the forwarding table, so local delivery through the dummy interface still works. BIRD's guide describes these as special routes that "silently drop the packet," which is why they must not be exported to the node's kernel.

Step 4: configure the upstream router

# /etc/bird/bird.conf on router
router id 10.0.0.1;

protocol device { }

protocol kernel {
    ipv4 { export all; };
}

filter from_anycast {
    if net = 192.0.2.53/32 then accept;
    reject;
}

template bgp anycast_node {
    local 10.0.0.1 as 64496;
    hold time 9;
    ipv4 {
        import limit 10 action disable;
        import filter from_anycast;
        export none;
    };
}

protocol bgp node_a from anycast_node { neighbor 10.0.0.11 as 64511; }
protocol bgp node_b from anycast_node { neighbor 10.0.0.12 as 64511; }

sudo birdc configure
sudo birdc show protocols
sudo birdc show route for 192.0.2.53 all

You should see two routes for 192.0.2.53/32, one via each node, with one marked best after the lower RFC 4271 tie breakers.

Step 5: add the health check

The script withdraws after three consecutive failures and re announces only after five successes and at least 60 seconds since the last withdrawal. BIRD documents enable and disable as acting on "a given protocol instance."

#!/bin/sh
# /usr/local/sbin/anycast-health.sh
ADDR=192.0.2.53
NAME=health.lab.example
PROTO=anycast_dns
FAIL_LIMIT=3
OK_LIMIT=5
HOLD_DOWN=60

fails=0; oks=0; state=up; last_down=0
while true; do
  if dig @"$ADDR" "$NAME" TXT +time=1 +tries=1 +short | grep -q '"ok"'; then
    oks=$((oks + 1)); fails=0
  else
    fails=$((fails + 1)); oks=0
  fi
  now=$(date +%s)
  if [ "$state" = up ] && [ "$fails" -ge "$FAIL_LIMIT" ]; then
    birdc disable "$PROTO" >/dev/null && state=down && last_down=$now
    logger -t anycast-health "withdrew $ADDR after $fails failures"
  elif [ "$state" = down ] && [ "$oks" -ge "$OK_LIMIT" ] && \
       [ $((now - last_down)) -ge "$HOLD_DOWN" ]; then
    birdc enable "$PROTO" >/dev/null && state=up
    logger -t anycast-health "announced $ADDR after $oks successes"
  fi
  sleep 1
done

# /etc/systemd/system/anycast-health.service
[Unit]
Description=Anycast DNS health check
After=bird.service nsd.service

[Service]
ExecStart=/usr/local/sbin/anycast-health.sh
Restart=always

[Install]
WantedBy=multi-user.target

sudo chmod 755 /usr/local/sbin/anycast-health.sh
sudo systemctl daemon-reload
sudo systemctl enable --now anycast-health

In production, also compare the SOA serial with the expected one, and decide whether the checker itself dying should withdraw the route.

Step 6: test from the client

dig @192.0.2.53 lab.example SOA +nsid | grep -i nsid
while true; do
  printf '%s ' "$(date +%T)"
  dig @192.0.2.53 id.server CH TXT +short +time=1 +tries=1 || echo timeout
  sleep 1
done

Step 7: test failover

On the node that is answering, stop the DNS server and watch the log:

sudo systemctl stop nsd
journalctl -t anycast-health -f

Within about three seconds the check withdraws, the router shows one path, and the client loop switches to the other node's identity after a timeout or two. Start NSD again and the node returns only after the hold down. Then try the cases health checks do not cover:

• Power off a node. The route goes when the router's 9 second hold timer expires; BFD makes this faster.
• Stop the health check while NSD is broken. The route stays and the node black holes its catchment, which is why the checker must be supervised and its absence alerted on.
• Flap NSD every few seconds. Confirm the hold down keeps the route stable.
• Withdraw during a long TCP session such as a zone transfer you allow in the lab, and watch the connection break.

Step 8: take it toward production

1. Use a provider independent /24 and /48; RFC 7454 notes longer prefixes are "generally neither announced nor accepted."
2. Publish a ROA for exactly that prefix for every origin AS, without maxLength, and matching IRR route objects.
3. Check the prefix's validity from outside your network before bringing up the second node.
4. Validate on the upstream routers. In BIRD, roa_check() returns ROA_UNKNOWN, ROA_INVALID or ROA_VALID against a table filled by the rpki protocol.
5. Measure catchments with RIPE Atlas before and after every change, and write the withdraw and absorb playbooks RFC 9199 recommends.

Common mistakes

• Announcing without a health check. A BGP session that is up proves only that the BGP daemon runs.
• Checking the wrong thing. A process or open port check misses stale zones and broken backends. Query a real name and check the answer.
• A shared dependency in every check. One central failure then withdraws every node.
• No hold down. A flapping check produces a flapping route, and damping elsewhere can suppress the prefix for far longer than the fault.
• ROAs that miss an origin AS. That node's routes become Invalid wherever validation is enforced, and its catchment silently shrinks.
• ROAs with a broad maxLength. They authorise more specifics you never announce.
• Prefixes longer than /24 or /48. Most networks filter them; host routes only work inside one network.
• Assuming nearest means fastest. BGP chooses by policy, not latency. Measure before you conclude a new node will help a region.
• Withdrawing every node under attack. Decide in advance which sites absorb and which shift load.
• Long lived sessions on anycast with no plan. Hand off to unicast after setup, use QUIC's preferred address, or use DNS based steering.

FAQ

What is IP anycast in simple terms?

One IP address announced from several places at once. Internet routing delivers each client's packets to one of them, usually the one its network prefers, and to the client it looks like a single server.

Is anycast the same as load balancing?

Not exactly. Anycast spreads traffic across sites coarsely, by which networks fall into each catchment, and cannot balance by server load. Most anycast services also run load balancers inside each site.

How does anycast choose the closest server?

It does not measure distance. Each network picks a route with BGP using local preference, AS path length, MED and interior cost. The result is often nearby, but business relationships can send a client much further away.

Does anycast work with TCP?

For short connections over stable routing, yes, and many services rely on it. A route change during a connection moves packets to an instance with no state, which breaks it, as RFC 7094 describes.

How many DNS root server instances are there?

On 25 October 2026 root-servers.org reported 2,049 operational instances run by 12 independent organisations for the 13 root identities. The number changes as sites are added and retired.

Can an anycast prefix be hijacked?

Yes, like any prefix, and a rogue instance can be hard to spot because legitimate ones already appear in many places. ROAs for every legitimate origin, origin validation, monitoring and signed data such as DNSSEC and TLS reduce the risk.

Do I need a separate ROA for each anycast site?

You need one ROA per origin AS, not per site. If every site uses the same ASN, one ROA covers them. If sites use different ASNs, each needs its own ROA for the prefix.

How do I find out which anycast instance I am reaching?

For DNS, use dig +nsid or query hostname.bind or id.server in the CHAOS class. For other services, look for an instance identifier in response headers, or run a traceroute and read the last hops, as in our traceroute guide.

Does anycast stop DDoS attacks?

It divides them rather than stopping them. Each attacking device's traffic goes to the site its own network prefers, so a distributed attack spreads across sites. Sites still need capacity and filtering; see our DDoS explainer.

Where Safeguard fits

Safeguard does not announce routes, run BGP, validate ROAs, measure catchments or mitigate DDoS attacks, and it does not analyze router firmware or network operating systems. The fit is with the software an anycast node runs that your team builds or packages: a Linux host or container image carrying a DNS server or caching proxy, a BGP daemon, a health check in Python, Go or shell, and agents for logs and metrics, each with open source dependencies. Safeguard scans those repositories, container images and SBOMs (safeguard scan --dir ., --image <name>, --sbom <file>), lists the components and versions inside them, matches them against vulnerability databases and ranks findings by reachability. When an advisory lands for a DNS library or a package in your health check, the platform shows which projects contain that component and version, so you know which node images to rebuild and roll out site by site.

Anycast multiplies every software decision by the number of sites: one node image with a vulnerable library is deployed to every location that announces your prefix. Supply chain hygiene still matters here even though routing itself is outside Safeguard's scope, because the node images, health checks and automation that drive announcements are ordinary software with dependencies, and the fix paths below apply to those components rather than to your routers' own operating systems.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at the image you deploy to every anycast site, the same scan lists the packages and versions inside it and their known vulnerabilities before you roll it out.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and it reads the finding and advisory, asks before any command that changes something, moves lodash to 4.17.21, runs npm install and npm test with your approval, and pushes nothing. The same flow fits a dependency bump in the service that runs your health checks, where you want a person to see each change before it reaches every site.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which Safeguard tools Claude can use. A network team can then ask in plain language which of its projects contain a given version of a DNS or BGP library.

Click through it at your own pace, or open it full screen.

To try it on your own node images, download Safeguard and read the CLI documentation.

Quick check

Sources

• RFC 1546: Host Anycasting Service
• RFC 3258: Distributing Authoritative Name Servers via Shared Unicast Addresses
• RFC 4271: A Border Gateway Protocol 4 (BGP-4)
• RFC 4291: IP Version 6 Addressing Architecture
• RFC 4786: Operation of Anycast Services (BCP 126)
• RFC 5001: DNS Name Server Identifier (NSID) Option
• RFC 5398: Autonomous System Number Reservation for Documentation Use
• RFC 5737: IPv4 Address Blocks Reserved for Documentation
• RFC 6382: Unique Origin ASNs per Node for Globally Anycasted Services (BCP 169)
• RFC 6811: BGP Prefix Origin Validation
• RFC 7094: Architectural Considerations of IP Anycast
• RFC 7454: BGP Operations and Security (BCP 194)
• RFC 8212: Default External BGP Route Propagation Behavior without Policies
• RFC 9000: QUIC
• RFC 9199: Considerations for Large Authoritative DNS Server Operators
• RFC 9319: The Use of maxLength in the RPKI (BCP 185)
• root-servers.org
• Root Server Operators: December 2025 DDoS against multiple DNS root servers
• RIPE NCC: RIPE Atlas
• BIRD User's Guide 2.0: Remote control
• BIRD User's Guide 2.0: Filters
• BIRD User's Guide 2.0: Protocols
• NSD documentation: nsd.conf

Last reviewed: 25 October 2026. Root server instance counts change continuously, and BGP behavior differs between implementations and provider policies; check root-servers.org and your platform's documentation before relying on any figure or default described here.