This weekend the NANOG mailing list was abuzz about an F-root IPv6 route leak, that resulted in the F-root DNS server instance located in Bejing, China, being queried from outside of China. This normally doesn't happen, as this instance is advertised with the BGP attribute NO_EXPORT, which means it should not be visible outside of immediate neighbor Autonomous Systems (ASes). We looked at the DNSMON data about this event, and found that 5 out of 29 IPv6-enabled DNSMON monitors saw the Bejing F-root instance. We also found there was an earlier leak on 29-30 September.
An email thread on the NANOG mailing list this weekend alerted the network operator community to a specific route leak of the IPv6 prefix for the F-root DNS server. This leak resulted in parts of the global traffic to the F-root server being directed to a specific instance of this server in Bejing, China. On the mailing list there was a strong sentiment that this is bad because it means that some queries to and responses from F-root will pass through the Great Firewall of China (GFC), which can rewrite queries. People are afraid that the GFC would rewrite DNS queries for clients outside of China, which some refer to as exporting censorship. An analysis by Andree Toonk on his BGPMon blog has the BGP view of this event, and shows that a number of providers had their best IPv6 path to the F-root instance in China from approximately 18:00 (UTC), 1 Oct 2011 to 19:00 (UTC), 2 Oct 2011.
We looked at this event from DNSMON, which is a system run by the RIPE NCC that monitors the global DNS infrastructure, by querying it at high fidelity from a network of vantage points around the world .
DNSMON captures the hostname of the root-servers it queries by means of " magic" hostname.bind-queries . These queries are done and recorded approximately every minute. We looked through the August, September and October data up until today to see if we could find the hostnames of the Bejing F-root Bejing instance ( pek2a and pek2b ). The results are plotted in Figure 1.
Out of a total of 29 IPv6-enabled DNSMON locations, we see five monitoring points that saw the Bejing F-root instances. These five are physically located in Stockholm (SE), London (GB), Sao Paulo (BR), Hamburg (DE) and Hong Kong (HK).
Four out of five monitoring points had the same pattern of seeing the Bejing instance. The pattern consists of three separate intervals where the Bejing instance was seen. There was a good write-up on the BGPMon blog regarding the third interval; as far as we are aware, the first two had not been previously detected. The first interval was from 18:57:51 (UTC), 29 September to 02:13:14 (UTC), 30 September. The second interval, which was very short, lasted from 03:49:55 to 04:11:24 (UTC) on 30 September.
The odd one out is tt120 , which only saw the Bejing F-root instance for approximately five minutes at the beginning of the first interval, where the other vantage points that saw this effect observed it for longer periods. It did see the Bejing F-root instance during the full second interval. It didn't see the Bejing F-root instance at all in the third interval. We don't know currently how or why tt120 is different from the other four. If you have information you can share about this, please comment below.
We looked back as far as 1 August 2011, which is as far as we have detailed data available. Besides from what is shown in Figure 1, we didn't find these or other DNSMON boxes seeing the Bejing F-root instance.
As already mentioned elsewhere, DNSSEC makes it impossible for anyone to change in-flight DNS data between DNS servers. So implementing DNSSEC can eliminate concerns about the GFC in this respect.
Stephane Bortzmeyer has also stated, comparing the IPv6 Internet to the IPv4 Internet: "Because the IPv6 Internet [topology currently] is much more flat, a very small change can dramatically alter the catchment of an anycast instance." The effects of route leaks in IPv6, as in this F-root Bejing case, should become less pronounced as the IPv6 network continues to mature.
The RIPE NCC could implement a monitoring system in DNSMON to warn both DNSMON hosts and root-server operators if anycast nodes that should be local show up in places where people don't want or expect them. If you think this is a good idea, please let us know.
If anybody has any corroborating data, please comment below. We're also still looking into this, so watch this space.