ANDNA - Netsukuku Host Naming Service

Hello! This is the second article about Netsukuku , a project to create a P2P alternative to the modern Internet.

This time I will talk about ANDNA (A Netsukuku Domain Name Architecture) - the name resolution service for IP addresses, which is the local equivalent of the DNS service and is protocol compatible with it.

Those who do not know what it is all about, I recommend reading the first part .

')

Foreword

In the last article, due to the sew of inspiration in my ass , I promised to talk about routing and types of trace packets. However, this topic requires a rather dense rethinking and thoughtful smoking of manuals, which did not have enough time. Therefore, I decided to write about the name service, since it was easier for me to comprehend it.

In general, the second part turned out the way it was :)

Basic principles

In the modern Internet, you can reach a certain network node in two ways. The first is to directly specify the IP address of the node. The second way is to address the node by its name. There are few good names and everyone wants to get them. Therefore, the allocation and use of names has to be regulated by law. For this, there is an ICANN organization that leads the process of creating zones and delegates the rights to registrars of individual countries.

In the case of Netsukuku, things are different. Since the node address is a variable value, you can not bind the name directly to the IP. The network is decentralized, and generally unmanaged. Accordingly, the approach to the process of registering names must also meet these requirements.

All nodes have equal rights to receive the name. The only limitation is related to the number of names associated with a single node (to prevent cybersquatting). Otherwise, the user is free to choose any name up to 500 characters long. So if you have imagination, there will be no shortage of names :)

Like the entire Netsukuku network, ANDNA is built on a distributed basis. Thus, there is no single data warehouse. Information "spread" on all nodes of the network; multiple duplication ensures the reliability and resiliency of its work. According to calculations, the volume of the base at each node, even in the worst case, should not exceed 300 Kb, so the requirements for minimizing the resources used are observed here.

Register Host Name

Suppose that some node X wants to register the name "habr.ru":



For this, it calculates a hash on behalf of: h ("habr.ru") = 0x11223344. The numeric representation of the hash is interpreted as the address of the node that will be considered the repository. This is the so-called hash node (node ​​H). Further, the hash node performs some checks (it is written about them below), and then enters the association of the name and address into its database. After that, the node X is considered the owner of the name and just will not lose it.

Any node that wants to know the address of the node with the name “habr.ru”, in the same way, calculates the hash and gives a request to the H node (or rather, to a randomly selected neighbor from the same group).

Of course, with low population of addresses, a direct hit of the hash will be quite rare, so some assumptions are made:

• If a node with address H exists, it is used;
• If not, the gnode address of H (11.22.33.x) is used;
• If there is no such group, then the group with the number closest to the desired one is taken (for example, 11.22. 34 .x). Such a group is called rounded (rounded gnode).

It is important to note that this in no way interferes with the normal operation of the service. When new nodes appear anywhere on the network, the service automatically adapts to the changed conditions.

Access control

Having registered some successful name, we naturally do not want an arbitrary node to take it away from us. This is secured by digital certificates. Rights control is carried out at all stages of interaction and is completely reliable.

When registering a new name, the initiator node generates a pair of cryptographic keys, and then the public key transfers to the domain, among other registration information. This key will be saved by the hash node throughout the lifetime of the given name; any actions of the owner must be confirmed by a corresponding digital signature. Thus, if the host’s IP address is changed, or the name is renewed, the owner’s site must first confirm its rights.

By default, a hash node will store name information for 30 days after registration. After that, the actions of the owner of the name to extend it are required. The name will remain yours if at least once a month your site appears on the network.

If after this period the registration has not been extended, the name is given to the next candidate. Moreover, the mechanism of "live queue" is provided here.

Registration queue

Only one node can be associated with a name at a time. However, anyone can apply for a name by trying to register it for themselves. Hash node stores a list of five candidates for registration, which is filled in the order of requests.

As soon as the name is released, the hash node deletes the top entry and re-registers the name to the new owner. In short, the usual approach - who got up earlier, that and sneakers.

