For about a half hour on Saturday, some requests to one of Google’s DNS servers in the US were re-routed through a network in Venezuela. A false Border Gateway Protocol (BGP) announcement from the Venezuelan network caused the diversion, which affected networks primarily in Venezuela and Brazil, as well as a university network in Florida. It all started at 5:23pm Greenwich Time (UTC).

Andree Toonk of the network monitoring service BGPmon.net told Ars that the false routing request was dropped 23 minutes later, “most likely because the network that announced this route realized what happened and rolled back the change (to their router) that caused this.” During the intervening period, he said, traffic may have been re-routed back to Google, or it just may have been dropped. The result was failed DNS requests for those on the affected networks.

Network rerouting through bogus BGP “announcements”—advertisements sent between routers that are supposed to provide information on the quickest route over the Internet to a specific IP address, such as the Google DNS service’s 8.8.8.8—have become increasingly common as a tool for Internet censorship. They're used to stage “man-in-the-middle” attacks on Web users and to passively monitor traffic to certain domains.

As Ars’ Dan Goodin reported in November, researchers at Renesys found that large swaths of Internet traffic belonging to government agencies, ISPs, and financial institutions have been diverted over and over by BGP exploits, being herded by routers through suspicious networks where they may have been subjected to monitoring or attack. But these sorts of reroutes also happen frequently because of network misconfiguration.

Route advertisements for ranges of IP addresses are sent between routers with a classless inter-domain routing (CIDR) numeric suffix to specify the size of the address range they’re routing to. The most common advertisements use a CIDR suffix of /24 (for example, 8.8.8.0/24), which specifies a block of 256 IP addresses (8.8.8.0 to 8.8.8.255). But the request that hijacked Google’s DNS server address used a CIDR suffix of /32, making it specific to a single IP address. As a result, the request wasn’t propagated as widely as it might have been, Toonk said, but it made the request much more effective at diverting traffic.

“The good thing is that many network filter routes more specific than a /24, so a more specific /32 route is typically not propagated very far,” Toonk said. “This would have limited the scope and impact of this incident. The bad news is that a /32 route is always selected over the 8.8.8.0/24 route that is normally announced by Google.” As a result, any router that received the bogus advertisement and didn’t filter it out would automatically use its routing data to forward packets with DNS requests for Google.

It’s theoretically possible that the diversion of traffic could have been used to intercept and alter DNS requests. However, there’s no evidence to suggest that, Toonk said. And Renesys’ Doug Madory told Ars that other signs point to it being an issue of someone screwing up weekend router maintenance.

The network that sent the request, Madory said, “leaked other internal routes earlier in the day. So I suppose someone was tinkering with the network over the weekend. We see routing goof-ups like this almost every day.” The same network, he said, is also advertising routes for a network address block in China. That's likely because it's using the IP range for an internal private address block on its network.

Madory added that since Google DNS usually routes regionally—and that the Google DNS service for South America is hosted at locations in Buenos Aires, São Paulo and Santiago—the router advertisement may have been intended to tweak DNS performance on the local network by forwarding requests to Google’s US servers instead. “For five months, Google was re-routing Google DNS queries from South America back to the US for resolution. Local resolution returned to South America last month. Google never offered an explanation for the change in service other than it was an ‘operational issue.’"