dhcpcd-discuss

Thanks for the response Roy.

>> From which point are you coming from - the host dervies it's hostname
from DHCP or the host instructs the DHCP server it's hostname?
>>For the former, dhcpcd only sets the hostname using a strict set of rules
based on what the current hostname is and the if it matches the last
hostname sent by DHCP.

The host is instructing the DHCP server my hostname is 'KensDevice' via
Option 81.
Then the server responds to the host via option 81 in the Offer -  your
FQDN is actually  dhcp-10-0-0-12.mycompany.com
In this situation I have my own code that honors this change and sets the
hostname of the device to 'dhcp-10-0-2'.
This is what the server updated in DNS.  I can use it to ping/reach the
device but not the name I first reported 'KensDevice'.

>>It sounds like your node already knows it's hostname, so this is just for
getting the DHCP server to update DNS yes?

Correct .. the reason I am using the 'fqdn=both' option in dhcpcd is so it
will report back via the flags if it is willing to do the update or not.
If it says it will not do the update I have another package that will
attempt to do its own DNS update.

I agree dhcpcd is correctly following the RFC by not sending both options.
My goal in asking the question was to see if this is a issue others have
seen.   Perhaps my server is just misconfigured.
At the moment I have not got past my IT bureaucracy to find out exactly
what type of server software is in use.

This conversation I found using this 'infoblox' software is the closest I
have found to what I am experiencing.
https://community.infoblox.com/t5/DNS-DHCP-IPAM/Generate-Hostname-if-not-Sent-by-Client/td-p/5061

They discuss how the server conf file uses this instruction to pick the
auto generated name.


*ddns-hostname = pick ( option fqdn.hostname,option
host-name,concat ("dhcp-",binary-to-ascii(10,8,"-", leased-address)))*


It would be nice if they had similar instructions that indicate how they
decide if the host name was omitted by the client or not.

Ken



On Sat, Feb 17, 2018 at 3:53 PM, Roy Marples <roy@xxxxxxxxxxxx> wrote:

> Hi Kenny
>
> On 14/02/2018 15:52, Kenny Napier wrote:
>
>>     I found a old discussion that explains well that the RFC 4702 says
>> you must not send both option 12 and option 81 since this is redundant
>> data.   The main part of this discussion was around the fact that the
>> client does not know if the server supports this option or not.
>>
>>   I am running into servers that seem to support option 81 but the lack
>> of option 12 is the key factor in the server making the decision to change
>> my host name with a server generated name.
>>
>
> From which point are you coming from - the host dervies it's hostname from
> DHCP or the host instructs the DHCP server it's hostname?
>
> For the former, dhcpcd only sets the hostname using a strict set of rules
> based on what the current hostname is and the if it matches the last
> hostname sent by DHCP.
>
> This new name is communicated back in the Option 81 response 'Offer' and
>> 'ACK' packets.
>>
>> If I change dhcpcd to always include option 12 the sever does not
>> auto-generate
>> a new hostname and correctly builds the expected option 81 responses that
>> tell us if it will
>> update the dns records or not.
>>
>> I have seen some servers contain a configuration option that says
>> auto-generate a host name if the client does not provide one.   So it
>> appears these servers are treating the absence of option 12 as lacking a
>> host name even when they seem to have some knowledge of option 81 that has
>> the host name included.
>>
>> I sampled a few other dhcp clients and found windows 10 is working in
>> this manner.
>> It will -not- send option 81 in the discover packet - only option 12.
>> It will then send both in the request packet.
>> It looks like someone was trying to work around the same server behavior.
>>
>>   I am curious if someone has ran into this issue before or have any
>> thoughts on the best way to be compatible.   It feels like a fully
>> complaint server would just ignore duplicate data from option 12.
>>   A  comment in the code around this suggests including both caused a
>> issue in the past for windows.
>>
>>                  /*
>>                   * RFC4702 3.1 States that if we send the Client FQDN
>> option
>>                   * then we MUST NOT also send the Host Name option.
>>                   * Technically we could, but that is not RFC conformant
>> and
>>                   * also seems to break some DHCP server implemetations
>> such as
>>                   * Windows. On the other hand, ISC dhcpd is just as non
>> RFC
>>                   * conformant by not accepting a partially qualified
>> FQDN.
>>                   */
>>
>
> It sounds like your node already knows it's hostname, so this is just for
> getting the DHCP server to update DNS yes?
>
> Regardless, the comment is correct and the RFC is quiet explicit. dhcpcd
> is correct on this matter and will not change unless the RFC does.
>
> Luckily dhcpcd has several options, if you set `fqdn disable` in
> dhcpcd.conf then it only sends option 12 which should work around these
> faulty DHCP servers as you describe.
>
>    I am using 6.11.5 at the moment.
>>
>
> dhcpcd-7 is no different here.
>
> Roy
>