Differences between revisions 5 and 6
Revision 5 as of 2006-04-07 17:39:24
Size: 4175
Editor: alpt
Comment:
Revision 6 as of 2006-04-11 04:57:43
Size: 5610
Editor: alpt
Comment:
Deletions are marked like this. Additions are marked like this.
Line 14: Line 14:
The Scattered Name Service Disgregation is the generalization of the DNS MX
concept. With the SNSD a hostname can be associated to multiple IPs.
Each assigned IP has a service number, in this way the IPs with the same
service number are grouped in an array.
The Scattered Name Service Disgregation is the ANDNA equivalent of the
SRV Record of the Internet Domain Name System, which is defined here:
http://www.ietf.org/rfc/rfc2782.txt
For a brief explanation you can read:
http://en.wikipedia.org/wiki/SRV_record

SNSD isn't the same of the "SRV Record", in fact, it has its own unique
features.

With the SNSD it is possible to associate IPs and hostnames to another
hostname.
Each assigned record has a service number, in this way the IPs and hostnames
which have the same service number are grouped in an array.
Line 19: Line 28:
therefore it will get the IP associated to the hostname which has the
specified service number
. Example:
therefore it will get the record of the specified service number which is
associated to the hostname. Example:
Line 24: Line 33:
X associates the 11.22.33.44 IP to the `http' service number (80) too. X associates the "depausceve" hostname to the `http' service number (80) of
"angelica".
X associates the "11.22.33.44" IP to the `ftp' service number (21) of
"angelica".
Line 27: Line 39:
its web browser tries to resolve it, it asks for the IP associated to
the `http' service, therefore the resolution will return 11.22.33.44.
its web browser tries to resolve it, it asks for the record associated to
the `http' service, therefore the resolution will return "depausceve".
The browser will resolve "depausceve" and will finally contact the server.
When the ftp client of Y will try to resolve "angelica", it will get the
"11.22.33.44" IP.
Line 30: Line 45:
The node which has the 11.22.33.44 IP is called "SNSD node".
The IP of the SNSD node is called "SNSD IP".
The node which has the 1.2.3.4 IP is always called "register node", but can
also be name "Zero SNSD node".
The node associated to a SNSD record is called "SNSD node". In this example
"depausceve" and 11.22.33.44 are SNSD nodes.

The node which registers the records and keeps the registration of the main
hostname is always called "register node", but it can also be named "Zero SNSD
node", in fact, it corresponds to the most general SNSD record: the service
number 0.
Line 37: Line 55:
== Service and priority number == == Service, priority and weight number ==
Line 41: Line 59:
The service number specifies the scope of an IP. The IP associated to the
service number `x' will be returned only to a resolution request which has the
same service number.
The service number specifies the scope of a SNSD record. The IP associated to
the service number `x' will be returned only to a resolution request which has
the same service number.
Line 48: Line 66:
An IP of service number 0 corresponds to a normal IP. It will be returned to a
general resolution request.
The service number 0 corresponds to a normal ANDNA record. The relative IP
will be returned to a general resolution request.
Line 53: Line 71:
The IP has also a priority number. This number specifies the priority of
the IP inside its service array.
This is how a hash_node chooses which IP will be replied to a resolution
request:
The SNSD record has also a priority number. This number specifies the priority
of the record inside its service array.
The client will contact first the SNSD nodes which have the higher priority,
and only if they are unreachable, it will try to contact the other nodes
which have a lower priority.
Line 58: Line 77:
First of all it goes in the array of the specified service number.
Let's suppose that in the `http' service number array there are 8 different
IPs. The IP, which will be sent in the reply, is chosen in a pseudo-random
manner: each IP has a probability to be picked, which is proportional to its
priority number, therefore the IPs with the higher priority are more likely to
==== Weight ===

The weight number, associated to each SNSD record, is used when there are
more than one records which have the same priority number.
In this case, this is how the client chooses which record using to contact
the servers:

