A few weeks ago, Mauricio Vergara Ereche, who in addition to having a very cool-sounding name works for Chile’s NIC, noticed that queries to one of the root name servers were returning odd answers. In particular, queries he sent to i.root-servers.net for domain names like www.facebook.com were being answered not with a referral to the com name servers, as you’d expect, but with an address record for www.facebook.com. Unfortunately, that address record wasn’t correct; it led nowhere.
Further probing determined that it was queries sent to the instance of i.root-servers.net in Beijing that were being answered bogusly. And it wasn’t i.root-servers.net that was behaving badly: Kurt Erik Lindqvist, the CEO of Netnod, which helps coordinate i.root-servers.net’s operation, as well as Xiaodong Lee, CTO of CNNIC, China’s NIC, which hosts the Chinese i.root-servers.net, both denied having anything to do with the mischief. Instead, the working theory is that China’s government is intercepting the queries and forging the bogus responses, partly to keep ordinary Chinese citizens from Harmful Western Imperialist Influences like Facebook (and of course FarmVille).
In fact, they’re known to have intercepted DNS queries and forged answers for some time. What’s new is that routes to the Beijingish instance of i.root-servers.net were being advertised to the world outside of the Middle Kingdom, so some part of the rest of the world’s population that’s closer RTT-wise to Beijing than to the other instances of i.root-servers.net were subject to these antics, too.
Now Netnod, faced with the prospect that queries to one of their root instances would be answered incorrectly and unpredictably, did the right thing by kicking the Beijingly replica of i.root-servers.net out of their little club. That eliminates the immediate problem. What will be interesting, though, is whether they can reinstate the Beijing root some time after July 1.
Because remember, come July 1, the root zone will be signed. Turn on DNSSEC validation and configure the root zone’s public key as a trust anchor and your recursive name server won’t believe those bogus responses. A bogus address record for www.facebook.com won’t bear the signature of the root zone’s private zone-signing key, so your recursor will discard it.
Unfortunately, detecting the problem isn’t the same as correcting the problem. As a few folks on the dns-operations mailing list (where this issue was discussed) commented, name servers that encounter DNSSEC-signed data that fail to validate don’t currently retry their queries, trying other root name servers, for example. But even so, it’s often vitally important just to detect the mischief, lest you inadvertently send your sensitive email through a hostile mail server, expose your login and password to an unknown web site, or offer your extra crops to a Chinese intelligence officer.
