DNS question:

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.

Any ideas? Thanks!

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.

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.

That sounds great, but I only understand about 65% of that (passing?).

What is a split dns setup?

How do I have 1 place where I map mqtt-ha.mydomain.local to the IP and have 10 different routers know about it?

So are you stating that you wish all the traffic from the locations will go out the WWW to reach the home assistant server at location Y?

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.

So are you stating that you wish all the traffic from the locations will go out the WWW to reach the home assistant server at location Y?

No, not at all.

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.

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 you local dns server

/ip dns static add forward-to=IP_OF_YOUR_LOCALLY MANAGED_DNS_IN_MIKROTIK regexp=".*local\\.mqtt" ttl=1h type=FWD

and in local 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

I was hoping for a solution that did not involve maintaining a statis DNS entry in each router.

Is there a problem creating a A record for the domain at the DNS host for the domain?

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!! ;-P
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??

@BartoszP
I needed something like this too and your solution is perfect, thanks

@anav: I see no savings at all

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.

You do not need to waste Easter eggs

@Josephny

Is there a problem creating a A record for the domain at the DNS host for the domain?

Not at all. I used that in production for a corporate network.

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'm following except for this:

The "one central dns" is the Authoritative name server, right?

I'm not clear where the "local" comes into play.

OMG ...Josephny please focus

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.

OMG ...Josephny please focus

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.

OMG....BartoszP please listen to my thinking (;-)

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:

mqtt1.mydomain.com to 10.35.62.100

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.

What am I missing?

Huston .... there is a problem.

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.

@anav: I see no savings at all

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.

One can lead a horse to water............

Anav:

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)

Huston .... there is a problem.

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.

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.

@anav: I see no savings at all

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.

One can lead a horse to water............

What exaclty do you concur with?

Are you saying that it is more work to manage DNS servers at each location? That is my understanding of this.

So, why is everyone yelling at me if you are all agreeing with me?

@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)

What is that advice I should listen to?

Why not use the authoritative DNS server?

Josephny ... to be honest ... please do not waste our time. My time at least.

(A) (B) (C) are the three possible solutions or steps you have take.

You do not understand or you do not want understand your own needs.
How to describe it better. You manage your own DNS server or use existing one.

What game do you play with us?

Josephny ... to be honest ... please do not waste our time. My time at least.

(A) (B) (C) are the three possible solutions or steps you have take.

You do not understand or you do not want understand your own needs?
How to describe it better. You manage your own DNS server or use existing one.

What game you play with us?

I'm not playing any game.

I apologize that I gave you that impression.

Just try to understand that: viewtopic.php?p=1136393#p1136393

Hi Bartosz, Trying to understand your advice and with Larsa endorsement, of course!

I too like Joseph, being not IT professional need some conceptual guidance.

What I think your saying, in techno speak, is in static DNS we attach or identify an IP address with an URL or domain name that we have given to each IOT deviceas its entry argument to reach thehome assisstant server on a remote router.
So I find it confusing as to why an IOT device on a router should be given an IP of a local DNS server instead of the IP address of the home assistant server on the host router???

/ip dns static add forward-to=IP_OF_YOUR_LOCALLY MANAGED_CENTRAL_DNS regexp=".*local\\.mqtt" ttl=1h type=FWD

Following the bouncing ball, of the above script, the iot device is somehow directed to a local DNS server and then what??? I dont see how this traffic then goes into the wireguard tunnel, exits the remote router and finds its way to the home assistant server on the remote host router.

I am lost trying to follow your solution on this router or any other of the remote routers with iot devices that need to access the home assistant server on the host router.

DNS question:
...
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.

Any ideas? Thanks!

Anav:

The question is about DNS configuration, not how to configure and pass the traffic from branches to main place using VPNs.

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.

Thank you for your understanding and your help.

I believe that I understand your suggestion.