The client asks ANDNA the resolution request and it gets, for example, 8
different records.
The first record which will be used by the client is chosen in a pseudo-random
manner: each record has a probability to be picked, which is proportional to its
weight number, therefore the records with the heavier weight are more likely to
Line 64: Line 90:
If the IPs have the same priority, then the choice is completely random. Note that if the records have the same priority, then the choice is completely
random.
Line 68: Line 95:
The registration method of a SNSD IP is similar to that described in the The registration method of a SNSD record is similar to that described in the
Line 71: Line 98:
The SNSD node has to take care of the registration and the updating of its IP.
It will send normal registration requests to ANDNA, but it will sign the
request with the same privke of the register_node.
In the registration request the relative service and priority number will be
specified too.
The maximum number of SNSD records which can be associated to an hostname is
256.

The registration of the SNSD records is performed by the same register_node.
Line 78: Line 104:
anything about it. It has only to check the validity of the signature, in this
way, it is sure that the request was sent by a "friend" of the register_node
.
anything about it. It has only to check the validity of the signature.
Line 81: Line 106:
The steps necessary to register a SNSD IP are:
 * Copy the ANDNA keyring of the register node, which is saved in its lcl_cache, to the SNSD node:
The register node can also choose to use an optional SNSD feature to be sure
that a SNSD hostname is always associated to its trusted machine. In this
case, the register_node needs the ANDNA pubkey of the SNSD node to send a
periodical challenge to the node.
If the node failes to reply, the register_node will send to ANDNA a delete
request for the relative SNSD record.

In practice, the steps necessary to register a SNSD record are:
 * Modify the /etc/netsukuku/snsd_nodes file.
Line 84: Line 116:
register_node# cd /usr/share/netsukuku/
register_node# scp andna_lcl_keyring snsd_node:/etc/netsukuku/snsd/<HNAME>[:<service>[:<priority>]]
# <HNAME> is the hname of the register_node
# <service> is the service number. It is separated from the <HNAME> by a ':'
# character.
# <priority> is the priority number. It is optional and it is seperated from the <service>
# number by a ':' character. To specify the priority number it is also
# necessary to specify the service number.
register_node# cd /etc/netsukuku/
register_node# cat snsd_nodes
#
# SNSD nodes file
#
# The format is:
# hostname:snsd_hostname:service:priority[:pub_key_file]
# or
# hostname:snsd_ip:service:priority[:pub_key_file]
#
# The `pub_key_file' parameter is optional. If you specify it, NetsukukuD will
# check periodically `snsd_hostname' and it will verify if it is always the
# same machine. If it isn't, the relative snsd will be deleted.
#

depausceve:pippo:http:1
depausceve:1.2.3.4:21:0

angelica:frenzu:22:1:/etc/netsukuku/snsd/frenzu.pubk
register_node#
register_node# scp frenzu:/usr/share/andna_lcl_keyring snsd/frenzu.pubk
Line 93: Line 138:
 * Send a SIGHUP to the NetsukukuD of the SNSD node:  * Send a SIGHUP to the NetsukukuD of the register node:
Line 95: Line 140:
register_node# ssh snsd_node "killall -SIGHUP ntkd" register_node# killall -SIGHUP ntkd
# or, alternatively
register_node# rc.ntk reload

NTK_RFC 0009

Subject: Scattered Name Service Disgregation


This text describes the Scattered Name Service Disgregation, an extension of the ANDNA protocol. 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.


SNSD

The Scattered Name Service Disgregation is the ANDNA equivalent of the SRV Record of the Internet Domain Name System, which is defined here: http://www.ietf.org/rfc/rfc2782.txt For a brief explanation you can read: http://en.wikipedia.org/wiki/SRV_record

SNSD isn't the same of the "SRV Record", in fact, it has its own unique features.

With the SNSD it is possible to associate IPs and hostnames to another hostname. Each assigned record has a service number, in this way the IPs and hostnames which have the same service number are grouped in an array. In the resolution request the client will specify the service number too, therefore it will get the record of the specified service number which is associated to the hostname. Example:

