Re: Pro tip: "ddns-updates off" in dhcpd.conf

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux