It may or may not be applicable for what you are trying to do.
My question is why do you need split DNS for the IOT subnet? Do you have different IOT devices on the same subnet?
Are there are other ways to target those specific IOT devices…
My post was not at all limited to any particular project or endeavor of mine.
As you know, I’m always exploring and learning (or trying to), and split-dns is just something that piqued my interest.
As I perhaps too subtly stated, I’m not sure how or if split-dns is useful or applicable to me.
I just found it cool.
In a very general sense, it’s just a little nicer be able to use hostnames, particularly if hostnames follow an easy to remember format such as: XXXrouter.internal
Nonetheless, your specific aquestions about different IoT devices on the same subnet, and about targeting them, is interesting.
I assumed as always, that you are short of time and thus want to getter done. If you have time to read novels, that is a different story '=)
Wait till you hit the chapters on VRRP VXLAN and BGP.
By the way, Home Assistant devices typically obtain IP addresses from the Home Assistant server through the network’s DHCP server, which is usually the router, rather than directly from the Home Assistant server itself.
This sounds much like the UNIFI approach where one can use a. create dhcp option and then in DHCP for the LAN add name of option.
b. Domain Name attached to DNS server for the LAN, plus static DNS setting.
Maybe, home assistant appears to be a dogs breakfast with differing information wherever you look. One place says the server scans the network for devices…
To be clear, Home Assistant is not a DHCP server, so nothing can “obtain [an] IP address from the Home Assistant Server.”
I’m sorry for the confusion this is causing.
The IoT device has an IP address. It obtains it in the usual way: Either through static assignment or DHCP. The method that it uses (static or dhcp) is a configuration option in the device.
The data that the IoT device gathers, collects, relays, etc. that makes it an Internet of Things devices (for example: The light switch is on, or “turn the light switch on,” or “the temperature in the room is 70*F”) can be exchanged by a number of different methods or protocols. One such method is MQTT. If using MQTT, then the device needs to know some things about the MQTT broker (similar to a server), including it’s IP address and port number. This IP address (of the MQTT broker) is completely unrelated to the device’s IP address.
For example, the device might have a local, private address of 192.168.0.100 and the MQTT broker (a “server” also sitting on the LAN) might have an IP address of 192.168.0.200. The IoT device (at 192.168.0.100) will send it’s useful data to the MQTT broker located at 192.168.0.200.
You miss the point entirely,
The two options presented DHCP and DNS are to inform the iot device, what is the IP address of the HA server, not to change the local subnet IP the iot device is using.
I stated it above, DHCP OPTION creation and the use of the name of the OPTION in DHCP server settings for the subnet the IOT devices are in.
OR
Create a domain name for the SERver and use in in the DHCP Server settings in the subnet for the IOT devices and then use IP DNS Static settings to point the domain name to an IP address.
Well HA does not use DHCP Option codes, must have coders from the dark ages.
In any case you could try something like this simple DNS pointing.
IOT Subnet on R2 - 192.168.55.0/24 IP of server on R1 - 10.10.10.15
ON R2 /ip dhcp-server network
add address=192.168.55.0/24 dns-server=192.168.55.1 domain=joseph.home gateway=192.168.55.1
/ip dns static
add address=10.10.10.15 name=HAserver.joseph.home type=A
Since you already have the rest of the pieces in place on R2 add dst-address=10.10.10.0/24 gateway=wireguard1 table=main
and add chain=forward action=accept in-interface-list=MyDevices ( or iot subnet ) dst-address-list=MyServers out-interface=wireguard1
and add chain=srcnat action=masquerade out-interface=wireguard1
It should work as on R1 we effectively have add chain=forward action=accept in-interface=wireguard out-interface-list=LAN
DHCP servers have an ability to attach some information in the return packet when they answer to the request.
That additional information, called “Options”, is rarely used explicity by SOHO but it could simplify your admin life.
Some of them are exposed in Winbox the way you think it is a standard set of information but some of them are hidden in special DHCP Options menu. Have you ever had to set NTP servers to get your network work? The typical minimum set of settings is:
IP address
Subnet mask
Default gateway IP address
DNS server IP address
Lease time (during which a client can use the IP address allocated/leased by a DHCP server)
R2 is a remote location (from R1) where there are Tasmota IoT devices, right?
I don’t know what “domain=joseph.home” does.
It’s all just fine, however, because we can either use split-DNS or a domain name in the IoT device’s MQTT broker config field and we know those frames will be allowed entry into the wireguard tunnel because they originate from the IoT network.
I didn’t mean to make this thread all about my own nitty-gritty networking challenges.
But please answer my questions here →