Se plantea la utilidad de utilizar el DNS para nombrar cada dirección IP relacionada con el nodo, de permitir la traducción de un nombre de host a un IP y viceversa.
En principio cada grupo wireless será responsable por su propio dominio y la asignación de nombres a las direcciones IP de sus nodos. Si se ofrece un servicio de este tipo se recomienda que el servidor DNS para este dominio también será disponible en Internet.
En este documento se representará el nombre de dominio utilizado de manera genérica como ${GROUP}, pero podría ser por ejemplo: redlibre.net, madridwireless.net o un subdominio de un dominio gestionado por el grupo correspondiente.
Todas los nodos y clientes se podrían nombrar de una forma parecida para facilitar su identificación:
Primero se dará un nombre a cada nodo: NODE="nodo". El nombre del nodo debe ser corto.
Sería conveniente que cada grupo tenga una página web pública con información de sus nodos y la configuración y ubicación de cada uno. De esta manera los posibles clientes podrían localizar el nodo más cercano.
Dentro de cada nodo se nombrará todos los hosts/nodos/clientes como un subdominio de ${NODE}.${GROUP}, de la forma: "nombre".${NODE}.${GROUP}.
Los nombres recomendados a incluir en el DNS serán los siguientes:
| Nombre | Descripción | Dirección IP |
|---|---|---|
| network | la dirección de la red | 10.x.y.0 |
| router | el router principal del nodo | 10.x.y.1 |
| client1 | la dirección ip de primer cliente del nodo | 10.x.y.2 |
| ... | ||
| client29 | la dirección ip del último cliente del nodo | 10.x.y.62 |
| broadcast | la dirección de broadcast de la red | 10.x.y.63 |
| netmask | el netmask de la red | 255.255.255.224 |
Debemos destacar que el alta de esta información en el DNS es para un motivo sencillo: la ayuda con la identificación del tráfico IP dentro de la red. Es muy útil.
Se podría asignar en el DNS otros nombres de host, y está posibilidad será opcional y cuestión del gestor del nodo correspondiente si es un subdominio de su nodo o del gestor de DNS global si es un nombre "global".
Por ejemplo la asignación del nombre www.nodo23.madridwireless.net será cuestión del gestor del nodo23 de MadridWireless, y la signación del nombre www.madridwireless.net, como es lógico, del administrador de madridwireless.net.
A la vez que existírá un relacion nombre -> ip, también se configurará un servidor de nombres para permitir la resolución inversa: ip -> nombre. Este uso es muy cómodo para la resolución de problemas y para identificar la fuente de tráfico IP en la red.
Así que hará falta unos registros del tipo:
0.0.64.10.in-addra.arpa. IN PTR network.${NODE}.${GROUP}.
1.0.64.10.in-addra.arpa. IN PTR router.${NODE}.${GROUP}.
...
El servidor de nombres para resolver la direcciones
inversas está todavía pendiente de definir.Debemos indicar que en el caso de la resolución del DNS inversa, podría ser necesario disponer de un servidor DNS común que sea capaz de resolver direcciones ip a nombres para más que un grupo. Es una situación diferente a la resolución "normal" donde cada grupo lo puede gestionar de manera independiente.
[Se podría delegar el DNS inverso también: es algo que se debe estudiar en el futuro si esta opción conviene más.]
Se surgiere que NO se modifique el DNS inverso, al menos para los nombres estándar: network, router y broadcast para cada nodo.
Para facilitar la gestión de estos multiples nombres se plantea el uso de unas herramientas web o email, como el robot del dominio ampr.org. Ver abajo para una explicación de su funcionamiento.