This is part 5 of a five-part series. Part 1: The Rabbit Hole covers the investigation, Part 2: Building an IT Department covers what I built because of it, Part 3: The Bill for Letting AI Watch the House covers what running it for real cost, Part 4: Prove the Safety Net Actually Catches You covers a fix that quietly broke something else.

Part one mentioned, almost as an aside, that a DNS query on this connection took a detour through Bangalore before doubling back toward Mumbai. It never got a proper follow-up. This part is that follow-up: how far away the DNS server measuring 37 milliseconds actually is, and what accounts for the rest of that time.

Measuring distance to an anycast resolver

The house's DNS resolver answers queries to one particular provider in about 37 milliseconds, consistently, night after night. The obvious question is how far away that server physically is. That doesn't have an easy answer, because the server's IP is anycast.

The lazy way to answer it is to look up where the server's IP address is registered. That's also, for this specific kind of server, close to useless. DNS providers like this one run on anycast: the same address is announced from dozens of physical locations worldwide, and whichever one is actually reachable is invisible from the address alone. A standard geolocation lookup on this address reported a city on the other side of the world, though it did flag the address itself as anycast, meaning the location it reported wasn't reliable.

Bounding distance with the speed of light

Round-trip time sets a hard ceiling on distance instead: light in fiber-optic glass travels at a fixed, known speed (meaningfully slower than light in a vacuum, but still fast and knowable), and no signal reaches a destination faster than that speed allows, whatever the network in between is doing.

Running that math against the measured 37 milliseconds puts the absolute farthest that server could be at a little under 3,700 kilometers. The geolocation database's answer was several times further than that, which meant it wasn't describing the server actually being reached.

The provider's published location data

Guessing a closer, more plausible city would have been progress, but not proof. The DNS provider publishes an official list of every location it runs from, coordinates included, but it's served through an interactive map rather than a plain list. Maps like that are usually a thin rendering layer over a data file loaded separately, and the page's own source confirmed it: a script reference pointed directly at a CSV, the actual spreadsheet backing the map.

That file lists the provider's own location in this country as active, coordinates included, in the closest major city, a little over a hundred kilometers away. Not a guess. Their own published operational data.

At that real distance, the speed-of-light round trip comes out to under 1.4 milliseconds. The connection actually takes 37. Ninety-six percent of the measured time isn't the server being far away at all. It's everything happening in between.

The traceroute

"Everything happening in between" needed a specific answer. A traceroute shows every router a packet passes through, and one hop in the middle of this path belongs to the same large national carrier this ISP relies on for its own upstream connectivity, covered in part one.

That router's own reverse-DNS name contained a three-letter airport-style city code, standard practice for a national carrier labeling its own infrastructure. That code was Bangalore's. A separate, independent lookup on the very next hop in the path put it in Delhi. Two cities, a combined couple thousand kilometers out of the way, sit between this house and a DNS server that's a little over a hundred kilometers away as the crow flies. That matches the Bangalore detour mentioned in part one, now confirmed hop by hop instead of glanced at in a single traceroute.

It's also worth ruling out the more obvious explanation before landing on routing: a shared, oversubscribed connection under real load tends to look noisy, latency bouncing around depending on how busy things are at that particular moment. This doesn't look like that. Ten repeated measurements to the same server came back within half a millisecond of each other, essentially every time. Noisy contention produces jitter; a fixed bad path produces a consistent number that's simply too high. This is the second case.

Multihoming versus path selection

This ISP isn't thin on backup options. It's multi-homed through three separate major carriers simultaneously, covered in part one. Multiple upstream connections mean that if one goes down, there's somewhere else for traffic to go. That's valuable, and it's a completely different property from choosing the best available path for a given destination on an everyday basis.

The way internet routing actually picks a path between two networks doesn't optimize for physical distance or measured latency by default. It optimizes for the shortest chain of networks in between, a completely different metric that has nothing to do with geography. A route that hops through fewer networks can still be, in real kilometers, dramatically longer than a route that hops through more. Making the actual fast option win instead requires someone actively tuning the network to prefer it, and that's a level of operational sophistication that redundancy alone doesn't buy you. A large national carrier juggling three ways in and out of a network, for a business at this scale, mostly just needs a path that works. Making sure it's consistently the best path is a different, harder, more expensive job, and there's no evidence anyone here is doing it.

Summary

The number that started this, 37 milliseconds to a server about 135 kilometers away, wasn't a distance problem. It was a two-city routing detour: reverse-DNS hostnames on the traceroute's middle hops resolved to Bangalore and Delhi, a combined couple thousand kilometers neither city had reason to be on the path between this house and its nearest DNS node.