The node X has registered the hostname "angelica". The default IP of "angelica" is 1.2.3.4. X associates the "depausceve" hostname to the `http' service number (80) of "angelica". X associates the "11.22.33.44" IP to the `ftp' service number (21) of "angelica".

When the node Y resolves normally "angelica", it gets 1.2.3.4, but when its web browser tries to resolve it, it asks for the record associated to the `http' service, therefore the resolution will return "depausceve". The browser will resolve "depausceve" and will finally contact the server. When the ftp client of Y will try to resolve "angelica", it will get the "11.22.33.44" IP.

The node associated to a SNSD record is called "SNSD node". In this example "depausceve" and 11.22.33.44 are SNSD nodes.

The node which registers the records and keeps the registration of the main hostname is always called "register node", but it can also be named "Zero SNSD node", in fact, it corresponds to the most general SNSD record: the service number 0.

Note that with the SNSD, the NTK_RFC 0004 will be completely deprecated.

Service, priority and weight number

Service number

The service number specifies the scope of a SNSD record. The IP associated to the service number `x' will be returned only to a resolution request which has the same service number.

A service number is the port number of a specific service. The port of the service can be retrieved from /etc/services.

The service number 0 corresponds to a normal ANDNA record. The relative IP will be returned to a general resolution request.

Priority

The SNSD record has also a priority number. This number specifies the priority of the record inside its service array. The client will contact first the SNSD nodes which have the higher priority, and only if they are unreachable, it will try to contact the other nodes which have a lower priority.

==== Weight ===

The weight number, associated to each SNSD record, is used when there are more than one records which have the same priority number. In this case, this is how the client chooses which record using to contact the servers:

The client asks ANDNA the resolution request and it gets, for example, 8 different records. The first record which will be used by the client is chosen in a pseudo-random manner: each record has a probability to be picked, which is proportional to its weight number, therefore the records with the heavier weight are more likely to be picked. Note that if the records have the same priority, then the choice is completely random.

SNSD Registration

The registration method of a SNSD record is similar to that described in the NTK_RFC 0004.

The maximum number of SNSD records which can be associated to an hostname is 256.

The registration of the SNSD records is performed by the same register_node. The hash_node which receives the registration won't contact the counter_node, because the hostname is already registered and it doesn't need to verify anything about it. It has only to check the validity of the signature.

The register node can also choose to use an optional SNSD feature to be sure that a SNSD hostname is always associated to its trusted machine. In this case, the register_node needs the ANDNA pubkey of the SNSD node to send a periodical challenge to the node. If the node failes to reply, the register_node will send to ANDNA a delete request for the relative SNSD record.

In practice, the steps necessary to register a SNSD record are:

  • Modify the /etc/netsukuku/snsd_nodes file.

register_node# cd /etc/netsukuku/ 
register_node# cat snsd_nodes
#
# SNSD nodes file
#
# The format is:
# hostname:snsd_hostname:service:priority[:pub_key_file]
# or
# hostname:snsd_ip:service:priority[:pub_key_file]
#
# The `pub_key_file' parameter is optional. If you specify it, NetsukukuD will
# check periodically `snsd_hostname' and it will verify if it is always the
# same machine. If it isn't, the relative snsd will be deleted.
#

depausceve:pippo:http:1
depausceve:1.2.3.4:21:0

angelica:frenzu:22:1:/etc/netsukuku/snsd/frenzu.pubk
register_node#
register_node# scp frenzu:/usr/share/andna_lcl_keyring snsd/frenzu.pubk
  • Send a SIGHUP to the NetsukukuD of the register node:

register_node# killall -SIGHUP ntkd
# or, alternatively
register_node# rc.ntk reload


related: ["Netsukuku RFC"]

Ntk_SNSD (last edited 2008-07-04 12:47:31 by jaromil)