Name limit

Formally, a node can have any number of names. However, for practical reasons, a limit is imposed on the number of names, equal to 256. It seems to me that 16 would be above the roof, but the authors apparently have a different opinion :)

In addition to the hash of the node, so-called. counter node - counter node. This node stores the number of names associated with the source node. It works like this:



When a registration request is received, the hash node H calculates the hash from the public key “ABC” of node X, which in turn is already treated as the address of the node of counter C. The hash of the node queries the counter to find out how many names are currently associated with a registering node.

If this number does not exceed the limit, the counter value is increased by 1 and registration continues. If not, the registration of the domain node will be denied.

Since there is no single repository of information and it is not known in advance who will be used as a counter node, it is practically impossible to compromise this mechanism.

In fact, the hacker's task is reduced to the task of generating a pair of keys using a previously known hash (address). And this leads immediately to the two most difficult tasks: a) to find a collision hash function (restore the original block) and b) to build a private key using this block (public key), which is unrealistic doubly.

Distributed query caching

Each node that resolved a certain name to an address stores the result in its cache. This cache is readable to everyone around. A node X that performs a search for a node actually asks its neighbor Y from the same group, which is randomly selected. Further two options are possible.

Option one: a neighbor checks for an entry in its cache and returns it to node X.


Option two: there were no entries in the cache; node Y produces resolution in the usual way.


The result of this algorithm is to increase the speed of the service and reduce the load on the hash nodes corresponding to popular names.

Reverse name resolution

If node X wants to know all the names associated with node Y, it simply asks the node Y about this :)

Redundancy

Since any node in our network can be disconnected at any time, it is necessary to provide a redundancy mechanism in information storage. This is implemented at the level of the group containing the node hash.



When registering a new name, the information is recorded in all nodes of the group, that is, the entire group of nodes close to the hash node will contain copies of the information. Accordingly, if you turn off the main hash of the node, any node in the group will be able to answer the question.

When name resolution is performed, the node that has calculated the hash refers to an arbitrary node of the group hash, that is, abcx. Thus, it turns out that all the nodes of the group process requests uniformly.

A similar mechanism applies to groups of counters.

DNS compatibility

ANDNA can work in traditional DNS compatibility mode. For this, a “wrapper” is launched on the user node, listening on port 53 and forwarding requests to the network. Due to this, the existing software will be able to work on the Netsukuku network without any changes.

Summary

So, in this article, we looked at the ANDNA service, which is used to store and resolve host names. We found out that the service complies with the ideology of the entire Netsukuku network, is distributed and fault-tolerant. Storing information is not very annoying to each node, and therefore also does not represent a problem. Any budget router will do the job.

Conclusion

In conclusion, I would like to note that this article is in fact a free retelling of documentation. The authors note that, in general, the architecture of the service has been worked out, but it is still far from complete. In particular, I am somewhat confused by the mechanism of introducing redundancy.

As mentioned above, redundancy is achieved by distributing information within a group of hash nodes. On the one hand, it allows you to easily distribute the load between the nodes, choosing them randomly.

On the other hand, it is not entirely clear what to do if the whole group is suddenly cut off from the network. It turns out that the rest of the network will not have a single node that can resolve the name, the hash of which falls on the disabled group. Probably, the solution should be sought in the mechanism of periodic polling by the owner of the name of his hash group. If suddenly it is completely unavailable - re-register the name again. Then, when the connection is restored, the group hash will always be able to agree (comparing the keys and finding out that the owner of both copies of the names is the same).

Behind this, I will ask to leave. I hope you enjoyed this article as well as the previous one :)

PS: Next time I will address in more detail the issues of routing, QSPN algorithm and issues related to it.

PPS: Another question: is this level of detail suitable for articles? Maybe worth digging deeper? Or vice versa, to concentrate more on ideas, and not on implementation? Although the latter here and so there was almost no.

_{Charts are created using the smartdraw editor.
Separate graphic elements taken from iconfinder.net}