Assume you have a server attached to a mesh node and that node has internet access. Proper routing is set up so that the public DNS system points to your external public address, and all the forwarding is correct to see the server anywhere on the web.
Also, this same server can be accessed through the mesh network using the xxx.local.mesh addressing.
All is well. One can access the server using the DNS name if connected to the web, or using the OLSR name if connected on the mesh.
Now comes the wish list.....
We have a client application that has an entry for 'Server' where you enter the server name. Which works fine on the internet network. Now, the internet goes down and the client host computer has mesh access instead of internet access. I want the client 'Server' field to contain something that the mesh network recognizes AND that the public DNS recognize.
In other words, I want to idiot proof the process so that an individual does not have to think 'Oh, the internet is down but I am connected to the mesh so I have to change the Server field to xxx.local.mesh instead of a FQDN.'
The only way I see this happening is for a server to run bind over the mesh and feed that into OLSR. Can it do that? Is everyone here smarter then I am and can guide me through setting that up possibly? Another solution? Darryl?
Thanks
Mark
You are here
OLSR - DNS failover
Thu, 05/25/2017 - 17:29
#1
OLSR - DNS failover
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Many programs support multiple server addresses, this one perhaps support as such? Any reason to not always run it over the mesh? Best way to test the mesh is to use it with traffic across it regularly.
This client program does not support multiple server addresses. If it did I would not have to be asking for another method to accomplish the task.
Yes, we cannot run on the mesh all the time because the mesh is not always available, as is the internet during a disaster.
This is not for testing. We know the mesh works. It is used every day. The client program does something completely different and simply uses a network for the client-server communications.
I simply want to know if there is a way that a server, on the mesh, can also advertise it's FQDN over the mesh so that the client will seamlessly continue to operate as the client moves from one network to the other. Whether that is something the node can do, or if there is someone here that knows of a way to do it is one of the questions I pose.
Mark
"I simply want to know if there is a way that a server, on the mesh, can also advertise it's FQDN over the mesh so that the client will seamlessly continue to operate as the client moves from one network to the other. Whether that is something the node can do, or if there is someone here that knows of a way to do it is one of the questions I pose."
Currently this is not a feature on nodes, all name space for the mesh is currently in the "local.mesh" name space which is intentionally outside the global internet namespace.
As for knowing if a feature exists or not the entire program is currently documented in the node help which is available both on node and here is the link to the latest version for stable release http://www.aredn.org/content/aredn-help-file-31610