I'm trying to think of a clean way to determine the location of machines (mainly, which datacenter they belong to) based on their network settings.

I would like it to be dynamic, and I'm thinking of using special DNS records that would be specific to the DNS server in each datacenter.

For example, you could have:

root@machine1# dig TXT mysite
mysite      3600    IN  TXT "DC1"
root@machine2# dig TXT mysite
mysite      3600    IN  TXT "DC2"


I know that DNS has a special LOC record for location, but it takes coordinates, so it doesn't help in my case. Is there a standard way of addressing this issue, another special type of record for it, or some standard entries in TXT records?

  • How about using PTR records? – joeqwerty Mar 20 '12 at 20:44
  • @joeqwerty: can you explain how you would use them please? – ℝaphink Mar 20 '12 at 20:45
  • Well, a PTR record is an ip address to hostname mapping, so based on the ip address you could determine what datacenter the host resides in, assuming you're using a different range of ip addresses at each datacenter. For that matter, why not just use the A records? The host A record should resolve to the ip address assigned to the host, and again assuming you're using a different ip address range in each datacenter, this will tell you what datacenter the host resides in. DDNS is supported by most, if not all, DNS implementations. – joeqwerty Mar 20 '12 at 20:50
  • I see. I don't want to parse the IP address(es) of the machine. They might have several, on interfaces whose names I don't know (not even mentioning it could be vlan interfaces), so I don't want to depend on that, hence the idea of using a specific DNS record that would be independent on the machine. – ℝaphink Mar 20 '12 at 21:04
  • 1
    Do you have control of the entire domain? If so, you could in theory build your DNS records to reflect at least by geographic region. Something like "www.us.myawesomestuff.net" and "www.eu.myawesomestuff.net". – JohnThePro Mar 20 '12 at 21:33

11 Answers 11


(First, excuse me for not agreeing with your question.) IMHO, apparently the right place for such host configuration information is DHCP. DHCP intended to provide a client with all the information required to use various services available on a subnet.

You can use some standard DHCP option, I find domain-name as the closest to your purposes. You can use something like this on you DHCP server:

   option domain-name DC1;
   option domain-name dc1.example.org;

Alternatively (and probably even better), DHCP allows site-specific options, you can define a DHCP option named, say option site-name of type text (it also requires some numeric option code) as follows:

   option site-name code 222 = text;
   option site-name "DC1";

On the DHCP client you define this option code, request the option and bake some /etc/dhcp/dhclient-enter-hooks script where you actually use it.

EDIT: On recent distros, dhclient-enter-hooks no longer called, instead put your script to /etc/NetwokManager/dispatcher.d/ folder., like this:

# save me as /etc/NetwokManager/dispatcher.d/02test

printenv >>/tmp/dhcp-env

Once DHCP obtains a lease, you'll see all your DHCP variables dumped into the /tmp/dhcp-env.

Maybe you better define all your printer names, apt servers etc. each in a separate DHCP option instead of just identifying datacenter but storing all the relevant config in the client.

If you opt to use DNS anyway, I find your TXT a good option, don't know of anything standard defined for such purpose, except maybe for this: server-id option in named.conf: The ID the server should report when receiving .... a query of the name ID.SERVER with type TXT, class CHAOS.

i.e in your named.conf you define

server-id DC1; //or DC2 etc.

Sorta intended to identify which DNS server I'm talking to, which is sorta close to what you need.

  • I had thought of DHCP options, too, but it didn't seem like the easiest option. Now, how would I retrieve this "site-name" option on my clients? – ℝaphink Apr 6 '12 at 6:24
  • You write a script and put it at /etc/dhcp/dhclient-enter-hooks. dhclient runs this script each time it obtains a DHCP lease. This script recieves all the DHCP stuff as environment variables. Seems easy enough. – Sandman4 Apr 6 '12 at 9:06
  • Edited my answer - actual script location is different on new distributions. – Sandman4 Apr 6 '12 at 10:15
  • Thanks. That's useful, I'll try that. One problem is left: machines which don't use DHCP (typically, servers with a static address). What could I do for these, without specifying manually on which DC they are? – ℝaphink Apr 7 '12 at 11:37

