It may be useful to use the DNS to name each IP address related to a node, permitting the translation from hostname to IP address and vice versa.
In principle each wireless group will be responsible for its own domain and the assignment of names to the IP addresses of its nodes. If a service of this type is offered then it is recommended that the DNS server for the domain is also accessible from the Internet.
In this document the domain name used will be represented generically as ${GROUP}, but it could be for example: redlibre.net, madridwireless.net or a sub-domain managed by the corresponding group.
All the nodes and clients could be named in a similar fashion to ease their identification:
First a name will be given to each node: NODE="node". The node name should be short.
It will be convenient if each group were to maintain a public web page with information about its nodes and the configuration and position of each one. This way future clients will be able to locate the nearest node to them.
Within each node the hosts/nodes/clients will be named as a sub-domain of ${NODE}.${GROUP}, in the following way: "name".${NODE}.${GROUP}.
The recommended names to include in the DNS are the following:
| Name | Description | IP Address |
|---|---|---|
| network | network address | 10.x.y.0 |
| router | the node's router | 10.x.y.1 |
| client1 | the address of the node's first client IP address | 10.x.y.2 |
| ... | ||
| client29 | the address of the node's last client IP address | 10.x.y.62 |
| broadcast | broadcast address | 10.x.y.63 |
| netmask | the node's netmask | 255.255.255.224 |
We should point out that the addition of the information in the DNS is for a simple reason: to help with the identification of IP traffic within the network. It is quite useful.
Other host names could be assigned in the DNS and this will be optional and a question for the node's administrator if the hostname is a sub-domain of the node, or of the "global" DNS administrator if the hostname is global to the domain.
For example the assignment of the name www.node23.madridwireless.net will be a question for the MadridWireless'node23 administrator, and the assignment of the name www.madridwireless.net, as should appear logical, will be a question for the administrator of the domain madridwireless.net.
At the same time as there will exist a relation name -> IP, the name server will also be configured to be able to make the inverse resolutions: IP -> hostname. This is very useful for identifying the source of IP traffic in the network.
Therefore it will be necessary to have the following types of records:
0.0.64.10.in-addra.arpa. IN PTR network.${NODE}.${GROUP}.
1.0.64.10.in-addra.arpa. IN PTR router.${NODE}.${GROUP}.
...
The nameserver to resolve these inverse addresses still
needs to be defined. We should also note that to carry out the inverse resolutions a common name server will be required, capable of resolving addresses from different wireless groups. This is different to the situation when a normal hostname is resolved because in the latter case this can be managed independently by each group.
[The inverse IP to name resolution can be delegated as well, and this is something which will need studying in the future.]
It is suggested that the reverse mappings are NOT modified from their standard values so that there is an orthogonal mapping of the form:
clientX.${node}.${group} IN A a.b.c.d
d.c.b.a IN PTR clientX.${node}.${group}
To ease the management of these multiple names the use of a web or mail tool such as the ampr.org robot could be used. See below for an explanation of the functionality provided by this robot.