back to article 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 …

  1. This post has been deleted by its author

  2. Kevin McMurtrie Silver badge

    Do be evil

    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.)

    1. Anonymous Coward
      Anonymous Coward

      Re: Do be evil

      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").

      1. FIA Silver badge

        Re: Do be evil

        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...)

        1. Anonymous Coward
          Anonymous Coward

          Re: Do be evil

          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?)

          1. Graham Cobb Silver badge

            Re: Do be evil

            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.

        2. BOFH in Training
          Trollface

          Re: Do be evil

          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!

          ;)

          1. Flocke Kroes Silver badge

            Re: Do be evil

            So crims buy niceIongdomainnamewhichissupersecure.com and spam everyone with an email advising people to check their account for unauthorised transactions with a handy link to their domain instead of yours.

            1. nagyeger
              Holmes

              Re: Do be evil

              Ah! Another demonstration that sans-serif fonts are evil.

        3. Chris 15

          Re: Do be evil

          I was imagining a robot from Sirius Cybernetic Corps with a Genuine People Personality to be fair

          'Have a Great Day' at the end :)

    2. RichardBarrell

      Re: Do be evil

      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.

      1. Michael Wojcik Silver badge

        Re: Do be evil

        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.

    3. Kevin McMurtrie Silver badge
      Facepalm

      Re: Do be evil

      I meant the cache is case insensitive.

  3. Neil Barnes Silver badge
    Headmaster

    Colour me surprised (in upper case)

    Obviously I'm getting senile; I had thought that DNS requests were case sensitive.

    1. Anonymous Coward
      Anonymous Coward

      Re: Colour me surprised (in upper case)

      They're not, neither are email addresses. However, anything past the first slash in a URL can be as that is no longer a DNS matter, you're then sending instructions to a specific resolved FQDN.

      1. Henry 8

        Re: Colour me surprised (in upper case)

        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.

        1. Anonymous Coward
          Anonymous Coward

          Re: Colour me surprised (in upper case)

          I stand, no, wait, sit corrected. Thank you. Accuracy matters!

        2. Michael

          Re: Colour me surprised (in upper case)

          A continued argument I've had with a member of our sales team who is incapable of entering his email correctly. Apparently the spec is wrong...

        3. FIA Silver badge

          Re: Colour me surprised (in upper case)

          ^---- 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

          1. SloppyJesse

            Re: Colour me surprised (in upper case)

            Still gets my goat how many web forms claim an email address with a plus sign in it is not valid.

            1. Anonymous Coward
              Anonymous Coward

              Re: Colour me surprised (in upper case)

              Yes, it's a definite minus..

            2. MOH

              Re: Colour me surprised (in upper case)

              Are Lingus refused for years to accept email addresses with an apostrophe for online ne booking.

              Lucky they're not at all common in Irish surnames or name.surname email addresses

            3. Martin an gof Silver badge

              Re: Colour me surprised (in upper case)

              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.

    2. Captain Scarlet
      Coffee/keyboard

      Re: Colour me surprised (in upper case)

      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.

      1. This post has been deleted by its author

  4. spireite Silver badge

    Am I being Dense?

    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.

    www.theregister.com

    www.TheRegister.com

    www.THeregister.com

    ad infinitum?

    1. Phil O'Sophical Silver badge

      Re: Am I being Dense?

      I think the point is that poisoning with all the possible variants requires several orders of magnitude more effort, and so makes it impractical.

    2. sreynolds

      Re: Am I being Dense?

      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?

      1. Tom Chiverton 1 Silver badge

        Re: Am I being Dense?

        Oddly, they've thought of that, and it's even quoted in the article. They only mess with a-zA-Z.

        1. Lennart Sorensen

          Re: Am I being Dense?

          Fortunately since DNS uses IDN encoding for any non ascii domains, and IDN encodes UTF using ascii, it will in fact still be ascii in the request and hence it will work. The domain name will in fact be even longer and more effective in that case due to the encoding.

      2. John H Woods Silver badge

        Re: Am I being Dense?

        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.

        1. Crypto Monad Silver badge

          Re: Am I being Dense?

          This is for (Google) caches talking to authoritative servers. The Google caches are not talking to other caches.

          1. John H Woods Silver badge

            Re: Am I being Dense?

            Ah, of course... Thanks.

      3. m_churchers

        Re: Am I being Dense?

        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.

        1. DS999 Silver badge

          Re: Am I being Dense?

          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.

      4. SloppyJesse

        Re: Am I being Dense?

        You missed the other 3 letters in the domain.

        ...

        aa.Com

        aa.COm

        aa.COM

        ...

        So 2^5 for that short example.

      5. Anonymous Coward
        Anonymous Coward

        Re: Am I being Dense?

        This isn't new, or indeed uncommon,

        DNS resolvers have been doing this for years. Our internet-servers logs are full of them.

      6. Michael Wojcik Silver badge

        Re: Am I being Dense?

        This has got to be one of the most stupid proposals that ever came our of google.

        It didn't come from Google; it came from Paul Vixie and David Dagon. The I-D is linked in TFA.

        Really, that's an impressive amount of wrong for such a short post. Congratulations.

    3. Anonymous Coward
      Anonymous Coward

      Re: Am I being Dense?

      It's not just harder, you also elevate the chance of detection and so prompt a cache refresh. This stuff only works if nobody notices that it's happening.

    4. doublelayer Silver badge

      Re: Am I being Dense?

      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.

    5. waldo kitty
      Boffin

      Re: Am I being Dense?

      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...

      1. doublelayer Silver badge

        Re: Am I being Dense?

        "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.

  5. Mike007 Bronze badge

    Umm... My home resolver has been doing this for years.

    In case you are wondering, I haven't noticed any breakage.

    1. Korev Silver badge
      Big Brother

      Do you run a PiHole or similar on your network? I'm just wondering how they'd be affected.

      1. Mike007 Bronze badge

        I just have unbound running on my router providing a local recursive resolver, no filtering.

        1. A.P. Veening Silver badge

          I just have unbound running on my router providing a local recursive resolver, no filtering.

          I would recommend running Pi-Hole as well, with Pi-Hole using the Unbound as upstream server.

    2. Arthur the cat Silver badge

      Umm... My home resolver has been doing this for years.

      In case you are wondering, I haven't noticed any breakage.

      Ditto. Like you I'm running unbound and I turned on the option as soon as I switched from using named.

  6. Anonymous Coward
    Anonymous Coward

    If I understand it correctly, this means that facebook.com is better protected than nsa.gov. Length really counts, always and everywhere (I'm speaking about passwords).

    1. Elongated Muskrat Silver badge

      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.

      1. katrinab Silver badge
        Meh

        Yes but there are far fewer permutations of nsa.gov than of reallylongdomainname.com, so it is much easier to poison all of them.

        1. Elongated Muskrat Silver badge

          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.

          1. Jadith

            Would this mean, then, if you spoof a bunch of DNS Server IP addresses, even simpler in UDP, you could send a series of fake poisoning attacks to get those DNS servers blocked?

            Well then....

      2. Dimmer Silver badge

        If it is UDP, would the packet likely be spoofed?

    2. sreynolds

      Not really.

      https://dnssec-analyzer.verisignlabs.com/facebook.com

      No DNSSEC

      https://dnssec-analyzer.verisignlabs.com/nsa.gov

      So why not just bite the bullet and start using DNSSEC? Get rid of these nasty low probability hacks?

      1. Arthur the cat Silver badge

        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.

        1. sreynolds

          Well DNSSEC in a useable form has been around since 2010. Its adoption by mainstream DNS provides should have started in earnest around 2013/14. At the typical adoption rates there should have been 90%+ adoption by now (assuming securing DNS is a problem that needs to be fixed).

          1. Arthur the cat Silver badge

            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.

  7. MarkB
    Boffin

    "Length really counts, always and everywhere "

    Anyone who say "size doesn't matter" hasn't hung wallpaper.

    1. Hubert Cumberdale Silver badge
      Coat

      Is that because if you have a huge dong it can get in the way when you're trying to paste the paper to the wall?

      1. Jimmy2Cows Silver badge
        Joke

        I find it helps give extra support and stops the lower end of the drop flapping around.

    2. Anonymous Coward
      Anonymous Coward

      It's widely known that people prefer well-hung wallpaper.

  8. Luiz Abdala
    Windows

    VPN for DNS

    Looking from outside, in a hot take, and before my morning coffee, it looks like a VPN tunnelling made for DNS requests: obfuscate the contents of the DNS request so it can't be tracked / spoofed / tampered.

    PS. we need a coffee cup or tea symbol.

    1. Anonymous Coward
      Anonymous Coward

      Re: VPN for DNS

      You're mistaken. Think about what happens to your DNS query once it pops out the end of your VPN tunnel or the reply before it goes into that tunnel.

      I agree a coffee cup or tea symbol would be a good idea.

  9. Anonymous Coward
    Anonymous Coward

    and https:// ?

    Not quite sure what the point of returning a bogus IP address is, if the website at that IP address can't present the correct SSL cert. Especially these days since Chrome et al are so insistent on sites being SSL ?

    1. Elongated Muskrat Silver badge

      Re: and https:// ?

      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.

      1. Arthur the cat Silver badge

        Re: and https:// ?

        The problem is that there are some root certifying authorities that not entirely trustworthy.

        Also some supposedly trustworthy CAs have on occasions accidentally signed bogus certificates for domains like microsoft.com.

    2. Anonymous Coward
      Anonymous Coward

      Re: and https:// ?

      You want to address all the potential holes you can, not just rely on one security feature to save you!

  10. NullDev
    Windows

    Effective DNS Cache Size

    I wonder how this change affects effective DNS cache size. Does each domain take up a significantly larger chunk of the cache due to all their various case permutations? Perhaps the cache itself is case-insensitive and there is a translation layer?

    1. Keith Langmead

      Re: Effective DNS Cache Size

      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.

  11. FrenchFries!

    What's DNS? All I have is the Internet Yellow Pages. Hardback and floppy!

    1. Anonymous Coward
      Anonymous Coward

      I fear you're in trouble then. Bird flu is severely affecting your quill supply chain..

      1. Arthur the cat Silver badge

        I fear you're in trouble then. Bird flu is severely affecting your quill supply chain.

        Not to mention the carrier pigeons the network relies on.

    2. mattaw2001

      (.... Shudders in NIS on Solaris)

      1. Anonymous Coward
        Anonymous Coward

        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.

  12. FrenchFries!

    Bring back the Internet Yellow Pages.

  13. JohnTill123
    Go

    StudlyCaps for the Win!

    Whoever thought that StudlyCaps (https://en.wikipedia.org/wiki/Alternating_caps) would wind up being a security tool?

  14. elsergiovolador Silver badge

    Transmission

    If this becomes normalised, then you could treat capital letter as 1 and all the rest as 0. Then you could encode messages to DNS server acting as a proxy, of course with your own end to end encryption layer.

    1. Crypto Monad Silver badge

      Re: Transmission

      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.

      1. sten2012

        Re: Transmission

        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.

  15. RichardBarrell

    This is common practice already

    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.

  16. Anonymous Coward
    Anonymous Coward

    KERMIT in Sperry-Univac assembler

    for reasons only known to the author, the assembler version of KERMIT for the Sperry 1100 was like this. A pig to read.

    1. captain veg Silver badge

      Re: KERMIT in Sperry-Univac assembler

      > KERMIT for the Sperry 1100 was like this. A pig to read.

      No, Kermit was a frog. Miss Piggy was a pig.

      -A.

  17. Marty McFly Silver badge
    Holmes

    An end-run around DNS based ad blockers??

    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?

    1. doublelayer Silver badge

      Re: An end-run around DNS based ad blockers??

      Any DNS filter worth using understood that domain names are case insensitive a long time ago, hopefully as of version 1, and blocks anyway. If yours doesn't, find a better one.

  18. Nifty

    DNS queries on a postcard please. All letters of the alphabet to be cut out from newspapers and pasted onto it.

  19. tekHedd

    How does this benefit Google?

    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.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like