|
Size: 846
Comment:
|
← Revision 11 as of 2008-06-26 09:55:38 ⇥
Size: 2053
Comment: converted to 1.6 markup
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| This text describes the way gnode request for MX in adna. It will be included in the final documentation, so feel free to correct it. But if you want to change the system here described, please contact us first. |
This text describes how the MX DNS query are resolved by ANDNA. * WARNING * This RFC has been deprecated by the NTK_RFC 0009 * WARNING * |
| Line 11: | Line 13: |
| In DNS server the MX field is provided by the DNS itself, to leave ADNA more flexible the MX in Ntk is provided by the host itself. When you need to know the MX of a domain you contact the domain main node via dsn query, the node. using the dns_wrapper, give you it's MX. |
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, |
| Line 14: | Line 18: |
| This requires small changes in the code: it is just necessary that the dsn_wrapper contact the domain main node instead the adna server and the node will reply with the MX field. | == hname MX resolution == |
| Line 16: | Line 20: |
| Easy and straight, that permit the ADNA server to be free from all the request but the Name resolving | 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] |
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]