Every router will have an entry in its "/ip dns static" table that will forward all requests for the IP of mqtt.local to another DNS server that I manage.

Just so I'm absolutely clear, as an example: A device at location 1 (that has an IP network of 192.168.0.0/24) needs the IP address of mqtt.local

That device asks its DNS server (192.168.0.1) and that DNS server tells the device to go and ask the DNS server at a completely different location (for example, 192.168.2.1).

That way, any changes to the IP address of mqtt.local need only be made on the DNS server at 192.168.2.1.

Is my understanding correct?

Other than that, for private DNS I recommend using _____.mqtt.internal instead of _____.local.mqtt
(or intranet, or private, or corp, or home, or lan)
https://www.rfc-editor.org/rfc/rfc6762#appendix-G

That device asks its DNS server (192.168.0.1) and that DNS server tells the device to go and ask the DNS server at a completely different location (for example, 192.168.2.1).

The DNS server (192.168.0.1) doesn't tell the device to go ask the other server. The DNS server performs the lookup itself, but by asking the other server (192.168.2.1, instead of the usual upstream servers), then the server relays the answer to the client devices. From the viewpoint of the client devices, they have only asked one server (192.168.0.1) in one query and get the answer from one server only (192.168.0.1).

But for you as the admin, the final outcome will still be the desired one below:

That way, any changes to the IP address of mqtt.local need only be made on the DNS server at 192.168.2.1.

That device asks its DNS server (192.168.0.1) and that DNS server tells the device to go and ask the DNS server at a completely different location (for example, 192.168.2.1).

The DNS server (192.168.0.1) doesn't tell the device to go ask the other server. The DNS server performs the lookup itself, but by asking the other server (192.168.2.1, instead of the usual upstream servers), then the server relays the answer to the client devices. From the viewpoint of the client devices, they have only asked one server (192.168.0.1) in one query and get the answer from one server only (192.168.0.1).

But for you as the admin, the final outcome will still be the desired one below:

That way, any changes to the IP address of mqtt.local need only be made on the DNS server at 192.168.2.1.

Perfect -- thank you for the clarification.

Hi Bartosz, Trying to understand your advice and with Larsa endorsement, of course!

I too like Joseph, being not IT professional need some conceptual guidance.

What I think your saying, in techno speak, is in static DNS we attach or identify an IP address with an URL or domain name that we have given to each IOT deviceas its entry argument to reach thehome assisstant server on a remote router.
So I find it confusing as to why an IOT device on a router should be given an IP of a local DNS server instead of the IP address of the home assistant server on the host router???

/ip dns static add forward-to=IP_OF_YOUR_LOCALLY MANAGED_CENTRAL_DNS regexp=".*local\\.mqtt" ttl=1h type=FWD

Following the bouncing ball, of the above script, the iot device is somehow directed to a local DNS server and then what??? I dont see how this traffic then goes into the wireguard tunnel, exits the remote router and finds its way to the home assistant server on the remote host router.

I am lost trying to follow your solution on this router or any other of the remote routers with iot devices that need to access the home assistant server on the host router.

I can try to explain (and hopefully make things clearer, and not more confusing).

The IoT devices (in my case, Tasmota devices) get their IP address, gateway, DNS server, etc. via DHCP from the local router.

These devices have certain configuration settings that have to do with their functionality as IoT devices -- specifically, relaying information and commands between itself and a 'server.' MQTT is one such method for communicating this data. As such, the devices need to know what the MQTT server's (or broker's, in MQTT-speak) IP address is. That is one of many configuration items programmed into the Tasmota device.

The MQTT broker can be identified by IP address or domain name. If by domain name, then the IoT device will look to the DNS server it was told to use at the time of getting an IP address to get from that DNS server the IP address of the the MQTT broker (just like any device that uses a domain name would do).

Once it gets the IP address, it sends out frames using that IP address and the router then handles the frames from there.

