←back to thread

220 points speckx | 10 comments | | HN request time: 0.405s | source | bottom
1. LeoPanthera ◴[] No.45145684[source]
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.

replies(5): >>45145833 #>>45146265 #>>45146306 #>>45146581 #>>45147614 #
2. gillparryz ◴[] No.45145833[source]
I wish, it re-read the configuration upon SIGHUP, but doesn't.

https://manned.org/man/dnsmasq#head6

replies(2): >>45146539 #>>45146576 #
3. kwk1 ◴[] No.45146265[source]
> 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

Android Public Tracker - Support for DHCPv6 (RFC 3315) - Status: wontfix

4. latchkey ◴[] No.45146306[source]
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.
replies(1): >>45146487 #
5. LeoPanthera ◴[] No.45146487[source]
I suspect my home network will not get close to that limit.

Probably.

6. jclulow ◴[] No.45146539[source]
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.
replies(1): >>45146582 #
7. LeoPanthera ◴[] No.45146576[source]
Oh huh. I was convinced that it did. I stand corrected.
8. jimmaswell ◴[] No.45146581[source]
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?
9. gillparryz ◴[] No.45146582{3}[source]
That is fair for a home-lab setup.
10. gucci-on-fleek ◴[] No.45147614[source]
> 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#:~:t...