NTK_RFC 0004

Subject: Mail Exchange request

This text describes how the MX DNS query are resolved by ANDNA.

• WARNING *

This RFC has been deprecated by the NTK_RFC 0009

• WARNING *

In the DNS the resolution of the MX field is handled directly by the DNS servers, in ANDNA, instead, the resolution of an MX hostname is a redirect request. In short it means that the request, instead of being sent to a hash_node, is sent to the register_node itself,

hname MX resolution

The resolution of a MX hostnames in ANDNA works in this way:

• We are trying to resolve the MX of the "pippo" hname.
• "pippo" is resolved normally and the IP of the register_node is gained.
• We ask to the register_node the IP of its MX.

hname MX registration

Since the IP of the MX node can change during the time, the register_node must be aware of its current IP. It is the MX node itself that tells the register_node its current IP each time it changes. The MX node to contact the register_node has to simply resolve its hname. The register_node has to verify the authenticity of the IP update request, therefore the MX node will sign the request with the private key of the register_node.

This system is necessary because the MX node and the register node have to be synced. In this way when the register_node dies or can't be reached anymore, the MX node can't be contacted too. Moreover this system prevents the spoofing of the MX node.

The steps necessary to register a hname MX are:

• Copy the ANDNA private key of the register node, which is saved in its lcl_cache, to the MX node:

register_node# scp /usr/share/netsukuku/andna_lcl_keyring mx_node:/etc/netsukuku/mx/<HNAME_MX>
# <HNAME_MX> is the hname relative to the MX node

• Send a SIGHUP to the MX NetsukukuD:

register_node# ssh mx_node "killall -SIGHUP ntkd"

If no MX is associated to an hostname, the register_node will use its own IP as the default MX IP.

related: [Netsukuku_RFC]