Is it practical to provide DNS service within an AREDN mesh? I mean something similar to dynadot or namecheap, where people can publish mydomain.com or yourdomain.com, MX records for their domain, SPF and DKIM records etc. and anyone can refer to them conveniently. Of course, the published names would resolve to mesh 10.x IP addresses. It seems clear someone could host a DNS server, but I don't know how users would configure their DNS clients.
For example, consider a laptop whose only connection is to a Ubiquiti NanoStation. Could its Microsoft Mail client be configured to send email to smtp.my-city-races.org (which identifies an SMTP server connected to an AREDN node)?
You are here
DNS service for AREDN clients
Fri, 08/20/2021 - 16:56
#1
DNS service for AREDN clients
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Unless I'm missing something - that already exists. Your hypothetical laptop would be getting a DHCP address from the attached AREDN node. Included in the DHCP information is that the local node should operate as the DNS provider for that laptop. The node will be able to resolve any AREDN device or advertised service from OLSR data, and therefore be able to pass along DNS resolution to the laptop when requested. There is no need to run a mail server with a .com address.
For the sake of discussion, let's assume there is a need to handle email addressed to @mydomain.org. Is this practical?
A suitably configured DNS server can resolve MX records for mydomain.org, which will enable MTAs to forward mail to the right server. But how would clients know to query that DNS server, instead of (or in addition to) the server in their node? As far as I know, the DNS server in a node only resolves .local.mesh names, and can't handle MX records at all.
As far as I know,that is correct that the node will only resolve .local.mesh address. Why do you need to resolve some other domain?
As far as MX records, there are mail servers all over the mesh that work fine, so I am going to assume that they are able to get MX records.
Top Level Domains are not supported. No .com, .org, .net, ...
By default names must be alphanumeric or hyphen or underscore.
Likely names beginning with hyphen or underscore are not allowed.
The domain .local.mesh is automatically appended.
So, AREDN will not support mydomain.com, yourdomain.com, or smtp.my-city-races.org .
However, in workstations connected to the local AREDN network may alter their /etc/hosts file as
smtp.my-city-races.org w6jmk-smtp-server w6jmk-smtp-server.local.mesh
I hope this helps,
Chuck
{account name}@{host}.local.mesh
My mail server is connected to the external Internet. If I send an email to an external address, the mail server will forward it out. However, that would be coming from a MESH address (as per the above addressing). So if an external account wanted to respond, it would go nowhere. Mesh addreses are not part of the greater Internet.
What you need is a mail server which can handle external and internal addressing automatically. On a server like that, every account interacting with the outside world would have a primary email address as the Internal and an Alias as the external. The server would need to automatically re-format your return email address for outbound emails and again for inbound emails.
I'm not aware of any such email server. One probably exists, I just haven't heard of it.
Hope that helps at least on the mail server side of things.
I aim for users to have a single email address, which works both inside the mesh and outside in the public Internet. I've made this work for a single email server (w6jmk-postoffice in the SFWEM). But to exchange email between different servers within the mesh, better DNS service is wanted. The problem is also described here.
But I'm not sure this is practical. I've noticed that the node forwards DNS queries to a name server quite frequently. Most of them come from Windows computers attached to the node. The name server responds quickly. Most of the queries are for names in the public Internet, to which the name server responds with Refused. It's a fair amount of traffic, which would be sent over inter-node microwave links in a realistic situation. I fear it would clog up the inter-node links.