IPFire Location: A decentralised, signed database in DNS

In the recent series of updates on IPFire Location, we are bringing you an exciting new feature today: Query our location database using DNS!

IPFire Location is a great project to work on. It supplies so many applications with useful data about where an IP connection might be coming from. That can be used to filter traffic, conduct statistical analysis to identify threats, localise online shops and a thousand more things.

We have been great advocates due to our passion for this project and have been working hard to get IPFire Location into as many distributions as possible. The list keeps growing and currently contains a lot of major distributions: Debian, Fedora, Ubuntu, Archlinux and of course in IPFire we make a lot of use of IPFire Location, too.

But sometimes, it isn't easily possible to integrate this software. Sometimes it is not necessary to have thousands of queries, only a few. And sometimes it is not necessary to have access to all the available data in the database, just a few bits. Although the library currently is only ~80 KiB and therefore very lightweight, why carry around the extra weight?

How to query a database without the data?

We came up with a new way to access this data from applications that don't have libloc. An HTTP API? Too bloated because we would generate a lot of overhead for transferring tiny responses. But how about DNS? It is perfect for this purpose! DNS is a protocol that virtually every device on this planet speaks. It is incredibly light and scales across the entire globe. And it is fast!

So I went ahead and built it :)

If you resolve www.ipfire.org, you are getting two IP addresses, 81.3.27.38 for IPv4 and another 2001:678:b28:: for IPv6. If you now want to query the IPFire Location database using DNS, you will have to apply a technique that is called a reverse lookup where the IP address is being reversed (that is not where the name is coming from) to send a request. For example 81.3.27.38 turns into 38.27.3.81.

To query certain information, you will need to append the appropriate domain names. Currently we support:

Let's see this in action:

Sending a query for a TXT record of 38.27.3.81.cc.location.ipfire.org gives us the country code where this IP address is hosted:

$ dig +short TXT 38.27.3.81.cc.location.ipfire.org
"DE"

If the country isn't enough, we can find out what data center this IP address is from.

$ dig +short TXT 38.27.3.81.origin.location.ipfire.org
"AS24679 - kyberio GmbH"

The same also works for IPv6 with only a slightly longer address:

$ dig +short TXT 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.b.0.8.7.6.0.1.0.0.2.cc.location.ipfire.org
"DE"
$ dig +short TXT 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.2.b.0.8.7.6.0.1.0.0.2.origin.location.ipfire.org
"AS204867 - Lightning Wire Labs GmbH"

Please check out the documentation for more examples.

Globally Decentralised & Cryptographically Secured

Using DNS is fast because there is no complicated TLS handshake. Instead, the query is a very small packet containing only the essential amount of data and the responses are equally small. A country code actually only needs two bytes to be transferred. That allows us to use another builtin feature of DNS: Global caching. Since the responses are so small and clients are usually never talking to authoritative DNS servers, responses get cached by the recursors which allows faster response times.

If you have heard about IPFire Location before, you will remember that we are emphasising a lot that our database is cryptographically signed. We deem this necessary since we deploy it in our firewall which means that a maliciously created database could mean major damage. How can we ensure the integrity of the data when using DNS instead of the builtin signature algorithm? The answer to that is DNSSEC. If supported by the client, the authenticity of the database can be verified by verifying the DNSSEC signatures on the response packet.

Why IPFire Location?

As you have seen with the dig CLI tool, this service is very easy to use. But it has always been that way due to the many language bindings that are available for C, Python, Perl and Lua. There are however many applications around written in other languages which can now be extended using IPFire Location over DNS. Considering the accuracy and authenticity of the data as well as fast lookups from the very start of the project allows us to bring Geo location data further than others, enabling a brighter future. There are so many opportunities opened now by IPFire Location using DNS that I don't even know where to begin: Threat Detection, Localisation, Network Analysis, Compliance. You name it. We got you covered.

To find out more about IPFire Location and its application, please visit the website.