Posts

In the early phase of Russia - Ukraine war, Ukraine made a strange request to ICANN. They asked ICANN to remove .ru (Russian ccTLD) from the root DNS servers, revoke SSL certs for .ru and shut down root DNS servers hosted in Russia.

Here are the three requests they made:

Complete letter is here (and original source is here). This is going to be one of few notable cases where critical internet infrastructure is being weaponised. ICANN declined the request for good. Due to my limited understanding of Russia, Ukraine, US, EU, NATO etc I am not going to comment on the conflict itself. But coming to the critical infrastructure part - this reminds me of my earlier blog post on Doomsday and DNS resolution.

I am in Bangalore for two days. While there are many things packed into these two days short schedule, one of the most exciting ones is Google Global Network India Innovation Summit. While Google has presented across various events in past talking about their AS15169 backbone, this is the first summit where they are covering it in detail and that too with the Indian context!

Must say that I find AS15169 quite fascinating on the BGP side of things. A massive network which follows “cold potato” routing i.e keeping the majority of traffic over IGP over larger locations, terminating BGP sessions on the virtual appliance with SDN backing, a pretty robust failover design with BGP + DNS taking care of server(s) and even entire PoP failing. I blogged about them back in 2020 here. So this should be fun!

This is my first and probably going to be the only blog post talking about a NOG i.e a Network Operator Group. I usually do not talk about that here because NOG is supposed to be facilitating the work of the network operator community and in itself should not be a topic to focus on or talk about. As a matter of fact, I find it a bit irritating when NOGs are presented as the end goal when parties are thrown in just to celebrate certain age of NOG when hours are wasted just telling stories about NOG planning etc.

Lately, I have been struggling to keep latency in check between my servers in India and Europe. Since Nov 2021 multiple submarine cables are down impacting significant capacity between Europe & India. The impact was largely on Airtel earlier but also happened on Tata Comm for a short duration. As of now Airtel is still routing traffic from Europe > India towards downstream networks via the Pacific route via EU > US East > US West > Singapore path. Anyways, this blog post is not about the submarine cable issue.

Vultr has announced start of their Mumbai location on 12th of this month. It’s amazing to see them entering India. Always a good thing for growth of cloud computing on demand in India.
Besides Vultr, we have got Amazon AWS, Microsoft Azure, Google Cloud, Digital Ocean, Linode, Oracle Cloud etc in India. I heard OVH also planning for Indian location and so have to see how that goes.

In meanwhile, let’s have a quick check on Vultr’s network connectivity. I just created a Virtual machine in Mumbai to look at the routing and connectivity. I got following for my test VM:

Background

Lately, NIXI has been making a bit of news in the Indian peering ecosystem. NIXI for those who may not be aware is the National Internet Exchange of India. It was founded in 2003 with the idea to provide inter-connection layer 2 peering fabric for local Indian ISPs. They were supposed to ensure domestic Indian traffic is exchanged within India and not outside of India. In my previous post, I did cover how that is not true for now. They never picked up much interconnection due to a number of fundamental issues with their policies.

A developer friend recently asked me about the design of redundancy on servers. He had a valid point - running BGP can be tricky and expensive since most colo & datacenter host would offer simple static routing & usually with just a couple of IP addresses. Furthermore, due to IPv4 exhaustion, the prices of /24 have shot off pretty massively. On top of this burning, a /24 on single or multiple servers is also a questionable design practice unless one of hosting & selling hundreds of virtual machines on those servers.

No blog post since Aug 2021. Last few months extremely (and happily) busy. I got blessed with a baby boy in September and since then being happily busy.

Gotta resume blog posts here!

Someone recently reached out to me discussing DNS and as that person started taking deep dive in DNS, he came across the glue records. He asked me “Why not just use A records on a sub-zone with glue record at the parent zone”?

This was a fantastic question. I am going to document it in this post on why not. First and foremost let’s have a clear understanding of glue records.

After my last post about home networking, I am jumping back into global routing. More specifically how Indian traffic is hitting the globe when it does not need to. This is an old discussion across senior management folks in telcos, policymakers, and more. It’s about “Does Indian internet traffic routes from outside of India?” and if the answer is yes then “Why?” and “How much?”

It became a hot topic, especially after the Snowden leaks. There was even an advisory back in 2018 from Deputy National Security Advisor to ensure Indian internet traffic stays local (news here). Over time this has come up a few dozen times in my discussion with senior members from the Indian ISP community, individuals, and even latency-sensitive gamers. So I am going to document some of that part here. I am going to put whatever can be verified publically and going to avoid putting any private discussions I had with friends in these respective networks. The data specially traceroutes will have measurement IDs from RIPE Atlas so they can be independently verified by other network engineers.