# Gentoo DHCP client not registered with DNS server

## scottsmith77

I have search the forums and the web about my problem. I am surprised that I can't find anything related to this.

I have a pc with gentoo on my work network, using DHCP (dhcpcd). Everything works fine, except that my hostname is not registered with the domain's (Windows, I think) DNS server.

In /etc/conf.d/net, I have added

```
iface_eth0="dhcp"

dhcpcd_eth0="-h ssmith2"

```

If I perform a name lookup from another host for 'ssmith2', I get:

```
C:\>nslookup ssmith2

Server:  server.domain.com

Address:  10.1.129.30

*** server.domain.com can't find ssmith2: Non-existent domain

```

Right now, I suspect that my DNS server requires a domain sent by the host to register it. The captured DHCP request from the Gentoo PC has these options:

```
Option 53: DHCP Message Type = DHCP Request

Option 57: Maximum DHCP Message Size = 548

Option 50: Requested IP Address = 10.1.130.43

Option 51: IP Address Lease Time = infinity

Option 55: Parameter Request List

   1 = Subnet Mask

   3 = Router

   6 = Domain Name Server

   12 = Host Name

   15 = Domain Name

   17 = Root Path

   23 = Default IP Time-to-Live

   28 = Broadcast Address

   29 = Perform Mask Discovery

   31 = Perform Router Discover

   33 = Static Route

   40 = Network Information Service Domain

   41 = Network Information Service Servers

   42 = Network Time Protocol Servers

Option 12: Host Name = "ssmith2"

Option 60: Vendor class identifier = "Linux 2.4.22 i686"

Option 61: Client identifier

   Hardware type: Ethernet

   Client hardware address: 00:50:da:c4:e7:be

End Option

```

For reference, my Windows PC that registers correctly, has these options:

```
Option 53: DHCP Message Type = DHCP Request

Option 61: Client identifier

   Hardware type: Ethernet

   Client hardware address: 00:c0:9f:1f:40:d6

Option 50: Requested IP Address = 10.1.130.112

Option 12: Host Name = "ssmith"

Option 81: Client Fully Qualified Domain Name (20 bytes) = "ssmith.domain.com"

Option 60: Vendor class identifier = "MSFT 5.0"

Option 55: Parameter Request List

   1 = Subnet Mask

   15 = Domain Name

   3 = Router

   6 = Domain Name Server

   44 = NetBIOS over TCP/IP Name Server

   46 = NetBIOS over TCP/IP Node Type

   47 = NetBIOS over TCP/IP Scope

   31 = Perform Router Discover

   33 = Static Route

   43 = Vendor-Specific Information

End Option

```

The thing that sticks out to me is that the Windows request has the FQDN in it. I did try to put "-h ssmith2.domain.com" in /etc/conf.d/net, but there was no difference in behavior.

Windows has a setting to "Register this connection's address in DNS". I seem to remember a setting in Red Hat to cause this to happen (but the interface conf files were completely different ). I can't find anything similar  in Gentoo.

Is there any way to force dhcpcd to send the FQDN? If hacking of dhcpcd code is required, any links/info on modifying the source (or ebuild?) would be appreciated!

Thanks in advance for any help that anyone can provide!

----------

## rmalolepszy

This would be my guess, it is however a guess.

Option 81: Client Fully Qualified Domain Name (20 bytes) = "ssmith.domain.com"

I have no idea how you would include that in your DHCP Requst.  Do you set your domainname at some point? 

```
echo "domainname.com" > /etc/dnsdomainname
```

```
/etc/init.d/domainname start
```

```
rc-update add domainname default?
```

----------

## Chris W

http://www.win2000mag.com/Articles/Print.cfm?Action=Print&ArticleID=7187 describes the Windows DHCP server's mechanisms for dynamically updating a DNS server.  Indeed Option 81 is required by the Windows DHCP server in order to attempt update of the DNS, although it also implies that it only does this for Windows clients which makes option 60 relevant also.

