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]