Railtel (the telecom arm of Indian railways) is running free wifi hotspots across the country in collaboration with Google. It’s there since last two years and started with the MoU between Railtel and Google (news here) back in 2015. Fast forward to 2018 - the free wifi project railway stations seems to be doing quite well with so many users using it. The project covers 361 stations and is expected to reach it’s target of 400 stations soon.
Yesterday Google’s Bangladeshi website google.com.bd was hacked and this happened via DNS. It was reported on the bdNOG mailing list at morning in a thread started by Mr Omar Ali.
This clearly shows how authoritative DNS for “com.bd.” (which is same as bd. btw) was poisoned and was reflecting attackers authoritative DNS. Later Mr Farhad Ahmed posted a screenshot of google.com.bd showing hackers page:
Later Mr Sumon Ahmed mentioned that it happened because web frontend of .
One of frequent email and contact form message I get my blog is about available content networks in India and where one can peer. There are certain content networks in India and of course most of the content networks have open peering policy and are usually happy with direct inter-connection (we call as “peering”) with the ISP networks (often referred to as “eyeball networks”). Some of these networks have a backbone which connects back to their key datacenter locations on their own circuits via Singapore/Europe, some other have simply placed their caching server where cache fill happens over IP transit.
Just was looking around at EDNS support by Google. To find how it supports and how packet looks like I created a test NS records for dnstest.anuragbhatia.com pointing to one of test server (178.238.225.247). I wasn’t running any DNS server on the server. Just ran quick tcpdump. At server end:
sudo tcpdump 'port 53 and dst 178.238.225.247' -nn -vvv -w sample.pcap Then I forcefully triggered DNS queries via Google’s recursor using:**
And finally academic session over. Done with all vivas and related stuff. Next will be exams likely in June. Time for me to get ready for travel. :) Anyways an interesting topic for today’s post - Google Public DNS. Lot of us are familier with popular (and free) DNS resolvers 8.8.8.8 and 8.8.4.4. I have covered reason in previous posts on why it tends to fail with Content Delivery networks like Akamai which rely on anycasting at bottom DNS layer and simple unicasting on application servers.