Suspicious Route against a Root DNS Prefix
In this blog post, we discuss the detection of a suspicious route against a root DNS prefix, as identified by the Code BGP Platform. We highlight the speed of detection, the low visibility of the suspicious route, the significance of utilizing alternative data sources for BGP monitoring, and the importance of RPKI in preventing such events. The post also provides information on accessing the public instance of the Code BGP Platform which monitors root DNS prefixes.
Detecting a Suspicious Root DNS Prefix Route with the Code BGP Platform
The Code BGP Platform has detected that AS137661 is announcing prefix 184.108.40.206/24, which belongs to ICANN and serves as the IPv4 prefix of the “L-Root” domain server, one of the 13 authoritative name servers for the DNS root zone.
The event began at 11:15:06 UTC on 2023-04-28 and fifty two (52) hours later is still ongoing. We have informed ICANN’s NOC and will continue monitoring this event for any developments.
Speed of Detection
In the screenshot from the Code BGP Platform’s Looking Glass, we can see the prefix, Origin AS, Neighbor AS, AS path, RPKI status, and two timestamps which are automatically adjusted by the web browser to the user’s time zone (in this case UTC +3). The “Last Update” field contains the timestamp of the actual BGP update, whereas the “First Detected” field contains the timestamp of the update when it was stored in the Code BGP Platform’s database. These two timestamps are identical, indicating a sub-second delay between the time we receive an update and when we store it in the database – an engineering goal for the Code BGP Platform since its inception two years ago. As shown in the previous screenshot of the email alert, we received the alert one second later, demonstrating the speed of the Code BGP platform in detecting suspicious routing events.
Low Visibility of Suspicious Route
The logic behind the Code BGP platform’s data presentation, is that under each resource, we provide a sub-table with the sources which contribute information for the given resource, accompanied with geolocation information. In this case, the resource is prefix 220.127.116.11/24 and it’s suspicious route, and the source is one of the Code BGP Monitor routers located in Singapore.
The route’s low visibility can be explained due to the very long AS Path (11 hops, including 7 prepends of AS 9829). Interestingly, the route is currently not visible by RIS Live, which is one of the data services of the Code BGP Platform. However, the route has been picked up by only three (3) servers which contribute data to the NLNOG Ring’s Looking Glass.
AS Path Prepending of Suspicious Route by Provider
We added AS 137661 to the Code BGP Platform and started monitoring their announcements. Interestingly, out of the hundreds of routes having this AS as origin, this suspicious route is the only one which is prepended so excessively (7 times!) by AS 9829, which is one of the two AS 137661’s upstreams. Obviously, they should have dropped this invalid route instead of prepending it, so this observation raises additional questions.
Impact on the Data Plane
Quoting the Artemis paper: “Exact prefix hijacks take place when the hijacker announces a path for exactly the same prefix announced by the legitimate AS. Since shortest AS-paths are typically preferred, only a part of the Internet that is close to the hijacker (e.g., in terms of AS hops) switches to routes towards the hijacker.” In the case of root DNS prefixes, the impact on the data plane is even more limited, since these prefixes are heavily anycasted. Therefore, it is possible for such events to go unnoticed. Combining this with the low visibility of this route, we can assume that the impact of this event on the data plane is likely negligible.
Super-prefix Announced by the Same AS
As our friend Migwei Zhang pointed out, the super-prefix 18.104.22.168/23 belongs to ICANN and is also being announced by AS137661! This announcement has very limited visibility too (due to the very long AS Path) but is being picked up by Arelion’s Looking Glass, HE’s BGP toolkit and bgp.tools.
Importance of Having Alternative Data Sources for BGP Monitoring
A recent research study entitled “On the Effectiveness of BGP Hijackers That Evade Public Route Collectors” has shown that such BGP events with low visibility can easily “fly under the radar”. Our findings from this event are aligned with the research results, since this event is not visible by RIS Live. This fact further illustrates the importance of having alternative data sources for BGP monitoring and not relying solely on public feeds.
Importance of RPKI
According to AS Rank, AS 137661 is a stub network with only two upstreams, one of which is AS 9829, which is also visible in the route as the direct neighbor of AS 137661. Unfortunately, prefix 22.214.171.124/24 is not covered by a RPKI ROA . Moreover, according to the ROV Deployment Monitor and RoVista, AS 9829 is not implementing ROV. If those two conditions were true, such a BGP event, which is usually the result of fat fingering, would have been stopped at its inception.
Access to the Public Instance of the Code BGP Platform
To gain free access to the public instance of the Code BGP Platform, which monitors all root DNS prefixes, from our website’s home page click on “Try It”, and sign up. Alternatively, you can use this direct link.
Stay tuned for our upcoming blog post, where we will discuss the reasons behind monitoring root DNS prefixes. Moreover, we will include all the suspicious events the Code BGP platform has detected since we began monitoring these prefixes a few months ago.
Lefteris Manassakis, Code BGP