If your DNS queries LoOk liKE tHIs, it's not a ransom note, it's a security improvement 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 …
This post has been deleted by its author
Is this only implementing the IETF draft, which seems like not a great idea since it's a draft, or is this a new trick to evade privacy measures? 'forums.theregister.com' would be 20 bits for Google to leak data from one service to another. If the IETF is followed, blocking those bits would cause the DNS response to be rejected.
(The TLDR of the draft is that DNS caches remain case sensitive but the response must use the original case. This makes blind, brute-force forgery of DNS responses over UDP more difficult.)
How? I really don't understand.
I also don't understand how a DNS response has to be original case when a response is the IP number. Are numbers case sensitive (I knew the 3 and 8's were up to something!!!).
As far as the randomization of a URL goes, web developers have been using a random string to invalidate a cache since... well, forever? If you've done any web development, you learned this on day 1 (it's up there with "hello world").
I also don't understand how a DNS response has to be original case when a response is the IP number.
That's the response from your resolver to your query, but the inter-dns server response includes the entire record. So it will go something like this:
You: "Hey Google DNS do you know about thisdomain.example.com'
Google: 'No, I don't, I do know about example.com I'll ask that...'
Google: 'Hey example.com, do you know about tHISdoMaIn.eXaMPle.cOM?'
example.com: 'Yeah, sure, here's it's DNS entry '192.168.0.1 A tHISdoMaIn.eXaMPle.cOM'
Google: 'Cool, cheers..'
Google <to you>: 'Here's the IP...'
But if a mallicious actor is trying to attack this domain:
You: "Hey Google DNS do you know about thisdomain.example.com'
Google: 'No, I don't, I do know about example.com I'll ask that...'
Google: 'Hey example.com, do you know about tHISdoMaIn.eXaMPle.cOM?'
<at this point google gets flooded with fake responses:>example.com: 'Yeah, sure, here's it's DNS entry '10.0.0.1 A thisdomain.example.com'
Google: 'Hang on... that doesn't exactly match...'
Google <to you>: 'Error...'
(The protocol description may not be 100% accurate, but you get the idea... I suspect the voices are more robotic in reality...)
If I understand correctly, the existing (inter-)DNS lookup standards would *already* require the authoritative server to maintain the case of the domain request when sending back the result?
Otherwise Google- presumably- wouldn't be able to tell the difference between a legitimate response from a server that doesn't support the scheme (e.g. and has converted it to lower case) and a malicious response trying to poison their cache?
Also, the title says "If your DNS queries LoOk liKE tHIs", but since the scheme relates to requests between Google's caches and the authoritative DNS servers (not the end user), why would they need to bother propagating the randomly-capitalised domain name back to the end user?
(Or was the article title specifically addressing those running DNS servers anyway?)
If I understand correctly, the existing (inter-)DNS lookup standards would *already* require the authoritative server to maintain the case of the domain request when sending back the result?
I'm not sure that is the case, which is why this hasn't been widely implemented so far, and Google are being careful about where they roll it out. The DNS RFCs are many, and complex, including RFCs with titles like "Best Current Practice" - which get replaced over time, of course.
The RFCs certainly require that (for Internet name lookup queries using text strings, which are not all the types of queries DNS servers can handle) they "treat ASCII upper and lower case letter codes as matching" (but only ASCII letters, not other bytes, such as punctuation). But treating as matching does not mean the result will be transformed to use the same combination of upper and lower case.
Modern DNS servers, particularly for big sites, are generally running very few different software implementations, which probably all return the response in the same case as the query. However, in the past there were many different DNS servers (see, for example, the now almost useless "class" field - two bytes that are now always just the value 1 despite other classes being defined). A few of them may still exist on the internet somewhere.
So shorter domain names are bad since it will not be that many variants to match the case used by the DNS server.
I have a nice long domain name which should be very secure in this case since the permutations are too hgh. nicelongdomainnamewhichissupersecure.com is for sale. Only 100000000 bucks!
;)
It's common for IETF RFCs to remain marked as "draft" forever, almost regardless of how widely they are implemented.
ISPs have been doing this one for years already. Last time I checked, about 8 years ago, about 10% of DNS requests from the UK have randomly capitalised letters.
RFCs are not Internet-drafts, and a draft is not an RFC.
It's common for RFCs to remain in Experimental state, i.e. on the Non-Standards track and never advanced to Informational – but not all that common. There are currently 529 Experimental RFCs, and 2857 Informational ones (and 338 Historic).
It's more common for Standards-track RFCs to fail to make it to Internet Standard: there are 129 Internet Standard RFCs, and a whopping 3964 in Proposed Standard, plus 139 Draft Standard. (Draft Standard was a level between Proposed Standard and Standard until it was removed by RFC 6410 in 2011. Alas, those 139 Draft Standard RFCs – two of them from the 1980s – don't seem likely to ever make it to Standard.)
But in any case, draft-vixie-dnsext-dns0x20-00.txt is an expired Internet-Draft (from 2008), not an RFC. Regardless of whether it's a good idea, it's just an idea that was published through the IETF's I-D process. It never made it to RFC Land.
The comment about email addresses is not strictly true. The domain part (after the @) is case-insensitive, but the local part (before the @) "MUST be interpreted and assigned semantics only by the host specified in the domain part of the address" (RFC 5321). Whilst in practice many mail servers will handle the local part in a case-insensitive manner, one shouldn't rely on that behaviour.
^---- this a thousand times over.
Email addresses are case sensitive.
They can be very long (so that VARCHAR(50) isn't 'good enough')
You can't just validate them with that simple regex you have....
One day I'll get round to writing some test cases to piss off people who don't know this. :D
Still gets my goat how many web forms claim an email address with a plus sign in it is not valid.
Speaking as the owner of one of the 'new' gTLDs created... erm... nine or ten years ago, it still annoys me how many web forms seem to.validate addresses based on the length of the TLD; they will accept any old rubbish so long as it is two or three characters, but will reject anything with four, five or more characters, even if it's a well-established TLD.
M.
Unless you are thinking of after the FQDN after the slash, which for Linux is normally case sensitive (Unless it has changed).
Oh wait I am thinking the whole URL where as you have said DNS query which is FQDN only. Oh well I'll leave my stupidness up as I hate to see the comment deleted by author.
This post has been deleted by its author
Surely it is finite. AlL iT IS is 2 to the number of alpha chars. ie. aa.com Aa.com AA.com AA.com 2^2 - 4 and so on.
And how is the alphabet factory going to handle those foreigners that don't just some ascii chars?
Just check the calendar and it is not April 1. This has got to be one of the most stupid proposals that ever came our of google. Are they using their own AI to generate this crap?
Finite but large; for 17 chars like www.theregister.com that's a 2^17 (about 130,000) increase in the number of bogus responses an attacker has to create.
But I agree it seems a bit of a weird hack. AIUI you are trying to defeat the caching of DNS servers you don't control. If any of these servers start using case insensitive cache lookups to return case sensitive answers, you're back to square 1.
The server you are targeting will query upstream with a 16 bit query ID - 65k possible values. You have to thrash the server with fake replies in the hope that one of your fake replies has the correct ID and hits the server before the genuine reply. A single case-unknown character will expand this to 128k, then 256k etc.
Yes it's finite, but when most servers reply in ~5-10ms, it becomes far less likely you will get the right ID and case in time. It's a perfectly reasonable idea to try and reduce the effectiveness of cache poisoning without requiring the entire world to modify their DNS systems. The biggest issue as mentioned in the article is servers that happen to reply with the case changed as they will effectively get completely rejected, although that isn't many servers. I don't believe it was ever specified that servers *must* respond in the same case as the query, but I haven't checked. It seems all the major DNS software (bind/unbound/etc) does.
Also, as far as I'm aware, all international domain names are (at least currently) converted to pure ascii for DNS lookups.
Google is only concerned about AUTHORITATIVE name servers, and probably for 99%+ of domains are operated by large ISPs and registrars. What they're doing doesn't matter for the caching name server I am running in my wireless router. For the remaining <1%, they'll be using open source stuff like named or dnsmasq, or commercial offerings like Microsoft's (I assume they have their own name server because of course they would do that)
So they work with the big ISPs/registrars so their software (which is probably partially or even fully custom) is compliant, and authors of the software used by those who like controlling their own to support that. Then it is just a matter of a long waiting game for authoritative name servers running non-compliant software to be replaced or upgraded.
In this example, there are 17 characters that can be either case, so 2^17 or 131072 combinations you'd have to spam. For each of these, you have to send 65536 packets with different IDs to avoid being filtered, which comes to a total of 2^31 packets. Each DNS response packet will have at least 32 bytes and likely more like 50 depending on whether they compress the name, have multiple addresses, or use IPV4 or IPV6 addresses. Even if they managed to compress it to 32, which I don't think is possible, that's 64 GiB in spam packets that has to be sent to the resolver before the real result comes in. In order to manage that, you'll need a really fast network connection, and their firewall is going to start sending alarms about the DoS they think is going on. Compared to the 3.125 MiB needed to attempt the same attack on a resolver that always uses lowercase, it's much harder to pull off.
So, if this hack.... (for in my mind it is a 'hack') is a workaround to prevent cache poisoning, then surely the workaround for the workaround is to poison with all the variants.
ummm... isn't there still only one cache entry for the domain even though there are many possible case variants? it is only the conversations between DNS servers that carry the caSe ChanGes, isn't it? if i'm correct, then there's still only one normalized(?) variant of the domain name in the cache... the question is if the one that is cached is the correct one and that is determined by the conversation between the servers... i think...
if caching DNS servers were to have to cache all the case variants that cross their desks, we'd have a new(?) problem to deal with... that being "cache explosion" which could eat server memory (or storage) till OOM failure(s) lead to DOS and we certainly don't want that...
"surely the workaround for the workaround is to poison with all the variants."
Yes, but that's a lot harder. I calculated the effect on www.theregister.com in a different comment, but it requires you to be able to send 64 GiB of packets to the server before the real packet comes back from the resolver, which is a neon sign indicating you're doing something bad and giving any sufficiently-motivated defender information about your malicious systems, and in addition it would be pretty hard to manage even if they had all the alarms turned off.
"isn't there still only one cache entry for the domain even though there are many possible case variants?"
Probably, assuming the cache is being run correctly. This would be a bit of extra assurance that that cache line is valid and can be trusted by the next system to receive the answer if it's also randomizing and checking case. If the cache isn't doing that, then this is likely to lead to frequent cache evictions and reduced performance until someone changes the code.
I think the point that the article misses is that if someone tries to resolve nsa.gov, and the upstream resolution asks for nSa.GOv, the moment it gets a reply that isn't right, such as NSa.gOv, that's a massive red flag that someone is attempting a cache poisoning attack. You can then blacklist the IP address that the non-matching answer is pointing at and try again. The attackers would have to have use of a whole range of IP addresses to avoid this blocking them out immediately.
This is my point, the moment you try to poison all of them, it becomes obvious that you are as bad actor. ANY variation that doesn't match flags the associated IP address as bad.
The point is that you can't poison all variations, you must poison only the correct variation, if you try to poison even one incorrect one, the associated IP address you are trying to poison it with (which is highly likely to be the same IP address you use for all poisoning attempts, unless you have access to a range of IP addresses) is flagged. You would have to use a unique IP address for each poisoning attempt. Even for a three-letter domain (and this is ignoring the domain suffix), that means having 8 IP addresses to hand, and writing off 7 of them, or using a single IP address, and taking a 1 in 8 chance of guessing the right variation, and for the other 7 times out of 8, getting your IP address blocked.
So why not just bite the bullet and start using DNSSEC? Get rid of these nasty low probability hacks?
DNSSEC can only be implemented by those running the domain's servers. The 0x20 bit hack can be implemented by clients., allowing a smidgeon of extra security until the domain owners get their fingers out.
At the typical adoption rates there should have been 90%+ adoption by now
I'm not sure whether to laugh or cry at that. A few days ago a glitch on my firewall broke DNSSEC until I rebooted it – the only domain affected was Mythic Beasts(*), who host our DNS and mail (which was how I realised DNSSEC was broken). If I'd left the problem in place other domains might have had problems after their cached records expired, but I have no idea how far DNSSEC has actually penetrated.
(*) MB run with relatively short TTLs on their records so problems turn up faster.
The problem is that there are some root certifying authorities that not entirely trustworthy. They can issue a certificate that purports to be a genuine one for the domain.
This is a real problem, although some work is being done to not trust obviously untrustworthy ones.
There wouldn't be any impact on the cache size, as those permutations wouldn't be getting stored.
If Google needed to query the record for www.theregister.com then it would make the query for www.tHeRegistER.cOm, the auth DNS for theregister.com would receive that request, see that www.tHeRegistER.cOm = www.theregister.com, and reply with the answer while maintaining the ID number and case of the requested domain. Once received Google would then update its cache for www.theregister.com.
It doesn't need separate cache entries for theregister.com, tHeRegister.Com, TherEgISter.coM etc as they're all the same domain when stored in case-insensitive format. The case sensitivity is only used within the queries between Google and the Auth DNS servers, not in storage.
Don't knock it. Due to being at the very beginning of the Internet and us not quite watching what the developers got up to we had for a while a platform that used that to authenticate.
When we got to 100k users it became evident that that was, umm, rather far from ideal*. That said, better qualified Solaris hacks we got involved expressed amazement that it actually kept on working for that long, but that was mainly because it had one machine for itself due to the massive amount of memory it took.
* British users will recognise this for the understatement it is.
Not really, because you will be talking to a local cache. If you query www.tHeRegIStEr.com followed by www.therEGISTER.com, the second answer will come directly from the cache (both are equal to "www.theregister.com") and so there will be no second query forwarded to the auth server - which is presumably the target you're trying to talk to. You could set the TTL to zero, but it will be noisy, and the cache could enforce its own minimum TTL anyway.
Better just to use random-looking subdomains of your domain. This is what Iodine does, AFAIK.
Random looking subdomains is what I've seen before. Iodine and cobalt strike. Cant vouch for everything out there. But almost certainly for the reasons you say.
And if you don't need the recursion (so don't have to worry about intermediate caches) you just pump whatever data straight out of 53 instead and don't mess around with all this anyway.
A significant fraction of ISPs implement this same mechanism. Virgin Media is an example in the UK. Last time I had a chance to look, about 8 years ago, about 10% of all DNS requests from residential ISPs in the UK had random capitalisation for this purpose.
DNS -> googleads.com = blocked
DNS -> GooGLEAdS.cOm = Nope, not on the advertising block list, here is the DNS entry.
Google likes to pretend they are benevolent for all, but they often have a secondary agenda they don't talk about. The crowds cheered for "DNS over HTTPS" to save us from the evil ISPs. Of course that goes right around any DNS filtering to block unwanted advertisements....but that is just a by-product of the 'feature'.
I wonder if this is another hit they are attempting at ad blockers?
Maybe I'm cynical. No, actually I'm not, Google has demonstrated repeatedly that they actually care about absolutely nothing but ad revenue. When Google does something for security, privacy, heck when they heavily sponsor a good cause like Mozilla, it's safe to assume that it's because they want to bypass my DNS blocks, track my browsing, and use the threat of withdrawing that funding to control the only viable alternative while also using that alternative to pretend we have choice.
So, it's not cynicsm to ask the question:
In what way does this make it harder for me to block ads? How does it benefit Google? I can't see it but that's just making me more worried.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