It's intruiging that the Windows machine assumes that it knows its domain (Option 81) before it is configured.  Presumably the server just trusts this when updating the DNS.

You could try the -S option to dhcpcd.  This triggers a second DHCP_DISCOVER after the DHCP_OFFER.  At this point the dhcpcd might use the domain information from the DHCP_OFFER in the second DISCOVER.

Edit: I just did a quick investigation with an XP machine using my Linux DHCP server.  The XP machine doesn't have a configured domainname at startup, and none is present in the REQUEST.  The ACK does contain this information.  There is an attempt to update my DNS server (denied) that does not come from the client.  Still looking...

----------

## RazBlack

i've run into a similar problem, not sure why my host name is not registered in w2k DNS server after DHCP request has been made,and successful

i can ping host names on the network that are w2k based, just not the linux machine...

----------

## Casper Gasper

Does reverse DNS work?  This is covered in Minasi's Mastering Windows 2000 Server which I don't have with me right now, but AFAIR on a W2K network the client is responsible for registering the forward DNS entry and the DHCP server does the reverse DNS entry.  

  I'm sure there must be a way of doing this, but I suppose if all else fails you can just give the machine a static dhcp lease and  add a DNS entry manually.

  hth,

 Casper.

----------

## RazBlack

reverse wasn't working either....

i ended up giving it a static IP and manually registering the workstation in W2K DNS... (argh)  I'ld hate to have to do this for hundreds of workstations.. what a pain.

I guess I got lazy since a quick fix aluded me.

----------

## nobspangle

There are two solutions to this problem.

Here is a bug which includes a patch that allows dhcpcd to use option 81.

There is a setting on the DHCP server that tells it to update DNS for client that don't provide option 81. The option is labeled something like "update DNS for older clients such as NT 4.0 and 98". I have that option set at work and any box grabbing an address through dhcp (inlcuding wyse terminals, printers etc.) get an entry in DNS.

----------

## overcast

how do i make use of this patch?

i've figured out as much as needing to use 'patch' to apply it to an existing file, but i have no idea what file that is.

----------

## robgrady

 *overcast wrote:*   

> how do i make use of this patch?
> 
> i've figured out as much as needing to use 'patch' to apply it to an existing file, but i have no idea what file that is.

 

I have the same problem.  I saw this other thread where the bug originated, but I don't think I applied the patch correctly since I saw no change in behavior.  Can anyone give a rundown on how to apply it?

----------

## robgrady

Okay, so it looks like I did apply the patch correctly.  I checked the output of

```
emerge dhcpcd-1.3.22_p4-r5.ebuild
```

and the following line quickly scrolled by

 *Quote:*   

>  * Applying dhcpcd-1.3.22_p4-r5-optionFQDN.diff.bz2 ...                                                     [ ok ]

 

So I guess I have that patch installed, but the I still get an unknown host error if I try to ping using my computer's hostname from another computer.

```
robgrady@computer2:==> ping computer1

ping: unknown host computer1

robgrady@computer2:==> ping computer1.domain.com

ping: unknown host computer1.domain.com

```

Are there any additional settings I have to use to enable the FQDN option?

----------

## robgrady

Starting to feel like a chatterbox...

So I reread the man page for dhcpcd after I re-emerged and found the -F option to enable FQDN and yelled "Eureka!" and scared everyone in the office.

 *Quote:*   

> SYNOPSIS
> 
>        dhcpcd      [-dknorzBCDFHNRSTY]      [-t <timeout>]     [-c <ExecFilePath>]     [-h <hostname>]
> 
>             [-i <vendorClassID>]  [-I <clientID>]  [-l <leasetime>]   [-s [ipaddr]]   [-F noneptrboth]
> ...

 

So I enabled the option, restarted dhcpcd and net.eth0 and got this:

