BGP Hijacks and RPKI

What a BGP hijack looks like

If BGP itself is new to you, start with BGP Basics: How Internet Routing Works. In short, each network announces the prefixes it can deliver, and others choose among the paths they hear. A hijack inserts a false announcement into that process. There are three common shapes:

Many hijacks are accidents: a typo in a prefix list, a router that redistributes internal routes into BGP, or a test announcement that escapes. Deliberate hijacks are less common but well documented. Attackers have used them to send spam from borrowed address space, to intercept traffic, and to impersonate DNS servers.

Route leaks are a different problem

A route leak is the propagation of a routing announcement beyond its intended scope. RFC 7908, Problem Definition and Classification of BGP Route Leaks, classifies the common forms. The classic case is a customer that buys transit from two providers and accidentally re-announces routes learned from one provider to the other. The second provider prefers customer routes, so it starts sending traffic for large parts of the Internet through a small network that cannot carry it.

In a leak, the origin AS is usually correct. The prefixes are real and the origin is real; only the path is wrong. That is why RPKI origin validation does little against leaks. The newer defense is BGP roles, specified in RFC 9234, where each side of a session declares whether it is a provider, customer, or peer, and routes are marked so they cannot flow back up to a provider. Strict export filters on customer sessions remain the most effective control today.

How RPKI and ROAs work

RPKI mirrors the way address space is allocated. The five Regional Internet Registries act as trust anchors and issue resource certificates to their members that list the prefixes and ASNs each member holds. A member uses its certificate to sign Route Origin Authorizations (ROAs). A ROA says three things:

The maximum length is the longest prefix the AS may announce from inside that block. A maxLength of 24 means only the /24 itself is authorized; a /25 from the same block is not. Setting maxLength wider than you actually announce, for example /24 with maxLength 28, quietly authorizes more-specifics you never send, which an attacker can then announce with a forged origin. Keep maxLength equal to what you announce unless you have a clear need.

Network operators run relying-party software, often called a validator, that downloads the signed objects from every trust anchor's repository, checks the signatures, and produces a list of validated ROA payloads. Routers fetch that list from the validator using the RPKI-to-Router protocol, defined in RFC 8210, so the routers themselves never handle the cryptography.

Route origin validation in practice

With the ROA above in place, a router that performs route origin validation (ROV) labels each route it receives with one of three states:

The common policy is "drop Invalid, accept Valid and NotFound." NotFound must be accepted because a large share of address space still has no ROA. Dropping Invalid routes is what gives RPKI its value: a more-specific hijack of a prefix with a correct ROA is rejected by every network that enforces it, and the hijack only spreads through networks that do not.

The most common operational failure is self-inflicted. An organization moves a prefix to a new provider, or starts announcing a more-specific for traffic engineering, and forgets to update its ROA. Its own announcement becomes Invalid and quietly disappears from part of the Internet. Update ROAs first, wait for validators to pick them up, then change the announcement.

Protecting your DNS from routing attacks

Name servers are an attractive target because a hijacker who receives queries for your zone can answer them with any records it likes. Several layers help:

• Publish ROAs for every prefix that holds your authoritative name servers, or confirm your DNS provider does so for the addresses it uses. Keep maxLength tight.
• Sign your zone with DNSSEC. A hijacker can capture queries, but it cannot produce valid signatures. Validating resolvers will reject forged answers and return SERVFAIL rather than accept them. That is a failure, but a safe one. See Debugging DNSSEC validation errors for how this looks from the resolver side.
• Spread name servers across networks. Name servers in different prefixes and different autonomous systems, as discussed in Multi-DNS Provider Strategy, mean one hijacked prefix does not take the whole zone.
• Monitor announcements of your prefixes with a BGP monitoring service, so an unexpected origin or more-specific raises an alert in minutes rather than when users complain.

Remember that routing is only one path to taking over a domain. An attacker who controls your registrar account can change the NS records without touching BGP at all, which is covered in Domain Hijacking and Registry Lock.

How DNS Panopticon helps

Website Recon looks up each resolved address in RDAP for the network that holds it, and in BGP routing data for the AS that announces it. If a hostname suddenly resolves to an address announced by an AS you do not recognize, that is worth investigating. Domain Visualizer resolves a domain's public records live and reports on delegation and DNSSEC signals, so you can confirm that the zone is signed and that its name servers are where you expect.