dhcpcd-discuss

>>Now, the problem might stem from dhcpcd encoding the FQDN hostname as a
DNS label and NOT as a text string. This is because text strings where
supported in early drafts, but >>deprecated before it became an actual RFC.
Some ISC dhcpd server versions do not like DNS label encoding in the FQDN
hostname.
>>However, the encoding bit is set correcting in dhcpcd and the supporting
server HAS to support it as per the RFC.

You nailed it.  This is the issue.   I can change dhcpcd to use
ascii-encoding and it works.
It turns out we are using InfoBlox as the dhcp server.
My IT department is suppose to be logging a issue with this company to see
if they will fix it.
They are a big player in the enterprise market so hopefully they care about
following RFC's.

Thanks for the help.
I hope this thread helps others that might run into this issue.



On Tue, Feb 20, 2018 at 7:00 AM, Roy Marples <roy@xxxxxxxxxxxx> wrote:

> Hi Kenny
>
> On 19/02/2018 04:43, Kenny Napier wrote:
>
>> 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 <
>> http://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.
>>
>
> What package do you use? Maybe it's something I could include as a generic
> hook in dhcpcd.
>
> Maybe this package could update DNS to add KensDevice as an alias to the A
> record to work around the buggy DHCP server?
>
> 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.
>>
>
> No-one has reported this behavior before.
> Because the server supports FQDN I would guess the error is on the DHCP
> server.
>
> **
>> 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-Hos
>> tname-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.
>>
>
> My understanding from the above config statement is that the hostname
> would be one of three things from that statement, picking the first non
> blank entry - so FQDN option hostname part, hostname option, string based
> on leased address.
>
> Now, the problem might stem from dhcpcd encoding the FQDN hostname as a
> DNS label and NOT as a text string. This is because text strings where
> supported in early drafts, but deprecated before it became an actual RFC.
> Some ISC dhcpd server versions do not like DNS label encoding in the FQDN
> hostname.
> However, the encoding bit is set correcting in dhcpcd and the supporting
> server HAS to support it as per the RFC.
>
> Roy
>