The Border Gateway Protocol (BGP), also known as the “two-napkin protocol,” is often described as “the glue that holds the Internet together” because it enables networks to exchange reachability information about their IP prefixes and the paths leading to them.
BGP’s original specification (RFC 1105), dating back to 1989, was created when the Internet primarily consisted of universities, research institutions, and governmental networks that operated on mutual trust. As a result, there was no need to incorporate security mechanisms such as authentication and authorization into the protocol. At the time, no one anticipated the Internet would "escape the lab" and become what it is today, interconnecting billions of people worldwide.
This lack of intrinsic security by design has impacted the Internet for decades. Routing attacks, such as BGP hijacks, frequently make headlines. In these incidents, victim networks either experience outages and become unreachable, or have their traffic intercepted and potentially manipulated.
The Criticality of Root DNS Prefixes
Given BGP's inherent vulnerabilities, our team began monitoring critical Internet infrastructure for potential BGP origin hijacks. Specifically, in January 2023, we started using Code BGP (now part of Cisco ThousandEyes) to monitor root DNS prefixes.
The root DNS servers are the authoritative name servers for the DNS root zone. We chose to monitor the BGP prefixes corresponding to the IP addresses of these servers for two main reasons:
- First, the root DNS servers sit at the top of the global DNS hierarchy—they represent critical Internet infrastructure that must be protected.
- Second, root DNS prefixes are typically heavily anycasted. Our intuition was that any potential BGP anomaly against these prefixes would go largely unnoticed because, due to anycast, the impact on the data plane would be minimal or even negligible.
How We Monitor Root DNS Prefixes
To identify and track these events, we use a systematic approach. Identifying the root DNS prefixes and originating autonomous system numbers (ASNs) is straightforward: First, identify the covering prefix of each root DNS server’s IP address in the Default-Free Zone (DFZ). Then, identify the ASN that announces it.
The DFZ refers to the Internet's backbone routing infrastructure, where major ISPs and network operators maintain complete routing tables with specific paths to all global destinations, rather than relying on simple default routes. A covering prefix is the most specific network block that encompasses a particular IP address within the global routing table. Since Internet routing works with address blocks rather than individual IPs, we monitor the advertised prefix that "covers" each root DNS server's address.
For example, B-Root's IPv4 address (199.9.14.201) is covered by its announced prefix, 199.9.14.0/24.
Most root DNS operators use only one ASN to announce the root DNS prefixes, which makes it easy to create alerts based on the rule: “This prefix is allowed to be announced only by this ASN.”
The only notable exception to this rule is Verisign. Verisign is the only root DNS operator that manages two root DNS server clusters, A-Root and J-Root, unlike the other operators, each of which manages just one. Additionally, Verisign implements RFC 6382, meaning it announces its prefixes using a unique ASN for each global anycast node, resulting in over a hundred ASNs. This makes creating alert rules for Verisign a more challenging process, but it is still achievable using the ThousandEyes API.
The BGP Route Visualization view of the ThousandEyes platform, as shown in Figure 1, illustrates Verisign’s deployment and makes it easier to comprehend. This example involves A-Root.
On the left-hand side, we have the BGP monitors, which provide the platform with BGP data. After a number of hops (which are hidden in this view), we see on the right Verisign’s backbone ASN 7342. Then we see all the various ASNs Verisign uses to announce 198.41.0.0/24 (A-Root’s IPv4 prefix), and next to that we have the prefix we are monitoring.
Extensive documentation for creating BGP tests and alert rules is available on the ThousandEyes Docs page, which provides detailed guidance on configuring the ThousandEyes platform for such monitoring.
Historical Insights: Early BGP Anomaly Detections
Our early monitoring efforts, conducted using the now-retired Code BGP platform (which has since been integrated with ThousandEyes), revealed several BGP anomaly events targeting root DNS prefixes.
January 2023: F-Root
On January 27, 2023, the platform detected that AS24028 (REDtone) appeared as the origin of prefix 2001:500:2f::/48, which belongs to the Internet Systems Consortium (AS3557) and is the IPv6 prefix of the “F-Root” domain server.
The event had limited propagation and was observed by only one source, namely the RIPE RIS peer 2406:f400:8:34::1, which resides in Singapore. This limited propagation can be attributed to the prefix being covered by a Resource Public Key Infrastructure (RPKI) Route Origin Authorization (ROA).
February 2023: E-Root and F-Root
On February 25, 2023, the platform detected that AS17639 (Converge ICT Solutions Inc.) appeared as the origin of prefix 2001:500:2f::/48, which is the same prefix as before. It belongs to the Internet Systems Consortium (AS3557) and is the IPv6 prefix of the “F-Root” domain server.
On the same day, at the same time, the same AS17639 (Converge ICT Solutions Inc.) appeared as the origin of prefix 2001:500:a8::/48, which belongs to NASA's Ames Research Center and is the IPv6 prefix of the “E-Root” domain server.
We note that the offending network (AS17639 Converge ICT Solutions) is also mentioned in a report by Aftab Siddiqui for events that took place in 2020. However, we cannot be certain of the intent, as these events might have been misconfigurations.
The event lasted over 18 hours and served as a great example of how a simple task, such as signing your RPKI ROAs, can protect you against origin hijacks and/or misconfigurations. The E-Root prefix is not covered by a ROA, whereas the F-Root prefix is. This resulted in the blast radius of the event being almost three times larger in the case of E-Root compared to F-Root.
June 2023: K-Root
On June 12, 2023, the platform detected that AS201333 (Naquadria S.R.L.) appeared as the origin of prefix 193.0.14.0/24, which belongs to RIPE NCC and is the IPv4 prefix of the “K-Root” domain server.
The event lasted for two hours and had limited propagation, as it was observed only by monitors in Italy. Again, this limited propagation can be attributed to the fact that this prefix is covered by an RPKI ROA.
As always, we communicated our findings to the root DNS operators. The team at RIPE NCC informed us that the AS201333 (Naquadria S.R.L.) network was expected to propagate the K-Root service prefix (as evidenced by the AS25152 object of K-Root in the RIPE database). What is not expected, though, was that they would announce that prefix from their AS! RIPE NCC’s engineers pulled the prefix from this hosted K-Root node, and the issue was resolved.
April 2023: L-Root
On April 28, 2023, the platform detected that AS137661 (Rajcomp Info Services Ltd.) appeared as the origin of the prefix 199.7.83.0/24, which belongs to ICANN and is the IPv4 prefix of the “L-Root” domain server.
This event had multiple characteristics that made it particularly interesting. The invalid announcement was prepended seven times, extending the AS-path length to 11 hops. BGP's "path-hiding" behavior played a crucial role in limiting the event's visibility.
Unlike protocols that might advertise multiple paths to the same destination, BGP follows a "best path only" principle: When a router learns multiple routes to the same network prefix, it evaluates them using factors like AS-path length and local preference, then advertises only the single best path to its neighbors. This means that even malicious or misconfigured routes may never be visible to monitoring systems if better legitimate paths are available.
In this case, the hijacked route, with its artificially lengthened AS-path, was hidden from most of the Internet because shorter, more attractive paths were available, significantly limiting the visibility of the announcement. However, it was picked up by one of our monitors.
We wrote a blog post detailing our findings about this event. Regarding the impact on the data plane, we mentioned that “we can assume that the impact of this event on the data plane is likely negligible” due to the very long AS-path and the anycast nature of this announcement.
Monitoring Root DNS Prefixes With Cisco ThousandEyes
Following the acquisition and integration of Code BGP by Cisco ThousandEyes in August 2023, our teams have collaborated to enhance the ThousandEyes platform's BGP monitoring capabilities. This integration has enabled significant technical advancements, including the deployment of ThousandEyes BGP monitors in production and the transition of our BGP data pipeline to real-time.
Previously, our monitoring approach focused exclusively on detecting anomalies in the control plane. We have since expanded our methodology to utilize the comprehensive ThousandEyes platform for root DNS prefix monitoring. This evolution has allowed us to move beyond control plane analysis by incorporating data plane measurements, providing a more complete view of BGP events and their real-world impact. Using this enhanced approach, we have identified another event involving L-Root, which we describe in detail below.
June 2025: L-Root
Since June 20, 2025, the Cisco ThousandEyes platform has detected that AS3132 (Red Cientifica Peruana) is appearing as the origin of prefix 199.7.83.0/24, which again belongs to ICANN (AS20144) and is the IPv4 prefix of the “L-Root” domain server.
Out of hundreds of BGP monitors, only 19 of them detect the event, indicating its low visibility.
If we narrow our focus to the changes in paths observed by a single BGP monitor that has visibility of the event, for example, our monitor in Houston, TX, from Tier 1 ISP Lumen (AS3356), we clearly see the offending network (AS3132 Red Cientifica Peruana) originating the prefix on June 20, as well as the legitimate path being withdrawn in favor of the offending one.
Explore the event further in the ThousandEyes platform (no login required).
Our newly introduced BGP Updates table was created for this exact use case: When BGP anomalies occur, you are able to drill down to the level of raw BGP updates and understand what happened. In the example in Figure 8 below, we have used the BGP Updates table filters to look for AS paths that include AS 3132 anywhere in the path during the previous week. We notice that this AS is originating the prefix (rightmost AS), and the network that always receives and propagates the announcement is Lumen (AS 3356). The prefix is not covered by an RPKI ROA; therefore, the RPKI status is “NotFound.”
June 2025: L-Root (Impact on the Data Plane)
As mentioned earlier, at Code BGP, we could only speculate about how events would impact the data plane, since the Code BGP platform had only control plane capabilities. With Cisco ThousandEyes, we can now measure the data-plane impact directly.
To assess the effect of a specific event on the data plane, particularly since it involves a root DNS prefix, the most appropriate measurement approach is a DNS test. Since L-Root serves the .org domain, we have created a DNS test targeting wikipedia.org, specifying the IP addresses of L-Root as the DNS servers.
Additionally, to receive alerts when AS3132 appears in the AS path, we established an associated path trace alert rule.
Our results indicate that out of the 1000+ Cisco ThousandEyes Cloud Agents that are deployed worldwide, 104 forward DNS queries towards L-Root via the offending network.
Therefore, accounting for potential variations in Cloud Agent network connectivity, we estimate that approximately 10% of the global Internet is currently forwarding DNS queries to L-Root through the offending network. This finding represents a real-world impact that extends far beyond theoretical security concerns.
L-Root serves as one of the 13 root DNS servers that handle queries for top-level domains like .org, .com, and country code domains. When users worldwide attempt to resolve domain names, their queries ultimately depend on these root servers.
Our measurement indicates that the hijacking network could potentially monitor, log, or manipulate DNS responses for millions of users without their knowledge, enabling sophisticated attacks such as DNS poisoning, traffic analysis, or man-in-the-middle attacks against websites and services. Furthermore, the 10% figure likely represents a conservative estimate, as our measurement infrastructure may not perfectly mirror global Internet traffic patterns. This demonstrates that even "limited" BGP hijacks can have far-reaching consequences for Internet users.
We have contacted ICANN to share our findings and have provided them with access to our data.
Moving forward, we are exploring ways to systematically measure data plane impact whenever control plane anomalies occur. Our team is developing approaches to automate the creation of corresponding data plane tests, which would enable us to provide real-world impact insights to users seamlessly. This capability will provide a more comprehensive understanding of how BGP events impact actual network traffic and user experience.