```
robgrady@computer2:==> /etc/init.d/net.eth0 restart

 * Bringing eth0 down

 *   Releasing DHCP lease for eth0...                                                                       [ ok ]

 *   Stopping eth0...                                                                                       [ ok ]

 * Bringing eth0 up via DHCP...

DHCP Client Daemon v.1.3.22-pl4

Copyright (C) 1996 - 1997 Yoichi Hariguchi <yoichi@fore.com>

Copyright (C) January, 1998 Sergei Viznyuk <sv@phystech.com>

Location: http://www.phystech.com/download/

Usage: dhcpcd [-dknorzBCDHNRSTY] [-l leasetime] [-h hostname] [-t timeout]

       [-i vendorClassID] [-I ClientID] [-c filename] [-s [ipaddr]]

       [-w windowsize] [-L ConfigDir] [-G [gateway]] [interface]                                            [ !! ]

```

Notice in the Usage: line there is no mention of the -F option.  So... any ideas what to try?  I am guessing I should re-emerge something, but I don't know what.

----------

## overcast

 *robgrady wrote:*   

> Okay, so it looks like I did apply the patch correctly.

 

I'd appreciate it if you'd tell how you went about applying it.

----------

## robgrady

I tried just re-emerging dhcpcd the normal way (not ebuild) and saw that the dhc-fqdn USE flag is disabled by default.  So I did the following, with net-misc/dhcpcd dhc-fqdn in the package.use file:

```
computer1 root # emerge -aDv dhcpcd

These are the packages that I would merge, in order:

Calculating dependencies ...done!

[ebuild   R   ] net-misc/dhcpcd-1.3.22_p4-r5  -build -debug +dhc-fqdn -static 0 kB 

Total size of downloads: 0 kB

Do you want me to merge these packages? [Yes/No] yes

```

I can now successfuly connect to the network with the -F option enabled, but the the problem remains.  So I am at a loss now.  Any suggestions?  I will keep working on it and will update if I make progress.

----------

## overcast

I've noticed the use flag as well but I don't understand what I'm supposed to do with the patch file.

----------

## robgrady

I should preface this by saying that I have been using Gentoo for only a couple of months, so I am very much a noob.  But here goes...

I can't say this for sure, but I think the patch has been incorporated into the ebuild already.  So I think emerging dhcpcd with the dhc-fqdn flag enabled will take care of that.

```
# echo net-misc/dhcpcd dhc-fqdn >> /etc/portage/package.use

# emerge -aDv dhcpcd

```

Check to verify that the fqdn flag is enabled and go ahead with the emerge.  So I think that should take care of getting the FQDN functionality.  Now, I haven't gotten this to work yet, but I would think all you need to do after that is edit your /etc/conf.d/net file:

```
dhcpcd_eth0="-h computer_name -F both"
```

But as I said, it doesn't work yet.  And I don't know anything about the -F options of ptr and A, so I guessed both.  I have tried all combinations of hostname (hostname or hostname.domain.com) and -F options (none|ptr|both) with no success, so I am not sure if anything I have said is correct, but it makes sense to me.

----------

## robgrady

I checked my /var/log/debug file and this is what I get when I restart net.eth0:

```
Oct 29 10:36:36 localhost dhcpcd[15362]: Not Deleting Dhcp Cache

Oct 29 10:36:36 localhost dhcpcd[15362]: sending DHCP_RELEASE for xxx.xxx.xxx.202 to xxx.xxx.xxx.25

Oct 29 10:36:37 localhost kernel: bridge-eth0: disabling the bridge

Oct 29 10:36:37 localhost kernel: bridge-eth0: down

Oct 29 10:36:39 localhost kernel: bridge-eth0: enabling the bridge

Oct 29 10:36:39 localhost kernel: bridge-eth0: up

Oct 29 10:36:39 localhost dhcpcd[17324]: broadcasting DHCP_REQUEST for xxx.xxx.xxx.202

Oct 29 10:36:39 localhost dhcpcd[17324]: broadcastAddr option is missing in DHCP server response. Assuming xxx.xxx.xxx.255

Oct 29 10:36:39 localhost dhcpcd[17324]: dhcpIPaddrLeaseTime=1209600 in DHCP server response.

Oct 29 10:36:39 localhost dhcpcd[17324]: dhcpFQDNHostName is missing in DHCP server response.

Oct 29 10:36:39 localhost dhcpcd[17324]: DHCP_ACK received from  (xxx.xxx.xxx.25)

Oct 29 10:36:39 localhost dhcpcd[17324]: No resolv.conf.sv to restore

```

