There are services that allow a lookup of an IP address or Autonomous System Number (ASN) and return information about that IP number resource. The Regional Internet Registries (RIRs) each operate a database that records (among other data items) the number resource and the details of the entity that is described in the relevant number registration record. The data can be queried using the whois query tool by providing an IP Address or an ASN. The response is based on the registry’s database entries relating to that IP address or ASN in response.
An Internet search using the term ‘tools to retrieve information about an IP address’ will reveal a collection of such services.
One service that caught my attention was the ip-to-asn mapping service provided by Team Cymru, and in particular, the DNS variant of this service.
This service requires some preprocessing of the query string. The octets of the IP address need to be reversed, and in the case of an IPv6 address, the ‘:‘ delimiter needs to be replaced by the same reverse order of the string of 8-bit octets. Here are a couple of examples:
$ dig +short TXT 31.108.90.216.origin.asn.cymru.com
"3561 | 216.88.0.0/14 | US | arin | 1998-09-25"
$ dig +short TXT 8.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.b.0.6.8.4.1.0.0.2.origin6.asn.cymru.com.
"15169 | 2001:4860::/32 | US | arin | 2005-03-14"
That IPv6 address query is ugly, and the IPv4 address used in the query is not any better! This need for reverse ordering and translating IPv6 addresses seems to me to be an unnecessary step. What would be easier is to query directly for an IPv4 address or an IPv6 address without any preprocessing. Can we do this?
Database instead of a zone file, and flexible use of characters
‘Classic’ DNS uses the concept of a ‘zone file’, which lists all the defined labels in the zone. When a server receives a query name (and query type), the server looks for an exact match of the query name with the labels defined in the zone file to resolve the query. If it finds a match, the server assembles the matching records as its response. However, the concept of a ‘zone file’ is convenient, but not necessary.
Some servers use a database backend in place of a zone file and perform a database lookup to find the response record. More generally, a DNS authoritative server could execute any procedure it wanted that generated a DNS response that correlates in some manner to the query it received.
Further, we can revisit the question of which characters are permitted in a DNS query. In practice, this means that, perhaps despite the strictures described in various RFCs, the DNS in practise is surprisingly flexible about which characters can be used to form DNS query names. Even the ‘.‘ character, normally used to define the ‘cut points’ from one zone to a delegated subordinate zone, can also be used within a DNS zone label. The DNS appears not to care!
Assembling the stupid trick
To assemble this particular stupid DNS trick, we can put these two observations together. We need to use a DNS authoritative server platform that supports the concept of using a ‘plug-in’ backend server in place of a zone file lookup. The PowerDNS authoritative server supports this function. Unlike the IP-ASN-mapping DNS tool provided by Team Cymru, it’s possible to create an authoritative server that does not require reversing octets or stripping out the IPv6 ‘:‘ delimiters.
The result is a simple query with the same output:
$ dig +short TXT 216.88.0.0.origin.asn.ipasn.net
"216.88.0.0/14 | 3561 | US | arin | 1998-09-25"
and
$ dig +short TXT 2401:2000:6660::.origin6.asn.ipasn.net
"2401:2000::/32 | 4608 | AU | apnic | 2007-06-19"
This data is assembled by:
- Looking up the address prefix in a current Border Gateway Protocol (BGP) routing table snapshot to retrieve the origin AS.
- Looking in a geolocation database to get the CC where the address prefix is located.
- Looking into RIRs’ statistics reports to retrieve the RIR that holds the registration record and the date of registration.
Could we push this concept a bit further?
For example:
$ dig +short TXT 216.88.0.0.ipasn.net"216.88.0.0|IPv4|ADVERTISED|216.88.0.0/14|3561|CenturyLink_Communications,_LLC|US|United_States_of_America|arin|216.88.0.0/14|assigned|1998-09-25|VLD|216.88.0.0/14|24|3561|ARIN"
This output shows that:
- The advertised address prefix is a /14.
- The originating AS is AS3561.
- The name of the organization that holds this prefix is ‘CenturyLink_Communications, LLC’ in the United States.
- The registry status of this address prefix is ‘assigned’ by ARIN.
- The date of the registration is 25 September 1998.
- There is a valid Route Origin Authorization (ROA) published for this address, using a maximum length of 24 and an originating AS of AS3561.
- The Resource Public Key Infrastructure (RPKI) Trust Anchor (TA) for this ROA is operated by ARIN.
It’s possible to generate the same information formatted as a JSON data object:
$ dig +short TXT 216.88.0.0.json.ipasn.net
"{\"Address\":\"216.88.0.0\",\"Class\":\"IPv4\",\"BGP\":\"ADVERTISED\",\"Advertised_Prefix\":\"216.88.0.0/14\",\"Origin_AS\":\"3561\",\"Org_Name\":\"CenturyLink_Communications,_LLC\",\"CC\":\"US\",\"CC_Name\":\"United_States_of_America\",\"RIR\":\"arin\",\"RIR_Prefix\":\"216.88.0.0/14\",\"Reg_Sta" "tus\":\"assigned\",\"Reg_Date\":\"1998-0-25\",\"ROV\":\"VLD\",\"ROA_Prefix\":\"216.88.0.0/14\",
\"ROA_Maxlen\":\"24\",\"ROA_AS\":\"3561\",\"ROA_TAL\":\"ARIN\"}"
DNS recursion is also supported by having the back-end process perform its own DNS resolution operation.
$ dig +short TXT www.potaroo.net.dns.ipasn.net
"2401:2000:6660:0:0:0:0:108|IPv6|ADVERTISED|2401:2000::/32|4608|APNIC_Research_and_Development|AU|
Australia|apnic|2401:2000::/32|assigned|2007-06-19|VLD|2401:2000::/32|35|4608|APNIC_RPKI_Root"
Or, if you wanted the IPv4 address record rather than the default IPv6 record:
$ dig +short TXT www.potaroo.net.a.dns.ipasn.net"203.133.248.108|IPv4|ADVERTISED|203.133.248.0/24|4608|APNIC_Research_and_Development|JP|Japan|apnic|203.133.248.0/22|assigned|2007-05-22|VLD|203.133.248.0/23|24|4608|APNIC_RPKI_Root"
We can also query individual attributes:
$ dig +short TXT 216.88.0.0.cc.ipasn.net
"US"
$ dig +short TXT 216.88.0.0.rpki.ipasn.net
"VLD_216.88.0.0/14-24_3561_ARIN"
DNS as a distributed processing system
Is this useful?
I’m not sure if it’s useful to anyone, but this exercise illustrates the inherent flexibility that lurks in the DNS, where it’s possible to dynamically generate DNS responses based on the query string. The DNS system is not just a distributed directory, but can be seen as a form of a distributed processing system, and queries as coded instructions, which DNS servers execute.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.