DNS is a very strange location, if you want to put it into free-text.

From your description I derive that there are automated setup-routines that differ from data center to data center (since they use different primary DNS servers).

What I am doing - and this is my recommendation to you - works independent of the operating system: Set the SNMP-SysLocation during the automated installation and activate SNMPD. If you have multi-homed servers (i.e. many different network connections) you might have a separate administrative network as well. Setup the snmpd to listen in that network using the "AgentAddress" directive in snmpd.conf.

  • I want to avoid modifying each host when they move, since the goal is to detect where I am. Take for example laptops going from site to site. I would like them to automatically detect where they are (site1, site2, etc.) and configure themselves accordingly (printers, apt server, etc.). – ℝaphink Apr 4 '12 at 8:11
  • @Raphink So you have different networks in each location? Then you could use different DHCP-servers for each network and set a different DNS-server (or DNS-domain) for each network. Then you can define aliases pointing to the "right" local destinations (e.g. installserver will point to installserver.location2 when DHCP at location 2 delivers a searchlist for "location2" and you use "installserver" to contact the apt-server...). – Nils Apr 4 '12 at 21:11

If you want something simpler, just text, like "US/IL/Chicago/1060 W Addison St/floor 1/rack 2", use TXT records. That's what they're for. Script it up using dynamic DNS if necessary. TXT it can be in forward DNS attached to host names, or reverse DNS attached to IP addresses or even whole subnets (which might make the most sense for your case).


What's the numeric structure of your network like? As long as you're not sharing subnets between locations, you could grep a text file that maps a subnet to a data center. Could even make simple script to lookup the name, and then grep the file with the ip address from the lookup Datacenter1 Datacenter1 Datacenter1 Datacenter2 Datacenter2 Datacenter2
Now you say "mainly" location.... if you want rows, racks, enclosures, slots... that's a different beast where the answer about SNMP-SysLocation would be better.

  • The problem with using subnets to define location is that some machines have more than one interface, and I'd have to analyze all of them. I'd rather depend on a service provided authoritatively by the network I'm in. Typically, if a private DNS entry is resolved, I know for sure it will map to the information I want. – ℝaphink Apr 4 '12 at 8:10

I personally wouldn't recommend using DNS, as it is a centrally managed service meaning that if a server moves locations, you'd have to update the location information on the DNS server and wouldn't be able to simply control it on the system being moved.

If, on all the systems you're managing you can run SNMP and you know that the SNMP configurations allow you to store a system location (I believe they should, as Nils mentioned), you could run SNMP and have the systems store a location entry there. This would be slightly better in that you can control the server location on the server itself - if it moves, you can change the location easily and if the server is off, you won't be getting outdated information. However, there is the issue that if SNMP is off, you wouldn't know where the server is since you wouldn't be able to query SNMP.

I believe your best choice for managing this type of information properly would be to use a DC asset management system - as to which one, that would be up to you (there are plenty to choose from).

  • Maybe my question is not clear: I don't want to manage the location on the host, I want the host to discover its location automatically, so the goal is precisely that if a host is moved, it detects its new location without having to modify its own configuration. – ℝaphink Apr 4 '12 at 8:08
  • Ok, so then you want a centralized location system but if someone moves the server and doesn't update the data, then the host will not know its location changed. Sandman4's recommendation of DHCP is a good one if you want something centrally managed. Perhaps you should look at applications that can put together a network topology map based on MAC addresses and using router/bridge information so that you can get an idea of what's located where... – Eli Sand Apr 5 '12 at 23:27
  • If someone moves the server, I want the server to know its location changed, without changing anything on it. – ℝaphink Apr 6 '12 at 6:18

If all I had to work with is DNS I'd probably look at creating an srv record for each dns server to record the location which you could then retrieve, however something like active directory would be a far better solution

  • I'd avoid active directory, being in an environment that is 99.9% Linux servers. – ℝaphink Apr 4 '12 at 8:09
  • Why would you avoid active directory? Apache and fedora offer Linux based equivalents. – Jim B Apr 4 '12 at 12:29

