Yesterday there was an article in the Indian paper Financial Express with the title “OTTs may have to pay access charge to telcos”.
Quoting a few points from the article:
Social media intermediaries like WhatsApp, Facebook and Twitter, and over-the-top (OTT) players like Netflix, Prime Video and Disney+Hotstar may have to pay a carriage charge to telecom service providers Data, particularly video, comprises 70% of the overall traffic flow on telecom networks, and this would grow further with the rollout of 5G services Upon reference from the DoT, Trai is currently studying various possible models under which OTTs can be brought within the purview of some form of regulation According to sources, an interconnect regime is a must between OTTs and telcos because as 5G services grow, there would be immense data/ video load on networks, which may lead to them getting clogged or even crashing at times.
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:**