…getting a homelab project idea, where I create LOC records for devices without a dynamic IP address so I can figure out where the f*k they are without having to keep a continuous mental map running at all times. Free up some mental bandwidth as it were.
Very, very cool function to have. I wonder how feasible it’d be to dynamically update it using GPS measurements for fleet tracking, given even Cloudflare had to patch in support.
Even without LOC, there's also TXT. In my work lab (size of a medium DC, tonnes of devices from a variety of vendors) we used formatted TXT records to store things like: rack elevations, host/port for serial access server, switched power outlet info, reservation status, loan / return info and more. With this and cnames for rack numbers/elevations, with simple scripts we could do more than either a free-but-clunky or a decent-but-expensive DC management system could, from CLI, and quicker.
A reasonable compromise might be to use the HINFO and RP records? The latter even has a reference to a name where a TXT record can be placed with additional information, if necessary.
> where I create LOC records for devices without a dynamic IP address so I can figure out where the f*k they are without having to keep a continuous mental map running at all times
Obligatory bash.org quote[1]:
<erno> hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is.
I don't know that the accuracy afforded by LOC would be enough to pinpoint objects inside a house, though the optional fields may perhaps be used to provide room/rack location.
Lat/lon are in thousandths of a second of arc. If I did my math right, that means the worst-case precision is a hair over 3cm. Altitude is in centimeters, so on a comparable scale.
Looks to me like it is accurate enough to locate even the smallest network-connected devices! Provided someone doesn't invent wifi-connected rice grains, of course.
I could, but I'd rather not enable HTTP on devices that don't need it.
Don't get me wrong, I'm keenly aware there's easier ways to accomplish such a goal, but that's not the point. I have discovered something new and, as a way of practicing multiple other skills at the same time, am musing over homelab projects I could do to put it into practice and cement that knowledge.
It's just like my internal-only emoji DNS resolver: goofy, amusing, and ultimately impractical outside of the homelab, but still a great way to learn several new things together.
you could run ur own resolver somewhere and have ur devices update that? i think dns updates are a bit 'slow' sometimes so unsure how much u'd need to update them. if its frequent id say ur own dns resolver would be fastest as ur control the records directly on the box u query
During 2024 Summer Olympics my then employer which DNS and core network I was still managing as I returned summer holiday. I was told by helpdesk our users around different locations at campus were not able to open national TV broadcaster streaming services and view the games.
I found out by asking few of these users that they got denied claiming to be from UK and that streaming services were not allowed abroad. TV broadcaster told me once I got someone to know anything about the matter reply, that they use MaxMind GeoIP service. So I went to see and test few addresses from MaxMind debug page and that clearly showed many addresses from around 20 subnets of /16 our IPv4 CIDR block were showing the same.
So I sent email to MaxMind support asking why and tried to find out means they use to check where each network is located and populate it to their GeoIP DB, which then clients either mirror or use remotely from their service.
After few emails with their support that they did not use RIPE (RIR) database at all as RIPE terms of use doesn't allow using RIR information for commercial purposes. So MaxMind neither did not apparently use WHOIS (RDAP) LOC records, and wrong information did not update from our LOC records DNS had either.
I never got any explanation how they figure out where that IP or CIDR block is being used. Between the lines I was assuming it's perhaps some kind of trade secret they don't like to talk about. Maybe it's using mobile devices location service or like, but amount these days VPN's are being used that could lead them updating bogus information to database service use they then sell and naive customers trust <eh>.
But most I was surprised by that how easy it was update information, basically just communicating clearly and writing polite convincing message they seemed to take that information pretty much by face value and that I was sending my messages from DNS SOA RNAME address.
But if GeoIP data provicers don't use that then who or what services do, that I still have no idea.
These days RFC8805[0] is pretty widely supported. But as far as I understand, it's not entirely trusted and geolocation providers will still override that data if it doesn't match traceroutes and whatever other sources they use
A bit late to reply so much longer (10h) I posted my comment. But just for the record here I go.
After reading that RFC8805 here it's what it writes situation at the time of publishing August 2020.
"8. Finding Self-Published IP Geolocation Feeds" and subsequent
The issue of finding, and later verifying, geolocation feeds is not formally specified in this document. At this time, only ad hoc feed discovery and verification has a modicum of established practice (see below); discussion of other mechanisms has been removed for clarity."
and subsequently
"8.1. Ad Hoc 'Well-Known' URIs
To date, geolocation feeds have been shared informally in the form of HTTPS URIs exchanged in email threads. Three example URIs ([GEO_IETF], [GEO_RIPE_NCC], and [GEO_ICANN]) describe networks that change locations periodically, the operators and operational practices of which are well known within their respective technical communities."
I spent also a moment trying to figure out what can I find about its adoption and use and didn't find much of it. Some blog posts, articles and comments to question whether Amazon AWS or Microsoft Azure support it and answers were pretty much nope, no they don't at least yet time of writing last year and this year.
Thus I'm concluding it's unlikely any major source of location information for GeoIP providers like MaxMind. Nope they're not, it's too marginal source for them to spend time on so little used spec yet.
Yes traceroute is something where approximate rough estimate where IP perhaps could be as up to ISP level hosting it, but traceorgute isn't usually allowed pass firewalls and seldom reaches target IP on networks where clients really are.
One possibility is BGP advertised and known information like https://www.cidr-report.org provides could be used. But like I wrote commercial GeoIP data providers are not allowed to use WHOIS information from RIR registries. It's their ToS generally prevent it being collected and resold why MaxMind told me that they don't use it.
Thus the LOC information I had updated RIPE DB in our records LOC or any other information there were not used by MaxMind. Or at least that's what they claim. True or not I don't know, but that's what they tell if you ask from them.
Also apparently they did not use LOC records from the organization domain I maintained DNS LOC records either. And I got no answer why nor what they use as their sources of information. As it's more likely some kind of trade secret of them.
I once wrote something that did, as an internal tool.
It was basically an MPLS traceroute tool that used LOC records on RFC1918 loopbacks to plot pretty maps (well, the lines were way too straight on long range links, but ...).
It was used by marketing and basically nobody else, but it existed !
Oh wow. Did I really write that 11 years ago! How time flies.
The post mentions 743 LOC records in the entire database; I'd be very curious to hear what that number's at now?
I will ask someone to find out and report back.
The answer is... 2,386 LOC records.
How many of those additional 1,643 were a result of your 2014 blog post? :)
Their example in the blog post, geekatlas.com, no longer provides an LOC!
Any chance of convincing someone to do a stat dump on all record types?
…getting a homelab project idea, where I create LOC records for devices without a dynamic IP address so I can figure out where the f*k they are without having to keep a continuous mental map running at all times. Free up some mental bandwidth as it were.
Very, very cool function to have. I wonder how feasible it’d be to dynamically update it using GPS measurements for fleet tracking, given even Cloudflare had to patch in support.
Even without LOC, there's also TXT. In my work lab (size of a medium DC, tonnes of devices from a variety of vendors) we used formatted TXT records to store things like: rack elevations, host/port for serial access server, switched power outlet info, reservation status, loan / return info and more. With this and cnames for rack numbers/elevations, with simple scripts we could do more than either a free-but-clunky or a decent-but-expensive DC management system could, from CLI, and quicker.
A reasonable compromise might be to use the HINFO and RP records? The latter even has a reference to a name where a TXT record can be placed with additional information, if necessary.
> where I create LOC records for devices without a dynamic IP address so I can figure out where the f*k they are without having to keep a continuous mental map running at all times
Obligatory bash.org quote[1]:
<erno> hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is.
[1]: https://qdb.lol/quote/5273
I don't know that the accuracy afforded by LOC would be enough to pinpoint objects inside a house, though the optional fields may perhaps be used to provide room/rack location.
Lat/lon are in thousandths of a second of arc. If I did my math right, that means the worst-case precision is a hair over 3cm. Altitude is in centimeters, so on a comparable scale.
Looks to me like it is accurate enough to locate even the smallest network-connected devices! Provided someone doesn't invent wifi-connected rice grains, of course.
> Looks to me like it is accurate enough to locate even the smallest network-connected devices!
This should be a standard feature of server cages. The base rack itself could have a GPS receiver and provide the relative location of each rack.
That way when you nudge the rack over a few feet to make room for the foosball table it automatically updates its own physical location.
Makes sense, Thanks for the correction
Haha. Great idea, I might try this one.
You could just serve up a text file over HTTP.
I could, but I'd rather not enable HTTP on devices that don't need it.
Don't get me wrong, I'm keenly aware there's easier ways to accomplish such a goal, but that's not the point. I have discovered something new and, as a way of practicing multiple other skills at the same time, am musing over homelab projects I could do to put it into practice and cement that knowledge.
It's just like my internal-only emoji DNS resolver: goofy, amusing, and ultimately impractical outside of the homelab, but still a great way to learn several new things together.
you could run ur own resolver somewhere and have ur devices update that? i think dns updates are a bit 'slow' sometimes so unsure how much u'd need to update them. if its frequent id say ur own dns resolver would be fastest as ur control the records directly on the box u query
Oh, well, writing your own dynamic DNS system is certainly a great learning project.
buzzkill
Unfortunately the example included (geekatlas.com) appears to be long gone, so we're not able to enjoy this ourselves.
A list still exists at <https://www.ckdhr.com/dns-loc/sites.html>.
[flagged]
https://news.ycombinator.com/item?id=41099567
Who remembers the ICMB meta tag?
https://en.wikipedia.org/wiki/ICBM_address
(It's funny that the Wikipedia article has it in the section Modern use)
That's nice and all, but is there anything that consumes LOC records?
That's a good question.
During 2024 Summer Olympics my then employer which DNS and core network I was still managing as I returned summer holiday. I was told by helpdesk our users around different locations at campus were not able to open national TV broadcaster streaming services and view the games.
I found out by asking few of these users that they got denied claiming to be from UK and that streaming services were not allowed abroad. TV broadcaster told me once I got someone to know anything about the matter reply, that they use MaxMind GeoIP service. So I went to see and test few addresses from MaxMind debug page and that clearly showed many addresses from around 20 subnets of /16 our IPv4 CIDR block were showing the same.
So I sent email to MaxMind support asking why and tried to find out means they use to check where each network is located and populate it to their GeoIP DB, which then clients either mirror or use remotely from their service.
After few emails with their support that they did not use RIPE (RIR) database at all as RIPE terms of use doesn't allow using RIR information for commercial purposes. So MaxMind neither did not apparently use WHOIS (RDAP) LOC records, and wrong information did not update from our LOC records DNS had either.
I never got any explanation how they figure out where that IP or CIDR block is being used. Between the lines I was assuming it's perhaps some kind of trade secret they don't like to talk about. Maybe it's using mobile devices location service or like, but amount these days VPN's are being used that could lead them updating bogus information to database service use they then sell and naive customers trust <eh>.
But most I was surprised by that how easy it was update information, basically just communicating clearly and writing polite convincing message they seemed to take that information pretty much by face value and that I was sending my messages from DNS SOA RNAME address.
But if GeoIP data provicers don't use that then who or what services do, that I still have no idea.
These days RFC8805[0] is pretty widely supported. But as far as I understand, it's not entirely trusted and geolocation providers will still override that data if it doesn't match traceroutes and whatever other sources they use
https://datatracker.ietf.org/doc/html/rfc8805
A bit late to reply so much longer (10h) I posted my comment. But just for the record here I go.
After reading that RFC8805 here it's what it writes situation at the time of publishing August 2020.
"8. Finding Self-Published IP Geolocation Feeds" and subsequent
The issue of finding, and later verifying, geolocation feeds is not formally specified in this document. At this time, only ad hoc feed discovery and verification has a modicum of established practice (see below); discussion of other mechanisms has been removed for clarity."
and subsequently
"8.1. Ad Hoc 'Well-Known' URIs
To date, geolocation feeds have been shared informally in the form of HTTPS URIs exchanged in email threads. Three example URIs ([GEO_IETF], [GEO_RIPE_NCC], and [GEO_ICANN]) describe networks that change locations periodically, the operators and operational practices of which are well known within their respective technical communities."
I spent also a moment trying to figure out what can I find about its adoption and use and didn't find much of it. Some blog posts, articles and comments to question whether Amazon AWS or Microsoft Azure support it and answers were pretty much nope, no they don't at least yet time of writing last year and this year.
Thus I'm concluding it's unlikely any major source of location information for GeoIP providers like MaxMind. Nope they're not, it's too marginal source for them to spend time on so little used spec yet.
They could get a rough estimate of an IP location using traceroute from many different known locations. Very rough but it’s a starting point.
For some cases, they might just lookup who owns that IP range and put their address as the IP location.
Yes traceroute is something where approximate rough estimate where IP perhaps could be as up to ISP level hosting it, but traceorgute isn't usually allowed pass firewalls and seldom reaches target IP on networks where clients really are.
One possibility is BGP advertised and known information like https://www.cidr-report.org provides could be used. But like I wrote commercial GeoIP data providers are not allowed to use WHOIS information from RIR registries. It's their ToS generally prevent it being collected and resold why MaxMind told me that they don't use it.
Thus the LOC information I had updated RIPE DB in our records LOC or any other information there were not used by MaxMind. Or at least that's what they claim. True or not I don't know, but that's what they tell if you ask from them.
Also apparently they did not use LOC records from the organization domain I maintained DNS LOC records either. And I got no answer why nor what they use as their sources of information. As it's more likely some kind of trade secret of them.
I once wrote something that did, as an internal tool.
It was basically an MPLS traceroute tool that used LOC records on RFC1918 loopbacks to plot pretty maps (well, the lines were way too straight on long range links, but ...).
It was used by marketing and basically nobody else, but it existed !
/dev/null
It consumes all
See also: <https://www.ckdhr.com/dns-loc/>
something something it's always DNS