- Developer Corner
- Recent posts
DNS allows to resolve the name of an IP address. This is sometimes called "reverse lookup". In fact, it is actually "normal" resolution of a PTR record. The name of such a record would be, for example, 188.8.131.52.in-addr.arpa. The .arpa TLD is managed by IANA.
This blogpost is meant to spread ideas that have been exchanged via private email and might be interesting for a broader audience. If you feel like you have useful comments, don't hesitate to do so.
Reverse resolution is a useful feature to enhance readability of service descriptors.
Examples where reverse lookups are useful include:
Received an email from bob@ABCD.zkey or pubkey authentication by ABCD.zkey to my service.
In GNS, reverse resolution is currently not supported and even if it was, there are some obstacles that need to be managed.
Reverse lookups in GNS
GNS names (.gnu TLD) are resolved relative the the user's local root zone. GNS reverse lookups are limited to PKEYs. e.g. Alice wants to know who ABCD.zkey is and how her root namespace relates to that identity.
A simple example reverse lookup would be:
$ gnunet-gns -R ABCD.zkey
This tells alice that ABCD.zkey is actually "dave" that is known by Alice's friend "bob".
However, the actual lookup of this delegation is non-trivial in GNS as bob can choose any name for dave's PKEY. This name is unknown to Alice.
A straight forward approach for a lookup would be the following:
Why does resultion stop at 5.? Because if Alice cannot find a delegation to ABCD in one of her known and delegated PKEYs there is no way for her to enumerate all records in those namespaces (by design, GNS leverages this for query privacy and record confidentiality).
This method is characterized by two properties:
Advanced reverse lookups in GNS
In some discussions with Christian we have established a few approches that can improve reverse resolution.
If namespaces would contain special records under the "+" label that point back to other namespaces delegating to them it would allow us to implement an algorithm to lookup the delegation "backwards", i.e. starting from the zone in question (ABCD):
This approach requires the addition and management of REVERSE records. As this cannot be expected by the user it must be done by GNS automatically. For example, GNS might periodically check if any namespaces delegated to from the root zone also contain a delegation back to our root zone (e.g. by checking if alice.bob.gnu can be resolved to Alice's root zone). Those namespaces are added in a REVERSE record.
REVERSE and FORWARD records
We could also support some kind of directed
search from both ends:
Now, if we want to find out who ABCD.zkey is, we start from both ends:
Each of the iterations results in an exponential increase in the
working sets, so we shoud stop at some maximum number of records inspected with "not found".
Global delegation DB
If we add a way to distribute the public
delegations, for which something simple like running a combination of
gossip (new public record) and the existing GNUnet SET union protocol
(new neighbour) between peers should allow us to easily replicate the
entire public DB globally. Then, reverse lookup is trivial (local
DB operation), at least as long as all public links can be globally
replicated. Might combine it with some modest proof-of-work to avoid
people spamming the network.
This might also require us to redefine record visibility to: