In an attempt to further secure our online browsing activities, Google has started rolling out a new approach to DNS (Domain Name System) queries & responses.
For those who are unsure about how DNS works – Check out my DNS primer before reading any further. For those familiar with DNS – please read-on.
As you know, the results of most DNS queries come from DNS caches, not the authoritative servers themselves. Whilst this is not a problem in itself, a DNS cache can often be the target of a DNS cache poisoning attack which can be used to trick people into visiting fake, malicious websites by accident.
The M.O. of a DNS poisoning attack
In this attack, an attacker issues a DNS query to a DNS resolver server asking for a domain which it knows is not in the servers cache.
The DNS resolver issues a series of recursive DNS queries to other servers in an attempt to resolve the query
Before any answers can be returned, the attacker floods the server with many fake responses in an attempt to poison the resolver cache with fake values.
The reason why this type of attack is often successful is because DNS uses UDP which has no security checks which it’s sister protocol TCP has, so its easier to inject fake UDP packets into a network stream than it is to do the same with a TCP session.
Another reason for the success of attacks like this is that DNS query IDs are 16-bit in length, meaning a possible value range of between 0 – 65,535, which means an attacker only has to try 65.5k tries to get the correct ID.
But DNSSEC exists?
Yes, DNSSEC (DNS security extensions) is a thing, and it has mechanisms within it designed specifically to stop attacks such as DNS cache poisoning.
But only if it’s deployed onto servers which support DNSSEC that is, and there are a lot of servers out there which don’t use DNSSEC.
DNS poisoning is not new
DNS poisoning is almost as old as DNS itself, and techniques to try to limit such attacks have been around for a while.
Back in 2008, the IETF (Internet Engineering Task Force) published a draft proposal which suggested using bit 0x20 of the DNS label to improve the identity of DNS transactions.
Google’s plan
It is this proposal which Google has used as the basis of it’s new approach.
In the proposal, it is suggested that if the characters in a DNS query are randomised, then it would add a layer of entropy to the process which servers could use to sanity check the responses they recieve.
So for example if a server issued a request for cYbErTRAinER.uk and received a response for cybertrainer.uk, it would know that the response is fake.
Google trialed this feature back in 2009 on a small number of name servers, but late 2022 saw Google start to push this new feature out on a broader scale, ands have said that they expect to complete their global rollout sometime around March or April 2023.
So how does it work?
If we look up the ASCII values for the letter “c”, we get the following data:
- Decimal = 99
- Hexadecimal = 63
- Binary = 01100011
The idea is to flip bit 0x20, which in binary is the value 32. So if we flip the bit which is in the position which represents 32 in our octet we will get a new value.
This becomes:
- Binary 01000011
- Hexadecimal = 43
- Decimal = 67
Decimal 67 is the letter “C”
If this approach is performed randomly on each octet of the value in the DNS query the result is various possibilities of a domain name
- CyberTRAiner.uk
- cYbErTRainER.uk
- CYBErtrAInER.uk
- CybertRAINeR.uk
As you can see, this will make is much harder for a criminal to be able to spoof all possible variants of the domain.
It’s not a 100% foolproof solution, but it should be enough to thwart most DNS cache poisoning attempt.