The "dhcpFQDNHostName is missing in DHCP server response." is what caught my eye, anyone know what that might mean?

Edit:  Okay, I should say that I am guessing the DHCP server response does not include the hostname, what I mean is what can I do about it?

----------

## robgrady

I just checked on another computer here and you do need to have the patch to enable FQDN.  But I think if you can see the dhc-fqdn flag, then you have the patch installed.  You just need to make sure you have that flag enabled when you emerge dhcpcd after installing the patch.

----------

## robgrady

overcast, how far have you gotten with this problem?  Do you have the patch installed?  If so, has it helped anything?

----------

## robgrady

Just a quick update, it looks like this might be something on the server end for me. I just spoke with our tech support and there is some sort of master list that my computer needs to be on in order to get registered on the DNS server. I will let you know if this turns out to be the problem for me.

----------

## kevquinn

It's common for well-configured DHCP servers to have a list of MAC addresses (the ethernet hardware address) to which they'll assign IP addresses - this is probably what your tech support is talking about.  However, if you're dual-booting from the same machine, this is unlikely to be the issue, as the MAC address is hard-wired in the ethernet adapter.

BTW "dhcpFQDNHostName is missing in DHCP server response" means that the server didn't echo the option 81 code in its response - indicating that the server didn't "see" it; perhaps because it was malformed, or not permitted for some reason.

The "dhc-fqdn" use flag (that I invented unilaterally) is for testing - to make it easy to back out the changes in case something breaks.  Before it goes stable, I intend to remove the use flag.

I can't look into the various bits raised above properly right now; I've commented the issues raised here on my bug to remind me to look into them.

----------

## robgrady

Great, thanks for the reply.  That is what I expected the error message meant.  I suspect that it is related to not being on the list of allowed addresses.

 *kevquinn wrote:*   

> The "dhc-fqdn" use flag (that I invented unilaterally) is for testing - to make it easy to back out the changes in case something breaks. Before it goes stable, I intend to remove the use flag.

 

Does this mean that your patch is being incorporated into the next dhcpcd release?

----------

## kevquinn

 *robgrady wrote:*   

> Does this mean that your patch is being incorporated into the next dhcpcd release?

 

I have no idea - I haven't had any response from the package maintainer(s)  :Sad:   Presumably marking the bug as an "enhancement" means it drops to the bottom of the dev's priority list - it's only been in bugzilla for a couple of months.

----------

## saurion

 *robgrady wrote:*   

> I should preface this by saying that I have been using Gentoo for only a couple of months, so I am very much a noob.  But here goes...
> 
> I can't say this for sure, but I think the patch has been incorporated into the ebuild already.  So I think emerging dhcpcd with the dhc-fqdn flag enabled will take care of that.
> 
> ```
> ...

 

I suggest to change the line in /etc/conf.d/net

dhcpcd_ethX="..."

to 

dhcpcd_ethX="-h `hostname`"

that way it automatically and i think correctly takes the right hostname.

My humble oppinion. Thanks.

----------

## stevit

Any news on this one yet?

I have the same problem, haveing "-h" in for quite a while. Everytime I receive a new IP

from the DHCP-Server I get the old hostname from the last user who had that IP.  :Sad: 

Even appling that patch does not work for me. I even tried the full hostname with -h.

Nothing changed at all.

here is what I have in my net file:

```

iface_eth0="dhcp"

dhcpcd_eth0="-h belphegor -F both"