So, we are not at all discussing anything other than the best way for the IoT device to be configured with the address (be it IP address or domain name) of the MQTT broker.

Does that help?

Just thought I'd chime in to add to the confusion. Generally, private (RFC1918, etc.) addresses are permitted in public DNS records, in fact this is not uncommon. The rise in popularity of this is in fact rising because it's not exactly easy to do split DNS nowadays with hard-coded DNS servers on devices, default DoH use, the requirement to support not-managed-by-the-given-company devices, etc. Discussions on whether this is good practice leads to long mailing list chains - there was a notable one on the NANOG list a while ago that is actually worth a read.

Another possible solution is to use your public server IP in the DNS record and simply configure your router to nat these connections to your local (preferred) instance.

Just thought I'd chime in to add to the confusion. Generally, private (RFC1918, etc.) addresses are permitted in public DNS records, in fact this is not uncommon. The rise in popularity of this is in fact rising because it's not exactly easy to do split DNS nowadays with hard-coded DNS servers on devices, default DoH use, the requirement to support not-managed-by-the-given-company devices, etc. Discussions on whether this is good practice leads to long mailing list chains - there was a notable one on the NANOG list a while ago that is actually worth a read.

Another possible solution is to use your public server IP in the DNS record and simply configure your router to nat these connections to your local (preferred) instance.

Thank you -- that adds important depth to the topic we are discussing.

One reason I like both(1) adding a private IP address to the public DNS records AND (2) Bartosz' split-dns solution is because this way I can keep the Home Assistant server completely inaccessible from outside the wireguard tunnel. I would not be surprised at all if there are ways to ensure the same level of security using the NAT solution you describe, but I personally find it important to configure things in a way that I have at least a reasonable understanding and mastery of, and I'm finally understanding the security value to wireguard (and VLANs, but that's another topic entirely).

What you have in your DNS records and whether you do or don't do nat has no bearing on your firewall and access control capabilities.

What you have in your DNS records and whether you do or don't do nat has no bearing on your firewall and access control capabilities.

Maybe I'm misunderstanding, but I assumed that by NAT you meant opening a port that forwards frames arriving on the public IP address port of the router (the WAN port) to the Home Assistant/MQTT server.

yup, I understand that you have 100 devices, that you dont need to touch, they are already set for 192.168.0.x
There is no need to touch DNS or add DNS servers or make any DNS rules to ANY of the nine routers to get their traffic to the host router for the home assistant server.
The home assistant server if you change IP can be managed by simply changing a single IP on a single router ( in the dstnat rule )
To me DNS is a bad distraction although a good learning exercise.......
So would getting a starlink connection for each router and connecting all to a CHR and having lots of merry fun...................... great for learning but a complete waste of precious time you state you are short of.............

Now, you did mention you plan on changing the location of the Home assistant server, which would have been useful to know as that is a different requirement that needs to be communicated prior to setting up a config. In that case, one has to weigh the changes required using the NON DNS method provided. Even there one simply changes/moves the DSTNAT RULE to the new router and DONE. Anything else you need to do for firewall rules and ip routes/allowed addresses will apply to both methods....... as the DNS method simply provides a new Destination IP address for the device. GUESS WHAT THEY ALREADY HAVE IP ADDRESSES TO LOOK FOR.

I am still wholly unconvinced any DNS shenanigans are required. In fact, I feel like Im the only sane person left on this planet
I was sure rextended was made of only practical bones, must be using his funnybone today ..................

The question is about DNS configuration, not how to configure and pass the traffic from branches to main place using VPNs.

You miss the point, the OP does not intend on reaching the home assistant server over the WWW, he wants all traffic to go over wireguard tunnels between the routers.

The question is about DNS configuration, not how to configure and pass the traffic from branches to main place using VPNs.

You miss the point, the OP does not intend on reaching the home assistant server over the WWW, he wants all traffic to go over wireguard tunnels between the routers.

Traffic will stay on the WG tunnel. That is not in doubt.

The question of using a DNS or a routing/firewall solution comes down to (1) how much work it is initially configure and (2) how much work it will be in the case of a change to the ip addresses of the Home Assistant server and (3) how complex or simple the solution it.

I see the DNS solution, especially using an A record on the authoritative/public DNS server as the simplest solution and the easiest to implement and the easiest/quickest in case of an IP change.

It seems to me that the routing/firewall solution requires entries on all routers initially, and is a workaround to actually changing the MQTT server's address on each IoT device that will haunt me in the future when I look at the router's configs, or want to set up a new site, and can't figure out why it's not working or why I mapped 192.168.0.103 to 10.35.62.100.

You have mentioned to me many times that there is enormous value at being able to look at a config and understand not just what it is doing but why.

What you have in your DNS records and whether you do or don't do nat has no bearing on your firewall and access control capabilities.

Maybe I'm misunderstanding, but I assumed that by NAT you meant opening a port that forwards frames arriving on the public IP address port of the router (the WAN port) to the Home Assistant/MQTT server.

No, I didn't mean that. I meant that the endpoint devices connect to an IP as their server, wither statically configured or obtained using DNS. Then a router (on your preferred side of the tunnel) redirects these to whatever server is actually intended to handle their connections.

That is the point I am making, the work required for firewall rules and routing and allowed IPs needs to be done reqardless of which method is used to get information from the iot device to the home assistant server. What I am saying is that you need to really do a comparison

SETUP from where you are now!

a. visit every iot device
b. set up dns server on every router
c. setup dns settings on every router

VICE
one dstnat rule on one router.

CHANGE IP ADDRESS

Visit every router to change DNS Setting

VICE
modify IP address on one rule on one router.

CHANGE Assistant Server to new router

go to every DNS router to change IP address

VICE
move one dstnat rule to the new router.

Okay, I think we are making progress.

First, let's leave out the variable of going to each IoT device. This is something that I will need to do regardless of which solution is implemeneted.

The question is whether to add a domain name or an ip address in the MQTT configuration of the IoT device.

Option A -- Public DNS Entry:

1) Add mqtt1.mydomain.com in the IoT device's config.
2) Add the DNS entry in the authoritative DNS server.
3) Create a route at every router directing IoT devices to reach mqtt1.mydomain.com via the wireguard tunnel.



