Split DNS on UDM Pro
Less than a month ago I wrote about how to split your DNS forwards depending on the domain. Like sending any queries for example.com to 192.168.1.2 allowing you to have an internal resolution for some domain names. A common scenario is for a company with externally published services on its domain. While the user outside will hit a Firewall, WAF, or load balancer as they navigate to the URL users on the inside might not be able to take the same route. There might be issues with firewalls dropping traffic coming from the inside with their public IP as the destination or it’s just not as efficient as routing the traffic internally to the server.
In my last post, I showed how to do this via the config.gateway.json file that applies to USG setups with controllers, either Cloud Keys or self-hosted. Now we will take a look at the Dream Machine which has no support for the config.gateway.json setup but brings a lot of other interesting things to the table.
UDM Pro – Dream Machine Pro
In short, the Dream Machine is a Security Gateway, NVR for cameras, Cloud Key, and much more in one appliance! Without going into the specs too much there are several key things that make this a step up for deployments with faster Internet connections as well as several VLANs with firewall rules between them. For starters brings a lot more brute force, even with intrusion detection and/or prevention enabled it can sustain a 3.5 Gbps throughput. It also has 10 Gbs SFP+ uplinks both for WAN and the core switch!
The limitation that forces you to scrap any config.gateway.json is that the Dream Machine isn’t running EdgeOS so all configuration has to be done in the Network application itself, or does it?
Dream Machine Pro Mods
As stated above the Dream Machine Pro is powerful, you can even run Docker containers on it and use it as an all-in-one appliance. However possible I wouldn’t recommend it since it will take up resources and might cause stability issues over time. But there are a few useful mods that you can and might need to make to bend it into your overall setup. There are other things like mods for supporting Cloudflare DDNS that runs in a container that doesn’t need to be on your firewall. Why do we use DDNS in the first place? To expose internal services like a NAS or Docker/Kubernetes cluster, if that is down the DDNS doesn’t really matter anyway so why not run it on the NAS or internal cluster instead!
So why do I need DNS split or conditional DNS forwarding on my Dream Machine Pro? I already have the internal DNS server for the DNS split so why not just push that via DHCP to all my clients? The answer is simple, I want to segment my setup. My DNS server is running on my home lab clusters and they sometimes get rebooted or taken down for a short time while I test stuff. That will prevent me from accessing the Internet since the DNS server is down. So I want one “segment” in my environment that is a production network that should always work independently of everything else. Since the DNS server on the cluster only handles the split DNS to access the services on the cluster it’s reasonable for it to go up and down with the cluster.
Boostchicken-dev hosts a Github repository called udm-utilities that are full of mods for the UDM and UDM Pro. Currently, this project has over 40 contributors and it’s regularly maintained. But we only need one of their basic mods for this to work.
Setting up split DNS / conditional DNS forwarding
Like all other devices, the UDM Pro will start from scratch when rebooted and then get provisioned by the controller, even though the controller is running on the same device. They are logically separated but that’s a whole other discussion. So if we change anything it will be lost at the next restart. With the config.gateway.json approach, our changes are applied in the provisioning stage after reboot and are that way persistent. We are going to add the change so it re-applies after each reboot.
Start by adding on-boot-script from udm-utilities, this requires you to enable SSH and set an SSH password on the device. Proceed with caution since you can brick both your warranty and your device. Once that is installed all scripts in /mnt/data/on_boot.d will be executed on boot.
We can use this to add a script that reconfigures DNSMasq to have the conditional forward as we want. Create a script in the on boot folder like vi /mnt/data/on_boot.d/script_dns.sh then add the following to the file:
#!/bin/sh cat > /run/dnsmasq.conf.d/script_dns.conf <<- "EOF" server=/example.com/192.168.1.2 EOF # Restart dnsmasq so it sees the new conf file kill -9 `cat /run/dnsmasq.pid`
Then hit ESC and write :wq for write and quit. Not really a vim fan myself, more of a nano guy. Then make the script executable chmod +x dns.sh then you can test it out with ./mnt/data/on_boot.d/script_dns.sh
Check that your config was written with cat /run/dnsmasq.conf.d/script_dns.conf if all looks good run a nslookup against your UDM from another machine and check that the responses are as expected. If all is good, test a reboot and verify that everything is working automatically.