```

----------

## robgrady

We are having discussions with our tech support at work about other issues before we can continue with this problem.  So for me, there has been no change.  My suggestion would be to contact whoever handles the DHCP and DNS servers and make sure that it isn't a problem on their end.  I am still keeping an eye on this, and other related threads, and will update when I have a resolution.

----------

## stevit

wrote an mail to support and mentioned the ideas that came up here within the forum. Now I have to wait.

Hope there will be an solution for this. I hate it to be online with wrong hostnames.

Makes sshing my machine quite frustrating. -.-

----------

## kevquinn

I've updated the patches for -r5 and -r7, which are now the only current ebuilds for net-misc/dhcpcd.  As before see https://bugs.gentoo.org/show_bug.cgi?id=64307

Changes are to fix the syntax error text (trivial), and to re-order the request so that option 81 appears at the end (i.e. so options are listed in the request in ascending order).  This may or may not help with robgrady's "dhcpFQDNHostName is missing in DHCP server response." thing.

For those wishing to try the patch, here's a summary of what to do:

1) Copy net-misc/dhcpcd from /usr/portage to your portage override directory - set this up if you haven't already; I suggest: 

```
mkdir /var/portage
```

 Add 

```
PORTDIR_OVERLAY="/var/portage"
```

to /etc/make.conf then

```
mkdir /var/portage/net-misc

cp -r /usr/portage/net-misc/dhcpcd /var/portage/net-misc
```

2) Download the main patch file in its compressed form and save to /usr/portage/distfiles

3) Download the ebuild patches, and apply them to the ebuilds in the portage overlay directory 

```
cd /var/portage/net-misc/dhcpcd

patch < ~/downloads/r5-ebuild.patch
```

4) Recalculate the digests (otherwise portage refuses the build as the files are not the same as those in Gentoo portage) 

```
ebuild /var/portage/net-misc/dhcpcd/dhcpcd-1.3.22_p4-r5.ebuild digest
```

5) add 'dhc-fqdn' use flag for net-misc/dhcpcd, by adding the following line to /etc/portage/package.use (create the file if it doesn't already exist): 

```
net-misc/dhcpcd dhc-fqdn
```

6) emerge dhcpcd

7) Do "/sbin/dhcpcd -h" and check the syntax text that is printed contains '[-F none|ptr|both]" - if it's not there, something went wrong above.

8) Set the appropriate options in /etc/conf.d/net - for example, I have: 

```
dhcpcd_eth0="-D -h `/bin/hostname` -F both -G"
```

 but obviously read the man page etc and work out what you need.

Good luck!

----------

## UberLord

baselayout-1.11.7-r2 supports dhcpcd, dhclient, udhcpc and pump for DHCP clients.

dhclient supports the fqdn option out-of-the-box

@kevquinn, the DHCP spec requires that the fqdn is sent in DNS-style binary

   encoding

http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-07.txt

The patch does not seem to allow for this.

I have a patch for udhcpc todo the same thing, but mines ASCII as well - what we need is to accept ASCII and convert it.

----------

## stevit

Mhhh.. I tried the first patch from kevquinn, but it hasn't worked for me.

After emerging dhcpcd with the new patch the dhcp listed me as wanted.

I also noticed that dhcpcd was started using the -h option two times.

(/sbin/dhcpcd -h <hostname> -h <hostname> eth0)

My /etc/conf.d/net included an  dhcpcd_eth0="-h <hostname>" - line.

Seems as if that is not necessary. I deleted that line cause dhcpcd sends the -h option anyway.

----------

## kevquinn

 *UberLord wrote:*   

> DHCP spec requires that the fqdn is sent in DNS-style binary encoding

 

Well, use of ASCII is currently marked "deprecated" rather than "obsolete", which means it's still supported on existing systems  :Smile:   I didn't bother with the "compressed" DNS encoding as nothing else in dhcpcd uses it (i.e. it all needs writing!).  I figured most (if not all) dhcp servers will in practice support ASCII encoding for a few years yet since this is what a lot of existing clients probably use (at least the older ones, perhaps Windows 98, Windows NT 4.0).  I must admit that once I reached the "works for me" stage, I lost impetus  :Wink:   Having said that, it shouldn't be difficult...

(for reference RFC1035 section 4.1.4 defines the DNS compressed text scheme)

----------

## egberts

How can we help push this fix along?

I'm convinced that this fix is perfect.

----------

## UgolinoII

I can confirm these steps worked perfectly for me also

----------

## zoltix

I hava the similar probl

thank

----------

## zoltix

I hava the similar probl

thank

----------

## wnreynolds

Had same problem, fixed before I discovered this thread and new version of dhcpcd. Configure the following shell script and put in  var/lib/dhcpc/dhcpcd.exe (make sure it is executable). Client must have bind-tools merged. Naturally, dns server must allow updates on the domain client is in and in the ptr domain (put  "allow-update { any; }; "  for each  domain in named.conf). In principle this could work with a trusted key, but that is a hack for another day.....

```

