Created attachment 493210 [details] patch to fix the issue see https://bugzilla.redhat.com/show_bug.cgi?id=694758 Description of problem: dhclient sends FQDN as a host name in DHCP request. this is a violation of the spec and makes ddns brake down Version-Release number of selected component (if applicable): dhclient-4.2.0-6.fc14.x86_64 How reproducible: always Steps to Reproduce: 0. I assume that a machine is installed with a FQDN, configured in /etc/sysconfig/network: HOSTNAME=stinkpad.example.com 1. configure an interface to use dhcp, example: TYPE=Ethernet BOOTPROTO=dhcp ONBOOT=yes DEFROUTE=yes IPV4_FAILURE_FATAL=yes IPV6INIT=yes IPV6_AUTOCONF=no IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no PEERDNS=yes PEERROUTES=yes 2. on a different machine on the same LAN segment, start wireshark and configure its filter as 'bootp.dhcp == 1' 3. start a live trace in wireshark 4. bring up the interface on the first machine Actual results: dhclient sends a FQDN as the hostname Expected results: either one of: 1 dhclient sends a FQDN as the FQDN option 2 dhclient sends the (scrubbed) hostname as the hostname Additional info: the configured hostname must either be scrubbed or when it is a FQDN then a different dhcp req option must be used (FQDN) in pseudo code: 1. if HOSTNAME is FQDN then make dhclient use FQDN request option else make dhclient use host name request option 2. if HOSTNAME is FQDN then scrubbed = take first part of HOSTNAME else scrubbed = HOSTNAME fi make dhclient use host name request option with value 'scrubbed' according to the spec, 1 is more correct because then the client can decide to update its own DNS if it is not in its own domain, also the DNS then only sets up a PTR record instead of an A record. see man dhcpd.conf
see also https://bugzilla.redhat.com/show_bug.cgi?id=697877
As stated in the original bug, I don't think initscripts needs changed to always send something, as you are suggesting - it's a configuration parameter for the admin if needed.
Then how about the decision to change NM to _always_ send a hostname??? (even though it now may send a fqdn, which my original bug report is about) Not fixing initscripts would make things inconsistent. So for consistency's sake either fix initscripts or revert the NM change. My patch makes things consistent and is a trivial patch. I __very___ strongly believe in consistency :-) So please reopen the bug
It changes behavior that's existed for 5-10 years; I don't think that's really appropriate. Why would you need to send the hostname each time?
See the original bugreport: DDNS The change in behavior the _is_ acceptable for NM but not for initscripts? Besides, sending the hostname each time is very much harmless.
Created attachment 493255 [details] alternate patch Here's a better solution - shorter, less complicated, faster, and doesn't somehow tie the user into requiring that a particular DHCP server support a different option based on how they define their own local hostname. Does this work for you?
Created attachment 493267 [details] new patch Actually, Both our patches wouldn't work, I checked them both. There are 2 parts to this patch: 1- when the DHCP_HOSTNAME is _not_ set then use HOSTNAME (first 'if' block added) 2- when DHCP_HOSTNAME is a FQDN then use the -F dhclient option, otherwise use the -H dhclient option. (second 'if' block added) The use of the -F and -H options can be found in 'man dhclient', which is quite specific about the -H option: '... The host-name string only contains the client's hostname prefix, ...' This new patch fixes the currently wrong behavior in case DHCP_HOSTNAME is a FQDN (2). I think this part is a _must-apply_. The new patch adds functionality such that NM and initscripts are consistent (1). I think this part is a _realy-really-want-it-applied_ :-) (1) and (2) are independent can be applied separately.
If DHCP_HOSTNAME is a FQDN, that's administrator error, it doesn't need handled.
it isn't handled other than: 'gee, the administrator configured a FQDN, so I guess he'll really want that. let's instruct dhclient that it has to send a FQDN'
bill, you suddenly became very quiet. any info on what you're going to do?
I stand by comment #6. Better to consistently exercise a single codepath rather than having client (mis)configuration exercise entirely different parts.
I don't quite understand the resistance against what I propose. How's not doing things according to the spec better than what I propose? I see that the -F exercises a different codepath, but come on, realistically, how different are they really? By only every using the -H option you're effectively closing the door on doing things correctly. If we change things now we have the opportunity to do it right... We know the right solution. Why not do it? Also, in your patch you're still allowing out-of-spec behaviour: if DHCP_HOSTNAME is defined as a FQDN then the behaviour is wrong: a FQDN name is sent under the -H option.
(In reply to comment #12) > I don't quite understand the resistance against what I propose. > How's not doing things according to the spec better than what I propose? > I see that the -F exercises a different codepath, but come on, realistically, > how different are they really? > > By only every using the -H option you're effectively closing the door on doing > things correctly. How so? We would always send the short hostname.
(That's always send the short hostname if DHCP_HOSTNAME is specified.)
> Also, in your patch you're still allowing out-of-spec behaviour: if > DHCP_HOSTNAME is defined as a FQDN then the behaviour is wrong: a FQDN name is > sent under the -H option. Bill, look at '-H ${DHCP_HOSTNAME:-${HOSTNAME%%.*}}': * this sends the configured DHCP_HOSTNAME is-as when it is defined; so when it is configured as a FQDN then a FQDN is sent under the -H option, which violates the spec. * this sends the short hostname when DHCP_HOSTNAME is not defined, which is correct behaviour
Should be fixed with a simple: [ -n "$DHCP_HOSTNAME" ] && DHCP_HOSTNAME=${DHCP_HOSTNAME%%.*} in expand_config().
ok. acceptable ;-) The only thing left then is that we're blocking the FQDN (-F) scenario but I'm getting the feeling you're not eager to solve that one. So combining comment 16 with your patch is fine with me then. Could you do this for F14, F15, RHEL 5 and RHEL 6 please?
Hi Bill, any progress on this bug? NM pushed out an update for the issue and solved their bug for it (https://bugzilla.redhat.com/show_bug.cgi?id=694758). If initscripts could also update then both initscripts and NM behaviour is again consistent. thanks!
Fixed in git for rawhide, may make a F-15 update. http://git.fedorahosted.org/git?p=initscripts.git;a=commitdiff;h=60ddb21fcdfb0594a35978aa0b04af4527c46d6e
thanks! a F15 update would be much appreciated. :-)