4 ms·

Because ISC DHCP was discontinued, I switched to dnsmasq, which also caused me to switch my home DNS server from unbound to dnsmasq so that local dhcp hostname

Because ISC DHCP was discontinued, I switched to dnsmasq, which also caused me to switch my home DNS server from unbound to dnsmasq so that local dhcp hostname registration would continue to work. I always thought of dnsmasq as a bit of a toy, but I have to admit I've been impressed. So far it's worked flawlessly, and I'm especially impressed that you can reconfigure it without restarting the process. My only complaint is not specific to dnsmasq, and that's with ipv6. Devices assign themselves essentially random addresses, so it's impossible to correlate DNS lookups from those addresses with what actual device is making the request. The obvious solution to this, a fully managed DHCP6 setup, does not seem to be well supported by dnsmasq, but it wouldn't matter even if it was because so many devices don't support DHCP6, only slaac. So the whole thing is a bit of a mess.

gillparryz 1y ago
I wish, it re-read the configuration upon SIGHUP, but doesn't. https://manned.org/man/dnsmasq#head6 https://manned.org/man/dnsmasq#head6
- LeoPanthera 1y ago
  Oh huh. I was convinced that it did. I stand corrected.
- jclulow 1y ago
  DNS & DHCP are generally short lived transactions that are very easy to restart and retry, so as long as it restarts very quickly that seems like a reasonable trade off in implementation complexity to be honest.
  - gillparryz 1y ago
    That is fair for a home-lab setup.
kwk1 1y ago
> The obvious solution to this, a fully managed DHCP6 setup, does not seem to be well supported by dnsmasq, but it wouldn't matter even if it was because so many devices don't support DHCP6, only slaac. Relevant reading: https://issuetracker.google.com/issues/36949085 https://issuetracker.google.com/issues/36949085 Android Public Tracker - Support for DHCPv6 (RFC 3315) - Status: wontfix
latchkey 1y ago
We found out the scaling issues with dnsmasq when we had about 20k blade servers hitting it for dhcp. UDP traffic caused it to fall over on a fairly beefy server. Switching to Kea solved the issue.
- LeoPanthera 1y ago
  I suspect my home network will not get close to that limit. Probably.
jimmaswell 1y ago
I just made my own router in the last month for the first time and chose isc-dhcpd. My understanding is it would be more accurate to call the software "finished" - the codebase is very mature and the DHCP protocol isn't exactly a moving target. It does everything I need in a LAN DHCP server, and it integrates very easily with BIND. Given I expect to never need to update this thing besides basic security updates to FreeBSD/pf, is there a strong reason for switching?
gucci-on-fleek 1y ago
> The obvious solution to this, a fully managed DHCP6 setup, does not seem to be well supported by dnsmasq I'm using dnsmasq for DHCPv6 and it seems to work fairly well for me. "dig <device-name> AAAA" returns the correct addresses for my DHCPv6-supporting devices. > but it wouldn't matter even if it was because so many devices don't support DHCP6, only slaac. This should theoretically work with "--dhcp-range=slaac,ra-names" [0], but it doesn't seem to actually do anything for me. [0]: https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html#:~:text=ra-names,-enables https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html#:~:t...

gillparryz 1y ago

I wish, it re-read the configuration upon SIGHUP, but doesn't. https://manned.org/man/dnsmasq#head6 https://manned.org/man/dnsmasq#head6

LeoPanthera 1y ago
Oh huh. I was convinced that it did. I stand corrected.
jclulow 1y ago
DNS & DHCP are generally short lived transactions that are very easy to restart and retry, so as long as it restarts very quickly that seems like a reasonable trade off in implementation complexity to be honest.
- gillparryz 1y ago
  That is fair for a home-lab setup.

kwk1 1y ago

> The obvious solution to this, a fully managed DHCP6 setup, does not seem to be well supported by dnsmasq, but it wouldn't matter even if it was because so many devices don't support DHCP6, only slaac. Relevant reading: https://issuetracker.google.com/issues/36949085 https://issuetracker.google.com/issues/36949085 Android Public Tracker - Support for DHCPv6 (RFC 3315) - Status: wontfix

latchkey 1y ago

We found out the scaling issues with dnsmasq when we had about 20k blade servers hitting it for dhcp. UDP traffic caused it to fall over on a fairly beefy server. Switching to Kea solved the issue.

LeoPanthera 1y ago
I suspect my home network will not get close to that limit. Probably.

jimmaswell 1y ago

I just made my own router in the last month for the first time and chose isc-dhcpd. My understanding is it would be more accurate to call the software "finished" - the codebase is very mature and the DHCP protocol isn't exactly a moving target. It does everything I need in a LAN DHCP server, and it integrates very easily with BIND. Given I expect to never need to update this thing besides basic security updates to FreeBSD/pf, is there a strong reason for switching?

gucci-on-fleek 1y ago

> The obvious solution to this, a fully managed DHCP6 setup, does not seem to be well supported by dnsmasq I'm using dnsmasq for DHCPv6 and it seems to work fairly well for me. "dig <device-name> AAAA" returns the correct addresses for my DHCPv6-supporting devices. > but it wouldn't matter even if it was because so many devices don't support DHCP6, only slaac. This should theoretically work with "--dhcp-range=slaac,ra-names" [0], but it doesn't seem to actually do anything for me. [0]: https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html#:~:text=ra-names,-enables https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html#:~:t...