Option B -- Split-DNS:

1) Add to each local router:

/ip dns static add forward-to=IP_OF_YOUR_LOCALLY MANAGED_CENTRAL_DNS regexp=".*local\\.mqtt" ttl=1h type=FWD

When changes are made to the IP of the server, no work is required at the local router.


2) Add to one router (the router where the Home Assistant server is):

/ip dns static add address=<IP-of-Server> name=broker.local.mqtt
/ip dns static add address=<IP-of-Server> name=broker

When changes are made to the IP of the server, these items need to be modified.


3) Add firewall rule at each local router allowing traffic from IoT devices to broker.local.mqtt



Option C -- Entirely Routing and Firewall:

1) At each router, add:

/ip route add dst-address=192.168.0.103 gateway=wireguard table=main

/wg peer to one router allowed address=192.168.0.103


2) At the router where the server is add:

/nat add chain=dstnat action=dst-nat in-interface=wg dst-address=192.168.0.103 to-address=10.32.64.100


Still seems to be that the most elegant, simplest, and clearest to understand in the future solution is option A, but I see that options B and C have some advantages also.

WRONG you do not get to set a false narrative. BE HONEST.
First, let's leave out the variable of going to each IoT device. This is something that I will need to do regardless of which solution is implemented.

Bullpucky, there is nothing you have to do at each device if they are all currently pointing at a the same faux address. You have all you need!!
If you need to visit each device for some other reason, okay, but its not clear you have yet.

