So I got a question from a customer. Their firewall team detected that clients tried to connect to 2.16.4.xxx (I replaced the last octet with x’s to protect the innocent). So who is 2.16.4.xxx, lets start with a simple reverse DNS query

C:\Users\virot>nslookup 2.16.4.xxx 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Name:    a2-16-4-xxx.deploy.akamaitechnologies.com
Address:  2.16.4.xxx

So now we know that we are talking about Akamai, well that doesn’t really help since it is the or one of the biggest CDN’s in the world.

So I asked the firewall team for information what was sent and they couldn’t help me. So we need to figure out which name is pointing to the IP. And I didn’t have access to the clients to check either. If I had access to a client I could have run ipconfig /displaydns this would have given me the same kind of information as I got from the cache. But wait I do have access to the DNS servers. Lets check in the DNS Cache.

Exploring the Windows DNS Server cache

Lets dump the entire cache to a file so we can work with it.

dnscmd dnsserver /zoneprint ..cache> C:\Temp\dnsdump.txt

Now we have a good file to look through. Lets start looking for A record is pointing to 2.16.4.xxx. I found another akamai name, so I needed to see what CNAME was pointing to that name and so it went a two times.. But in the end we found it. Below is the interesting parts of the dump I did.

crl.microsoft.com 533 CNAME crl.www.ms.akadns.net.
crl.www.ms.akadns.net 163 CNAME a1zzz.dscg.akamai.net.
a1zzz.dscg.akamai.net 1 A 2.16.4.yyy
    1 A 2.16.4.xxx

So in the end the client tried to reach crl.microsoft.com. This is a standard case why locking down your firewalls by IPs can be a time consuming endeavour.