Could DNS Solve Internet Routing Security Flaws? Fresh Ideas from IETF 126

The Internet Engineering Task Force (IETF) gathered in Vienna in late July 2026 for its 126th meeting, where network engineers tackled long-standing challenges in how internet traffic finds its way across the globe. Central to those discussions was the Border Gateway Protocol (BGP), the system that networks use to announce which IP addresses they control and how to reach them. While often invisible to everyday users, BGP’s security weaknesses can lead to traffic hijacks, surveillance, and outages. This year, a fresh idea surfaced: using the Domain Name System (DNS) to bring trust to routing announcements.

One topic that drew attention was the unexpected manipulation of the BGP ORIGIN attribute. When a router has multiple paths to the same destination, it uses a strict eight-step decision process to pick the best one. After comparing local preferences and AS path length, it looks at the ORIGIN code, a label that was meant to indicate how a route first entered BGP. The three possibilities are ‘i’ (learned from an internal routing protocol), ‘e’ (from the now-obsolete Exterior Gateway Protocol), and ‘?’ (incomplete, typically from static routes). In theory, this code should never change after being set, but researchers at the IEPG session showed that some networks have been rewriting it. By changing routes to the ‘e’ value, they force other routers to deprioritize certain paths, overriding the usual AS-path-length comparison. This practice first appeared in 2023 and has been growing: measurements now see the EGP origin value on a noticeable percentage of BGP advertisements. One operator openly admitted to using this trick to steer traffic away from distant routers, exploiting ORIGIN’s higher priority in the selection algorithm. Yet, if every network did the same, the benefit would cancel out, a classic case of “it works only if I’m the only one doing it.”

Efforts to add cryptographic security to BGP have been underway for over two decades, but progress has been slow. The AS_PATH attribute, which lists the chain of autonomous systems (ASes) a route has passed through, is particularly vulnerable to forgery. Existing solutions like BGPsec signed the full path but struggled with partial deployment: if any hop along the way didn’t support it, the signature chain broke. A more recent approach is Autonomous System Provider Authorization (ASPA), where each AS publishes a list of its upstream providers. Ideally, every AS relationship becomes known, making it possible to spot implausible paths, like a customer network pretending to be a transit provider. However, in a world where only a few thousand ASPA objects have been published in the Resource Public Key Infrastructure (RPKI), partial deployment creates ambiguity. Is a missing relationship a peer, a Tier-1 network with no providers, or simply an AS that hasn’t published its data? To help, networks can list AS0 as a provider to signal they are transit-free, but the interpretation remains complex. The ASPA draft has undergone 27 revisions over nearly ten years, yet router vendors have been slow to implement it, waiting for a stable RFC before committing resources.

Against this backdrop, PAVA (PAth VAlidation) offers a dramatically simpler model, and it leans heavily on the DNS. The core idea is to break an AS path into overlapping triplets (and end-pairs). For example, a path of four ASes becomes three triplets, each representing a two-step or three-step segment. Each AS would then publish its adjacent relationships in its own DNS zone, using DNSSEC for authenticity. The DNS records would indicate whether each link is an ‘up’ (customer-to-provider), ‘down’ (provider-to-customer), or ‘summit’ (peer-to-peer) relationship. By checking these records, BGP routers can tell if a path contains an invalid sequence, such as jumping from one provider to another without an up-down transition. Because DNSSEC signatures can be tied to the same cryptographic keys already stored in RPKI’s trust anchor, validation becomes seamless. This approach not only eliminates the need for a separate, resource-hungry synchronization protocol (the RPKI’s current Achilles’ heel), but also allows for incremental deployment: if an AS doesn’t publish PAVA records, the path is simply treated as unvalidated rather than blocked. The presentation at IETF 126 showed how DNS, a globally scaled and robust infrastructure, could shoulder the burden of distributing routing security data efficiently.

For everyday internet users, these routing security debates matter more than they might seem. When BGP paths are hijacked, whether accidentally or maliciously, traffic can be redirected through eavesdropping points or blackholed entirely. A DNS-based validation system like PAVA would make such attacks much harder to pull off, especially if combined with widespread adoption of DNSSEC. In the meantime, individuals can take steps to reduce their own exposure. Using a privacy-focused DNS resolver that supports DNSSEC and encrypted transport (such as DoH or DoT) ensures that the first step of any connection, the DNS lookup, is authenticated and shielded from snooping. AEU DNS, for instance, provides DNS-over-HTTPS with built-in ad and tracker blocking, helping users avoid malicious domains that might be used in routing attacks. As the IETF continues to refine these proposals, a more trustworthy internet starts with simple, user-side choices that reinforce end-to-end security.