To be frank, even if you had to set the IOT devices, they were not already setup, I would still recommend a faux IP, vice the actual IP of the server for sure, but even over the DNS method.
For the simple reason I have outlined, later to change the iot device traffic to a new IP, only requires a change on the dstnat rule and none on the iot devices. Less work in my book.
Perhaps others see a fault in my logic, as I dont mind being wrong.

...For the simple reason I have outlined, later to change the iot device traffic to a new IP, only requires a change on the dstnat rule and none on the iot devices. Less work in my book.
Perhaps others see a fault in my logic, as I dont mind being wrong.

Wrong

Let services do what they are designed to do.
Do not mask static configuration with dst-nat rule. It's a fast convinient solution just for now but is it the future-proof solution?

Assuming that all IoT devices are configured to use DNS names - no matter what DNS server serves that name - then if Josephny manage to configure OSPF or OSPF+BGP for routing among offices/branches, the only setting to change is the DNS value.

I do not know if the trafic goes now only from branches to main office or (sooner or later) there would be a need for office->branch trafic. What then?
What if Josephny decide to set additional inter-branch connections to have HA? What about setting just dst-nat redirections? What about central NAS placed at main place?

RIGHT, you proved me right again thank Bartosz........
A config is based on a set of established requirements, not vapour future wishes.

If the op wants efficiency, the shortest path to get his 10 routers up and running as they are now, DNS is stewpid.
If the op wants to tinker with DNS, which is more viable now after disclosing he can bulk change the setting on devices, then by all means
go ahead and do the DNS option. It as you say has some future proofing built in, aligns the desired functionality with a tool so designed, and provides further learning experience.

I'm not convinced the OP will be attempting BGP or more complex functionality anytime soon as he is still working on VLAN filtering but one never knows.

Not familiar with home assistant, but similar to UNIFI approach........
Q1 -> can via a DHCP option, we give the IOT devices on the IOT subnet, the IP address of the home assistant server
Q2.--> can we via DHCP for the IOT subnet provide the domain name of the DNS server (domain=bartosz.home) and then in IP static
add-address=serverIP name=HA.bartosz.home type=A

Not familiar with this mqtt or broker concept.

RIGHT, you proved me right again thank Bartosz........
A config is based on a set of established requirements, not vapour future wishes.

If the op wants efficiency, the shortest path to get his 10 routers up and running as they are now, DNS is stewpid.
If the op wants to tinker with DNS, which is more viable now after disclosing he can bulk change the setting on devices, then by all means
go ahead and do the DNS option. It as you say has some future proofing built in, aligns the desired functionality with a tool so designed, and provides further learning experience.

I'm not convinced the OP will be attempting BGP or more complex functionality anytime soon as he is still working on VLAN filtering but one never knows.

Not familiar with home assistant, but similar to UNIFI approach........
Q1 -> can via a DHCP option, we give the IOT devices on the IOT subnet, the IP address of the home assistant server
Q2.--> can we via DHCP for the IOT subnet provide the domain name of the DNS server (domain=bartosz.home) and then in IP static
add-address=serverIP name=HA.bartosz.home type=A

Not familiar with this mqtt or broker concept.

OP here: I do indeed tinker (way too much).

I don't understand either Q1 or Q2.

MQTT is completely, 100% separate from the IP address that is assigned (statically or dynamically) to the IoT device. MQTT is a protocol used by the IoT device to communicate with the another device (a broker/server) so that data collected by the IoT device, or data needed by the IoT device is exchanged. The device needs to know how to reach the broker/server, and this is where the IP address versus domain name question comes into play.

A (very rough) analogy can be made to the DNS settings in ROS. We configure an MT device so that it knows who to ask for IP addresses when all we give it (and therefore all it knows) is a hostname. So we configure ROS to ask 1.1.1.1 whenever it needs to translate www.google.com to an IP address. In this way, 1.1.1.1 is just a config setting in ROS and is in no way the IP address of any local device (MT or otherwise).