CNAME of shame
Before I left work on Friday some of our proxies were showing a DNS error getting to https://app.powerbi.com our MSP was left pursuing this. I decided to do a bit of digging myself.
A DNS query can provide an ‘A’ response which tells the querier the ip address associated with the given name, but often a CNAME record can be returned (Canonical Name) which effectively just points to another address. For example this website is available on www.labtinker.net or just labtinker.net. My DNS (Route 53 in AWS) provides the ‘A’ record for labtinker.net: .
but a CNAME for www.labtinker.net
so if you query www.labtinker.net you are re-directed to labtinker.net which in turn provides the ip address. This excerpt from an nslookup -debug www.labtinker.net illustrates this:
Now, there is nothing to stop you from pointing your CNAME to another CNAME:
So here test2.labtinker.net has a CNAME for test1.labtinker.net which in turn has a CNAME for labtinker.net
Of course, each time you do this another DNS lookup has to be made but two layers of CNAMEs isn’t terrible.
Now app.powerbi.com has considerably more as seen in this Wireshark DNS response.
…and doing nslookup -debug app.powerbi.com you’ll see the merry dance the DNS response sends you on. I don’t have access to a lab version of the proxy that’s used at work but I do have a Fortigate in a GNS3 lab and that can act as an explict proxy. I won’t bore you with the topology. (It’s a host going through an Fortigate set up an explicit proxy). This proxy has no issues with app.powerbi.com:
so I decided to set up ‘nested’ CNAMEs as follows…
…and then browse to testf.labtinker.net to see what happens.
If I browse on this laptop, I get to testf.labtinker.net: (I’m using my ISP’s DNS – Virgin)
And this is what Wireshark showed me…
Through a VM running through my Fortigate proxy:
(This was when the proxy was running Fortigate’s own DNS).
However, if I go one layer down and go to teste.labtinker.net (slightly unfortunate hostname but you can see how it was derived)
Initially, I though this was a limitation on the proxy but I changed the proxy DNS to point at 1.1.1.1 and cleared the DNS and it then resolved testf.labtinker.net without issue.
I suppose I was hoping to hit a universal practical limitation with nested CNAMEs, and while there do appear to be some inefficiencies (which you would expect) they don’t appear around the levels of nesting in use for app.powerbi.com
I have two options – carry on playing around with this or go and get some lunch then sit on the balcony drinking wine.
UPDATE: I wasn’t on the inner circle on the issue which prompted my experimentation but I learnt that it had been resolved when the DNS TCP listener was enabled on the load-balancer the proxies got their DNS from. Presuambly, the size of the DNS request had triggered the proxy to use DNS over TCP. Historically, dns over tcp was only used for zone transfers but this is no longer the case:
https://www.ietf.org/id/draft-ietf-dnsop-dns-tcp-requirements-15.html
You can get ‘nslookup’ to use tcp for dns by typing ‘set vc’ within the utility. Here is a Wireshark extract of TCP DNS.
Incidentally, I carried on with my CNAME chaining to see when they would break (just from a normal laptop (using 1.1.1.1)) – I got as far as testj.labtinker.net which was 20 layers of CNAMES (tcp or udp made no difference).
This post feels somewhat rambling discursive but let’s double-down: this podcast deals with the subject of DNS over TCP – the takeaway it’s not just for zone transfers so allow it!