Should I use a dedicated DHCP/DNS server hardware
Should I use a dedicated DHCP/DNS server hardware
My current setup has my DHCP + DNS on my Unifi USG. However, as I have all my apps hosted on a different server (unifi, plex, home assistant, NAS, etc.) I've ran into issues trying to get things set up.
Basically, Unifi needs to know where the unifi server is, but it's assigning the IP address to it.
Should I put DHCP+DNS onto it's own system? Should I put it on my current server? And any non-Pi recommendations for systems? (I've had the PI filesystem clobber itself too many times)
Edit: I'm starting to think that the real problem is having UNIFI on the same system as the server, as it prevents me reconfiguring any of the server routing information without also disconnecting unifi...
Edit 2: I'm going to try switching the server from a static DHCP lease to a static IP. If that's doesn't work, then I think I'll move the unifi server onto it's own system. Thanks!
Generally speaking, any device ("server") hosting a "service" NEEDS to be assigned a static IP. It simplifies routing significantly and avoids random break problems because DHCP is incredibly stupid at times....
Is there any specific reason you need DHCP to assign an IP to your main hosting server vs setting it all statically?
Moving it to it's own system will not fix the routing problem. You can probably still leave it on the USG.
You should be able to set a fixed static IP on your server, and then also statically assign that same IP to your server in your USG DHCP config- as long as they both are "thinking about" the same IP I think routing should work correctly.
If that breaks, try just assigning the static IP only from the USG side or only from the server's side. I'm 90% sure that even if the USG does not have your server machine in it's client list, if it sends broadcast packets to an entered IP looking for the unifi server, and the unifi server is listening on that manually set IP, they should be able to talk.
disclaimer: i am high as shit right now and this may be bullshit
Is there any specific reason you need DHCP to assign an IP to your main hosting server vs setting it all statically?
I've done this. I think the real problem is if I ever change the server MAC or IP, as now the unifi server isn't picked up by the USG, which means I can't change the static address.
Either use a static IP on the server or setup DHCP to always reserve & assign a specific IP for the server's MAC address.
I'm not familiar with USG but any decent appliance with DHCP+DNS functionality should be able to do this.
Sidnenote about the PI filesystem self-clobbering: Are you running off of an SD card? Running off an external SSD is way more reliable in my experience. Even a decent USB stick tends to be better than micro-SD in the long run, but even the cheapest external SSD blows both of them out of the water. Since I switched my PIs over to that, they've never had any disk-related issues.
You can use log2ram to mitigate that.
Alternatively, you can even boot a root filesystem residing on an NFS share, but in the case of a rpi hosting the network's DNS and DHCP services, you could end up with a chicken and egg problem.
I've completely bricked two SD cards using a Pi. The USB option sounds interesting, I'll have to try it.
Grab this cable: https://www.amazon.com/gp/product/B00XLAZODE/ (make sure it's the USB 3.1 version, not the USB 3.0) then plug in any SATA device. you should be able to find a 512GB SATA SSD for less than $40.
Basically, Unifi needs to know where the unifi server is, but it’s assigning the IP address to it.
Set a static IP on the Unifi server.
Already done, but I ran into issues when I needed to change the IP or MAC.
I use pihole for managing DNS and DHCP. It's run via docker and the compose file and dnsmasq configs are version controlled so if the Pi dies I can just bring it up on another Pi.
The Pi with pihole has a static IP to avoid some of the issues you described.
That's what I do. I do have a small VM that is linked to it in a keepalived cluster with a synchronized configuration that can takeover in case the rpi croaks or in case of a reboot, so that my network doesn't completely die when the rpi is temporarily offline. A lot of services depend on proper DNS resolution being available.
I've been meaning to standup another pihole on another pi for DNS redundancy. I have to research how to best keep the piholes in sync. So far I've found orbital-sync and gravity-sync.
Unifi is specific about expecting the controller address to not change. You have several options: There's the “override controller address” setting, which you can use to point the devices at a dns name, instead of an ip address. The dns can then track your controller. It doesn’t exactly solve your issue, though, as USG doesn’t assign dns names to dynamic allocations.
Another option is to give the controller a static IP allocation. This way, in case you reboot everything, USG will come up with the latest good config, then will (eventually) allocate the IP for controller, and adopt itself.
Finally, the most bulletproof option is to just have a static IP address on the controller. It's a special case, so it's reasonable to do so. Just like you can only send NetFlow to a specific address and have to keep your collector in one place, basically.
I'd advise against moving dhcp and dns off unifi unless you have a better reason to do so, because then you lose a good chunk of what unifi provides in terms of the network management. USG is surprisingly robust in that regard (unlike UDMs), and can even run a nextdns forwarding resolver locally.
So this is where I'm a little confused. The USG had the option to assign a static IP (which I've done), but if you ever need to CHANGE that IP... Chaos. From what I understand the USG needs to propagate that IP to all your devices, but it uses the controller to do that. Then you also run into issues with IP leases having to time out. Same problem occurs if I ever upgrade my server and change out the MAC address. Because now the IP is assigned to the old MAC.
I'm not sure if there's any way around this. But it basically locks me in to keeping the controller (and thus my server) at a single, fixed IP, without any chance of changing it.
Here's how it works: unifi devices need to communicate with the controller over tcp/8080 to maintain their provisioned state. By default, the controller adopts the device with
http://controller-ip:8080/inform, which means that if you ever change the controller IP, you’ll must adopt your devices again.There are several other ways to adopt the device, most notably using the DHCP option 43 and using DNS. Of those, setting up DNS is generally easier. You'd provision the DNS to point at your controller and then update the inform address on all your devices (including the USG).
Now, there's still a problem of keeping your controller IP and DNS address in sync. Unifi, generally, doesn’t do DNS names for its DHCP leases, and devices can’t use mDNS, so you’ll have to figure a solution for that. Or, you can just cut it short and make sure the controller has a static IP―not a static DHCP lease, but literally, a static address. It allows your controller to function autonomously from USG, as long as your devices don’t reach to it across VLANs.
DHCP is a really stupid* service for the most part. Unless you are working with multiple subnets or have some very specific settings you need to pass to your clients, it's probably not worth it to manage it yourself. I don't want to discourage you though! Assigning static IP addresses by MAC can be extremely useful and is not always an option on routers. If you want static names and dynamic addresses, that is really where you need to manage both DNS and DHCP. It really depends on how and where you want names to be resolved and what you are trying to accomplish. (*stupid as in, it's a really simple service. You want it simple because when DHCP breaks, you have other serious issues going on.)
Setting up your own DNS is worth its weight in gold. You can put it just about anywhere on your network (before your gateway, after, in China, whatever.) and your network won't even know the difference if setup correctly. You can point BIND at the root servers and bypass your ISP completely if you want. ISP DNS services suck ass, so regardless of you resolve yourself, or forward all name queries to your anon DNS server of choice you have a really decent level of control on your network. It is the service to learn if you want to keep an eye on where your network wants to talk.
Your Unifi USG must play nice with your own server, by the laws of DNS. There may be some nuances when it comes to internal protocols like WINS, but other than that, it should be just fine.
I would setup a simple VM somewhere first, to answer your actual question. It's good practice to keep core services isolated on their own, dedicated instances. This is to speed up recovery time and minimize down time. Even on your home network, DNS and DHCP are services you do not want going down. It's always a pain when they do go down.
For the above reasons it's very nice to use dnsmasq, because DHCP + DNS integration is really sweet, and a full featured local DNS is gold.
OpenWRT comes with dnsmasq btw so if you have a dodgy router but it supports OpenWRT you may be able to breath new life into it.
Damn, I didn't realize the amount of hate for DHCP. Ive used an already configured system with a DHCP/DNS server set up and it was super easy to manage. Want to change or add a static IP? Edit the text file, add the MAC, reload.
I didn't know this wasn't reflective of the overall experience.
Meh, I didn't mean to hate on DHCP. It's just a service I have learned to keep running all by itself somewhere in a dark corner of my network. DNS and DHCP are just services that I don't like going down. Ever.
If only everyone was on IPv6, then everything could use SLAAC and worrying about IP assignment for client systems would be a thing of the past. IPv6 on a home LAN generally only uses DHCPv6 for configuring the DNS servers - client systems get IPs using SLAAC and learn their gateway using RAs (router advertisements).
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
Fewer Letters More Letters DNS Domain Name Service/System HTTP Hypertext Transfer Protocol, the Web HTTPS HTTP over SSL IP Internet Protocol NAS Network-Attached Storage PiHole Network-wide ad-blocker (DNS sinkhole) SATA Serial AT Attachment interface for mass storage SSD Solid State Drive mass storage SSL Secure Sockets Layer, for transparent encryption Unifi Ubiquiti WiFi hardware brand
[Thread #424 for this sub, first seen 11th Jan 2024, 09:35] [FAQ] [Full list] [Contact] [Source code]
New Lemmy Post: Should I use a dedicated DHCP/DNS server hardware (https://lemmy.world/post/10565049)
Tagging: #SelfHosted(Replying in the OP of this thread (NOT THIS BOT!) will appear as a comment in the lemmy discussion.)
I am a FOSS bot. Check my README: https://github.com/db0/lemmy-tagginator/blob/main/README.md