#!/bin/sh

# Configure these as necessary

PTR_DOMAIN="1.168.192.in-addr.arpa"

# n.b. note trailing dot

IP_ROOT="192.168.1."

DNS_SERVER="192.168.1.201"

# End configure

# This needs the trailing dot

HOSTNAME="$(/bin/hostname -f)."

NSUPDATE="/usr/bin/nsupdate"

# File with all the goodies in it.

VARFILE=$1

# "up" or "down"

UP=$2

. $VARFILE

# This will define vars that look like:

#IPADDR=192.168.1.111

#NETMASK=255.255.255.0

#NETWORK=192.168.1.0

#BROADCAST=192.168.1.255

#GATEWAY=192.168.1.1

#DOMAIN='mydomain.tld'

#DNS=192.168.1.201

#DHCPSID=192.168.1.1

#DHCPGIADDR=0.0.0.0

#DHCPSIADDR=192.168.1.1

#DHCPCHADDR=FF:FF:FF:FF:FF:FF

#DHCPSHADDR=FF:FF:FF:FF:FF:FF

#DHCPSNAME=''

#LEASETIME=86400

#RENEWALTIME=43200

#REBINDTIME=75600

#INTERFACE='eth0'

#CLASSID='Linux 2.6.11-gentoo-r9 i686'

#CLIENTID=FF:FF:FF:FF:FF:FF:FF

NODE="${IPADDR#${IP_ROOT}}.${PTR_DOMAIN}"

if [ "$UP" = "up" ]; then

  # add the A record

  $NSUPDATE<<-END_OF_UP_A_UPDATE

    server ${DNS_SERVER}

    zone ${DOMAIN}

    update delete ${HOSTNAME}

    update add ${HOSTNAME} 86400 IN A ${IPADDR}

    send

END_OF_UP_A_UPDATE

  # add the PTR record

  $NSUPDATE<<-END_OF_UP_PTR_UPDATE

    server ${DNS_SERVER}

    zone ${PTR_DOMAIN}

    update delete ${NODE}

    update add ${NODE} 86400 IN PTR ${HOSTNAME}

    send

END_OF_UP_PTR_UPDATE

else

  # delete the A record

  $NSUPDATE<<-END_OF_DOWN_A_UPDATE

    server ${DNS_SERVER}

    zone ${DOMAIN}

    update delete ${HOSTNAME}

    send

END_OF_DOWN_A_UPDATE

  # delete the PTR record

  $NSUPDATE<<-END_OF_DOWN_PTR_UPDATE

    server ${DNS_SERVER}

    zone ${PTR_DOMAIN}

    update delete ${NODE}

    send

END_OF_DOWN_PTR_UPDATE

fi

```

----------

## UberLord

Heh - that won't work with baselayout-1.12.x as we hijack the script variable!

I'll implement a "hook" call or patch dhcpcd to allow more than one script - but not today

----------

## kevquinn

Just to note for the record, it's often the case that only the dhcp server has authority to update the dns in which case client updates via nsupdate will fail.  Obviously in practice there are many sloppily configured networks that allow clients to do any dns update they wish...

----------

## UberLord

Good point. I can always patch the hook or extra script when someone moans enough on bugs  :Twisted Evil: 

----------

