On Sat, 2022-04-23 at 10:19 -0400, Sam Varshavchik wrote: > ome searching around found that people noticed this ten years ago, > and it's something dynamic dns-related. > > There was no configuration option to turn it off when people were > talking about it. There was only a compile-time option. I combed > through the man page. "ddns-updates off" sounded like a promising > candidate, I put it into dhcpd.conf, restarted dhcpd, and I don't see > dhcpd listening on some high port anymore. ddns-updates on/off should be about outgoing traffic. When your DHCP server is assigning addresses to clients it *can*, also, tell your DNS server to update your DNS records to include data for the client it just gave an IP to. i.e. The DHCP server is controlling the DNS server If you don't do that, you can turn off that feature with no side- effects. If you do use that feature, then more research is needed. There also is supposed to be some way for DHCP servers on a network to co-operate with each other. That's a different function, and I cannot remember the proper name for it. It's also something people rarely do, and it may not be possible to make two completely different DHCP servers co-operate (e.g. the basic one in your router may have very little configuration options other than being on or off, and the IP range to use). There's also "failover" options to do with a backup DHCP server (this isn't dual co-operating DHCP servers, it's a main one and a backup to takeover for if the main fails, or fails to respond in a timely manner). A somewhat different thing than simply splitting workloads. > This doesn't really matter for Fedora, firewalld will block this. But > it's awesome how this is enabled by default, and it's listening on > all IP addresses, and not just the DHCP subnet. Well, yes and no. Services should be configured appropriately. A firewall is an additional thing. Nothing should be wide open and depend on something else for protection. For what it's worth, the normal listening port for the DHCP server is port 67 UDP, and appears to listen to all interfaces. It pretty much has to, as the queries come from clients that may not already be a part of the network. Here's the output from this netstat command, and I've pasted the column headers back in so it's a bit more coherent: [root@server ~]$ netstat -uantoevp|grep dhcp Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name Timer udp 0 0 0.0.0.0:67 0.0.0.0:* 0 27919 1191/dhcpd off (0.00/0/0) udp 0 0 0.0.0.0:65390 0.0.0.0:* 177 322881 1191/dhcpd off (0.00/0/0) udp6 0 0 :::4717 :::* 177 322882 1191/dhcpd off (0.00/0/0) There's a local-port dhcpd.conf option that might include more than port 67 by default. If I put the option in, and give it a specific port, and only one port, and restart my DHCP server, I get the results I predict. I inserted this into my dhcpd.conf file: local-port 67; Now, it's only listening on the expected port: [root@server ~]$ netstat -uantoevp|grep dhcp udp 0 0 0.0.0.0:67 0.0.0.0:* 0 4866355 22730/dhcpd off (0.00/0/0) So, try setting a local-port parameter in your server, and see if you get the same results. (Yes, I know my netstat command had more options than it needed for this occasion, I just threw in all the ones I often use, as force of habit.) I don't know why mine was listening on 65390 as well. It's now shut off and I'll see if it breaks anything. Nor do I know why UPD6 listens on 4717. I don't use IPv6, I have no configurations set for it. And I'm not sure why IPv6 would need to use a different port number, though it could just be a simplistic approach for keeping it separate. NB: If you're also supporting BOOTP, it may be listening on port 68, as well. -- uname -rsvp Linux 5.11.22-100.fc32.x86_64 #1 SMP Wed May 19 18:58:25 UTC 2021 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure