I have 10 locations each with a number of IoT devices that talk to a Home Assistant server running its own MQTT broker.
Each location has its own private IP subnets (10.1.0.0/24, 10.2.0.0/24, etc.).
The server is at 10.100.0.1
The IoT devices need to be configured with the IP address of the MQTT broker (10.100.0.1) but it’s a PITA to program each device so I would prefer to use a domain name in place of the IP address.
I own plenty of domains, but Dotser.com will not let me create an A record that points to a private IP address. (Yes, I have a reasonable understanding of why this is frowned upon.)
Aplus.net (where I have some of my domains) will allow this. I am testing now.
I could add the record to each location’s router’s static DNS table, but I am trying to minimize the work (and the work involved when the IP of that server changes).
I thought about having all locations use one of the location’s router as its DNS server, but that introduces delay and failure possibilities.
To be clear, I am trying to be able to configure the IoT devices with a domain name so that I can change the IP address of the MQTT server without have to go back to each IoT device and reconfigure.
No need for public A records if you run your own internal DNS server with a split DNS setup. You can map a domain like mqtt-ha.mydomain.local (or whatever) to 10.100.0.1 and have all your IoT devices point to that DNS server. It’s best practice in setups like this and is simple, reliable and fully under your control.
Just set the name of MQTT broker in all devices to dns name eg. broker.local.mqtt and in all routers (assuming Mikrotik everywhere) set static dns entry forwarding all dns queries to your local dns server
*/ip dns static add forward-to=IP_OF_YOUR_LOCALLY MANAGED_CENTRAL_DNS regexp=".local\.mqtt" ttl=1h type=FWD
and in that central DNS set
/ip dns static add address=10.100.0.1 name=broker.local.mqtt
/ip dns static add address=10.100.0.1 name=broker
use local.mqtt private domain only for MQTT but it is not a necessary condition.
If you wish you can change local.mqtt to anything you want but the name has to be so unique to not clash with any public name.
IoT traffic from these Tasmota devices will still use the wireguard tunnel between all locations.
The server’s address will still be in the 10.35.62.x range (private IP).
The only difference is that the Tasmota devices will be configured with a domain name (e.g., mqtt1.mydomain.com) and the DNS IP lookup for that domain name needs to happen.
it is only the one forever setting to pass any dns query about any host @ local.mqtt domain to your central dns.
Then you manage only the one central dns and set all anyservername.local.mqtt names and it serves all other locations.
You just pick out particular domain from others queries and pass to your own DNS. Any dns you want.
I dont see the savings… In fact call BS on Bartoz and Larsa
(please prove me wrong, so I can eat egg off my face !!)
Right now you can simply NOT touch a single device, lets say there are 100 devices and get the job done.
All you need to do on each router is
/ip route
add dst-address=192.168.0.100 gateway=wireguard table=main
/wg peer to one router
allowed address=192.168.0.100,
and on router holding the server
/nat
add chain=dstnat action=dst-nat in-interface=wg dst-address=192.168.0.100 to-address=10.32.64.X
DONE, NOT one device needs to be individually worked on, no dns work at all.,
What smarter people than me are recommending IMHO is called extra work for no real gain. Bronx Cheer time!!
If the IP address of the home assistant server was changing every week sure, the DNS approach would make sense one would think, but WAIT!
A. Do you really see this happening? Are you actually planning on changing the home assistant server IP that frequently ( I think maybe never is more realistic )!
B And really what is the difference between changing the DNS record at one spot and changing the dstnat rule at one spot, if you do change server IP?
You change server IP to 10.42 vice 10.32
only one rule needs to be changed.
NAT: to-address=10.42…
Please explain how needing to change every device to DNS record is efficient use of ones time. What am I missing here??
when you change the address of mqtt broker then you need to change that rules.
If you stay consistent with dns names then only the central local dns has to be managed for any dns name you decide to use in local.mqtt domain.
You want two brokers … here you are broker1.local.mqtt + broker2.local.mqtt … want special GW … gw.local.mqtt … another broker … broker3.local.mqtt … and the only place you manage real IPs is central DNS.
One central DNS is the one you have enabled in your mikrotik (or any other dns/device that serves that function) that is not public.
Local means “local” … at your home/main office it is probably the same as “central” … at remote places it is the one that serves DHCP clients.
If you set 8.8.8.8, 1.1.1.1, 9.9.9.9 (or any other public one) then you are out of luck as you have to set DHCP server to point to local DNS server in that router to be able to manage your own domains that means local.mqtt.
I don’t want to use the local DNS server with a static entry because then I will need to make (and maintain) that entry for all Mikrotik devices (one at each location).
My idea is indeed to use the public, authoritative DNS server for the domain so that anyone, anywhere (with Internet access) will resolve:
I just set it up with my registrar (aplus.net) and it works.
Of course, there is only connectivity to mqtt1.mydomain.com (that is, 10.35.62.100) from one of my wireguard-conected routers, but it does resolve to that IP address.
This way, no local ROS entries are needed, no changes to the local ROS DNS entries are needed and no changes of ROS firewall rules are needed when the server’s IP address changes. The only change needed to be made when the server’s IP address changes is at the authoritative DNS host.
Please read advices that are presented to you twice. At least.
A. Find a DNS hosting that allows you to define “A” record as you wish with 10.100.0.1 address. Job done. No need to ask us for any help. Case closed.
B. You have to set up and manage the only one private “local” at your main office/place/home DNS server,managed only by you, that is “central” for other your sites. That sites have to be >>persuaded<< (configured) to pass queries for local.mqtt domain to your private central DNS server that resolves names like “anyname.local.mqtt” not involving any public DNS. It means that you have control/configure all “local” DNSes. Just once. With such a configuration all DNS names stay resolved as they are resolved now and only queries for *.local.mqtt are sent to your “central” DNS server.
C. if you locally (at every your site you manage) set DNSes to external ones - eg. 1.1.1.1 or 8.8.8.8 - then you have go back to (A). If you want control what & where is resolved then you need advanced solution and manage your own DNS or the one smart enough to do what you want. It could be hosted enywhere but if it is outside your private managed network you have to deal with it’s restrictions.
Hope that you undersand this.
PS.
It’s just as setting the rule for an administration staff:
Read the destination address. If it is an address of any of our offices (private) then send the documents using internal post service. If you have no idea what “Mr. Joe Doe @ new office” means then ask someone at the central office to resolve the destination (DNS query) and then send it properly.
Concur, in fact its actually more work to create DNS servers at each location and then modify each IOT device to look for a specific URL.
Once done, any change to IP address of the home assistant server would require changes to every local DNS server to match, vice the single dstnat rule on the server hosting the server.
Setting up additional DNS servers, and any firewall rules, etc, is an admin burden completely unnecessary, not needed and it saves NO work down the line ( and is actually more work ). Its a great approach/tool to have for the right scenario, this is simply not it.
Directing traffic for the faux address, already embedded in the IOT device, into the wireguard tunnel and pointing the router to select the peer hosting the server for the traffic, is simple, and efficient. At the host server router a one DSTNAT rule to redirect dst faux address to actual Server IP, is tidy and efficient. Any change to the IP needs a single mod to the dstnat rule, and done.
Assuming that each router already serves DNS function for LAN at every site then you have to add just one line to them. If only they are Mikrotiks.
The OP already decided to set all IoT devices to use DNS names so it’s not a problem.
Just asking: what if the IP of MQTT broker will change? You need reconfigure each NAT rule instead of change one DNS entry @ central localization.
What if you want split devices into two groups to use two brokers? What if you decide that broker should be moved from central location to another branch? NAT behind NAT to reach it from outside main localization?
DNS was invented just for such situations IMHO.
PS.
We do not discuss the inter office reachabiilty of devices what is another story.
@Josephny, please listen to BartoszP’s advice — they’re legit. My recommendation: don’t use an external DNS server for your local needs and private addresses (for a bunch of different reasons)
You list A, B, and C, but you don’t explain what this is a list of?
Are these alternatives? Are they components of a single solution?
Let’s assume they are alternatives.
I like the idea of A (use the authoritative DNS resolver to resolve mqtt1.mydomain.com to the server’s IP) and be done with it. Is there a problem with this approach? Seems to me to require the least amount of work, with the fewest moving pieces for later work in case something changes.
Yes, the chances of the MQTT broker server’s IP changing is real. It might be moved to another location, for example.
