This article is more than 1 year old
If your DNS queries LoOk liKE tHIs, it's not a ransom note, it's a security improvement
It’s not Google's plan. There’s no way it’s Google's plan. It was Google's plan
Google has begun broadly enabling case randomization in domain queries sent to authoritative name servers, in an effort to make cache poisoning attacks less effective.
This means queries for a domain like example.com, if handled by Google Public DNS, could be reformatted eXaMpLe.coM when the request is transmitted to DNS servers to look up. While this may get noticed by admins scrutinizing network traffic, the spicy formatting is not visible to the general public so no one should be any the wiser – if everything goes well.
When people try to visit a website – such as theregister.com – whatever browser or app they're using queries the site's domain name using the Domain Name System (DNS) to discover the IP addresses for the servers hosting the site. Such a DNS query commonly passes through a recursive DNS service that contacts other name servers until it ultimately gets an answer from an authoritative name server.
To hasten this multi-step process, DNS query responses may be cached by these intermediary name servers. This opens up the possibility of cache poisoning attacks.
Such an attack involves hitting one of these intermediary name servers with a bunch of DNS queries for domains that aren't in its cache. The victim server then contacts other name servers that can help it answer these queries. At the same time, the attacker floods the victim server with bogus responses disguised to look like legit responses from those other name servers.
The aim of the game is to get the victim server to accept one or more of these forged responses – and cache that wrong answer – so that criminals can take advantage of the misdirection. For example, the faked response could resolve a valuable domain name – such as superbigbank.com – to a server that masquerades as the bank and steals people's login details. If the victim server caches that bad info, browsers and apps subsequently using that server to connect to superbigbank.com end up at the wrong IP address.
This is all possible because DNS servers rely on UDP – a network protocol that's faster than TCP but doesn't make guarantees about connections and is consequently more vulnerable to spoofing. It also works because DNS query IDs are 16-bit fields, meaning their possible values can range only from 0 to 65,535 – a small enough range to guess with a deluge of malicious requests.
There's a detailed breakdown of this attack here if you're curious. And, yes, DNSSEC is supposed to thwart these kinds of cache poisoning attacks, when it's supported and used.
Back in 2008, Internet Engineering Task Force (IETF) published a draft proposal to defend against cache poisoning. "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity" describes a way to randomize the case of letters used in queries.
The technique is called DNS-0x20 encoding, in reference to the hexadecimal number 0x20 (32 in decimal) and its relationship to ASCII characters. Its binary representation (0b100000) has all of its bits set to zero except for the fifth, counting from zero – which for ASCII characters determines whether a letter is upper or lower case. For example, 01000001 (65 in decimal) is the ASCII code for an upper-case A, while 01100001 (decimal 97) is the ASCII code for a lower-case a.
Described in more detail in an an academic paper [PDF], DNS-0x20 encoding expands the range of possibilities an attacker must guess without confusing the resolution of DNS names and IP addresses.
Essentially, you randomly toggle the 0x20 bit in a query to jumble up the case, send that out to be resolved, and expect the response to have the same matching case. If the cases don't match, you may be caught up in a cache poisoning attack, as the attacker won't know which case bits will be set or cleared by you when doing their poisoning.
- All your DNS were belong to us: AWS and Google Cloud shut down spying vulnerability
- Chromium cleans up its act – and daily DNS root server queries drop by 60 billion
- Internet root keymasters must think they're cursed: First, a dodgy safe. Now, coronavirus upends IANA ceremony
- Q: Why pay for DNS?
DNS servers mostly don't differentiate between queries in ALL CAPS, lower case, or SoME miX OF the TWo. But the added complexity of mixed case queries matters to attackers, in proportion to the length of the domain name. "Each bit of DNS-0x20 encoding doubles the work an attacker must perform to achieve similar poisoning results," the paper explains.
Google has been toying with the idea since 2009, when it began testing the cache poisoning defense on a small number of name servers. Last August, the search and ad giant began deploying the technique more broadly.
"The case-randomized query name in the request will be expected to exactly match the name in the question section of the DNS server's reply, including the case of each ASCII letter (A–Z and a–z)," explained Google software engineer Tianhao Chi in a post on the Google Public DNS mailing list. "For example, if 'ExaMplE.CoM' is the name sent in the request, the name in the question section of the response must also be 'ExaMplE.CoM' rather than, e.g., 'example.com.' Responses that fail to preserve the case of the query name may be dropped as potential cache poisoning attacks."
Chi noted that only a small number of name servers (less than 1,000 IP addresses) do not handle case randomization correctly.
On Tuesday, Chi said that the web goliath has successfully deployed case randomization for some regions in North America, Europe and Asia, covering about 90 percent of queries not already protected by DNS over TLS.
"We are still deploying this feature incrementally, location by location," said Chi. "This is slower than originally planned because of the carefulness and our estimate of global enabling is around March to April 2023."
Chi said Google is watching for problems from non-compliant name servers and recommends that name servers preserve the query case in the response or support TCP as a fallback.
When all is said and done, the internet should be just a bit more secure. ®