dhclient does not register hostname to dynamic DNS (AD)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
isc-dhcp (Ubuntu) |
Fix Released
|
Medium
|
Stéphane Graber | ||
Quantal |
Fix Released
|
Medium
|
Stéphane Graber | ||
Raring |
Fix Released
|
Medium
|
Stéphane Graber |
Bug Description
== Rationale ==
Setting both fqdn.fqdn and host-name isn't quite supported. Various RFCs disagree on exactly what should be allowed and is further complicated by dhclient doing both dhcpv4 and dhcpv6.
This change simply reverts to the pre-12.10 situation.
== Test case ==
1) Update to new isc-dhcp-client
2) Get a new lease on a network using Windows DHCP server
3) Confirm that DNS was updated.
== Regression potential ==
There may be a regression for people expecting fqdn.fqdn to be set on DHCPv6, this should affect a very small part of our users (if any) and our previous fqdn.fqdn value wasn't technically valid anyway (wasn't a fqdn).
--- original bug report ---
This is not working in quantal (4.2.4-1ubuntu10) and raring (4.2.4-3ubuntu1), but is working in precise (4.1.ESV-
A patch fixed an issue for bug 991360 where dhclient.conf was amended to include:
send fqdn.fqdn = gethostname();
This causes failures when the client tries to register was some DHCP servers (for example Windows AD DDNS servers).
By commenting out this line and restarting the client, the client can then register with this type of DHCP server.
However, this is needed to ensure dhcpv6 works.
Related branches
description: | updated |
Changed in isc-dhcp (Ubuntu Quantal): | |
status: | Confirmed → Triaged |
status: | Triaged → In Progress |
tags: | added: cts-client-review |
tags: | removed: cts-client-review |
Well, starting with quantal we are using gethostname() as you can see in the default dhclient.conf:
stgraber@ castiana: ~/Desktop/ isc/quantal$ grep gethost isc-dhcp- 4.2.4/debian/ dhclient. conf
send host-name = gethostname();
send fqdn.fqdn = gethostname();
So, the problem appears to be that Windows gets confused when both fields are set, sadly, not setting fqdn.fqdn will make dhcpv6 fail miserably, so unless there's an easy to have fqdn.fqdn only be set when doing dhcpv6, I still prefer breaking DNS for some Windows DHCP than breaking for 100% of the dhcpv6 implementations.