Just a theory here, and I'm not a linux guy at all. If this was windows, I would simply setup dynamic DNS update ona single specific NIC that i know would always be plugged into network "x", and disable dynamic updates on the other NIC. Then I would know by the IP as the server moves around where its located.

However, since it looks like you don't have that option, one thing you could look into a pearl scirpt (as an example) that updates a CSV/TXT file or maybe even DNS.

The basic script would be:

  1. You have a centralized list of datacenter to IP mapping avaialbe for all servers to look up.
  2. Your server would be configured with a local script that runs daily, and check its NIC IP's and see if any IP matches a given subnet.
  3. if it matches it updates a CSV/TXT/DNS with its name and datacenter location.

IMO what might be better, is to actually have a central server use a script to look for a server by name and figure out its IP and then match it to a datacenter and store that in a CSV. Have it run once a day and create a new CSV daily. So all you'd have to do DNS wise, is simply make sure the A record is correct for the servers that move.

Edit 1:

The other thing that i don't think you've got covered is, how are you planning on handling purging a record after a server moves? Are you going to set an age limit on the record so that its deleted if not updated in "x" days? That would be another advantage to just using a simple centralized CSV. You could even use that centralized CSV to update DNS daily.

  • Right, but I don't want to depend on the subnet to know where I am. – ℝaphink Apr 6 '12 at 6:25

I actually set this up in our datacenters thusly:

  1. all servers have a standard search list except for; each datacenter is assigned a different, datacenter specific domain; i.e., www2.example, www3.example
  2. that domain is then placed first in the search list


  1. no resolution should be present in both the DC specific domain and any other domain; troubleshooting issues becomes a real nightmare
  2. using this method you must maintain multiple internal domains

This has proven a very effective method of allowing developers to create identical code that is then treated differently based on the calling location (server). For example, http://someapp:someport/blah/foo.do can be directed to an entirely different IP address (in our case


There's actually and interesting answer on stackoverflow which describes how to do this:

MaxMind Geolite city is free. If it is not good enough, you can apparently upgrade to a more accurate paid-version. I can't speak for the quality of the paid version, as I have never used it.

If you like your SQL, download the CSV version. Load it into your database of choice, and query away.

The faster and space-efficient option is to download the file binary blob version of the same database, and then use the C# class to query it.

Alternatively, I have found ipinfodb.com to be useful. Query is by simple HTTP GET. For example, to geolocate stackoverflow.com try:



Basically you can obtain this information by using the following command:

curl http://ipinfodb.com/ip_locator.php?ip=stackoverflow.com

Then parse the output from the response:

    <li>IP address : <strong></strong></li>
    <li>Country : US <img src="/img/flags/us.gif"/></li>
    <li>State/Province : CALIFORNIA</li>
    <li>City : SANTA CLARA</li>
    <li>Zip or postal code : 95050</li>
    <li>Latitude : 37.354108</li>
    <li>Longitude : -121.955236</li>
    <li>Timezone : -08:00</li>
    <li>Local time : April 6 13:23:41</li>
    <li>Hostname : stackoverflow.com</li>

Here, this command strips out the details:

curl http://ipinfodb.com/ip_locator.php?ip=stackoverflow.com|grep "<li>.*: "

Take a look at LLDP. It should be able to tell you what switch/router a specific server is on. From there, you can tell what datacenter it's in (either based on it's name, or you can store some additional metadata about it)


You might find this patent of interest. I believe it has been allowed to expire. https://www.google.com/patents/US20140051463 In case of link rot google "Paul Brabban patent".

ABSTRACT An apparatus and method for tracking physical locations from which a service is provided are disclosed. The apparatus comprises a communication module operable to send and receive messages, a location identifier and a query element operable to request the communication module to send a location request message for a service. The communication module is operable to receive a location response message responsive to said location request message, said location response message comprising location information for the service; and forward the location information of the service to the location identifier. The location identifier is operable to identify the physical location associated with the location information of the service.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.